必须显式管理std::thread生命周期：声明为类成员、启动前检查joinable、用std::atomic控制退出、析构时先stop再join，避免terminate和资源泄漏。
成员函数里直接用 std::thread 启动监控线程，但别裸奔
不能在成员函数里简单写 std::thread{&MyClass::monitor_loop, this} 就完事——线程对象一旦脱离作用域（比如函数返回），它会自动调用 std::terminate()。这是最常踩的坑，错误信息通常是 terminate called without an active exception。
必须显式管理线程生命周期：
- 把
std::thread成员变量声明为类内字段（如std::thread monitor_thread_） - 启动前先检查是否已运行：
if (!monitor_thread_.joinable()) { monitor_thread_ = std::thread{...}; } - 避免重复启动：多次调用启动函数时，应跳过或主动 stop+rejoin
用 std::atomic<bool></bool> 控制循环退出，别用普通 bool
监控线程通常长跑在 while 循环里，靠一个标志位控制退出。如果用普通 bool running_，编译器可能优化掉内存读取，或因缓存不一致导致线程永远看不到修改。必须用 std::atomic<bool></bool>。
典型写法：
std::atomic<bool> stop_requested_{false};
void monitor_loop() {
while (!stop_requested_.load(std::memory_order_acquire)) {
// 执行检测逻辑
std::this_thread::sleep_for(100ms);
}
}
</bool>
注意：load() 和 store() 默认使用 memory_order_seq_cst 也行，但显式加 acquire/release 更清晰；不要用 volatile 替代 atomic，它不提供线程同步语义。
析构函数里必须 join() 或 detach()，推荐 join()
类析构时若 monitor_thread_ 还活着且未 join()，会触发 std::terminate()。所以析构函数里要处理：
- 先设置
stop_requested_.store(true) - 再调用
monitor_thread_.join()—— 这是协作式退出的关键一步 - 如果担心
join()阻塞太久（比如监控逻辑卡死），可加超时等待 + 强制detach()，但 detach 后线程变成“孤儿”，无法保证资源清理，慎用
别在析构里只写 if (monitor_thread_.joinable()) monitor_thread_.join();，漏掉 stop 请求会导致 join 永远卡住。
监控逻辑中避免阻塞太久，否则 stop_requested_ 响应延迟
如果 monitor_loop() 里调用了无超时的 std::condition_variable::wait()、socket::recv() 或其他可能长期阻塞的操作，stop_requested_ 就没法及时被检查到。
解决方法：
- 改用带超时的等待：
cv_.wait_for(lock, 100ms, [&]{ return stop_requested_.load(); }); - 对 socket 使用非阻塞模式 +
select()/poll()，或设SO_RCVTIMEO - 避免在监控线程里做耗时同步 I/O；真需要，拆成独立 worker 线程，本线程只负责调度和信号响应
协作式退出不是“发个信号就立刻停”，而是“每轮循环都检查一次，尽快响应”。响应延迟取决于你单次循环的最大耗时。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
