C++20 std::jthread 详解：告别手动 join，拥抱协作式中断

1. 项目概述：为什么我们需要更现代的线程管理？

如果你写过C++多线程程序，大概率用过std::thread。从C++11引入至今，它一直是标准库中创建和管理线程的基石。但用过的人都知道，它有个“臭名昭著”的毛病：如果你忘记在析构前调用join()或detach()，程序就会直接std::terminate，毫不留情地崩溃。这就像你雇了个工人，活干到一半你直接关门走人，工人（线程）没地方去，整个工地（程序）就炸了。这种“资源泄漏即崩溃”的严格策略，初衷是好的，是为了防止悬空线程，但在实际开发中，尤其是异常安全、复杂生命周期管理的场景下，它成了无数bug和深夜调试的源头。

于是，C++20带来了std::jthread。这个“j”可以理解为“joining”或者“joyful”，因为它最大的改进就是自动汇合（automatic joining on destruction）。但这仅仅是它最表面的特性。std::jthread更深层的价值在于，它将线程与一个可中断的、更结构化的执行模型绑定在一起，引入了std::stop_token和std::stop_source这一套协作式中断机制。这意味着，我们终于有了一个标准化的、安全的方式来请求一个线程“优雅地停下来”，而不是粗暴地调用std::terminate或者依赖平台特定的API。

简单来说，std::thread是手动挡，给你最大的控制权，但也把所有的责任（和风险）都交给了你。std::jthread则是自动挡，内置了“安全气囊”（自动汇合）和“定速巡航”（协作中断），让你在享受便利的同时，写出更健壮、更易维护的并发代码。接下来，我会结合大量实际代码示例，带你彻底搞懂两者的使用、区别以及如何在实际项目中做出选择。

2. 核心细节解析：从 std::thread 的基础到陷阱

2.1 std::thread 的创建与基本生命周期

创建一个std::thread非常简单，你只需要传递一个可调用对象（函数、Lambda表达式、函数对象等）给它。

#include <iostream> #include <thread> #include <chrono> void helloFunction() { std::this_thread::sleep_for(std::chrono::seconds(1)); std::cout << "Hello from function! Thread ID: " << std::this_thread::get_id() << std::endl; } int main() { // 方式1：使用函数指针 std::thread t1(helloFunction); // 方式2：使用Lambda表达式（更常用） std::thread t2([](){ std::this_thread::sleep_for(std::chrono::milliseconds(500)); std::cout << "Hello from lambda! Thread ID: " << std::this_thread::get_id() << std::endl; }); // 方式3：使用带参数的函数 std::thread t3([](const std::string& msg, int value){ std::cout << msg << " with value: " << value << std::endl; }, "Hello with args", 42); // 必须等待线程结束，否则主线程退出会导致未定义行为 t1.join(); t2.join(); t3.join(); std::cout << "All threads finished.\n"; return 0; }

这里有几个关键点：

1. 线程立即启动：一旦std::thread对象被构造，操作系统线程就开始执行（具体时机由调度器决定）。
2. 参数传递：向线程函数传递参数是直接进行的，参数会被移动或复制到新线程的存储空间中。这意味着你需要确保传递的参数在新线程的整个执行周期内都是有效的。传递指针或引用到局部变量是危险的。
3. join()的必要性：join()会阻塞调用它的线程（通常是主线程），直到被join的线程执行完毕。这是确保线程安全结束、回收其资源的正确方式。

注意：std::thread对象本身是不可复制的，但它是可移动的。这体现了线程句柄的独占所有权语义——一个线程只能由一个std::thread对象管理。

std::thread t1([]{ /* ... */ }); // std::thread t2 = t1; // 错误！不可复制 std::thread t3 = std::move(t1); // 正确！所有权转移，t1不再代表任何线程 // 现在由 t3 来管理这个线程，t1.joinable() == false

2.2 第一个大坑：析构时的 std::terminate

这是std::thread最著名的陷阱。C++标准规定，如果一个std::thread对象在析构时仍然是joinable的（即，它关联着一个正在运行或可能正在运行的线程），那么std::terminate()会被调用，整个程序立即终止。

