登录
首页 >  文章 >  java教程

如何利用 DoubleAdder 的分段思想构建一个支持多线程无竞争写、单线程高效读的统计桶

时间:2026-05-03 20:57:44 234浏览 收藏

大家好,今天本人给大家带来文章《如何利用 DoubleAdder 的分段思想构建一个支持多线程无竞争写、单线程高效读的统计桶》,文中内容主要涉及到,如果你对文章方面的知识点感兴趣,那就请各位朋友继续看下去吧~希望能真正帮到你们,谢谢!

DoubleAdder 不支持统计桶,需封装数组或 Map 持有多个实例;推荐预设固定大小的 DoubleAdder[] 数组,避免动态扩容和哈希开销;写入须线程局部路由,读取宜批量调用 sum() 并注意精度与清理。

如何利用 DoubleAdder 的分段思想构建一个支持多线程无竞争写、单线程高效读的统计桶

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 引入不确定性

以上就是《如何利用 DoubleAdder 的分段思想构建一个支持多线程无竞争写、单线程高效读的统计桶》的详细内容,更多关于的资料请关注golang学习网公众号!

相关阅读
更多>
最新阅读
更多>
课程推荐
更多>