必须显式join()或detach()，因std::thread析构时若可joinable会调用std::terminate；正确做法是协作退出：用atomic标志+join()，或升级到C++20的std::jthread自动管理。
不能直接在成员函数里用 std::thread 启动裸线程并“托管”给类生命周期——线程对象析构时若仍在运行会调用 std::terminate，这是最常踩的坑。
为什么 std::thread 成员变量必须显式 join() 或 detach()
类中持有 std::thread 成员时，其析构函数会检查是否可 joinable：若为 true（即线程还在跑），直接终止程序。这不是 bug，是标准强制的安全机制。
- 不加任何处理就让线程随类析构 → 程序崩溃，错误信息通常是
terminate called without an active exception -
detach()虽能避免崩溃，但失去控制权：无法等待、无法通知退出、无法捕获异常，监控任务可能访问已销毁的this指针 - 正确做法是：在类析构前确保线程已结束，通常靠
join()+ 原子标志位协同退出
如何安全启动常驻监控线程（带退出信号）
核心是“协作式退出”：线程循环检测一个 std::atomic<bool></bool> 标志，外部通过修改该标志触发退出流程，再 join() 等待收尾。
- 声明成员：
std::atomic<bool> m_stop_requested{false}; std::thread m_monitor_thread;</bool> - 启动逻辑（例如在
start_monitoring()中）：m_monitor_thread = std::thread(&MyClass::monitor_loop, this); - 监控循环体必须包含：检查
m_stop_requested.load()、短时休眠（如std::this_thread::sleep_for(100ms)）、避免忙等 - 停止逻辑（例如
stop_monitoring()）：m_stop_requested = true; if (m_monitor_thread.joinable()) m_monitor_thread.join();
成员函数捕获 this 时的生命周期风险
异步线程内访问 this 是危险的——如果对象在监控线程运行期间被销毁，后续对成员变量或函数的调用就是未定义行为。
立即学习“C++免费学习笔记（深入）”；
- 仅靠
join()不足以保证安全：若用户先调用stop_monitoring()再立即销毁对象，没问题；但若没调用就销毁，std::thread析构仍会 terminate - 更稳健的做法是把监控逻辑移到独立函数或 lambda，并用
std::shared_ptr持有对象引用（例如auto self = shared_from_this();），前提是类继承自std::enable_shared_from_this - 若不用智能指针，至少要在文档/注释里明确要求：必须先调用停止接口，再销毁对象
替代方案：用 std::jthread（C++20）简化管理
C++20 引入的 std::jthread 自动在析构时调用 join()，且内置 std::stop_token 支持标准化中断协议，比手写原子标志更清晰可靠。
- 声明：
std::jthread m_monitor_thread; - 启动：
m_monitor_thread = std::jthread([this](std::stop_token stoken) { monitor_loop(stoken); }); - 循环内用
stoken.stop_requested()替代原子变量，语义更准确 - 析构时自动
join()，无需手动干预；若需提前退出，调用m_monitor_thread.request_stop() - 注意：
std::jthread不能跨 C++ 标准混用，旧项目需谨慎升级工具链
真正麻烦的不是启动线程，而是定义清楚“谁负责何时释放资源、谁拥有退出控制权、监控逻辑依赖的成员是否还活着”。哪怕用了 std::jthread，只要循环里访问了非原子的成员变量，仍得自己保证线程安全。
