本文目录导读：
你提到的“Java案例”具体是哪一个，我目前看不到，数据统计的差距”在Java项目里通常有几类典型来源，可以先按这个框架去判断：
先定位差距的类型
| 差距类型 | 典型表现 | 常见原因 |
|---|---|---|
| 同一系统内两次统计不一致 | 报表A和报表B对不上 | 统计口径、时间边界、过滤条件不同 |
| 与数据库直接查不一致 | 代码算出来和SQL查出来不同 | 缓存、事务隔离、分页、并发写入 |
| 分布式/多节点不一致 | 各节点数字不同 | 本地缓存、时钟漂移、最终一致性延迟 |
| 与业务预期不一致 | 数字明显偏大/偏小 | 重复计算、漏算、精度丢失 |
| 与历史对比突变 | 某天数据跳变 | 时区、夏令时、批量补数、口径变更 |
Java里最常见的“坑”
- 浮点精度：
double/float做金额或比率统计会累积误差，应该用BigDecimal，且指定RoundingMode。 - 整数除法：
int / int会截断，1/2 = 0，比率统计容易出错。 - 时间边界：
BETWEEN是否包含端点、LocalDateTime与Date混用、时区（UTC vs 东八区）不一致。 - 并发统计：
HashMap非线程安全，多线程count++丢失更新，应该用LongAdder/ConcurrentHashMap。 - 缓存与DB不一致：先更新DB后删缓存 vs 先删缓存后更新DB，读多写多时会出现偏差。
- 分页统计：一边翻页一边有新数据写入，导致总数和明细对不上。
- 事务隔离：
READ COMMITTED下两次查询结果可能不同，统计要放在同一快照里。 - 流式/批处理：
Stream.parallel()配合有状态操作、Collectors.groupingBy的并发版本用错。
排查思路（建议按顺序）
- 对齐口径：时间范围、过滤条件、去重规则、单位（元/分、秒/毫秒）逐条对比。
- 最小复现：拿一条已知数据，手工SQL算一遍，再跑Java代码，看差在哪一步。
- 加日志/断点：在聚合前后打印中间结果，定位是“取数错”还是“计算错”。
- 对账：用
COUNT、SUM在DB侧和Java侧分别跑，差值是否恒定（恒定→口径问题；随机→并发/缓存问题）。 - 压测验证：并发场景下重复跑，看差距是否随并发增大。
如果差距是“合理”的
有些差距本身不是bug：
- T+1 vs 实时：离线报表和实时看板天然有延迟差。
- 采样统计：用了近似算法（HyperLogLog、布隆过滤器）本身就有误差。
- 最终一致性：分布式系统里短暂不一致是设计取舍。
