DoubleAdder 不支持统计桶，需封装数组或 Map 持有多个实例；推荐预设固定大小的 DoubleAdder[] 数组，避免动态扩容和哈希开销；写入须线程局部路由，读取宜批量调用 sum() 并注意精度与清理。
DoubleAdder 本身不支持“统计桶”抽象，得自己封装
DoubleAdder 是个单值累加器，不是容器。它内部的 Cell[] 是为分散写竞争服务的，不对外暴露索引或分桶语义。想实现“多线程无竞争写、单线程高效读”的统计桶（比如按 HTTP 状态码分桶、按响应耗时区间分桶），必须在它之上再包一层结构——用数组或 Map 持有多个 DoubleAdder 实例，每个实例对应一个桶。
常见错误是试图复用同一个 DoubleAdder 实例去“模拟”分桶，比如靠传不同参数做路由，这会直接破坏它的线程局部性设计，导致 cells 数组频繁扩容甚至退化成只写 base，性能反而不如 AtomicLong。
- 桶数量建议预设且固定（如状态码 0–599 映射到 600 个桶），避免运行时动态扩容引入锁或 CAS 冲突
- 用
DoubleAdder[]数组比ConcurrentHashMap更轻量：无哈希计算、无链表/树遍历、内存连续利于 CPU 预取 - 如果桶 ID 稀疏或不可预知（比如用户 ID 哈希后分布极广），才考虑用
ConcurrentHashMap，但要接受 O(1) 平均但非确定的读写开销
写入时如何确保真正“无竞争”
关键不在 DoubleAdder 本身，而在桶路由逻辑是否线程安全且无共享状态。最稳妥的做法是让每个写入线程自己决定写哪个桶，并保证该决策过程不依赖任何跨线程可变变量。
- 状态码分桶：HTTP 处理线程拿到
statusCode后直接buckets[statusCode].add(1.0)，只要buckets数组已初始化完成，这就是纯局部操作 - 耗时分桶：先用位运算或查表把
elapsedMs映射到固定区间索引（如 0–99），再写对应DoubleAdder，避免浮点除法或分支预测失败带来的延迟 - 绝对不要在写入路径里做
getOrDefault(key, new DoubleAdder())这类操作——ConcurrentHashMap.computeIfAbsent()内部有锁，会成为瓶颈
读取时 sum() 调用的代价和时机很关键
DoubleAdder.sum() 是遍历 base + cells[] 的非原子操作，结果是弱一致性快照。对“单线程高效读”而言，问题不在并发安全，而在调用频次和聚合方式。
- 如果每秒调用 1000 次
sum()读一个桶，而这个桶实际只有 2 个Cell，那开销几乎可忽略；但如果对 1000 个桶都这么干，就是 1000×（遍历 2–8 个 Cell），不如批量读 - 推荐做法：读线程一次性遍历整个
DoubleAdder[]数组，对每个元素调用sum()，并用局部变量累加或存入新数组——避免反复触发 JVM 对同一对象的内存屏障刷新 - 注意
sum()返回的是double，连续小数值累加可能有精度漂移（比如加 0.1 一百次≠10.0），监控场景建议统一转为long单位（如微秒）改用LongAdder
长期运行后 cell 数组膨胀，得定期清理
DoubleAdder 不会自动收缩 cells 数组。突发流量后 cells.length 可能从 2 扩到 64，之后空闲线程仍占着槽位，sum() 每次都要遍历全部 64 个 Cell，哪怕其中 62 个是 0。
- 没有标准 API 清理，只能靠反射或继承重写——但不推荐。更务实的做法是：在低峰期（如凌晨）新建一批
DoubleAdder实例替换旧桶数组，让旧对象被 GC - 如果必须原地复用，可考虑在每次读取后判断
cells != null && cells.length > 8 && allCellsZero(cells)，再尝试通过反射置空cells字段（需Unsafe权限，生产慎用） - 真正的复杂点在于：你无法知道哪些
Cell是“真空闲”还是“刚被某个线程哈希进来但还没写”，所以所谓“清理”本质是权衡——宁可多占点内存，也不要为省几 KB 引入不确定性
