C++多个线程共享对象时怎么确定同步边界-C++-PHP中文网

同步边界由数据竞争点决定，即多个线程并发读写同一块非原子共享内存的位置；保护对象需覆盖所有读写访问（含间接访问），而非仅“明显修改”的操作。

c++多个线程共享对象时怎么确定同步边界

共享对象的同步边界由数据竞争点决定

同步边界不是凭空画出来的，而是由哪些变量/内存位置被多个线程并发读写决定的。只要两个线程可能同时访问同一块非原子内存（比如一个 int 成员、一个 std::vector 的 size() 返回值、或某个指针指向的对象），且至少一个是写操作，那这个访问点就是潜在的数据竞争点——也就是必须加同步的地方。

常见错误是只保护“明显在改”的操作，比如只锁 push_back 却忽略 empty() 或 front()：这些读操作和写操作若无同步，仍构成数据竞争。

判断依据不是“函数名是否带修改语义”，而是“是否访问共享可变状态”
const 成员函数不等于线程安全——如果它读的是被其他线程修改的成员，仍需同步
避免把整个对象生命周期当做一个粗粒度边界；细粒度边界（如只锁某个字段）更易推理，也更易发现遗漏

std::mutex 保护的不是代码段，而是数据访问序列

用 std::mutex 时，真正起作用的是「谁在什么时间点持有锁」+「哪些数据访问被包裹在 lock/unlock 之间」。锁本身不绑定到对象或函数，它只是个同步原语，你得自己确保所有对共享数据的访问都经过同一把锁（或等价的同步机制）。

典型反例：std::shared_ptr 管理对象，但多个线程通过不同 shared_ptr 实例访问其内部状态，而没对对象内容加锁——引用计数安全 ≠ 对象内容安全。

C++14

C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。

下载

同一个 std::mutex 实例必须覆盖所有对该对象的读/写访问，包括间接访问（如通过迭代器遍历容器）
不要在锁内调用用户可重入的回调（如 std::function），否则可能死锁或破坏临界区边界
考虑用 std::scoped_lock 替代手写 lock/unlock，避免异常导致漏解锁

move 之后的对象状态让同步边界突然失效

当一个共享对象被 move 构造或赋值后，原对象进入有效但未指定状态（valid but unspecified），其内部资源（如 std::unique_ptr 指向的堆内存、std::mutex 自身）可能已被转移。此时若其他线程仍在访问原对象，就不再是同步问题，而是未定义行为。

尤其危险的是：move 发生在线程 A，而线程 B 正在持锁访问该对象——move 不会自动释放锁，也不会通知其他线程。

禁止对正在被多线程访问的对象执行 move 操作
如果必须转移所有权，先用同步机制（如原子 flag + 条件变量）协商停写，再 move
std::mutex 不可拷贝不可 move，所以 move 对象时若含 mutex 成员，必须显式禁用或重新初始化（通常意味着不能 move）

std::atomic 和无锁结构不消除同步边界，只是改变其实现方式

用 std::atomic<int></int> 替代 int 可以消除对那个变量的锁需求，但这只适用于简单标量；一旦涉及多个相关变量（比如 count 和 data 数组长度），原子性就不自动传递。这时“同步边界”变成「哪几个原子操作必须按某种顺序执行」，需要用 memory_order 显式约束。

例如：一个线程写 ready = true（relaxed），另一个线程读 ready 后读 data，若没用 memory_order_acquire，编译器/CPU 可能重排，导致读到未初始化的 data。