LongAdder如何突破高并发计数瓶颈

LongAdder通过分段累加（cells数组）巧妙规避高并发下CAS自旋争用瓶颈，在写多读少场景（如实时请求计数、监控指标采集）中显著优于AtomicInteger；但它牺牲了强一致性——sum()仅提供弱一致的近似快照，不支持compareAndSet等原子条件操作，也不适用于读多写少、需精确判断或业务关键路径的场景；理解其设计取舍（空间换时间、只增不减的cells、GC友好但无复用机制），结合真实并发模式而非单纯理论压测做选型，才能真正发挥其高性能优势。

LongAdder 比 AtomicInteger 快在哪？

不是所有“原子操作”都扛得住高并发计数。当多个线程频繁调用 increment() 时，AtomicInteger 的 CAS 自旋会激烈竞争同一个内存地址，导致大量失败重试，吞吐量骤降。而 LongAdder 把一个值拆成多个单元（cell），线程先尝试往自己的 cell 累加，冲突少；只有在读取总数（sum()）时才合并——这是空间换时间的典型策略。

实操建议：

• 写多读少场景（如请求计数、采样统计）优先选 LongAdder；读多写少（如配置开关计数器）反而可能因 sum() 开销略高而不划算
• LongAdder 不提供 compareAndSet 类接口，无法替代需要强一致判断的逻辑（比如“仅当小于100才加1”）
• 初始化后不要反复调用 reset() —— 它内部会重建 cells 数组，触发内存分配和同步开销

为什么 sum() 返回值有时“不准”？

LongAdder.sum() 是弱一致性读：它遍历当前所有 cell 并累加 base 值，但过程中其他线程可能正在新增 cell 或更新已有 cell，结果只是某个瞬间的近似快照。这不是 bug，是设计取舍。

常见错误现象：

• 用 sum() == 0 判断“是否无任何操作”，结果偶发误判（新 cell 尚未被计入）
• 在 if-else 分支里基于 sum() 做业务决策（如“超阈值则告警”），但阈值检查与后续动作之间存在竞态窗口

实操建议：

• 监控类指标（QPS、错误数）完全接受这种误差；业务关键路径需强一致语义时，别用 LongAdder
• 若必须精确总数且写入不频繁，改用 AtomicLong；若写入频繁又需精确，考虑分段锁或外部聚合服务

cells 数组膨胀后不收缩，内存会一直涨？

LongAdder 的 cells 数组只增不减：线程发现冲突后会尝试扩容（最多到 CPU 核心数），但没机制回收空闲 cell。不过实际中，只要线程数稳定，cells 大小很快收敛，不会无限增长。

性能影响：

• 每个 cell 占 24 字节（对象头 + long 字段），16 核机器最多约 384 字节，内存压力极小
• 遍历 cells 的成本随数量线性增长，但通常不超过几十个，sum() 仍远快于高争用下的 AtomicInteger.get()
• GC 友好——cells 是普通对象数组，无特殊引用关系，不会阻碍回收

注意：LongAdder 不复用已创建的 cell 给不同线程，所以线程池动态伸缩时（如临时扩出大量短期线程），cells 可能短暂增多，但随后闲置，不会泄漏。

替代方案对比：什么时候不该用 LongAdder？

它不是万能解药。以下情况直接绕开：

• 需要原子地读-改-写（如 getAndIncrement()、addAndGet() 返回旧值/新值）——LongAdder 没有这些方法
• 数值范围超出 long（需 BigInteger 或分布式计数器）
• 运行在受限环境（如某些 Java Agent 或老版本 Android Runtime），LongAdder 在 Java 8+ 才可用，且依赖 Unsafe 的真正 CAS 支持
• 单线程或低并发场景——AtomicInteger 更轻量，无额外结构开销

复杂点在于：它的优势高度依赖真实并发模式。压测时用固定线程死循环调 increment() 看不出问题，但混合 I/O、锁等待、GC 暂停的真实服务里，cells 分配节奏和争用分布会更复杂，得看实际 profile 数据，不能只信理论模型。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~