同步边界由数据竞争点决定，即多个线程并发读写同一块非原子共享内存的位置；保护对象需覆盖所有读写访问（含间接访问），而非仅“明显修改”的操作。
共享对象的同步边界由数据竞争点决定
同步边界不是凭空画出来的，而是由哪些变量/内存位置被多个线程并发读写决定的。只要两个线程可能同时访问同一块非原子内存（比如一个 int 成员、一个 std::vector 的 size() 返回值、或某个指针指向的对象），且至少一个是写操作，那这个访问点就是潜在的数据竞争点——也就是必须加同步的地方。
常见错误是只保护“明显在改”的操作，比如只锁 push_back 却忽略 empty() 或 front()：这些读操作和写操作若无同步，仍构成数据竞争。
- 判断依据不是“函数名是否带修改语义”，而是“是否访问共享可变状态”
-
const成员函数不等于线程安全——如果它读的是被其他线程修改的成员，仍需同步 - 避免把整个对象生命周期当做一个粗粒度边界；细粒度边界（如只锁某个字段）更易推理，也更易发现遗漏
std::mutex 保护的不是代码段，而是数据访问序列
用 std::mutex 时，真正起作用的是「谁在什么时间点持有锁」+「哪些数据访问被包裹在 lock/unlock 之间」。锁本身不绑定到对象或函数，它只是个同步原语，你得自己确保所有对共享数据的访问都经过同一把锁（或等价的同步机制）。
典型反例：std::shared_ptr 管理对象，但多个线程通过不同 shared_ptr 实例访问其内部状态，而没对对象内容加锁——引用计数安全 ≠ 对象内容安全。
立即学习“C++免费学习笔记（深入）”；
- 同一个
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 可以消除对那个变量的锁需求，但这只适用于简单标量；一旦涉及多个相关变量（比如 count 和 data 数组长度），原子性就不自动传递。这时“同步边界”变成「哪几个原子操作必须按某种顺序执行」，需要用 memory_order 显式约束。
例如：一个线程写 ready = true（relaxed），另一个线程读 ready 后读 data，若没用 memory_order_acquire，编译器/CPU 可能重排，导致读到未初始化的 data。
-
std::atomic解决单变量读写同步，不解决复合操作（如“检查后执行”）的 ABA 问题 - 无锁队列等结构的同步边界藏在 CAS 循环条件里，错一个
memory_order就可能漏掉可见性保证 - 别为了“不用锁”强行上原子操作——多数场景下正确使用
std::mutex更清晰、更不易出错
