笙亿网络策划

C++20的std::jthread与std::thread的区别是什么？

约 6 分钟读完 1 阅
文章导读
排查时，我会先确认当前代码中 std::thread 对象的析构时机。最直观的区别是：std::jthread 与 std::thread 最直观的区别在于析构行为：当 std::jthread 对象析构时，如果线程仍可 join，它会自动调用 join() 等待线程结束；而 std::thread 析构时若线程可 join 则会调用 std::terminate 终止程序。这意味着使用 std:
📋 目录
  1. 壹 先看析构行为：自动 join 与 terminate
  2. 贰 内置停止令牌：协作式取消
  3. 叁 异常场景下的安全差异
  4. 肆 迁移步骤与配置检查
  5. 伍 验证方法
  6. 陆 回滚和风险
A A

先看析构行为：自动 join 与 terminate

排查时，我会先确认当前代码中 std::thread 对象的析构时机。最直观的区别是：std::jthread 与 std::thread 最直观的区别在于析构行为：当 std::jthread 对象析构时，如果线程仍可 join，它会自动调用 join() 等待线程结束；而 std::thread 析构时若线程可 join 则会调用 std::terminate 终止程序。这意味着使用 std::jthread 可以避免因忘记 join 导致的资源泄漏或崩溃，但同时也丢失了 detach 的能力。如果你需要线程独立运行（detach），或者希望完全控制 join 时机，应选择 std::thread。 这段描述直接指出了两种线程模型的核心差异。实际排查中，我会先检查项目中是否有未 join 的 std::thread 导致崩溃，如果经常出现，那替换为 std::jthread 可以自动修复这类问题。但要注意，如果现有代码依赖于 std::thread 析构时的 terminate 行为（例如作为断言检查），替换后行为会改变，需要调整测试用例。

内置停止令牌：协作式取消

另一个需要确认的方面是线程是否经常需要被外部信号中断。很多项目中用 std::atomic<bool> 或 std::promise 来自制停止标志，代码分散且容易出错。这时就可以考虑使用 std::jthread 的内置机制：std::jthread 内置了一个 std::stop_token 对象，通过 get_stop_token() 获取，并支持 request_stop() 主动发出停止请求。线程函数可以周期性检查 stop_token 的 stop_requested() 来优雅退出。而 std::thread 没有内置停止设施，需要自行实现，通常使用 std::atomic 或 std::promise 等，增加了代码复杂度和出错可能。如果你的线程需要响应外部取消信号，std::jthread 提供了现成的协作式取消方案。 替换后，线程函数内需添加对 stop_requested() 的检查点，否则停止请求会失效。验证方法：在测试中调用 request_stop() 并观察线程是否在合理时间内退出，同时检查线程函数是否正确处理了停止标志。

异常场景下的安全差异

当代码中有可能抛出异常时，我会特别注意线程对象的生命周期。在异常场景下，std::jthread 的自动 join 特性提升了异常安全性。例如，当某个作用域内创建了 std::thread 对象，接着抛出异常导致栈展开时，std::thread 的析构会触发 std::terminate，而 std::jthread 会安全地等待线程结束。这使得在异常可能发生的代码中，std::jthread 比 std::thread 更鲁棒。但需注意，自动 join 也会阻塞当前线程，若线程执行时间很长或死循环，可能导致死锁或长时间阻塞，应结合停止令牌使用。 如果项目中存在这种异常路径，建议先对每个 std::thread 使用场景添加 RAII 包装（比如 scoped_thread），再逐步替换为 std::jthread。验证方法：构造一个会抛出异常的作用域，观察程序是否崩溃或正常退出。

迁移步骤与配置检查

如果决定迁移，可以按以下顺序处理：第一步，将所有 std::thread 声明替换为 std::jthread，保持构造参数不变（接口高度相似）。第二步，删除原来手动 join 的调用（如果依赖自动 join）。第三步，在需要停止控制的线程函数中插入 stop_token 检查点。不需要修改头文件，C++20 标准库已提供。检查编译器版本：例如 GCC 10+、Clang 12+、MSVC 16.10+ 支持。可在 CMakeLists.txt 中设置 set(CMAKE_CXX_STANDARD 20)，然后编译测试。

C++20的std::jthread与std::thread的区别是什么？

验证方法

替换后，可以通过单元测试验证析构行为：创建 std::jthread 并直接让其离开作用域，观察线程是否正常 join 而非terminate。对于停止机制，编写一个循环检查 stop_requested() 的线程函数，然后从外部调用 request_stop() 并确认线程退出。同时检查性能：虽然 std::jthread 有 stop_token 的额外开销，但通常可以忽略。如果仍有疑虑，可以在压测中对比两种实现的 CPU 占用和响应时间，但在生产环境前需要先在小流量中验证。

回滚和风险

如果替换后发现行为异常，比如线程自动 join 导致主线程阻塞过长，或者 detach 的代码出错，回滚方案很简单：将 std::jthread 改回 std::thread 并恢复手动 join/detach 逻辑。风险主要来自两个地方：一是 stop_token 带来的极小内存开销（通常一个原子变量），二是自动 join 可能掩盖设计问题（例如线程应该被 detach 却依赖自动 join）。建议先在非关键路径上试用，确认符合预期后再全面推广。

最后，后续维护时，如果代码中同时存在两种线程类，容易造成混乱。建议统一使用 std::jthread，除非确实需要 detach 行为或对极低延迟有要求。可以在代码规范中注明：新线程一律使用 std::jthread，旧代码逐步迁移。遇到需要 detach 的场景，可以显式调用 detach()，但那样会失去自动 join 的优势，需要评估得失。