std::array本身不提供线程安全，因其仅为带长度的c风格数组封装，所有读写操作需显式加锁；它无构造/析构开销、非原子，多线程并发读写同一元素会导致未定义行为。
直接用 std::array 本身不提供线程安全 —— 它只是个带长度的 C 风格数组封装，所有读写操作都需你显式加锁或同步。
为什么 std::array 没有内置线程安全
std::array 是 trivially copyable、无构造/析构开销的聚合类型，标准库从未承诺其成员访问（如 operator[]、data()）是原子的。多个线程同时读写同一元素，或一个线程写、另一个读，就是典型的数据竞争 —— 行为未定义，可能崩溃、返回脏值、甚至引发硬件异常。
- 即使只读，若写线程正在赋值整个
std::array（如buf = new_data;），仍需同步：因为赋值是逐字节拷贝，读线程可能看到部分新、部分旧的状态 -
std::atomic<:array n>></:array>不合法 ——std::array不满足std::atomic对“可平凡复制且无非静态数据成员”的严格要求（它含内联数组，但某些平台对 >16 字节类型不支持 lock-free atomic） - 别指望编译器自动插入屏障：C++ 内存模型不为裸内存访问做任何保证
std::shared_mutex 适合单写多读场景
如果你的模式是「一个线程定期更新整块缓冲区，多个线程只读取当前快照」，std::shared_mutex 是最自然的选择 —— 它允许并发读，但写时阻塞所有读，比 std::mutex 吞吐更高。
- 写操作必须用
std::unique_lock<:shared_mutex></:shared_mutex>或lock()，确保独占 - 读操作必须用
std::shared_lock<:shared_mutex></:shared_mutex>（不是std::lock_guard！后者不兼容shared_mutex） - 记得配合
std::atomic<bool></bool>标志位（如buffer_ready）+std::memory_order_acquire/release，避免编译器/CPU 重排导致读到未完全写入的数据 - GCC 8+ / Clang 7+ 支持完整；MSVC 2019 16.8+ 起较稳定，旧版有已知竞态 bug
std::mutex + RAII 是通用兜底方案
当读写混合频繁、或写操作不总是整块替换时，老老实实用 std::mutex 最稳妥 —— 它没有兼容性陷阱，语义清晰，调试友好。
- 优先用
std::lock_guard<:mutex></:mutex>包裹临界区，避免手动lock()/unlock()导致异常时死锁 - 不要把
std::mutex声明为mutable后在const成员函数里锁 —— 这虽能编译，但会模糊“逻辑常量性”，增加维护成本 - 如果锁粒度太粗（比如整个
std::array共用一把锁），而实际只改个别索引，可考虑分段锁（shard lock），但需权衡额外内存与复杂度
std::atomic 仅适用于单元素原子操作
std::atomic 对 std::array 整体无效，但你可以把它用在数组的**单个元素**上 —— 前提是该元素类型本身支持原子操作（如 int、uintptr_t）。
- 例如：
std::array<:atomic>, 1024> buffer;</:atomic>，此时buffer[i].store(42)和buffer[i].load()是线程安全的 - 但注意：这无法保证「多个原子变量作为一个整体」的原子性 —— 比如你想让索引 5 和 6 同时更新为新值，仍需额外同步
- 对非 trivial 类型（如
std::string元素）不能套std::atomic；对浮点数，std::atomic<float></float>在某些平台非 lock-free，性能差
真正容易被忽略的是内存序和初始化顺序：即使锁用了，若写线程在锁内修改了 std::array 后没用 std::memory_order_release 标记就释放锁，读线程可能因 CPU 缓存不一致看到旧值；而局部 static std::array 的零初始化是线程安全的，但后续首次写入仍需同步 —— 它不解决运行时并发访问问题。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
