用 std::jthread + std::stop_token 启动监控线程最安全，但必须在线程函数内主动轮询 token.stop_requested()，否则仍会访问已析构对象。
直接结论：用 std::jthread + std::stop_token 启动监控线程最安全，但必须在线程函数内主动轮询 token.stop_requested()，否则仍会访问已析构对象。
为什么裸调用 std::thread 启动成员函数大概率崩溃
典型现象是析构时触发 std::terminate，或线程首次访问成员变量就 segfault。根本原因不是语法错，而是 this 指针在监控线程运行期间失效——比如对象是栈上局部变量、智能指针管理但未自持有、或提前被 reset()。
- 错误写法：
std::thread{&MyClass::monitor, this}——this是裸指针，无生命周期保障 - 更隐蔽的错：
[this] { monitor(); }—— 捕获的是指针值，不延长对象生存期 - 即使对象由
std::shared_ptr管理，若未继承std::enable_shared_from_this，shared_from_this()会抛异常
如何用 std::jthread 避免 joinable() 导致的 std::terminate
std::jthread 在析构时自动调用 request_stop() 并阻塞等待，解决了裸 std::thread 忘记 join() 就销毁的致命问题。但它不解决对象生命周期问题——你传进去的 this 还是可能失效。
- 启动时必须用占位符：
std::jthread{&MyClass::monitor, this, std::placeholders::_1}，让jthread自动注入stop_token - 线程函数签名必须带
std::stop_token参数，不能捕获外部 token - 析构函数中不要手动
join()——jthread已处理；但要确保monitor()内部响应及时，否则析构会卡住
stop_token.stop_requested() 和手写 std::atomic_bool 的关键差异
表面都是查“是否退出”，但底层语义完全不同：前者是协作协议，后者只是共享标志。
-
stop_token保证原子读 + acquire-release 内存序，无需额外memory_order参数 -
request_stop()会同步更新所有复制出的 token 实例（包括线程内std::stop_callback注册的清理逻辑） - 手写
std::atomic_bool m_stop{false}容易漏掉初始化、忘记在析构前设为true，或在阻塞点（如cv.wait()）后才检查，导致延迟退出 -
stop_callback可用于注册轻量级收尾动作，比如关闭文件描述符、释放非 RAII 资源
监控循环里最容易被忽略的退出时序陷阱
线程函数返回 ≠ 对象安全析构。如果 stop_requested() 返回 true 后还继续访问 this 成员（比如做日志、清理、调用虚函数），就可能踩到析构中半销毁的对象。
- 正确做法：在
while(!token.stop_requested())循环体外不做任何依赖this的操作 - 循环内每次迭代起始处检查，而非只在循环条件里检查一次
- 避免在
sleep_for()或wait()后再检查——应改用带超时的wait_until()并配合token判断 - 如果监控逻辑本身阻塞（如
epoll_wait），需额外发 dummy event 或调用notify_one()唤醒等待点
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
