前言C11 之前C 标准里没有任何线程设施写多线程程序只能直接用 POSIX 的pthread.h、Windows 的windows.h或者依赖 Boost.Thread 之类的第三方库。代码不可移植连「线程」这个概念都不在语言层面。C11 引入了thread、mutex、condition_variable、future、atomic一组头文件把线程创建、互斥、条件等待、异步结果和原子操作纳入标准。需要先说明版本边界本文讲的是 C11 提供的那套线程库。C20 在此基础上增加了std::jthread析构时自动请求停止并 join、std::stop_token、std::latch、std::barrier、std::counting_semaphore和std::atomic_ref。如果读者看到教程里用jthread那不是 C11 的内容。另一个常见误解是「std::thread对象等于线程本身」。对象只是一个句柄线程可能已经结束而对象仍然joinable()对象析构时若仍关联着未汇合的线程标准要求调用std::terminate。理解句柄与执行流的关系是避免程序莫名终止的第一步。本文按「创建与汇合、互斥与锁、条件变量、异步结果」四块讲每块给出一段完整示例最后列出实际编码中最容易踩的边界。所有代码以 C17 为基准只使用 C11 就已具备的设施。一、线程的创建、汇合与分离std::thread的构造函数是一个可变参数模板第一个参数是可调用对象后面是传给它的参数。参数会被按值 decay 后拷贝到线程的存储中这一点非常关键直接传局部变量的引用线程拿到的是副本要真正传引用必须用std::ref同时自己保证被引用对象的生命周期覆盖线程执行期。// 适用于 C17#include iostream#include threadvoid worker(int id, std::string name) {std::cout worker id name \n;}int main() {std::string name alpha;std::thread t1(worker, 1, name); // name 被拷贝std::thread t2(worker, 2, std::ref(name)); // 传引用需自行保证生命周期t1.join();t2.join();}线程启动后有两种收尾方式。join()阻塞当前线程直到目标线程结束并释放句柄detach()让线程在后台独立运行句柄与执行流脱钩。二者都只能对joinable()为 true 的对象调用一次重复调用会抛std::system_error。joinable()在默认构造、已经 join、已经 detach 三种情况下为 false。析构行为值得单独记住std::thread的析构函数不会替你 join也不会 detach。如果对象析构时仍joinable()标准规定调用std::terminate()。这不是资源泄漏那么温和而是直接终止进程。因此每一条创建路径都必须有对应的 join 或 detach异常路径也不例外实际工程中常用 RAII 包装C20 的std::jthread就是把这件事标准化。std::this_thread命名空间提供当前线程的操作get_id()取标识sleep_for()睡一段时长sleep_until()睡到某个时间点yield()提示调度器让出时间片。std::thread::hardware_concurrency()返回实现建议的并发线程数返回值可能是 0表示无法确定不能拿它做除数。二、互斥量与锁管理mutex提供四种互斥量std::mutex最常用、std::recursive_mutex同一线程可重复加锁、std::timed_mutex支持超时尝试、std::recursive_timed_mutex两者结合。此外还有std::shared_mutexC17读写锁和std::shared_timed_mutexC14。裸调用lock()/unlock()容易在异常路径上漏解锁标准因此提供了 RAII 包装包装器头文件特点适用场景std::lock_guardmutex构造加锁、析构解锁不可移动简单的作用域加锁std::unique_lockmutex可移动、可手动 unlock/lock、可延迟加锁条件变量、需要中途解锁std::scoped_lockmutexC17可一次锁多个互斥量多锁场景替代std::lock多把锁的场景必须避免死锁。两个线程分别持有 A、B 再去拿对方手里的锁就会互相等待。C11 的std::lock(a, b)用避免死锁的算法同时锁定多个互斥量C17 的std::scoped_lock把这件事包装成 RAII。不要自己按不同顺序嵌套lock_guard那正是死锁的经典来源。std::call_once配合std::once_flag可以保证某个初始化只执行一次即使多个线程同时到达。它比「双检锁 原子标志」更容易写对后者稍不留神就会在对象构造完成与标志置位之间留下重排窗口。三、条件变量等待与通知std::condition_variable解决的是「线程要等到某个条件成立才继续」的问题。它必须与std::mutex和std::unique_lockstd::mutex搭配wait(lock)会原子地释放锁并阻塞被唤醒后重新加锁再返回。裸wait(lock)必须放在循环里检查条件因为存在虚假唤醒spurious wakeup即使没有人调用notify等待也可能返回。标准库提供了带谓词的重载wait(lock, pred)它等价于循环检查应该优先使用。谓词在持有锁的状态下求值这一点决定了共享状态的读写都在锁保护之内。notify_one()唤醒一个等待者notify_all()唤醒全部。通知本身不需要持锁在释放锁之后通知可以避免被唤醒的线程立刻又因锁被占而阻塞。但要注意如果通知发生在「修改条件」和「释放锁」之间还是之后正确性都不受影响因为等待方是在持锁状态下检查谓词的。下面是一个完整的生产者消费者示例// 适用于 C17#include condition_variable#include iostream#include mutex#include queue#include threadstd::mutex g_mutex;std::condition_variable g_cv;std::queueint g_queue;bool g_done false;void producer() {for (int i 0; i 10; i) {{std::lock_guardstd::mutex lock(g_mutex);g_queue.push(i);}g_cv.notify_one();}{std::lock_guardstd::mutex lock(g_mutex);g_done true;}g_cv.notify_all();}void consumer() {for (;;) {std::unique_lockstd::mutex lock(g_mutex);g_cv.wait(lock, [] { return !g_queue.empty() || g_done; });if (g_queue.empty() g_done) {return;}int value g_queue.front();g_queue.pop();lock.unlock();std::cout value \n;}}int main() {std::thread p(producer);std::thread c(consumer);p.join();c.join();}这段代码里有几个刻意安排的细节g_done的读写都在锁内消费者在弹出元素后先解锁再处理避免把输出这种慢操作放在临界区退出条件是「队列空且已完成」而不是只看g_done否则会丢掉最后一批元素。四、异步结果future、promise 与 async线程函数的返回值没法直接从std::thread拿到标准用future解决。std::futureT代表一个尚未就绪的结果get()阻塞直到就绪并取出值只能取一次std::shared_futureT可以被多次get()。三种产生 future 的方式std::async(std::launch::async, f, args...)在新线程上运行返回 future。std::promiseT由生产者调用set_value或set_exception消费者从get_future()得到结果。std::packaged_taskSig把一个可调用对象包装成任务调用它时结果写入内部的 future。std::async的启动策略必须留意。默认策略是std::launch::async | std::launch::deferred由实现决定是新建线程还是延迟到get()/wait()时在调用线程上执行。若想要确定的并发行为显式写std::launch::async。另外std::async返回的 future 若被析构而任务尚未完成对于launch::async策略析构会阻塞等待任务结束这一点常被误认为「后台任务会自动继续跑」。// 适用于 C17#include future#include iostream#include threadint compute(int x) {return x * 2;}int main() {std::futureint f std::async(std::launch::async, compute, 21);std::cout f.get() \n; // 按语义应为 42std::promiseint promise;std::futureint result promise.get_future();std::thread t([promise] { promise.set_value(7); });std::cout result.get() \n; // 7t.join();}如果线程函数抛出异常异常不会穿过线程边界传播。使用std::async或packaged_task时异常被存入共享状态在get()时重新抛出而直接交给std::thread的函数若让异常逃逸标准规定调用std::terminate。所以线程入口函数应当自己捕获并处理异常或通过promise::set_exception转交。常见坑点❌ 创建std::thread后既不join()也不detach()让它离开作用域。✅ 每条路径都要收尾用 RAII 包装或 C20 的std::jthread。否则析构时std::terminate。❌detach()之后线程体按引用访问局部变量。✅ detach 的线程可能活得更久引用会悬垂改为按值捕获或保证对象生命周期覆盖线程。❌ 向线程函数传引用却漏写std::ref以为线程会修改原变量。✅ 线程参数默认被拷贝要共享同一对象用std::ref并自行保证同步与生命周期。❌ 用裸wait(lock)且不写循环。✅ 虚假唤醒是标准允许的用wait(lock, pred)或手写while (!pred) wait(lock);。❌ 多个互斥量在不同线程以不同顺序加锁。✅ 用std::scoped_lockC17或std::lock一次性锁定统一顺序只是辅助手段。❌ 认为std::async一定在新线程执行。✅ 默认策略允许延迟执行需要并发时显式传std::launch::async。❌ 线程函数让异常逃逸期待主线程能 catch。✅ 异常逃出线程入口会触发std::terminate在线程内捕获或用promise/packaged_task传递。❌ 把std::mutex声明为const或按值传递。✅ 互斥量不可拷贝、不可移动作为成员时通常用mutable std::mutex以便 const 成员函数加锁。总结组件头文件关键点std::threadthread析构前必须 join 或 detach参数默认拷贝std::mutex系列mutex配 RAII 包装多锁用scoped_lock/std::lockstd::condition_variablecondition_variable必须带谓词防虚假唤醒std::futurefutureget()只能一次可能重新抛出异常std::asyncfuture默认策略可能延迟执行需显式launch::asyncstd::atomicatomic只保证单操作原子顺序另议C11 线程库把「创建线程」变得简单但正确性仍然取决于三件事生命周期谁 join、谁 detach、共享状态哪些数据在锁内、唤醒条件谓词是否覆盖所有情况。把这三件事在代码结构上固定下来比记住更多 API 更有价值。
前言C11 之前C 标准里没有任何线程设施写多线程程序只能直接用 POSIX 的pthread.h、Windows 的windows.h或者依赖 Boost.Thread 之类的第三方库。代码不可移植连「线程」这个概念都不在语言层面。C11 引入了thread、mutex、condition_variable、future、atomic一组头文件把线程创建、互斥、条件等待、异步结果和原子操作纳入标准。需要先说明版本边界本文讲的是 C11 提供的那套线程库。C20 在此基础上增加了std::jthread析构时自动请求停止并 join、std::stop_token、std::latch、std::barrier、std::counting_semaphore和std::atomic_ref。如果读者看到教程里用jthread那不是 C11 的内容。另一个常见误解是「std::thread对象等于线程本身」。对象只是一个句柄线程可能已经结束而对象仍然joinable()对象析构时若仍关联着未汇合的线程标准要求调用std::terminate。理解句柄与执行流的关系是避免程序莫名终止的第一步。本文按「创建与汇合、互斥与锁、条件变量、异步结果」四块讲每块给出一段完整示例最后列出实际编码中最容易踩的边界。所有代码以 C17 为基准只使用 C11 就已具备的设施。一、线程的创建、汇合与分离std::thread的构造函数是一个可变参数模板第一个参数是可调用对象后面是传给它的参数。参数会被按值 decay 后拷贝到线程的存储中这一点非常关键直接传局部变量的引用线程拿到的是副本要真正传引用必须用std::ref同时自己保证被引用对象的生命周期覆盖线程执行期。// 适用于 C17#include iostream#include threadvoid worker(int id, std::string name) {std::cout worker id name \n;}int main() {std::string name alpha;std::thread t1(worker, 1, name); // name 被拷贝std::thread t2(worker, 2, std::ref(name)); // 传引用需自行保证生命周期t1.join();t2.join();}线程启动后有两种收尾方式。join()阻塞当前线程直到目标线程结束并释放句柄detach()让线程在后台独立运行句柄与执行流脱钩。二者都只能对joinable()为 true 的对象调用一次重复调用会抛std::system_error。joinable()在默认构造、已经 join、已经 detach 三种情况下为 false。析构行为值得单独记住std::thread的析构函数不会替你 join也不会 detach。如果对象析构时仍joinable()标准规定调用std::terminate()。这不是资源泄漏那么温和而是直接终止进程。因此每一条创建路径都必须有对应的 join 或 detach异常路径也不例外实际工程中常用 RAII 包装C20 的std::jthread就是把这件事标准化。std::this_thread命名空间提供当前线程的操作get_id()取标识sleep_for()睡一段时长sleep_until()睡到某个时间点yield()提示调度器让出时间片。std::thread::hardware_concurrency()返回实现建议的并发线程数返回值可能是 0表示无法确定不能拿它做除数。二、互斥量与锁管理mutex提供四种互斥量std::mutex最常用、std::recursive_mutex同一线程可重复加锁、std::timed_mutex支持超时尝试、std::recursive_timed_mutex两者结合。此外还有std::shared_mutexC17读写锁和std::shared_timed_mutexC14。裸调用lock()/unlock()容易在异常路径上漏解锁标准因此提供了 RAII 包装包装器头文件特点适用场景std::lock_guardmutex构造加锁、析构解锁不可移动简单的作用域加锁std::unique_lockmutex可移动、可手动 unlock/lock、可延迟加锁条件变量、需要中途解锁std::scoped_lockmutexC17可一次锁多个互斥量多锁场景替代std::lock多把锁的场景必须避免死锁。两个线程分别持有 A、B 再去拿对方手里的锁就会互相等待。C11 的std::lock(a, b)用避免死锁的算法同时锁定多个互斥量C17 的std::scoped_lock把这件事包装成 RAII。不要自己按不同顺序嵌套lock_guard那正是死锁的经典来源。std::call_once配合std::once_flag可以保证某个初始化只执行一次即使多个线程同时到达。它比「双检锁 原子标志」更容易写对后者稍不留神就会在对象构造完成与标志置位之间留下重排窗口。三、条件变量等待与通知std::condition_variable解决的是「线程要等到某个条件成立才继续」的问题。它必须与std::mutex和std::unique_lockstd::mutex搭配wait(lock)会原子地释放锁并阻塞被唤醒后重新加锁再返回。裸wait(lock)必须放在循环里检查条件因为存在虚假唤醒spurious wakeup即使没有人调用notify等待也可能返回。标准库提供了带谓词的重载wait(lock, pred)它等价于循环检查应该优先使用。谓词在持有锁的状态下求值这一点决定了共享状态的读写都在锁保护之内。notify_one()唤醒一个等待者notify_all()唤醒全部。通知本身不需要持锁在释放锁之后通知可以避免被唤醒的线程立刻又因锁被占而阻塞。但要注意如果通知发生在「修改条件」和「释放锁」之间还是之后正确性都不受影响因为等待方是在持锁状态下检查谓词的。下面是一个完整的生产者消费者示例// 适用于 C17#include condition_variable#include iostream#include mutex#include queue#include threadstd::mutex g_mutex;std::condition_variable g_cv;std::queueint g_queue;bool g_done false;void producer() {for (int i 0; i 10; i) {{std::lock_guardstd::mutex lock(g_mutex);g_queue.push(i);}g_cv.notify_one();}{std::lock_guardstd::mutex lock(g_mutex);g_done true;}g_cv.notify_all();}void consumer() {for (;;) {std::unique_lockstd::mutex lock(g_mutex);g_cv.wait(lock, [] { return !g_queue.empty() || g_done; });if (g_queue.empty() g_done) {return;}int value g_queue.front();g_queue.pop();lock.unlock();std::cout value \n;}}int main() {std::thread p(producer);std::thread c(consumer);p.join();c.join();}这段代码里有几个刻意安排的细节g_done的读写都在锁内消费者在弹出元素后先解锁再处理避免把输出这种慢操作放在临界区退出条件是「队列空且已完成」而不是只看g_done否则会丢掉最后一批元素。四、异步结果future、promise 与 async线程函数的返回值没法直接从std::thread拿到标准用future解决。std::futureT代表一个尚未就绪的结果get()阻塞直到就绪并取出值只能取一次std::shared_futureT可以被多次get()。三种产生 future 的方式std::async(std::launch::async, f, args...)在新线程上运行返回 future。std::promiseT由生产者调用set_value或set_exception消费者从get_future()得到结果。std::packaged_taskSig把一个可调用对象包装成任务调用它时结果写入内部的 future。std::async的启动策略必须留意。默认策略是std::launch::async | std::launch::deferred由实现决定是新建线程还是延迟到get()/wait()时在调用线程上执行。若想要确定的并发行为显式写std::launch::async。另外std::async返回的 future 若被析构而任务尚未完成对于launch::async策略析构会阻塞等待任务结束这一点常被误认为「后台任务会自动继续跑」。// 适用于 C17#include future#include iostream#include threadint compute(int x) {return x * 2;}int main() {std::futureint f std::async(std::launch::async, compute, 21);std::cout f.get() \n; // 按语义应为 42std::promiseint promise;std::futureint result promise.get_future();std::thread t([promise] { promise.set_value(7); });std::cout result.get() \n; // 7t.join();}如果线程函数抛出异常异常不会穿过线程边界传播。使用std::async或packaged_task时异常被存入共享状态在get()时重新抛出而直接交给std::thread的函数若让异常逃逸标准规定调用std::terminate。所以线程入口函数应当自己捕获并处理异常或通过promise::set_exception转交。常见坑点❌ 创建std::thread后既不join()也不detach()让它离开作用域。✅ 每条路径都要收尾用 RAII 包装或 C20 的std::jthread。否则析构时std::terminate。❌detach()之后线程体按引用访问局部变量。✅ detach 的线程可能活得更久引用会悬垂改为按值捕获或保证对象生命周期覆盖线程。❌ 向线程函数传引用却漏写std::ref以为线程会修改原变量。✅ 线程参数默认被拷贝要共享同一对象用std::ref并自行保证同步与生命周期。❌ 用裸wait(lock)且不写循环。✅ 虚假唤醒是标准允许的用wait(lock, pred)或手写while (!pred) wait(lock);。❌ 多个互斥量在不同线程以不同顺序加锁。✅ 用std::scoped_lockC17或std::lock一次性锁定统一顺序只是辅助手段。❌ 认为std::async一定在新线程执行。✅ 默认策略允许延迟执行需要并发时显式传std::launch::async。❌ 线程函数让异常逃逸期待主线程能 catch。✅ 异常逃出线程入口会触发std::terminate在线程内捕获或用promise/packaged_task传递。❌ 把std::mutex声明为const或按值传递。✅ 互斥量不可拷贝、不可移动作为成员时通常用mutable std::mutex以便 const 成员函数加锁。总结组件头文件关键点std::threadthread析构前必须 join 或 detach参数默认拷贝std::mutex系列mutex配 RAII 包装多锁用scoped_lock/std::lockstd::condition_variablecondition_variable必须带谓词防虚假唤醒std::futurefutureget()只能一次可能重新抛出异常std::asyncfuture默认策略可能延迟执行需显式launch::asyncstd::atomicatomic只保证单操作原子顺序另议C11 线程库把「创建线程」变得简单但正确性仍然取决于三件事生命周期谁 join、谁 detach、共享状态哪些数据在锁内、唤醒条件谓词是否覆盖所有情况。把这三件事在代码结构上固定下来比记住更多 API 更有价值。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
