std::bitset原生操作不支持多线程并发，因其&=、|=等操作本质是逐块读-改-写，CPU对单个字的“读+修改+写回”非原子，导致写撕裂、伪共享及性能退化；安全做法是按cache line划分写区域，避免共享写目标并末尾单独掩码处理。
std::bitset 本身不支持线程安全的并行位运算，直接多线程调用 &=、|= 或 flip() 会引发数据竞争；必须手动控制内存访问粒度和同步边界。
为什么 std::bitset 的原生操作不能直接多线程并发？
因为 std::bitset 没有内置锁或原子语义：它的 &=、|= 等操作本质是逐块读-改-写（如对每个 unsigned long 执行 dst[i] &= src[i]），而 CPU 对单个字的“读+修改+写回”不是原子操作。多个线程同时修改同一 cache line 中的不同位，会导致写撕裂（torn write）或 false sharing —— 实测 4 线程下吞吐可下降 40%。
常见错误现象包括：
- 结果偶尔少几个置位位，尤其在末尾字（
size() % word_size != 0时） - 程序偶发 SIGBUS（未对齐访问）或 SIGSEGV（越界读）
- 性能不随线程数线性提升，甚至退化
如何安全地做多线程 inplace 位运算（如 &=、|=）？
核心原则：**避免共享写目标，按 cache line 划分写区域，末尾单独掩码处理**。
立即学习“C++免费学习笔记（深入）”；
- 将位数组底层存储视为
uint64_t*，按 64 字节（即 8 个uint64_t）为单位切分任务 —— 这样每个线程操作独立 cache line，消除 false sharing - 每个线程只负责自己分到的 word 区间，执行
dst[i] &= src[i]或dst[i] |= src[i]，不跨区间 - 若总位数不是 64 的倍数，最后一块需额外掩码：
uint64_t mask = (1ULL ，然后 <code>dst[last] &= src[last] & mask; - 绝不使用
std::bitset::operator&=返回新对象的方式 —— 它隐式拷贝整个 bitset，开销远超计算本身
多线程 popcount 统计怎么避免累加竞争？
直接用 std::atomic<uint64_t> 累加会因频繁 CAS 导致严重争用；正确做法是每个线程维护本地 uint64_t 计数器，最后再合并。
- 输入数据必须 32 字节对齐（AVX2 要求），否则
_mm256_load_si256触发 SIGBUS - 每线程处理对齐段（
i += 32），用_mm256_popcnt_epi8+_mm256_sad_epu8加速；剩余不足 32 字节部分用_mm_popcnt_u64处理 8 字节单位 - 累加中间结果时，用
_mm256_extract_epi64(sum, n)提取 4 个 uint64，再本地相加 —— 不要试图用 SIMD 指令跨线程归约 - 最终合并只需一次普通加法：
total += local_count，无锁
哪些操作天然适合多线程，哪些必须串行？
真正能并行的是 **只读 + 写隔离** 场景；任何涉及全局状态变更的操作都需谨慎。
- ✅ 安全并行：
and_inplace/or_inplace（输入只读、输出按 cache line 分区）、count()（纯读）、any()/none()（短路即可，但注意 early-exit 会破坏负载均衡） - ⚠️ 需改造后并行：
flip()—— 必须拆成子区间，首尾字单独处理，中间整字批量~；且 flip 后若立刻count()，需确保该线程看到最新值（加std::atomic_thread_fence） - ❌ 不建议并行：
set(pos)/reset(pos)/operator[]—— 单 bit 写仍是非原子的位操作，多线程混写同一 word 仍可能撕裂；应改用std::atomic<uint64_t>+ 手动位操作
最容易被忽略的是：即使你把位数组切成 N 块分给 N 个线程，若没强制对齐到 cache line 边界，或没处理好末尾掩码，结果依然不可靠 —— 性能优化的前提是正确性，而正确性依赖于对底层内存模型和 CPU 缓存行为的精确控制。
