选用 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<string longadder></string>，key 为错误码，避免锁竞争
和日志、监控联动的实际姿势
单纯计数没意义，要能定位问题。建议：
- 把
LongAdder和BlockingQueue<errorrecord></errorrecord>绑定：每计一次，同步写一条轻量ErrorRecord（含行号、原始值、错误码），队列满时异步刷盘，便于事后抽样分析 - 清洗结束时，用
errorCounter.sum()值上报到 Prometheus：counter_total_errors{job="user_clean"} 1247，配合 Grafana 看板观察趋势 - 警惕“0 错误”假象：某些清洗逻辑会静默吞掉异常（比如
try-catch后 return null），此时LongAdder不会自增，但数据已损坏。必须确保所有业务异常都显式触发计数
真正难的不是写对 LongAdder.increment()，而是定义清楚“什么叫错误”——它必须对应可修复、可归因、可告警的业务语义，而不是技术异常的简单搬运。
