不能直接调用 join() 或 detach() 来“停止”线程，因 c++ 禁止强制终止；必须采用协作式退出，以 std::atomic 作退出标志，每次循环检查，并在阻塞点注入退出信号。
为什么不能直接调用 std::thread::join() 或 std::thread::detach() 来“停止”线程
因为 C++ 标准库明确禁止强制终止线程——std::thread 没有 stop()、kill() 或类似接口。强行中断（如 POSIX 的 pthread_cancel）会导致资源泄漏、析构未执行、锁未释放等未定义行为。真正可行的只有“协作式退出”：让线程自己感知到该停了，然后干净收尾。
用 std::atomic<bool></bool> 做退出标志是最常用也最安全的方式
它轻量、无锁、跨平台，且能被编译器和 CPU 正确优化（避免指令重排导致读取 stale 值）。关键点不是“设为 true”，而是确保线程循环中**每次迭代都检查它**，而不是只在开头判断一次。
- 必须声明为
std::atomic<bool> stop_requested{false};</bool>，不能是普通bool—— 否则可能因缓存不一致永远看不到变化 - 在线程函数里写成
while (!stop_requested.load()) { /* work */ }，不要用while (true)+ 中间if (stop_requested) break;—— 后者漏检风险高 - 主线程调用
stop_requested.store(true);后，需调用thread.join()等待其退出；不能只改标志就不管了
如果线程阻塞在 I/O 或条件变量上，怎么及时响应退出
单纯轮询 stop_requested 会浪费 CPU。得把退出信号“注入”到阻塞点：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 对
std::condition_variable::wait()，用带谓词的重载：cv.wait(lock, [&]{ return stop_requested.load() || has_data; });，这样唤醒后立刻检查标志 - 对 socket I/O，Linux 可设
SO_RCVTIMEO并配合select()/poll()轮询；Windows 可用WSAEventSelect()+WaitForMultipleObjects() - 对长时间 sleep，拆成多个短 sleep：
for (int i = 0; i
别忽略 RAII 和异常安全：退出前必须清理资源
线程函数退出路径不止一个——可能正常结束、可能被 return 提前跳出、也可能抛异常。所有资源（文件句柄、内存、锁）都得靠 RAII 自动管理，不能依赖“最后几行代码”手动释放。
- 用
std::unique_lock而不是std::lock_guard？不行——后者不能提前释放；但更推荐全程用std::unique_lock配合作用域控制 - 打开的文件用
std::fstream，不要裸指针；动态分配用std::unique_ptr，别用new - 如果线程持有自定义资源（比如硬件设备句柄），确保其析构函数是 noexcept 且能安全关闭
真正麻烦的从来不是“怎么发停止信号”，而是“怎么确保所有退出路径都走完 cleanup”。多线程里少一行 close(fd) 就可能卡死整个程序。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
