选用 LongAdder 而非 AtomicInteger 是因高并发下其分段累加机制可避免 CAS 争抢，实测性能提升 5–8 倍；需在业务规则失败处统一调用 increment()，确保语义准确，并在任务完成后调用 sum() 获取最终值。
为什么不用 AtomicInteger 而选 LongAdder
在单线程或者并发压力不大的清洗场景里，AtomicInteger 确实能轻松胜任。可一旦任务规模上来了——比如把清洗拆成上百个并行的 Stream.parallel() 子任务，或者用 ForkJoinPool 处理千万级记录——情况就完全不同了。此时，AtomicInteger.incrementAndGet() 的 CAS 操作会变成性能瓶颈：所有线程都争抢着更新同一个内存地址，导致大量线程陷入自旋等待，系统吞吐量往往会出现断崖式下跌。
那么，LongAdder 的妙处在哪里？它的核心是分段累加机制，内部通过 cell 分片和 base 基值来分散压力。每个线程会优先往自己所属的 cell 里写入增量，从而极大避免了竞争。实测数据很有说服力：在 128 核的集群环境下，错误计数的性能提升可以达到 5 到 8 倍。这就不再是细微优化，而是架构层面的效率跃升了。
如何在清洗流水线中嵌入 LongAdder 计数器
这里的关键，其实不在于“把计数器加在哪里”，而在于“由谁来触发加法”。一个常见的误区是，让每个清洗线程随意调用 add(1)，却不严格管控触发时机，结果不是漏计就是重复计，让统计数字失去了意义。
正确的做法，需要把握住几个要点：
- 统一入口判断：最好在清洗的主入口（比如
ParallelStream的forEach或map链末端）进行集中判断。只有当某条记录明确触发了业务规则失败——例如手机号格式非法、金额为负、时间戳溢出——时才调用errorCounter.increment()。 - 规避非错误路径：要避免在日志打印、空值跳过、字段默认填充这些非错误处理路径上调用计数器。否则，计数就会偏离真实的业务含义，变得不可信。
- 传递而非创建：如果清洗逻辑存在多层嵌套（比如先校验、再转换、最后落库），应该将
LongAdder实例通过参数形式传入最内层的校验函数，而不是在每个层级新建实例，或者简单地用静态变量持有。
获取最终统计值的两个坑
调用 LongAdder.sum() 看似简单，但实际使用时有两个陷阱需要警惕：
- 它不保证强一致性：如果清洗线程还在运行，此时调用
sum()返回的只是一个当前快照，很可能会漏掉最后几毫秒产生的增量。因此，务必等待所有并行任务通过join()或awaitTermination()真正结束后，再获取最终值。 - 慎用
sumThenReset()：不要用这个方法替代单纯的sum()。因为它会在求和后清零计数器，如果后续还有重试批次或关联处理，就会导致历史错误数据丢失，给问题排查和数据对账带来很大的麻烦。 - 分类统计的优化：如果需要按错误类型（比如“手机号错误”、“时间格式错误”）分别统计，不建议创建一堆独立的
LongAdder实例。更优的方案是使用ConcurrentHashMap，以错误码作为 key，这样既能分类，又能有效避免锁竞争。
和日志、监控联动的实际姿势
单纯的计数数字价值有限，必须能辅助定位问题。这就需要将计数器与可观测性体系联动起来：
- 绑定错误队列：可以将
LongAdder与一个BlockingQueue绑定。每次计数时，同步写入一条轻量的错误记录（包含行号、原始值、错误码等）。队列满时异步刷盘，这样事后就能进行抽样分析，快速定位问题样本。 - 接入监控系统：清洗任务结束时，将
errorCounter.sum()的最终值上报到 Prometheus 等监控系统。例如，形成counter_total_errors{job="user_clean"} 1247这样的指标，再结合 Grafana 等看板，就能清晰观察错误数量的趋势变化。 - 警惕“零错误”假象：这一点尤其需要注意。有些清洗逻辑会静默吞掉异常（比如在
try-catchLongAdder 自然不会递增，但数据其实已经损坏了。因此，必须确保所有业务层面的异常都能显式地触发计数。
说到底，真正的难点从来不是写对一句 LongAdder.increment()，而是如何清晰定义“什么才算一次错误”——它必须对应一个可修复、可归因、可触发告警的具体业务语义，而不是简单地将技术异常搬运过来。这才是让计数产生价值的关键所在。
