std::jthread配合stop_token能破掉成员函数死循环，因其提供协作式退出机制：自动在析构时request_stop并等待，且stop_token保证原子性、同步性和析构安全，要求循环内主动轮询token.stop_requested()。
为什么 std::jthread 配合 stop_token 能破掉成员函数死循环
因为普通线程（std::thread）没有内置退出通知机制，而类成员函数里写 while (true) 又极易忽略退出条件——结果就是对象析构了，线程还在跑，访问已销毁的 this 导致未定义行为。用 std::jthread + stop_token 是 C++20 提供的协作式退出标准方案，它把“该不该继续运行”的判断权交还给线程自身，且能在线程 join 时自动请求停止。
在类成员函数中正确使用 stop_token 的三步写法
关键不是加个参数，而是让循环体主动轮询、及时响应，并确保 token 绑定到当前线程的停止状态：
- 把
std::stop_token作为成员函数参数传入（不能捕获外部 token，必须由std::jthread构造时注入） - 循环内用
token.stop_requested()判断，而不是只靠外部 flag 或 sleep 后再检查 - 避免在
stop_requested() == true后还执行耗时操作或访问成员变量——此时对象可能正在析构
示例片段：
class Worker {
public:
void run(std::stop_token token) {
while (!token.stop_requested()) {
do_work();
std::this_thread::sleep_for(100ms);
}
// 此处可做轻量级收尾，但不要调用依赖 this 的复杂逻辑
}
private:
void do_work() { /* ... */ }
};
启动方式：std::jthread t(&Worker::run, &w, std::placeholders::_1); —— 注意占位符 std::placeholders::_1 让 jthread 自动传入自己的 stop_token。
stop_token 和自定义 bool flag 相比差在哪
表面看都是查一个“是否退出”，但底层语义和可靠性完全不同：
-
stop_token.stop_requested()是原子读+内存序保证，无需额外std::atomic封装 - 调用
jthread.request_stop()会同步触发所有关联 token 的状态变更，包括已复制出的多个 token 实例 - 自定义
std::atomic<bool> stop_flag</bool>容易漏掉 memory_order，或在析构时忘记设为 true，导致线程永远卡住 -
stop_token支持注册回调（stop_callback），适合清理资源，而 flag 没有这种扩展能力
最容易被忽略的析构时序陷阱
std::jthread 在析构时会自动调用 request_stop() 并阻塞等待线程结束——但这只有在线程函数真正响应 stop_requested() 时才安全。如果成员函数里有：
- 没检查 token 就直接进入长耗时计算（比如大数组遍历没分段检查）
- 用了
std::condition_variable::wait却没配合stop_token的 predicate 重载（C++20 提供了wait(token, pred)） - 在
token.stop_requested()为 true 后，又调用了已被析构的成员函数或访问了已 move 离开的资源
这些都会导致崩溃或 hang 住。真正安全的做法是：每次循环入口检查 token，且所有阻塞点都需支持提前唤醒。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
