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

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

为什么不能直接用 std::atomic 做高频计数

直接上答案：问题往往不出在原子性本身，而是出在内存布局上。现代 CPU 的缓存一致性协议（比如 MESI）有个特点：多个线程频繁写同一缓存行（通常是 64 字节）时，会触发“伪共享”。这意味着，哪怕每个线程只修改自己的变量，只要这些变量不幸落在同一个缓存行里，就会反复导致其他核心的缓存副本失效，从而引发大量的总线同步开销。实测下来，16 个线程并发自增一个 std::atomic，吞吐量可能比单线程还要低 30% 以上。

所以，关键点在于：std::atomic 能保证操作的原子性，但它不保证变量能独占整个缓存行。内存布局的隔离，得我们自己来做。

alignas(64) 必须配合对齐分配才真正生效

这里有个常见的误区：以为在结构体定义里加上 alignas(64) 就万事大吉了。比如定义了 struct alignas(64) PaddedCounter { std::atomic value; };，这还不够。如果这个结构体被声明为栈变量或者全局数组，它的起始地址可能并没有按 64 字节对齐，那么第一个元素就仍然可能横跨两个缓存行，甚至会“污染”后续的所有元素。

具体该怎么操作呢？

• 全局或静态数组：通常编译器会自动填充，天然满足 64 字节对齐。
• 堆上分配：必须使用 aligned_alloc(64, size) 或者 std::pmr::polymorphic_allocator 配合自定义的对齐策略。
• 使用 std::vector：要注意，std::vector 的默认分配器不保证对齐，必须传入一个能保证对齐的自定义分配器。

举个反面例子：auto* counters = new PaddedCounter[4]; —— 这里 new 返回的地址通常只保证 alignof(max_align_t) 对齐（一般是 16 字节），远远达不到 64 字节的要求。

线程索引映射要稳定且无冲突

这是实现“无竞争写”的核心前提：每个线程必须严格写入自己独占的那个桶，绝对不能出现多个线程写同一个桶的情况。否则，隔离缓存行的努力就白费了，效果和直接使用裸原子变量没什么两样。

那么，如何为线程分配唯一的索引呢？

• 一种方法是使用 std::this_thread::get_id() 做哈希再取模。但要注意，线程 ID 并不保证连续，存在哈希碰撞的风险。
• 更可靠的方式是在线程启动时，显式地传入一个索引。比如在线程池中执行任务时，将任务与一个固定的 tid 绑定。
• 如果直接使用 std::thread 创建线程，可以在 lambda 表达式中捕获序号：[tid=i](){ counters[tid].value.fetch_add(1, std::memory_order_relaxed); };

总之，务必确保映射关系是稳定且无冲突的。

读取阶段用 std::memory_order_relaxed 安全吗

答案是：安全，但有几个重要的前提。汇总线程作为唯一的读者，并且各个桶之间的数据没有依赖关系，我们只需要最终的一致性。使用 memory_order_relaxed 可以避免不必要的内存屏障，从而提升遍历所有桶进行求和的速度。

不过，有两点必须警惕：

• 同步点：主线程在开始读取汇总之前，必须确保所有工作线程都已经退出，或者已经通过屏障（barrier）等机制暂停了写入操作（比如调用 join）。否则，读到中间状态就是业务逻辑层面的问题，而非内存模型能解决的了。
• 可见性保证：如果统计值后续要用于条件判断（例如“累计超过 100 万则触发告警”），那么建议在读取所有桶之后、进行判断之前，加上一道 std::atomic_thread_fence(std::memory_order_acquire)。这能确保之前所有线程的写入操作，对当前执行判断的线程是可见的。

最后需要强调的是：分段设计巧妙地消除了写入时的竞争，但它并没有自动解决“读写并发时数据一致性”这个更高层次的语义问题——这个问题，最终需要由业务层面的同步机制来兜底。