longadder不会耗尽内存或导致oom，因其cells数组大小受cpu核数和inside_limit（默认1024）限制，扩容失败时自动退化至base更新；cell对象轻量无引用，gc压力极小。
LongAdder 在高并发场景下不会“耗尽 Cells 数组”导致内存被撑爆，它本身有明确的容量控制与退化机制，GC 表现取决于实际对象生命周期，而非 Cells 数组无限膨胀。
Cells 数组不会无限制增长
Cells 数组大小始终是 2 的幂次（如 1、2、4、8…），最大长度受 CPU 核心数限制（通常不超过 NCPU × 2），JVM 不会允许其无限扩容。当扩容尝试失败（如 CAS 更新 cellsBusy 失败、内存分配失败或达到上限），后续更新会退回到 base 字段，不再新增 Cell。
- 数组创建是惰性的：初始时 cells 为 null，所有操作走 base；仅当竞争显著时才初始化 cells。
- 扩容需获取 cellsBusy 锁，失败则直接重试 base 更新，不抛异常也不阻塞。
- JDK 源码中 cells.length 上限由 LongAdder.INSIDE_LIMIT（默认 1024）等约束，远低于引发 OOM 的量级。
Cell 对象本身 GC 压力极小
每个 Cell 是一个轻量级 long 类型封装（继承自 Striped64.Cell），只含一个 volatile long value 和 padding 字段，无引用其他对象，不持有业务数据或闭包。只要线程不再访问该 Cell，且 cells 数组引用被回收，Cell 实例就成为标准的不可达对象，可被常规 GC 正常回收。
- Cell 不参与业务逻辑，不缓存用户对象，不会造成内存泄漏链。
- cells 数组本身是 LongAdder 实例的字段，当 LongAdder 对象被回收（如 Spring Bean 销毁、局部变量出作用域），整个 cells 数组及其中 Cell 实例都可被一并回收。
- 即使数组长期存在，单个 Cell 占用约 64 字节（含缓存行填充），1024 个 Cell 总内存不足 64KB，对堆压力微乎其微。
真正影响 GC 的不是 Cells，而是误用场景
LongAdder 本身不会导致 GC 压力上升，但如果把它当作通用计数器滥用在错误上下文中，可能间接引发问题：
- 将 LongAdder 存入静态集合（如 static Map
）且永不移除，会导致 LongAdder 实例长期存活，连带 cells 数组无法回收。 - 在短生命周期对象中频繁 new LongAdder（如每次 HTTP 请求创建一个），虽单个轻量，但高频分配仍增加 Minor GC 频率——这不是 Cells 的锅，而是对象创建模式问题。
- 混淆 LongAdder 与业务状态容器：它只适合高并发累加统计，不能替代缓存、Session 或聚合根，否则容易把不该长期持有的数据绑定到其生命周期上。
对比 AtomicLong 更凸显设计合理性
AtomicLong 在极端竞争下持续自旋 CAS，CPU 空转严重，但内存占用恒定（仅一个 long）；LongAdder 以少量额外内存（cells 数组）换来了线性扩展能力，且这部分内存可控、无引用污染、易于回收。两者在 GC 表现上并无本质优劣，区别在于：前者压 CPU，后者压内存——而 LongAdder 的内存开销是收敛的、可预期的、不构成 GC 障碍。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
