原子变量对recv/read/sleep无效，因线程阻塞在内核态无法执行用户代码；c++20的std::stop_token是标准解法，可注入退出信号使阻塞调用提前返回。
不能靠 std::atomic<bool></bool> 轮询就完事——IO 阻塞线程卡在内核态，根本不会回来检查标志。
为什么原子变量对 recv/read/sleep 无效
当线程调用 recv()、read()、accept() 或 std::this_thread::sleep_for() 时，它进入内核态等待事件。此时 CPU 不再执行用户代码，while (!stop_requested) 的判断永远不会被执行，哪怕主线程早已调用 stop_requested.store(true)。
- 普通
bool变量：多线程下读写不可见，可能永远读不到新值 -
std::atomic<bool></bool>：能保证可见性，但解决不了“线程不回来”的问题 - 所有基于轮询的方案（比如
poll()+recv()分两步）：只要recv()出现在循环体里，就存在二次阻塞风险
C++20 的 std::stop_token 是唯一标准解法
它把退出信号“注入”到阻塞点内部，让系统调用提前返回，而不是等它自己结束。
-
std::condition_variable::wait(lock, pred, token)：收到 stop 请求后立即返回，不再等待条件满足 -
std::this_thread::sleep_for(dur, token)：超时前收到请求即返回，返回值为false（不抛异常） -
std::jthread自带std::stop_source：构造即绑定，join()会自动等待停止完成
示例：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
std::jthread t([](std::stop_token token) {
while (!token.stop_requested()) {
std::unique_lock lk(mtx);
cv.wait(lk, token, [&]{ return !queue.empty(); });
if (token.stop_requested()) break;
auto task = std::move(queue.front());
queue.pop();
task();
}
});
注意：cv.wait(..., token) 已隐含检查，但显式加 if (token.stop_requested()) break; 更安全，防止谓词返回 true 后仍需退出。
非 C++20 环境必须手动唤醒阻塞点
Linux 下用 eventfd + epoll，Windows 下用 WSAEventSelect + WaitForMultipleObjects，核心原则是：所有阻塞调用都必须被纳入统一事件循环。
- 不要在
epoll_wait()后再单独调用recv()—— 这会导致第二次阻塞 - 正确做法：把 socket 和 eventfd 同时加入
epoll，收到 eventfd 事件即视为退出请求 - socket 必须设为非阻塞（
O_NONBLOCK），否则recv()仍可能阻塞 - 对
sleep类需求，改用epoll_wait()带 timeout，或拆成多个短usleep()并每次检查原子标志
资源清理不是“最后几行”，而是每条退出路径都要覆盖
线程退出可能发生在：正常循环结束、token.stop_requested() 检查后 break、cv.wait() 抛出 std::stop_exception、甚至未捕获异常。
- 所有句柄（文件、socket、eventfd）必须用 RAII 封装，如
std::fstream、std::unique_ptr、自定义fd_guard - 锁必须用
std::unique_lock（可提前释放），避免std::lock_guard在作用域末尾才解锁 - 析构函数必须是
noexcept，否则异常传播会终止程序
真正难的从来不是“怎么发停止信号”，而是确保 close(fd)、fclose(fp)、sqlite3_close() 这类调用，在任意退出分支下都必然执行——少一行，就可能卡死整个服务进程。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
