C++多线程并发读写同一个数组引起数据竞争怎么加锁-C++-PHP中文网

std::mutex是保护数组并发读写的最直接有效手段，所有访问（含读取）都必须加锁；std::shared_mutex适用于读多写少场景；std::atomic仅支持单元素原子操作；std::vector本身非线程安全，任何写操作均要求全局同步。

c++多线程并发读写同一个数组引起数据竞争怎么加锁

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++ 算法竞赛自动化测试数据生成与校验框架

根据原题生成新题面、验证器及完整测试数据，自动套用 testlib 模板，用于用户要求生成测试数据时。

下载

读操作用 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> 要求 T 是平凡可复制（trivially copyable），不能用于含虚函数、非平凡构造/析构的类对象

std::vector 本身不是线程安全的，别信文档里的“无数据竞争”误导

官方文档说 “std::vector 的 const 成员函数不修改对象状态，因此可被多线程并发调用”，但这有个致命前提：**没有其他线程同时调用非常量成员函数**。一旦有线程执行 push_back、resize、clear，整个容器的内部指针（begin()、end()、容量）都可能重分配，此时其他线程哪怕只调用 size() 或 operator[]，也会踩到悬空指针或读到中间态数据。