std::thread析构时若仍joinable会调用std::terminate；安全做法是持有thread成员并确保析构前join/detach，用atomic_bool协作退出，捕获this时优先用shared_ptr或weak_ptr。
成员函数里直接用 std::thread 启动监控线程，为什么一退出就崩溃？
因为 std::thread 对象析构时若仍处于 joinable() 状态，会调用 std::terminate() —— 这是 C++ 标准强制行为，不是平台或编译器问题。常见于成员函数中启动线程后立即返回，而线程还在跑，this 指针可能已失效，或对象被销毁时线程未被显式 join() 或 detach()。
安全做法是：在类中持有 std::thread 成员，并在构造时初始化、析构前确保其已结束；同时避免裸指针捕获 this。
- 不要在成员函数里写
std::thread{&MyClass::monitor, this}后不保存句柄 - 捕获
this时，优先用std::shared_ptr<myclass></myclass>管理生命周期，或确保线程只在对象存活期内运行 - 监控线程内部必须定期检查退出标志（如
std::atomic_bool），不能依赖外部对象“突然消失”来终止
如何让监控线程响应协作式退出（非 std::thread::join() 阻塞等待）
协作式退出 = 主动轮询退出信号 + 线程自行清理 + 主线程再 join()。关键在于：退出信号必须是原子的、跨线程可见的，且线程主循环要有明确的检查点。
典型结构是：std::atomic_bool m_stop_requested{false} 作为开关，监控线程循环中用 if (m_stop_requested.load()) break;，并在退出前做资源释放（如关闭文件描述符、释放锁等）。
立即学习“C++免费学习笔记（深入）”；
-
m_stop_requested必须声明为std::atomic_bool，不能用普通bool—— 否则存在数据竞争和缓存不一致风险 - 不要在循环里只靠
sleep或wait等待，必须每次迭代都检查m_stop_requested，否则退出延迟不可控 - 如果监控逻辑涉及条件变量（如
std::condition_variable::wait_until），需配合notify_one()在request_stop()中唤醒等待中的线程
成员函数启动线程时，捕获 this 的三种写法及风险对比
错误最密集的地方就在 lambda 捕获方式。以下三例均在成员函数内启动线程，但安全性差异极大：
-
[this]{ /* 直接用 this->xxx */ }()：危险！若对象在该线程执行期间被销毁，this成悬垂指针，访问即未定义行为 -
[self = shared_from_this()]{ /* self->xxx */ }()：安全前提是你继承自std::enable_shared_from_this，且对象由std::shared_ptr管理；否则shared_from_this()抛异常 -
[ptr = std::weak_ptr{m_self}]{ /* if (auto p = ptr.lock()) { p->xxx } */ }()：最健壮，适合不确定对象生命周期的场景；但每次访问都要lock()判断是否有效，有轻微开销
注意：m_self 是类中声明的 std::shared_ptr<myclass></myclass> 成员，需在构造时通过 shared_from_this() 初始化（仅限 enable_shared_from_this 子类）。
为什么不用 std::jthread？它真能简化协作退出吗？
std::jthread（C++20）确实内置了协作式中断机制，但它不是“自动退出”，而是提供 std::stop_token 和 std::stop_source 基础设施。你仍需在线程函数中主动检查 token.stop_requested()，并手动设计退出路径。
它比手写 atomic_bool 更规范，支持嵌套中断、可传递性，且析构时自动 join()（不会 terminate），但不解决“如何安全捕获 this”或“如何清理资源”的问题。
- 用
std::jthread启动时，传入的函数第一个参数必须是std::stop_token，否则无法接入中断机制 - 它不能替代
shared_ptr生命周期管理 —— 如果线程里还用this，照样会悬垂 - 若项目尚未启用 C++20，强行用
std::jthread会导致编译失败；退而求其次，手写atomic_bool + condition_variable是更通用的选择
真正容易被忽略的是：协作退出不是“发个信号就完事”，而是“信号 + 检查点 + 清理 + join”四步缺一不可；少一步，就可能卡死、泄漏或崩溃。
