用 volatile bool 做中断标志不行，因其仅防止编译器优化，不保证原子性与内存顺序，多线程下可能读到陈旧值或被重排序；正确做法是用 std::atomic 或 c++20 的 std::jthread。
用 volatile bool 做中断标志为什么不行？
因为 volatile 只保证读写不被编译器优化掉，不提供原子性、不保证内存顺序，多线程下可能读到陈旧值或被重排序。常见现象是：主线程设了 stop_requested = true，工作线程却一直卡在循环里没退出。
正确做法是用 std::atomic<bool></bool>，它默认带 memory_order_seq_cst 语义，能跨线程可靠同步。
-
std::atomic<bool> stop_flag{false}</bool>—— 初始化必须显式，不能依赖隐式转换 - 读写都用
.load()和.store(true)，别直接用=赋值（虽然允许，但语义模糊） - 如果任务中存在长循环且无其他同步点，需在循环体内定期调用
stop_flag.load()，不能只在循环头检查一次
如何避免忙等待耗尽 CPU？
纯轮询 while (!stop_flag.load()) { /* work */ } 会让线程死占一个核，尤其空闲时毫无必要。
实际中应结合轻量级让出或条件等待：
立即学习“C++免费学习笔记（深入）”；
- 短暂停顿可用
std::this_thread::yield()，适合响应延迟要求不高（毫秒级）的场景 - 更省电的做法是用
std::condition_variable配合std::mutex，但要注意唤醒时机 —— 必须在修改stop_flag后立刻.notify_one() - 若任务本身有自然等待点（如
recv()、sleep_for()），直接在这些调用前检查stop_flag.load()即可，无需额外让出
中断点选在哪里才真正安全？
不是所有位置都能插中断检查。在资源持有期间（比如已加锁、已分配内存未释放、正在写文件中间）强行退出，会导致状态不一致。
安全中断点通常满足：当前操作已完成副作用，或能明确回滚。
- 避免在
std::lock_guard作用域内检查 —— 应在锁外判断，或改用带超时的try_lock_for - 网络 I/O 中，
send()后立即检查比recv()阻塞中检查更可控；后者建议用非阻塞 socket +poll()或select()统一管理中断 - 批量处理循环中，每处理 N 条数据检查一次
stop_flag，N 的选择取决于单条处理耗时和中断响应容忍度（比如 10–100）
std::jthread 怎么简化这件事？
C++20 的 std::jthread 内置协作式中断机制，比手管 std::atomic 更简洁，且自动 join，不易泄漏线程。
它的 std::stop_token 和 std::stop_callback 是关键：
- 构造
std::jthread t{worker, std::ref(stop_source)}，其中worker函数第一个参数必须是std::stop_token - 在循环中用
if (token.stop_requested()) break;—— 这比手动 load atomic 更语义清晰 - 需要清理资源时，用
std::stop_callback注册回调，它在线程被请求停止时自动触发，且保证只执行一次 - 注意：
std::jthread::request_stop()是线程安全的，但调用后不能假设工作函数立刻返回 —— 它只是发信号，仍需函数内配合检查
复杂点在于，现有代码迁移到 std::jthread 需重构函数签名；而 std::stop_callback 的生命周期绑定到 token，容易因提前销毁导致回调失效 —— 别把它定义在局部作用域里就完事。
