std::bitset的&、|、^运算本身是编译期分块并行的，但不支持多线程并发调用；因其无原子语义，多线程直接操作同一对象会导致读-改-写撕裂、伪共享及末尾掩码失效。
直接用 std::bitset 的 &、|、^ 就是最快的并行方案——但仅当模板参数是编译期常量且位宽不过大；一旦你试图多线程并发调用这些操作符，反而会引入数据竞争和性能退化。
std::bitset 的 operator& 为什么不能多线程并发调用
它内部确实是分块（如 uint64_t）并行执行单条 CPU 指令，但整个过程是单线程顺序完成的：所有块在一个线程里按序处理，不提供任何线程安全保证。你无法把一个 std::bitset 对象同时交给多个线程做 &=，因为：
- 没有原子语义，
dst[i] &= src[i]是“读-改-写”非原子操作，多线程写同一缓存行会触发伪共享（false sharing） - 末尾字若未对齐或未掩码，多个线程可能同时修改高位脏位，结果不可预测
- 编译器不会为你插入内存屏障或锁，越界读写在调试模式下可能静默崩溃
如何安全地做多线程 inplace 位运算（&= / |= / ^=）
核心是放弃 std::bitset 的封装，直接操作对齐的原始内存块。关键步骤：
- 用
alignas(64) std::vector<uint64_t></uint64_t>替代std::bitset，确保起始地址对齐到缓存行边界 - 计算总字数：
size_t words = (n_bits + 63) / 64，避免用.size()动态查 - 按线程数切分区间：
start = (tid * words) / num_threads，end = ((tid + 1) * words) / num_threads - 每个线程只处理自己的
[start, end)区间，执行dst[i] &= src[i]（无需原子） - 若
n_bits % 64 != 0，最后一块必须加掩码：uint64_t mask = (1ULL ，再 <code>dst[last] &= src[last] & mask
AVX2 加速并行 AND 的实际门槛和陷阱
只有当你满足全部以下条件时，手写 _mm256_and_si256 才值得投入：
立即学习“C++免费学习笔记（深入）”；
- 位数组 ≥ 1MB，且该运算高频调用（如每帧一次）
- 内存已用
aligned_alloc(32, bytes)或posix_memalign分配，地址 % 32 == 0 - 主循环严格按 32 字节步进：
for (size_t i = 0; i - 剩余不足 32 字节部分必须回退到
uint64_t标量循环，不能强行跨界读 - 末尾 bit 掩码仍需单独构造：
__m256i mask = _mm256_set1_epi8(...)，再_mm256_and_si256(v, mask)
std::vector 为什么是绝对陷阱
它不是“紧凑存储的 bool 数组”，而是特化容器，每次 operator[] 返回 proxy reference，背后是位提取 + 掩码 + 写回三步操作。这意味着：
- 无法被编译器向量化，
std::transform会退化为逐 bit 访问 - 多线程直接索引修改必然数据竞争，哪怕你用
std::atomic<bool></bool>包装也没用（x86 最小原子单位是字节） - 迭代器不是随机访问，
std::execution::par对它完全无效 - 实测比等效的
std::vector<uint64_t></uint64_t>慢 10 倍以上
真正容易被忽略的点：并行加速效果高度依赖内存布局一致性——对齐没做对，比不用 AVX2 还慢；末尾掩码漏掉一次，结果就错；而 std::bitset 看似简单，只要模板参数不是 constexpr，连编译都过不去。
