必须显式管理 std::thread 生命周期，否则析构时强制调用 std::terminate()；应 join 或 detach，推荐 raii 封装；共享数据须加锁，优先用 std::mutex + std::lock_guard；等待用 std::condition_variable 而非轮询；std::async 不等于自动线程管理。
必须显式管理 std::thread 对象的生命周期，否则程序会在析构时直接崩溃——这不是警告，是 C++ 标准强制行为。
std::thread 构造后必须 join 或 detach
线程对象一旦创建，底层线程立即启动；但 std::thread 对象本身不是“线程”，它只是对线程的句柄。如果该对象在仍处于 joinable() 状态下被销毁（比如函数返回、作用域结束），C++ 会无条件调用 std::terminate()。
- 常见错误现象：
terminate called without an active exception或直接进程退出，无堆栈、无日志 - 正确做法：在对象销毁前，二选一：
t.join()（主线程等它完）或t.detach()（彻底放手，但需确保它访问的所有资源（如局部变量、this 指针）生命周期足够长） - 推荐实践：用 RAII 封装，例如自定义
scoped_thread类，在析构时自动join()；避免裸用std::thread - 注意：
std::thread不可拷贝，只能移动；传参默认按值，若需引用，必须显式写std::ref(x)
共享数据不加锁就访问，结果不可预测
多个线程读写同一变量（如全局计数器、std::vector、类成员）时，不加同步机制，就是竞态条件（race condition）。编译器优化、CPU 缓存、指令重排会让结果完全失控，且问题往往只在多核环境或高负载时复现。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 最安全组合：
std::mutex+std::lock_guard—— 构造即加锁，析构即解锁，异常安全 - 别手动调
mtx.lock()/mtx.unlock()：一旦中间抛异常，unlock()就不会执行，导致死锁 - 粒度要细：只锁真正需要保护的临界区，而不是整个函数体；避免嵌套锁，否则极易死锁
- 读多写少场景可考虑
std::shared_mutex（C++17），支持多个 reader 同时进入
线程间等待不能靠 while(true) + sleep
轮询（busy-wait）浪费 CPU，且无法精确响应状态变化。当一个线程需等待另一线程完成某件事（如队列非空、标志置位），必须用 std::condition_variable 配合 std::unique_lock。
- 典型错误：写
while (!ready) std::this_thread::sleep_for(...)—— 效率低、延迟高、易错过信号 - 正确模式：
cv.wait(lock, []{ return condition; })，内部自动释放锁、挂起线程、被唤醒后重新加锁并检查条件 - 注意：
notify_one()和notify_all()必须在持有同一 mutex 的前提下调用，否则唤醒可能丢失 - 务必配合 predicate（lambda）使用
wait()，避免虚假唤醒（spurious wakeup）
std::async 不等于“免管理线程”
std::async 看似省事，但它隐藏了线程调度策略和生命周期细节，容易误用。
- 默认启动策略是
std::launch::async | std::launch::deferred，意味着可能延迟执行（甚至不执行），直到你调future.get()；这和“立刻启动新线程”的直觉不符 - 若未取回
std::future，其析构会阻塞并等待任务完成——这可能导致主线程意外卡住 - 性能开销比裸
std::thread更高，不适合高频小任务；适合有明确返回值、耗时较长的异步计算 - 不适用于需要精细控制线程数量或复用线程的场景（此时应上
std::thread_pool或自建线程池）
最常被忽略的点是：线程安全 ≠ 加了 mutex 就万事大吉。对象生命周期、this 指针有效性、静态局部变量、第三方库是否线程安全——这些都得逐个确认，缺一不可。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
