std::thread 的析构函数会对其内部状态进行隐式检查。如果线程保持 joinable 状态——意味着它表示一个仍然活跃的执行线程，尚未被连接或分离——析构函数会调用 std::terminate 来防止程序在可能存在问题的线程上继续运行。这种设计强制执行明确的生命周期管理，但为异常安全和提前返回路径带来了显著的风险。
在 C++20 中引入的 std::jthread 通过在其 RAII 设计中封装合作取消和同步，消除了这种风险。它的析构函数首先通过内部的 std::stop_source 发出取消信号，然后自动调用 join()，阻塞直到线程执行完成。这确保线程在对象被销毁之前优雅地终止，消除了在没有手动干预的情况下意外终止的可能性。
// 危险：std::thread void risky_task() { std::thread t([]{ /* 背景工作 */ }); if (config_error) return; // 这里调用 std::terminate()！ t.join(); } // 安全：std::jthread void safe_task() { std::jthread t([](std::stop_token st) { while (!st.stop_requested()) { /* 工作 */ } }); if (config_error) return; // 安全：析构请求停止并连接 }
考虑一个高频交易应用，它生成一个市场数据馈送线程来处理传入的报价。如果在初始化期间网络配置无效，函数会提前返回，在调用 join() 之前销毁 std::thread 对象。这种情况在基于异步 I/O 的应用程序中经常发生，其中在创建线程后资源获取可能失败，导致生产环境中的立即崩溃。
考虑的一种方法是将线程包裹在手动的 try-catch 块中，确保 join() 在每个返回路径和异常处理程序之前执行。尽管这种方法是明确的，但它证明是脆弱的；添加新的退出点或重构频繁引入了遗漏连接逻辑的回归，导致在错误恢复期间偶发的 std::terminate 调用。
另一个评估的解决方案涉及一个自定义的 ScopeGuard 类，该类存储线程引用，并在其析构函数中连接它。虽然这封装了安全逻辑，但它复制了库中已标准化的功能，并要求在多个模块中维护样板代码，从而增加了技术债务和审查开销。
团队最终在迁移到 C++20 后采纳了 std::jthread。通过替换 std::thread，析构函数自动通过 std::stop_token 发出取消信号，并等待线程完成而无需手动同步块。这消除了在异常或提前返回期间确保清理的负担，从而使代码库更安全且更易于维护。
为什么在 std::thread 上调用两次 join() 会导致未定义行为，std::jthread 如何在程序上防止这种情况？
一个 std::thread 对象跟踪它是否持有有效的执行线程句柄。一旦调用 join()，线程变为不可加入，但标准并未规定后续调用是否安全地检查该状态。再次调用 join() 违反了线程必须是可连接的前提，导致未定义行为，通常表现为崩溃、死锁或资源泄漏。
std::jthread 通过稳健的内部状态跟踪使 join() 成为幂等的。它的析构函数仅在线程可加入时调用 join()，并且后续的显式调用不会执行任何操作，镜像了智能指针重置操作的行为，防止意外双重连接错误。
如何通过 std::jthread 的 std::stop_token 实现合作式取消，这为何优于异步线程中断原语？
std::jthread 将每个线程与 std::stop_source 配对，并将 std::stop_token 传递给线程的入口函数。工作线程定期检查 stop_requested() 以清晰地退出其循环，确保不变量保持并释放互斥量。这与 std::thread 显著对比，其中中断需要平台特定的调用，如 pthread_cancel 或 TerminateThread，这些调用强行在指令中条停执行，并可能使共享资源处于损坏或锁定的状态。
当 std::jthread 被移动到另一个对象时，取消信号发生了什么，正在运行的线程是否观察到转移？
当 std::jthread 被移动时，源对象放弃对底层线程句柄和 std::stop_source 的所有权，变得空和不可加入。目标对象接管线程的控制。重要的是，传递给工作函数的 std::stop_token 保持有效，因为它引用了由 std::stop_source 管理的 stop_state，只要任何 token 或 source 引用它，后者就会持续存在。线程继续在新的 jthread 对象的所有权下运行，并且通过新句柄发出的取消请求仍将无缝到达原始工作线程。