void riskyFunction() { std::thread t([]{ std::this_thread::sleep_for(std::chrono::seconds(2)); std::cout << "Work done.\n"; }); // 忘记调用 t.join() 或 t.detach() } // t 离开作用域，析构！因为 t 仍是 joinable 的，程序崩溃！ int main() { riskyFunction(); std::cout << "This line will never be reached.\n"; return 0; }

为什么设计得这么严格？这背后是C++“资源获取即初始化”（RAII）哲学和避免未定义行为的权衡。如果一个线程被无声无息地丢弃，它可能还在访问已经销毁的栈变量、持有锁、或进行其他操作，导致数据竞争、死锁或资源泄漏，这种bug极难追踪。强制崩溃至少让问题在测试阶段暴露出来。

如何避免？你必须确保在std::thread对象生命周期结束前，线程状态是非 joinable 的。有三种途径：

1. join()：等待线程完成。这是最常用、最安全的方式。
2. detach()：将线程与std::thread对象分离，允许线程“在后台”独立运行。分离后，你无法再与之交互（join或获取id）。慎用，因为你需要确保分离的线程不会访问已失效的数据。
3. 移动所有权：将线程的所有权移动给另一个生命周期更长的std::thread对象。

实操心得：使用RAII包装器在实际项目中，手动管理join()很容易出错，尤其是在有多个返回路径或可能抛出异常的代码中。一个经典的技巧是使用一个简单的RAII包装器：

class ThreadGuard { std::thread& t_; public: explicit ThreadGuard(std::thread& t) : t_(t) {} ~ThreadGuard() { if (t_.joinable()) { t_.join(); // 或者根据策略选择其他操作 } } // 禁止拷贝和移动，确保职责明确 ThreadGuard(const ThreadGuard&) = delete; ThreadGuard& operator=(const ThreadGuard&) = delete; }; void safeFunction() { std::thread t([]{ /* ... */ }); ThreadGuard g(t); // 析构时自动join // ... 可能抛出异常的代码 // 无论是否异常，g的析构函数都会确保t被join }

C++20的std::jthread本质上就是这个模式的官方、增强版实现。

2.3 线程标识、硬件并发数与 yield

std::thread提供了一些有用的静态和成员函数来查询线程信息。

• std::this_thread::get_id()：获取当前线程的唯一标识符。可用于日志记录或调试。
• std::thread::hardware_concurrency()：一个静态函数，返回当前系统支持的真正并发运行的线程数（通常是CPU核心数）。这是进行线程池大小等配置时的重要参考，但注意它可能返回0（如果信息不可用）。
• std::this_thread::yield()：提示调度器让出当前线程的时间片，让其他就绪线程有机会运行。在忙等待（busy-wait）循环中，适当使用yield()可以减少CPU空转，但现代同步原语（如条件变量）通常是更好的选择。

int main() { std::cout << "Hardware concurrency: " << std::thread::hardware_concurrency() << std::endl; std::thread t1([]{ std::cout << "T1 ID: " << std::this_thread::get_id() << '\n'; }); std::thread t2([]{ std::cout << "T2 ID: " << std::this_thread::get_id() << '\n'; }); std::cout << "Main thread ID: " << std::this_thread::get_id() << '\n'; std::cout << "t1 ID: " << t1.get_id() << '\n'; // 注意：get_id() 是成员函数 t1.join(); t2.join(); return 0; }

3. std::jthread 的革新：自动汇合与协作中断

3.1 自动汇合：告别手动 join 的烦恼

std::jthread在接口上几乎与std::thread完全兼容，但它的析构函数行为不同：如果它是 joinable 的，析构函数会自动调用join()。这彻底解决了忘记 join 导致崩溃的问题。

#include <iostream> #include <thread> // C++20 起，jthread 也在 <thread> 头文件中 void simpleWork() { std::this_thread::sleep_for(std::chrono::seconds(1)); std::cout << "Work completed in jthread.\n"; } int main() { { std::jthread jt(simpleWork); // 不需要手动调用 jt.join() } // jt 离开作用域，析构函数自动调用 join()，等待线程结束 std::cout << "jthread destroyed safely. Main continues.\n"; // 对比 std::thread 的危险行为 // { // std::thread t(simpleWork); // } // 这里会崩溃！ return 0; }

这带来了巨大的便利性和代码简洁性。你可以在函数中自由地创建std::jthread对象，而不用担心异常安全或复杂的控制流。当然，如果你有特殊需求，仍然可以手动调用join()或detach()，但手动detach()后，析构时就不会再join了。

3.2 协作式中断机制：std::stop_token 与 std::stop_source

这是std::jthread相比std::thread最强大的特性。它引入了一套标准化的、请求线程停止执行的机制。

核心组件：

• std::stop_source：停止请求的“生产者”。持有它就可以发出停止请求。
• std::stop_token：停止请求的“消费者”。线程可以通过它来查询是否收到了停止请求。
• std::stop_callback：注册一个回调函数，当停止请求发出时自动执行。

std::jthread与它们的关联：每个std::jthread对象内部都拥有一个std::stop_source，并且会在构造时将这个stop_source对应的stop_token传递给线程函数（作为第一个参数，如果线程函数接受的话）。

void interruptibleWork(std::stop_token stoken) { for (int i = 0; i < 10; ++i) { // 每次循环前检查是否被请求停止 if (stoken.stop_requested()) { std::cout << "Stop requested. Cleaning up and exiting.\n"; return; // 优雅退出 } std::cout << "Working... " << i << std::endl; std::this_thread::sleep_for(std::chrono::milliseconds(500)); } std::cout << "Work finished normally.\n"; } int main() { std::jthread worker(interruptibleWork); // stop_token 被自动传递给函数 // 主线程做一些其他事情 std::this_thread::sleep_for(std::chrono::seconds(2)); std::cout << "Main thread requesting stop.\n"; worker.request_stop(); // 请求 worker 线程停止 // jthread 析构时会自动 join，等待 worker 线程响应停止请求并退出 // 不需要显式调用 worker.join() return 0; }

关键点解析：

1. 线程函数签名：要使线程能接收中断信号，其第一个（且仅第一个）参数必须是std::stop_token类型。std::jthread的构造函数会检测这一点。
2. request_stop()：这是std::jthread的成员函数，调用它即向其内部的stop_source发出停止请求。所有关联的stop_token都会立刻感知到。
3. 协作式：线程函数必须主动、定期地检查stop_token.stop_requested()。这个机制不会强制杀死线程，它只是传递一个请求。线程有责任在合适的时候检查并清理资源后退出。这避免了强制终止可能导致的资源泄漏和数据不一致。
4. stop_possible()：你可以通过stop_token检查是否有可能接收到停止请求（即，是否有关联的、尚未发出请求的stop_source）。

3.3 高级中断技巧：stop_callback 与条件变量集成

使用std::stop_callback进行资源清理有时，线程可能阻塞在某个不支持直接检查stop_token的操作上（比如一个第三方库的阻塞调用）。std::stop_callback允许你注册一个回调，当停止请求发出时立即执行，你可以在回调中设置标志或执行特定操作来唤醒阻塞的线程。

void workWithCallback(std::stop_token stoken) { std::stop_callback callback(stoken, []{ std::cout << "Stop callback triggered! Performing urgent cleanup.\n"; // 例如：关闭一个文件描述符，设置一个原子标志等 }); // 模拟一个长耗时、不支持中断的阻塞操作（通过循环模拟） auto start = std::chrono::steady_clock::now(); while (std::chrono::steady_clock::now() - start < std::chrono::seconds(5)) { if (stoken.stop_requested()) { std::cout << "Exiting after callback.\n"; return; } std::this_thread::sleep_for(std::chrono::milliseconds(100)); } std::cout << "Long operation finished.\n"; }

与std::condition_variable_any集成标准库提供了std::condition_variable_any，它是一个可以与任何锁类型配合使用的条件变量，并且原生支持std::stop_token。这为编写可中断的等待逻辑提供了极大便利。

#include <iostream> #include <thread> #include <queue> #include <mutex> #include <condition_variable> void consumer(std::stop_token stoken, std::queue<int>& queue, std::mutex& mtx, std::condition_variable_any& cv) { std::unique_lock<std::mutex> lock(mtx); // 使用支持 stop_token 的 wait 方法 cv.wait(lock, stoken, [&queue] { return !queue.empty(); }); // wait 的第三个参数是谓词，第二个参数是 stop_token。 // 当 stop 被请求时，wait 会立即返回，即使谓词为 false。 if (stoken.stop_requested()) { std::cout << "Consumer stopped while waiting.\n"; return; } // 正常处理数据 int data = queue.front(); queue.pop(); std::cout << "Consumed: " << data << std::endl; } int main() { std::queue<int> queue; std::mutex mtx; std::condition_variable_any cv; std::jthread consumerThread(consumer, std::ref(queue), std::ref(mtx), std::ref(cv)); // 主线程生产一些数据 { std::lock_guard<std::mutex> lock(mtx); queue.push(1); std::cout << "Produced: 1\n"; } cv.notify_one(); std::this_thread::sleep_for(std::chrono::seconds(1)); // 请求停止，即使消费者在等待，也会被唤醒并退出 std::cout << "Requesting stop.\n"; consumerThread.request_stop(); cv.notify_all(); // 通常配合 request_stop 一起通知，确保等待的线程被唤醒 // jthread 自动 join return 0; }

这种集成使得编写可安全退出的生产者-消费者模式变得异常简洁和可靠。

4. 深入对比与选型指南

4.1 功能与行为对比表

4.2 何时选择 std::thread？

尽管std::jthread更安全、功能更强，但std::thread仍有其适用场景：

1. 兼容旧代码/旧标准：项目必须兼容C++11/14/17标准。
2. 极致性能与最小开销：在对性能极其敏感、且线程生命周期非常简单（例如，创建后立即detach的守护线程）的场景下，std::thread的极简抽象可能有一丝优势。
3. 需要特殊析构行为：如果你明确需要在线程对象析构时执行detach()而不是join()，那么使用std::thread并手动detach()更清晰。虽然std::jthread也可以detach()，但它的默认安全行为（自动join）可能不是你想要的心理模型。
4. 第三方库或框架集成：某些库可能要求传递原生的std::thread对象。

4.3 何时选择 std::jthread？

对于绝大多数新的C++20及以上项目，std::jthread应该是默认选择。

1. 默认安全：自动汇合消除了最常见的一类并发bug，让异常安全变得简单。
2. 标准化中断：stop_token机制提供了一种干净、可组合的方式来请求线程停止，无需自己重新发明轮子（原子布尔标志+条件变量）。这大大简化了线程池、任务执行器等组件的实现。
3. 代码简洁性：省去了大量的try-catch块和手动join()调用，代码意图更清晰。
4. 与标准库更好集成：如condition_variable_any::wait对stop_token的支持，使得编写可取消的等待逻辑更加容易。

实操心得：项目中的迁移策略如果你正在维护一个使用std::thread的大型项目并计划迁移到C++20，不建议一次性全局替换。可以采取以下策略：

• 新代码一律使用std::jthread。
• 对于旧代码，在修改或重构相关模块时，逐步将std::thread替换为std::jthread。替换时注意检查线程函数是否需要适配stop_token参数。
• 对于非常稳定、生命周期简单的旧线程代码，如果改动风险大，可以暂时保留std::thread。

5. 实战：构建一个简单的可中断线程池

为了综合运用所学，我们来实现一个简易的、使用std::jthread和std::stop_token的线程池。这个线程池可以优雅地处理任务执行和关闭。

#include <iostream> #include <vector> #include <queue> #include <thread> #include <mutex> #include <condition_variable> #include <functional> #include <future> class SimpleThreadPool { public: explicit SimpleThreadPool(size_t num_threads = std::thread::hardware_concurrency()) { workers_.reserve(num_threads); for (size_t i = 0; i < num_threads; ++i) { // 为每个工作线程创建一个 jthread workers_.emplace_back(&SimpleThreadPool::workerLoop, this); } } ~SimpleThreadPool() { // 1. 请求所有线程停止 for (auto& worker : workers_) { if (worker.joinable()) { worker.request_stop(); } } // 2. 通知所有可能正在等待的条件变量 { std::lock_guard<std::mutex> lock(queue_mutex_); cv_.notify_all(); } // 3. jthread 析构函数会自动 join 每个线程 } // 提交任务，返回一个 future 以获取结果 template<typename F, typename... Args> auto submit(F&& f, Args&&... args) -> std::future<decltype(f(args...))> { using return_type = decltype(f(args...)); // 将任务包装进 packaged_task，以便获取 future auto task = std::make_shared<std::packaged_task<return_type()>>( std::bind(std::forward<F>(f), std::forward<Args>(args)...) ); std::future<return_type> result = task->get_future(); { std::lock_guard<std::mutex> lock(queue_mutex_); if (stop_requested_) { throw std::runtime_error("submit on stopped ThreadPool"); } tasks_.emplace([task](){ (*task)(); }); } cv_.notify_one(); return result; } private: void workerLoop(std::stop_token stoken) { while (!stoken.stop_requested()) { std::function<void()> task; { std::unique_lock<std::mutex> lock(queue_mutex_); // 可中断的等待：当有任务或收到停止请求时唤醒 cv_.wait(lock, stoken, [this] { return !tasks_.empty(); }); // 如果是因为停止请求而唤醒，且任务队列为空，则退出循环 if (stoken.stop_requested() && tasks_.empty()) { break; } // 取出任务 task = std::move(tasks_.front()); tasks_.pop(); } // 执行任务 task(); } // 线程退出前可以做一些清理工作 // std::cout << "Worker thread exiting.\n"; } std::vector<std::jthread> workers_; std::queue<std::function<void()>> tasks_; std::mutex queue_mutex_; std::condition_variable_any cv_; // 使用 _any 以支持 stop_token std::atomic<bool> stop_requested_{false}; }; // 使用示例 int main() { SimpleThreadPool pool(4); std::vector<std::future<int>> results; // 提交一批任务 for (int i = 0; i < 10; ++i) { results.emplace_back(pool.submit([i]{ std::this_thread::sleep_for(std::chrono::milliseconds(100)); std::cout << "Task " << i << " executed by thread " << std::this_thread::get_id() << std::endl; return i * i; })); } // 获取结果 for (auto& fut : results) { std::cout << "Result: " << fut.get() << std::endl; } // 析构时，pool会自动请求停止并等待所有线程结束 std::cout << "All tasks done. ThreadPool will now shut down gracefully.\n"; return 0; }

这个线程池的关键设计点：

1. std::jthread作为工作者：每个工作线程都是一个std::jthread，其线程函数workerLoop接受一个std::stop_token。
2. 可中断的等待：工作线程使用condition_variable_any::wait并传入stop_token。这样，当线程池析构调用request_stop()时，所有阻塞在wait上的线程都会被立即唤醒，从而快速退出循环。
3. 优雅关闭：析构函数首先对所有jthread调用request_stop()，然后通知条件变量，最后依靠jthread的析构函数自动join等待所有线程结束。这确保了所有已提交的任务都被执行（除非在停止请求后才从队列取出），并且没有线程被遗弃。
4. 任务提交与Future：使用std::packaged_task和std::future来支持获取异步任务的结果，这是线程池的常见需求。

6. 常见问题与排查技巧实录

6.1 编译与兼容性问题

问题：代码中使用std::jthread编译报错 “未定义的标识符” 或 “不是 std 的成员”。排查：

1. 检查编译器版本和标准：确保你使用的是支持C++20的编译器（如 GCC >= 10, Clang >= 10, MSVC >= 19.29 / Visual Studio 2019 16.11）并且编译时开启了-std=c++20或/std:c++20标志。
2. 检查头文件：std::jthread在<thread>头文件中，确保已包含。
3. 检查命名空间：确认没有定义与std冲突的宏或位于自定义的命名空间中。

6.2 线程函数参数传递的坑

问题：向线程函数传递引用或指针时，数据被意外修改或访问了无效内存。根因：std::thread和std::jthread的构造函数会衰减参数类型，并复制或移动参数到线程的内部存储。如果你传递了一个引用（int&），它会被复制（变成int）。如果你传递了一个指针或引用到局部变量，而该变量在线程启动前就销毁了，就会导致悬空引用/指针。

解决方案：

• 使用std::ref或std::cref来传递引用包装器。
• 对于需要共享所有权的数据，使用std::shared_ptr。
• 对于需要转移所有权的数据，使用std::move（确保移动后源对象不再被使用）。
• 对于std::jthread的stop_token，它是自动传递的，不要手动传递。

int global = 100; void badExample(int& ref, int* ptr) { // ref 和 ptr 可能指向已销毁的对象！ } void goodExample(std::stop_token stoken, const std::shared_ptr<Data>& data) { // 安全地使用共享数据 } int main() { int local = 42; int* ptr = &local; // 错误！local 的引用可能失效 // std::thread t1(badExample, local, ptr); // 正确：使用 std::ref 传递引用 std::thread t2(badExample, std::ref(local), ptr); t2.join(); auto data = std::make_shared<Data>(); std::jthread t3(goodExample, data); // stop_token 自动添加，data 通过 shared_ptr 安全共享 t3.request_stop(); return 0; }

6.3 stop_token 检查的时机与频率

问题：线程没有响应request_stop()的请求。排查：

1. 线程函数是否接受了stop_token参数？检查函数签名。
2. 是否定期检查stop_requested()？如果线程陷入一个长时间、不检查stop_token的循环或阻塞调用（如纯计算循环、某些同步I/O），则无法响应。必须在循环内或通过stop_callback集成检查点。
3. 检查频率是否足够？如果循环一次要几分钟，那么停止请求的响应延迟就会很高。需要在循环的关键点插入检查。

// 不好的例子：长时间计算无检查点 void busyLoop(std::stop_token stoken) { long long i = 0; while (i < 100000000000LL) { // 极长的循环 // 密集计算... i++; // 这里没有检查 stoken.stop_requested()！ } } // 改进的例子：定期检查 void betterLoop(std::stop_token stoken) { long long i = 0; const long long check_interval = 1000000; // 每100万次迭代检查一次 while (i < 100000000000LL) { // ... 部分计算 ... i++; if (i % check_interval == 0 && stoken.stop_requested()) { break; } } }

6.4 死锁与资源竞争

即使使用了更安全的std::jthread，并发编程的核心挑战——数据竞争和死锁——依然存在。

问题：程序挂起，线程无法结束。排查：

1. 检查锁的顺序：确保所有线程以相同的顺序获取多个锁，这是预防死锁的黄金法则。
2. 检查condition_variable的等待逻辑：使用condition_variable_any并与stop_token结合时，确保谓词逻辑正确。wait会在停止请求时返回，但你的代码需要处理这种情况（例如，在从任务队列取任务前，再次检查队列是否为空）。
3. join或request_stop的调用位置：确保没有线程在等待自己结束（自死锁）。确保request_stop()是在所有工作者线程还能正常检查stop_token的时候调用的（例如，不要在已经部分退出的线程上调用）。

一个典型的死锁场景（即使使用 jthread）：

std::mutex mtx1, mtx2; void thread1(std::stop_token st) { std::lock_guard<std::mutex> lk1(mtx1); std::this_thread::sleep_for(std::chrono::milliseconds(100)); // 模拟工作 std::lock_guard<std::mutex> lk2(mtx2); // 可能死锁，如果 thread2 先锁了 mtx2 } void thread2(std::stop_token st) { std::lock_guard<std::mutex> lk2(mtx2); std::this_thread::sleep_for(std::chrono::milliseconds(100)); std::lock_guard<std::mutex> lk1(mtx1); // 可能死锁，如果 thread1 先锁了 mtx1 }

解决：使用std::lock或std::scoped_lock(C++17) 来一次性锁定多个互斥量，或者严格规定锁定顺序。

6.5 性能考量与线程数量

问题：使用多线程后性能没有提升，甚至下降。排查：

1. 线程数量：创建远超 CPU 核心数的线程会导致大量的上下文切换开销。使用std::thread::hardware_concurrency()作为参考基准。对于I/O密集型任务，可以适当多于核心数；对于CPU密集型任务，接近或等于核心数通常最佳。
2. 任务粒度：如果任务非常小，创建和管理线程的开销可能超过任务本身的计算成本。考虑使用线程池来复用线程。
3. 数据竞争与缓存：频繁的共享数据修改会导致缓存失效和锁竞争，严重削弱性能。尽量设计无锁的数据结构，或减少临界区范围，或使用线程本地存储。
4. std::jthread的开销：相比std::thread，std::jthread有轻微额外开销（维护stop_source等）。在创建和销毁线程极其频繁的极端场景下（这本身可能是个设计问题），这可能被测量出来。但对于绝大多数应用，其带来的安全性和便利性远超过这点开销。

我个人在实际项目中的体会是，从std::thread迁移到std::jthread最大的收益不是性能，而是代码健壮性和可维护性。它强制你思考线程的停止逻辑，并提供了标准工具来实现它，这减少了许多难以调试的并发bug。对于新项目，除非有非常明确的、经性能剖析证实的理由，否则我会毫不犹豫地将std::jthread作为默认的线程管理工具。