何时不应将hardware_destructive_interference_size与std::atomic配合使用？

cppreference给出过一个把原子变量和普通数据打包的结构体示例，用来演示如何利用缓存行避免伪共享：

// 示例来源于cppreference
struct together
{
    std::atomic<int> dog;
    int puppy;
};

通常我们会让这类结构体按hardware_destructive_interference_size（即缓存行大小）对齐，防止其他线程的操作污染当前缓存行。但这种做法本质是用内存换性能，当内存成本远大于性能收益，或者根本没性能收益时，就不该这么做。具体场景包括：

• 内存极度受限的嵌入式/小型系统：比如8位单片机、只有几KB RAM的设备。假设缓存行大小是64字节，一个原本8字节的结构体对齐后会占满64字节，凭空浪费56字节。对这类系统来说，内存浪费可能直接导致程序无法加载，或者挤占其他关键数据的空间，得不偿失。

• 单线程或完全串行访问的场景：伪共享的前提是多个线程同时读写同一缓存行内的不同数据。如果你的together结构体或者原子变量全程只被一个线程操作，或者线程访问完全串行（比如用锁严格串行化），那伪共享根本不会发生。强行对齐只会白白浪费内存，甚至因为缓存行利用率降低，反而让单线程访问变慢。

• 批量处理密集的数组场景：如果要创建一个包含大量together结构体的数组，每个元素都按缓存行对齐的话，数组的内存占用会成倍数暴涨。比如原本1000个元素占8KB，对齐后会占64KB。这会导致缓存命中率急剧下降——原本能塞进L1缓存的数据现在只能放一小部分，反而拖慢批量处理的速度。这种情况下，宁愿接受极小的伪共享概率，也要保证缓存的高效利用。

• 伪共享概率极低的多线程场景：比如某些变量虽然在多线程环境，但线程访问的时间窗口完全错开（比如线程A写完后，线程B隔了很久才读），或者不同线程访问的变量几乎不可能落到同一个缓存行。这时候为了极低的性能风险去牺牲内存和带宽，完全没必要。

内容的提问来源于stack exchange，提问作者weineng