C++实现基于jthread的自动汇合线程 _ C++20协作式退出【源码】

C++实现基于jthread的自动汇合线程与协作式退出【源码】

在C++20中，jthread 带来了一个关键特性：自动汇合。这意味着，只要它持有一个活跃的线程，在其析构时就会自动调用 join()。这彻底告别了以往使用 std::thread 时必须手动检查并汇合的老套路——不再需要写 if (t.joinable()) t.join();，也无需额外封装RAII包装器。因为，jthread 本身就是一个完整的RAII对象。

为什么不用手动 join，但有时仍会 crash？

自动汇合听起来很美好，但它解决的只是“等待线程结束”的问题，而非“确保线程安全结束”。崩溃的根源往往在于线程函数访问了已销毁的资源。

• 最常见的情况是：线程函数通过 [&] 捕获了局部变量的引用，当这些变量的生命周期早于线程结束时，访问便成了未定义行为。
• 另一种情况是，在线程仍在运行时，jthread 对象本身被提前释放（例如被 vector::clear 清除，或因其所在作用域提前退出而析构）。虽然析构时会阻塞等待线程结束，但线程函数可能已经无法访问到预期的资源。
• 此外，jthread 在构造时若因系统资源不足而失败，会直接抛出 std::system_error，这一点与 std::thread 一致，并非静默失败。

如何正确配合 stop_token 实现协作式退出？

jthread 内置了 std::stop_source，可以通过 get_stop_token() 方法获取一个 std::stop_token，并将其传递给线程函数，用于轮询退出请求。需要明确的是，这是一种协作式退出机制，而非抢占式中断。线程函数必须主动检查停止信号。

jthread t([](std::stop_token st) {
    while (!st.stop_requested()) {
        // 执行主要工作...
        std::this_thread::sleep_for(100ms);
    }
    // 可选的清理逻辑
});

• 线程函数的首个参数必须显式声明为 std::stop_token，否则无法接收到停止通知。
• st.stop_requested() 是一个轻量级的无锁调用，可以高频检查。但为了避免在紧密循环中空转消耗CPU，通常需要配合 sleep 或条件变量等待，以保持响应性。
• 当外部调用 t.request_stop() 后，st.stop_requested() 会立即返回 true，但线程何时退出，完全取决于函数内部下一次检查的时机。

request_stop() 调用时机与线程状态的隐含依赖

request_stop() 方法是线程安全的，可以在任意时刻、从任意线程调用。它的作用仅仅是发出停止请求，本身既不阻塞，也不等待线程实际退出。真正的线程汇合，仍然发生在 jthread 对象析构的时刻。

立即学习“C++免费学习笔记（深入）”；

• 如果想实现“触发退出并等待完成”的流程，标准的做法是先调用 t.request_stop()，然后让 t 自然离开作用域析构，或者将其显式移动赋值为一个空的 jthread{}。
• 注意，不能对一个已经析构的 jthread 对象调用 request_stop()，否则会抛出 std::system_error（错误码为 std::errc::operation_not_permitted）。
• 还有一个容易忽略的静默失效点：如果线程函数根本没有接收和使用 stop_token 参数，那么即使成功调用了 request_stop()，线程也不会做出任何响应。

说到底，协作式退出的有效性，完全取决于线程函数内部是否及时、正确地响应 stop_token。自动汇合只是一个兜底的、确保资源不泄露的安全网，它并不能替代应用程序层面清晰、主动的退出逻辑。这一点，才是用好 jthread 的关键所在。