背景

两个线程更新不同计数器，逻辑上没有共享数据，却可能争用同一缓存行。伪共享是布局问题，不是原子变量失效。

核心判断

  1. 先确认热点来自并发写和缓存一致性开销。
  2. 按写入者划分数据，必要时使用每线程计数后聚合。
  3. 只有测量支持时才增加对齐或 padding。

最小示例

下面保留核心逻辑；业务类型、调用入口和环境配置按项目补齐。

struct alignas(64) Counter { std::atomic<std::uint64_t> value{0}; };
struct Metrics { Counter accepted; Counter rejected; };

边界与误区

64 字节只是示例假设，不是所有硬件的保证。过度 padding 会增加工作集，读多写少的数据可能因此更慢。

验证方式

固定线程数、CPU 亲和性和操作次数，对比吞吐及缓存相关事件。保留真实业务基准，不用单一空循环决定结构布局。

小结

高频并发写字段要避免伪共享，但任何 padding 都必须由 profile 证明收益。