应使用 std::jthread + std::stop_token 实现自动生命周期绑定和协作式退出，避免裸 std::thread 导致的析构崩溃与未定义行为；监控循环需在每个阻塞点前检查 stop_requested() 并采用可中断等待机制。
为什么不能直接在成员函数里用 std::thread 启动监控线程
因为 std::thread 构造后必须显式分离或加入，否则析构时会调用 std::terminate() —— 这在线程还在运行、而对象已销毁的场景下极常见。尤其当监控线程访问 this 成员变量时，若类实例提前析构，线程继续读写就触发未定义行为。
协作式（cooperative）意味着线程需响应外部信号主动退出，而非被强制杀掉。所以必须提供安全的生命周期绑定和退出通知机制。
- 避免裸
std::thread：不管理join()/detach()容易崩溃 - 禁止在析构函数中仅靠
join()：若线程卡在等待中，析构会永久阻塞 - 不要用全局
std::atomic<bool></bool>控制多个实例：无法按对象粒度控制启停
用 std::jthread + std::stop_token 实现自动生命周期绑定
std::jthread（C++20）是 std::thread 的安全替代：构造时自动关联 std::stop_source，析构时自动 request_stop() 并 join()（除非已手动分离）。配合 std::stop_token 可让监控逻辑主动轮询退出信号。
关键点是把 std::jthread 作为类成员，并在监控函数开头检查 token.stop_requested()，而不是依赖 sleep_for 硬等。
立即学习“C++免费学习笔记（深入）”；
class Monitor {
std::jthread m_thread;
mutable std::shared_mutex m_data_mutex;
int m_counter = 0;
void monitor_loop(std::stop_token token) {
while (!token.stop_requested()) {
{
std::shared_lock lock(m_data_mutex);
// 执行轻量检查，如读传感器、查状态位
}
std::this_thread::sleep_for(100ms); // 避免忙等，但非必须
}
}
public:
void start() {
if (m_thread.joinable()) return;
m_thread = std::jthread{&Monitor::monitor_loop, this};
}
void stop() {
if (m_thread.joinable()) {
m_thread.request_stop(); // 触发 token.stop_requested() == true
m_thread.join(); // 等待自然退出（注意：此步可能阻塞）
}
}
};
如何避免 stop() 调用时卡死
std::jthread::request_stop() 是异步通知，但若监控循环正阻塞在系统调用（如 epoll_wait、sem_wait 或无超时的 condition_variable::wait），它不会立即返回 —— 导致 join() 长时间挂起。
- 对条件变量：改用
wait_until或wait_for，每次循环都检查token.stop_requested() - 对文件描述符等待：用
epoll_pwait或ppoll，传入可被信号中断的sigset_t，并在信号处理中调用notify_all() - 对网络 I/O：设置 socket 为非阻塞 +
poll/select，或使用带超时的recv（如MSG_DONTWAIT）
核心原则：所有可能长期阻塞的点，都必须有“可中断”路径，并在每次迭代开头或结尾检查 token.stop_requested()。
成员函数启动时如何确保线程安全访问类状态
监控线程与外部调用线程（如 start()、stop()、或其它 setter）共享类成员，必须保护可变状态。但别用粗粒度 std::mutex 锁整个对象 —— 监控循环频繁读，外部偶尔写，更适合读写锁。
- 读多写少场景：用
std::shared_mutex（C++17），监控线程用std::shared_lock，写操作用std::unique_lock - 简单标志位（如启用开关）：可用
std::atomic<bool></bool>，但注意它不保证内存顺序外的同步语义；若涉及多字段协同变化，仍需互斥锁 - 避免在监控循环中调用虚函数或外部回调：无法控制调用方是否线程安全，容易引入隐式竞争
真正容易被忽略的是：即使用了 std::jthread，若监控函数里捕获了 this 并在 lambda 中访问非原子成员，而对象已在别处析构，依然 UB。所以务必确保 m_thread 是最后一个被销毁的成员（声明顺序靠后），且 start() 不在构造函数中盲目调用。
