DoubleAddr不是标准库函数或现成类，而是一种手动分段、缓存行对齐、单线程合并的计数器设计模式；它通过alignas(64)为各线程分配独占缓存行的计数器，从内存布局上消除伪共享，避免MESI协议因多线程写同一缓存行导致的频繁失效重载。
直接说结论：DoubleAddr 不是标准库函数，也不是某个开源库的现成类，它指的是一种**手动分段 + 缓存行对齐 + 单线程合并**的计数器设计模式。在 32 核以上服务器上，用 std::atomic 直接并排声明多个计数器，大概率会因伪共享拖垮性能——DoubleAddr 的核心价值，就是从内存布局上把争抢彻底切开。
为什么 std::atomic 并排声明会触发伪共享
两个 std::atomic 变量如果紧挨着声明（比如放在同一个 struct 里或连续数组中），它们极可能落在同一 64 字节缓存行内。当线程 A 写第一个、线程 B 写第二个时，MESI 协议会强制让整个缓存行在核心间反复失效重载——哪怕变量逻辑完全无关。
- 典型现象：2 线程递增总耗时比 1 线程还长；8 线程吞吐量不到 4 线程的 2 倍
- 验证方式：
perf stat -e cache-misses,cache-references观察 cache-misses 比例是否随线程数飙升 - 根本限制：CPU 硬件以缓存行为单位同步，无法按字段粒度隔离
alignas(64) 必须配数组 + 对齐分配才真正生效
alignas(64) 只保证单个对象起始地址对齐，但若数组本身未对齐，第一个元素仍可能跨缓存行，连带污染后续所有元素。
- 全局/静态数组通常安全：
static PaddedCounter counters[64]; - 堆上分配必须用
aligned_alloc(64, ...)，不能用new或默认malloc -
std::vector默认不满足要求，需自定义分配器，否则毫无意义 - 结构体内嵌时，
alignas(64)仅约束该字段偏移，不防相邻字段“挤进来”——所以推荐让PaddedCounter成为独立类型，且只含一个std::atomic成员
线程写入与合并必须严格分离
每个线程只写自己专属的 counters[tid].value，绝不越界；最终统计由单一线程遍历累加，避免再次引入竞争。
- 写入用
std::memory_order_relaxed足够，因为无依赖关系 - 合并阶段也用
relaxed加载，只要求最终一致性，不要求实时可见 - 切忌在写入路径做原子加法后立刻读取全局和——这会重新拉回竞争热点
- 如果需要近似实时值，可定期（如每 10ms）由专用线程触发一次合并，而非每次写都查
最容易被忽略的点：缓存行大小不是固定 64 字节。ARM64 部分芯片是 128 字节，苹果 M 系列统一 128 字节。硬写 alignas(64) 在这些平台可能失效——生产环境应通过 /sys/devices/system/cpu/cpu0/cache/index0/coherency_line_size 动态读取，或至少用编译期宏兜底。
