std::mutex是保护数组并发读写的最直接有效手段，所有访问（含读取）都必须加锁；std::shared_mutex适用于读多写少场景；std::atomic仅支持单元素原子操作；std::vector本身非线程安全，任何写操作均要求全局同步。
std::mutex 保护数组读写最直接有效
并发读写同一块内存时，std::mutex 是 C++ 标准库中最常用、最稳妥的同步手段。它不区分读/写操作，只要访问共享数组的代码路径可能重叠，就必须用锁包裹——哪怕只是读取，因为“读+写”或“写+写”同时发生就足以触发未定义行为。
常见错误是只给写操作加锁、放行多线程读取，这在多数场景下仍会出问题：现代 CPU 的缓存一致性模型和编译器优化可能导致读线程看到撕裂值（partial update）或过期值，尤其当数组元素是 int64_t 或自定义结构体时。
- 所有访问该数组的线程，无论
push_back、operator[]还是data()取地址，都必须包裹在std::lock_guard<:mutex></:mutex>作用域内 - 避免在锁内调用可能阻塞或抛异常的函数（如
std::cout <<），否则可能延长持锁时间或导致死锁 - 不要把
std::mutex声明为局部变量——它必须是全局、类成员或静态变量，否则每次调用都新建一把锁，完全失效
std::shared_mutex 适合读多写少场景
如果数组被大量线程频繁读取、但写入极少（比如配置缓存、只读映射表），可用 std::shared_mutex 替代普通互斥量，提升并发吞吐。它支持多个读线程同时进入，但写操作仍独占。
注意：C++17 才正式引入 std::shared_mutex，MSVC 19.20+、GCC 8.1+、Clang 7.0+ 支持；旧版本需用 boost::shared_mutex 或降级为 std::mutex。
立即学习“C++免费学习笔记（深入）”；
- 读操作用
std::shared_lock<:shared_mutex></:shared_mutex>，写操作用std::unique_lock<:shared_mutex></:shared_mutex> - 不能混用：一个线程持
shared_lock时，其他线程无法获得unique_lock；反之亦然 - 即使只有 1% 的写操作，也要确保所有写路径都用了
unique_lock，漏掉任意一处就会引发数据竞争
std::atomic 仅适用于单个数组元素的简单读写
std::atomic 不能直接用于整个数组，但可用来原子化操作单个元素（如计数器、标志位）。例如：把 int arr[1024] 改成 std::atomic<int> arr[1024]</int>，就能安全地对每个 arr[i] 独立执行 load()、store()、fetch_add()。
限制很明确：它不保证多个元素间的操作顺序，也不提供跨元素的原子性。比如“把 arr[0] 加 1 同时把 arr[1] 减 1”这种组合操作，std::atomic 无能为力，仍需 std::mutex。
- 仅当每个线程只操作固定下标、且操作本身是单一原子指令（如
++、=）时才适用 - 注意内存序：默认
std::memory_order_seq_cst安全但稍慢；若追求极致性能且逻辑清晰，可显式指定relaxed或acquire/release，但极易出错 -
std::atomic<T>要求T是平凡可复制（trivially copyable），不能用于含虚函数、非平凡构造/析构的类对象
std::vector 本身不是线程安全的，别信文档里的“无数据竞争”误导
官方文档说 “std::vector 的 const 成员函数不修改对象状态，因此可被多线程并发调用”，但这有个致命前提：**没有其他线程同时调用非常量成员函数**。一旦有线程执行 push_back、resize、clear，整个容器的内部指针（begin()、end()、容量）都可能重分配，此时其他线程哪怕只调用 size() 或 operator[]，也会踩到悬空指针或读到中间态数据。
- 不要依赖“只读函数就不用锁”——只要数组生命周期内可能发生任何写操作，所有访问都必须同步
- 用
std::vector存数组时，锁粒度建议覆盖整个容器操作，而不是按索引拆分；否则容易遗漏capacity()变更带来的隐式重分配 - 若数组大小固定且初始化后不再变更，可考虑用
std::array+std::mutex，避免堆分配和迭代器失效风险
真正麻烦的从来不是加锁本身，而是判断哪些访问路径需要锁、哪些可以不锁——尤其是当数组被多个类、多个模块、甚至第三方库间接引用时。漏掉任意一个写入口，或者误判某处“只是读”，都会让程序在高负载下间歇性崩溃，极难复现。
