【C++第三十章】线程库

前言 C11的线程库并不只是“把系统线程 API 换了个写法”而是在标准库层面给并发编程提供了一套更统一、更可移植的抽象线程怎么创建如何等待结束如何保护共享资源线程之间怎么同步通知哪些场景适合加锁哪些场景更适合原子操作甚至无锁结构为什么会碰到ABA这类更底层的问题这些都被放进了同一套框架里。很多人在学线程库时容易把thread、mutex、condition_variable、atomic、lock_guard、unique_lock这些内容拆成独立知识点去记。这样虽然能记住接口名但一到实际写代码时还是容易混乱为什么传锁给线程函数要加ref为什么锁里抛异常可能直接把程序卡死为什么条件变量一定要和谓词一起用为什么短临界区有时宁可自旋也不切换线程为什么CAS看起来没问题却还会出现ABA。真正更好的理解方式是先抓住线程库在解决什么问题多个执行流并发访问同一进程资源时如何保证正确性同时尽量兼顾性能。顺着这条主线再看各个工具它们的定位就会清楚很多。一.C11线程库的意义把并发能力纳入标准库 在C11之前多线程编程通常更依赖平台相关接口例如POSIX线程接口Windows原生线程接口这样做的问题很明显写法不统一代码可移植性差换平台往往就要改线程相关实现。C11把线程能力直接纳入标准库后最重要的价值就是提供跨平台统一接口让线程成为“标准C对象”把线程管理、同步、原子操作、异步结果等内容统一进同一套生态中1.1 线程对象化意味着什么std::thread不是一个句柄式的裸接口而是一个真正的对象。也正因为如此可以像普通对象一样把它们放进容器中管理例如用vectorthread批量创建和维护线程。1.2 线程库关注的不只是“启动线程”它更完整地覆盖了线程创建与销毁线程等待与分离互斥与加锁条件等待与唤醒原子变量与无锁操作更高层的future / promise / async二.std::thread线程为什么会被设计成对象 2.1 最基本的线程创建方式voidPrint(size_t n,conststrings){for(size_t i0;in;i){coutthis_thread::get_id():s:iendl;}}intmain(){threadt1(Print,100,线程1);threadt2(Print,200,线程2);t1.join();t2.join();return0;}2.2join()和detach()分别意味着什么join()等待目标线程执行结束detach()让目标线程与当前线程分离后台独立运行2.3 为什么线程对象必须妥善收尾因为线程不是普通值对象它背后关联的是系统级执行流。若线程对象生命周期结束前既没有join()也没有detach()程序通常会直接终止。2.4 为什么说线程函数的异常也要谨慎线程函数里的异常不会自动“传回主线程”但线程资源本身仍必须被正确回收。因此哪怕业务逻辑抛异常也仍要保证线程对象最终被join()或detach()。 避坑指南线程对象和线程执行流不是一回事但二者生命周期强相关。写了std::thread就必须明确这个线程最后是要join还是要detach。三. 给线程函数传参数为什么锁和共享变量常常要用ref线程创建时最容易踩坑的地方之一就是参数传递。3.1 一个典型场景voidPrint1(size_t n,conststrings,mutexm,intrx){for(size_t i0;in;i){m.lock();coutthis_thread::get_id()s:iendl;rx;m.unlock();}}调用时通常要写成mutex mtx;intx0;threadt1(Print1,100,我是鹏哥,ref(mtx),ref(x));threadt2(Print1,200,我是蛋哥,ref(mtx),ref(x));3.2 为什么不能直接把mtx和x传进去因为thread构造时接收参数本质上会对实参做保存和转发。对普通值类型来说按值拷贝通常没问题但mutex本身不允许拷贝共享计数变量若按值传就会变成每个线程各改各的副本3.3std::ref的作用到底是什么明确告诉线程构造器这里不是值传递而是引用语义传递。3.4 为什么这里会提到“完美转发”因为线程构造器是模板形式底层会对参数做模板推导和转发。表面上你写的是“传引用”但若不显式包装成引用语义模板层仍可能按值处理。因此ref在这里相当重要。 避坑指南传给线程函数的“引用形参”不代表调用时就天然按引用传。对需要共享的锁和变量通常要显式写std::ref(...)。四. 互斥锁为什么共享资源一旦并发访问就需要它 多线程最核心的问题不是“线程怎么开出来”而是多个线程同时访问共享资源时如何避免数据竞争。4.1 最基本的互斥语义mutex m;m.lock();// 临界区m.unlock();只要一个线程已经拿到锁其他线程就必须等待直到锁被释放。4.2 为什么锁保护的是“临界区”而不是某个变量名锁并不会自动知道你想保护谁它只是在时间上保证同一时刻只有一个线程能执行那段受保护代码。真正被保护的是这段代码里对共享状态的访问过程。4.3 递归调用为什么要用recursive_mutex若同一个线程已经拿到某把普通mutex在递归过程中又再次尝试锁它就会把自己阻塞住形成自锁死局。这时需要用recursive_mutex rm;它允许同一线程对同一把锁重复加锁并在相应次数解锁后才真正释放。4.4 什么时候才该考虑递归锁只有在设计上确实存在“同线程重入同一临界区”的需求时才用。它能解决问题但通常比普通互斥锁更重也更容易掩盖设计上的结构问题。五. 为什么“锁里抛异常”会导致死锁RAII在这里的价值是什么 ⚠️5.1 一个典型风险m.lock();// 中间抛异常m.unlock();如果中间代码抛出异常那么unlock()根本来不及执行其他线程就可能永远卡在这把锁上。5.2 这个问题本质上和资源泄漏是同一类问题锁本质上也是一种资源。只要资源释放依赖“手工写在后面”那一旦执行流提前离开这个收尾动作就可能丢失。5.3 更稳妥的办法用RAII管理锁这正是lock_guard和unique_lock存在的核心原因。六.lock_guard和unique_lock都是锁的RAII包装但定位不一样 6.1lock_guard最轻量的锁守卫mutex mtx;{lock_guardmutexlg(mtx);// 临界区}它的特点是非常直接构造时加锁析构时解锁不能手动解锁再重新加锁适合简单、固定作用域的临界区6.2unique_lock更灵活的锁管理器unique_lockmutexlock(mtx);它相比lock_guard的优势在于支持手动unlock()支持再lock()更适合与条件变量配合可配合定时锁等更灵活的场景6.3 为什么条件变量通常要求unique_lock因为条件等待过程中锁并不是一直保持不动而是要经历先持有锁检查条件条件不满足时自动释放锁并阻塞被唤醒后重新加锁再继续检查条件这种“释放-等待-重新占有”的灵活动作不是lock_guard这种纯作用域守卫能胜任的。6.4 两者如何选工具特点适合场景lock_guard轻量、简单、固定作用域普通临界区unique_lock灵活、可手动解锁再加锁条件变量、复杂同步流程 避坑指南不是所有加锁都要上unique_lock。简单临界区优先lock_guard需要灵活控制锁状态时再用unique_lock。七. 条件变量为什么“加锁”还不够还要“等待某个条件成立” 互斥锁只能解决“同一时刻谁能进临界区”却不能表达数据什么时候准备好了某个线程什么时候该继续谁该先执行谁该后执行这时就需要条件变量。7.1 条件变量最核心的操作condition_variable cv;unique_lockmutexlock(mtx);cv.wait(lock,predicate);7.2wait(lock, predicate)到底做了什么它的完整语义可以理解为当前线程先拿着锁若predicate不满足则释放锁并阻塞等待其他线程notify_one()或notify_all()唤醒它被唤醒后重新抢回锁再次检查predicate条件满足后才继续执行7.3 为什么一定要搭配谓词因为通知不是条件本身。线程被唤醒不代表真正条件已经稳定成立再加上还可能发生伪唤醒所以更稳妥的模式永远是醒来后重新检查条件。7.4notify_one()和notify_all()的区别notify_one()唤醒一个等待线程notify_all()唤醒所有等待线程八. 为什么条件变量容易出现“通知丢失”又为什么flag能解决它 8.1 经典问题通知先发生等待后发生假设线程t1先notify_one()线程t2这时还没真正进入wait()那这次通知就可能等于“白喊了”。8.2 为什么单靠通知本身不够因为通知不是状态通知只是一个瞬间事件。线程没赶上就没有历史记忆。8.3 共享布尔标志的作用例如用boolflagfalse;来表达“条件是否已经成立”。此时线程即使没赶上某次通知只要下次拿到锁后重新看flag仍能根据真实状态决定是否继续等待是否直接执行8.4 这就是“条件变量 状态变量”必须配套的原因 避坑指南条件变量只负责“通知”不负责“记住状态”。真正的同步依据必须放在共享状态变量里。九. 为什么有时短临界区宁可自旋也不一定立刻阻塞切换 ⚠️锁竞争时并不总是“阻塞睡眠”最划算。若临界区非常短线程上下文切换本身的成本可能比稍微忙等一会儿还贵。9.1 自旋锁背后的核心判断如果锁很快就会释放那与其把线程挂起再唤醒不如先原地循环尝试获取。9.2 自旋更适合什么场景临界区非常短多核 CPU 环境锁竞争不算激烈对响应时间要求较高9.3 它的代价是什么会持续占用 CPU临界区一旦变长等待线程会一直空转浪费资源单核环境下尤其不划算因为持锁线程都不容易真正跑起来9.4 为什么库里常见互斥锁而不直接给自旋锁因为自旋锁适用条件更苛刻误用代价也更高。很多时候需要根据具体业务场景自行实现或额外权衡而不是默认一把梭。十.atomic什么时候比加锁更合适 若共享状态只是简单标志位、简单计数器、简单交换操作那么整套互斥锁机制可能就有点重了。这时原子操作会更合适。10.1atomic解决的是什么问题在不加传统互斥锁的情况下保证某些单步共享操作具备原子性。例如atomicintx0;x;10.2 为什么它常被称作“无锁编程基础”因为它避免了互斥锁带来的加锁解锁开销阻塞唤醒开销一部分线程竞争导致的内核调度成本10.3 它并不适合所有临界区若临界区逻辑很长或者需要保护一组复杂状态的一致性只靠atomic往往不够。此时其他线程可能会长期在原子重试中空耗资源反而不如正常加锁更清晰。 避坑指南原子操作适合“很小、很单纯的共享状态”不适合把复杂临界区硬改成无锁。十一.CAS为什么它能成为很多无锁结构的核心 11.1CAS的核心思想CAS即Compare And Swap或Compare And Set典型逻辑是读取共享变量当前值判断它是否仍等于“我原先看到的期望值”若相等则原子地改成新值若不相等则说明期间被别人改过这次更新失败伪代码形式可以写成boolCAS(ptr,expected,new_value){if(*ptrexpected){*ptrnew_value;returntrue;}returnfalse;}11.2 为什么说它是原子操作因为它的比较和修改是不可分割的一体动作中间不会被别的线程插入修改。11.3 它为什么能避免传统锁开销因为它不需要显式把其他线程全挡在门外而是允许多个线程乐观尝试修改谁成功谁提交失败者重试。十二.CAS的ABA问题为什么“值看起来没变”也可能已经变过了 12.1 问题场景假设共享变量x初始为A线程 1 读到A准备做CAS(x, A, B)线程 1 被挂起线程 2 把x从A改成B线程 2 又把x从B改回A线程 1 恢复执行看到x仍然是ACAS(x, A, B)成功12.2 问题到底出在哪线程 1 只看到了“现在值还是A”却完全不知道中间发生过A - B - A也就是说值虽然回来了但历史过程已经变了。12.3 为什么这会造成真实风险在一些依赖“中间过程本身是否被改过”的场景里例如链表节点链接栈顶指针变化无锁队列节点状态变化这种“看似没变实际上变过”就可能导致逻辑判断出错甚至破坏数据结构。 避坑指南CAS只比较“当前值是否相等”并不知道这个值中途有没有绕一圈回来。这正是ABA的本质。十三. 无锁队列为什么也要小心CAS的竞争细节 ️无锁队列的入队过程本质上就是多个线程竞争去修改队尾链接关系。这里最关键的不是“谁先写一句代码”而是必须保证节点链接顺序不会互相覆盖。13.1 为什么要先连next再推进tail因为逻辑上先让当前尾节点的next指向新节点再把tail更新到新节点若顺序反了其他线程看到的队列状态就可能不完整。13.2 为什么CAS适合这里因为多个线程都可以尝试把某个空的next从NULL改成新节点。只有一个线程会成功失败线程则会发现状态已经变化再重新读取和重试。13.3 这说明无锁结构真正难的地方是什么不是“会不会写atomic”而是能不能看清数据结构在并发下的中间状态能不能证明每一步即使被打断也仍然合法能不能处理重试、竞争失败和状态回读十四. 一些容易混淆但很重要的补充点 14.1shared_ptr是线程安全的吗更准确地说引用计数操作本身通常是线程安全的它管理的对象资源本身并不会自动因此变成线程安全也就是说多个线程同时改同一个shared_ptr所指对象是否安全仍取决于对象本身有没有额外同步保护。14.2 懒汉单例在C11前后为什么结论不同若写法是局部静态对象staticSingleton inst;那么C11之后标准保证其初始化只会发生一次并具备线程安全语义而在更早时代这一点并没有统一保证。14.3 条件变量为什么常配合finished之类标志因为线程除了要被唤醒“干一次活”还往往需要知道这轮是否该退出是否还有后续任务当前轮到谁执行这些都不能靠通知本身表达而必须靠共享状态变量表达。总结 C11线程库这一章真正最值得建立起来的不是单独记某个类名而是形成一条完整主线线程库的核心任务是在“多个执行流并发访问同一进程资源”这一现实前提下解决创建、等待、同步、通信和性能权衡问题。沿着这条主线再回头看整章内容逻辑就会非常统一std::thread负责把线程纳入对象化管理join / detach负责线程生命周期收尾mutex负责互斥进入临界区recursive_mutex解决同线程递归重入lock_guard与unique_lock把锁也纳入RAIIcondition_variable负责“等待条件成立”这类线程通信flag wait(predicate)负责避免通知丢失和错误唤醒短临界区可能更适合自旋或原子重试atomic与CAS则把并发控制进一步推进到无锁结构层面但一进入CAS世界又必须继续面对ABA和复杂竞争状态问题所以这一章最后可以压缩成一句话线程库不只是“开线程”而是“围绕共享资源访问建立一整套正确性优先、性能权衡并存的并发控制体系”。当这条认识真正建立起来之后后面继续看线程池、生产者消费者模型、无锁数据结构、任务调度器甚至高并发服务器架构时都会自然落到同一条并发主线上。