本文收录于「流浪」的系列专栏Linux系统⚙️C数据结构与算法PythonLangChain LangGraph️MySQL 数据库Git 工具计算机网络LLM大厂面试、八股学习筑基专栏 博客主页流浪 原创首发于 CSDN前言线程十二用两个信号量把判空判满提前到访问之前环形队列单生产单消费一把锁都不用。本篇收两笔账一笔算给函数——线程安全与可重入到底什么关系一笔算给锁——死锁怎么成型、怎么破。最后把 STL 和智能指针的线程安全边界标清楚。一、线程安全与重入1.1 两个词各描述谁1. 线程安全是执行流自身的健康状态线程安全说的是线程自身的健康状态多个执行流并发跑跑完结果照样正确、互相不破坏判定标准线程八引过 man 手册口径能被多个线程同时调用且结果照样正确的函数才叫线程安全反面就是全局资源没加保护——判断和减减的缝隙被别的线程钻了ticket 抢票是原型2. 重入描述的是函数的特征重入说的是函数的特征同一个函数前一次调用还没返回又一次进入了再次进入的那次执行能不能照样正确决定了这个函数可重入还是不可重入两个词的宾语不同——线程安全的宾语是执行流跑起来的状态重入的宾语是函数这件东西的属性线程安全与重入不在同一个层面前者说执行流安不安全后者说函数能不能被重复进入。分清各描述谁两个词就搅不到一起。1.2 重入的两种情况1. 多线程重入函数第一种情况多个线程并发调用同一个函数第一个没跑完第二个又进来了两个执行流各拿一层调用函数里的共享数据同时被两份执行踩——线程八的抢票现场就是这一种2. 信号导致一个执行流重复进入函数第二种情况一个线程正跑在函数里信号打进来处理函数里又调了同一个函数同一条执行流把函数夹了两层——内层跑完回外层外层接着跑两层同时活着线程八提过 glibc 把两个维度分开标MT-Safe 管多线程并发进入AS-Safe 管中断后重入两条路不同对函数的要求是同一个——重入进来的时候自己带的东西够不够用碰不碰外面的共享状态。1.3 可重入是线程安全的子集1. 可重入函数一定是线程安全的只碰自己局部变量和参数的函数每一层调用都有独立的一份栈帧变量各是各的多线程进、信号打断后进每一层拿到的都是自己那一份结果互不污染连重复进入都扛得住的函数多线程同时调用没有出错的路径2. 线程安全不一定可重入加锁能把不可重入函数改造成线程安全一次只放一个进来并发的数据竞争被锁挡住——线程八的结论但重入撞的是另一堵墙第一次进入持着锁跑到一半第二次进入在 lock 上等递归死锁等的是第一次把锁解开而第一次正等着第二次返回——自己等自己谁都返回不了3. 不考虑信号重入时两者可以不区分两个方向合起来是子集关系可重入函数一定是线程安全的线程安全的函数不一定是可重入的若不考虑信号导致的那一种重入两个词在安全角度可以不区分——线程安全侧重并发访问公共资源的安全可重入描述函数能否被重复进入把信号场景算进来两者就必须分开答加锁是线程安全的恰恰在重入场景卡死可重入 ⊆ 线程安全。线程安全用锁就买得到可重入得看函数碰了谁——只碰自己栈帧的可以碰了共享状态的加锁也救不了重入。1.4 不可重入的典型函数1. 四类典型函数特征为什么不可重入不保护共享变量全局、静态数据被多层执行同时改写ticket 抢票是原型返回静态变量指针static 缓冲只有一份第二次进入直接覆盖第一次的结果调用 malloc/free堆由全局链表管理改链表改到一半被重入链就断了调用标准 I/O 库全局缓冲区同理——手册口径stdio 全部函数不是异步信号安全的四类的共性只有一条——函数依赖了自己栈帧之外的共享状态。名单可以背机制记住这一条就推得出来。二、死锁与四个必要条件2.1 死锁是什么1. 死锁的定义一组执行流各自占着一部分资源不放手又互相申请对方手里的资源你等我的、我等你的谁也拿不到想要的、谁也不撒手里的永久等待——这个僵局就是死锁本文语境里资源主要是锁但死锁不挑资源两把锁、锁加条件变量、锁加信号量都能成型2. 出现过的两个现场线程十推演过拿着锁去等条件变量、锁又攥在手里——唤醒的人进不了临界区等的人和持锁的人互卡线程十二的面试题里算过生产者持锁睡在信号量上消费者进不去、空位腾不出——双双卡死两个现场角色不同僵局的共同点一样占着的资源不放手等着的资源在别人手里2.2 双锁交叉申请的时序1. 僵局成型的四步线程一锁住锁 A线程二锁住锁 B——各持一把互不相干线程一申请锁 B锁被线程二持有睡下等待锁 A 不放手线程二申请锁 A锁被线程一持有睡下等待锁 B 不放手双方各持一把、各等一把能解开对方的那个动作永远轮不到执行2.3 死锁的四个必要条件1. 互斥资源一次只能被一个执行流占用——这是锁的本职线程九拆互斥锁原理拆的就是它破坏点资源能同时使用就无需排队但加锁就是为了独占资源所以这个死锁条件最难打破。2. 请求与保持一个执行流因请求资源而阻塞时对已获得的资源保持不放破坏点要新的就别攥旧的——申请前先释放已有的或者一次全拿3. 不剥夺一个执行流已获得的资源在未使用完之前不能强行剥夺破坏点等不到就上交——把已持有的资源还回去稍后重来4. 循环等待若干执行流之间形成一种头尾相接的循环等待资源关系破坏点给资源排个全序所有执行流按同一个顺序申请等待关系排成一条直线接不成环5. 四条同时成立死锁才成立四个条件都是必要条件死锁发生四条必然全部成立反过来任意一条被破坏死锁就锁不成——「必要条件」的准确含义就是缺一不可这也是避免死锁的全部抓手防死锁不用四条全防盯住最好破的那一条下手就够——互斥动不得就从剩下三条里挑。2.4 如何避免死锁1. 破坏必要条件的四个抓手资源一次性分配——破坏请求与保持要拿一次全拿不出现占着 A 等 B 的姿势申请带超时——破坏不剥夺等不到就超时返回把手里已持有的还回去稍后重试加锁顺序一致——破坏循环等待所有线程按同一顺序拿锁等待关系成一条直线头尾接不成环避免锁未释放的场景占着资源的窗口越短僵局越难凑成——RAII 封装的 LockGuard 在任何路径都还锁就是这一招的落地2. 银行家算法死锁避免的经典算法把资源借出去之前先推演一圈——借给这批执行流之后剩余资源还能不能让所有人按某个顺序全部跑完能全部跑完的顺序叫安全序列找得到就借、找不到就先不借——宁可不借不进僵局3. std::lock 一次性锁多把C 层给了现成工具std::lock 用死锁避免策略一次锁两把不存在锁住一把、卡在等另一把的窗口配 std::unique_lock 的 defer_lock构造时只包住锁不加锁最后一起上std::mutex mtx1,mtx2;// defer_lock构造时只绑定锁、不立刻加锁std::unique_lockstd::mutexlk1(mtx1,std::defer_lock);std::unique_lockstd::mutexlk2(mtx2,std::defer_lock);// 一次性锁两把顺序死锁从根上避开std::lock(lk1,lk2);破坏条件是预防银行家是避免std::lock 是工具——三层防的是同一件事别让四个条件凑齐。三、STL、智能指针与其他锁3.1 STL 容器不是线程安全的1. 默认不加锁STL 容器默认不加任何锁——库追求极致性能锁的开销宁可不付多线程并发读写同一个容器保护责任全在使用者库不知道使用场景的并发模式替用户加锁反而处处添堵STL 的选择是性能优先、安全自理——容器跨线程用锁自己配。3.2 智能指针的线程安全性1. unique_ptr 不进这个问题只在当前代码块内生效出了作用域自动析构所有权独一份不可拷贝、没有引用计数不存在多方共改的问题2. shared_ptr 的引用计数是原子的引用计数被所有拷贝共享读写标准库用原子操作CAS保证增减一步到位——多个线程各自拷贝、析构自己的副本安全边界要分清计数原子只保计数这一层——同一个 shared_ptr 对象本身的并发读写、所指对象内部的并发访问都不在保内shared_ptr 是局部线程安全——计数这一层交给原子操作所指对象那一层还得自己加锁。3.3 悲观锁、乐观锁、CAS、自旋锁、读写锁1. 五种锁的定位悲观锁取数据前先加锁假设别人一定会改乐观锁不加锁更新前用版本号或 CAS 校验没被改过CAS比较当前值相等才写入新值不等就重试——一条原子指令的语义自旋锁抢不到就原地空转重试不睡——与互斥锁的差别就在等锁的姿势互斥锁睡回去自旋锁站着等读写锁读共享、写独占读多写少的场景放开并发度自旋适合临界区极短的场景——等的时间比睡一觉的切换开销还短站着等才划算临界区一长自旋就成纯烧 CPU。四、文末面试题4.1 推导题1. 为什么线程安全不等于可重入用一把锁说清。答推导加锁保证多线程并发进入时一次只进去一个数据竞争被挡在锁外线程安全到手但重入要求同一条执行流第二次进入时依然正确而第二次进入撞上的是自己没解开的锁卡死在 lock 上等一个永远等不到的解锁。前者说的是并发互斥后者说的是重复进入——锁能解决前者解决不了后者所以线程安全买得到、可重入买不到可重入只能是线程安全的子集。2. 「四个必要条件」和「破坏任意一个即可避免」是什么逻辑关系答推导必要条件的含义是缺一不可——死锁要成立互斥、请求与保持、不剥夺、循环等待必须同时成立。逆否过来就是任意一条不成立死锁必然锁不成。所以避免死锁不需要四条全破破坏任意一条就够。工程上挑循环等待下手的原因也在这互斥是锁的本职动不得请求与保持和不剥夺要改分配协议唯独加锁顺序一致只改次序不动语义代价最小。3. 两个线程两把锁交叉申请推演死锁成型的全过程。答推导线程一锁 A 成功线程二锁 B 成功两边各持一把线程一申请 B被线程二持有睡下且不放手 A线程二申请 A被线程一持有也睡下且不放手 B。此时互斥天然成立请求与保持、不剥夺、循环等待三条同时凑齐四条件全部满足——能解开对方的动作分别被对方的锁挡着双方永久等待死锁成型。4. 加锁顺序一致为什么能破坏循环等待答推导循环等待要求等待关系头尾相接成环。规定所有线程都先 A 后 B 之后等 B 的人必先持有 A而等 A 的人按顺序规定手里一把锁都没有——他没有任何东西可以被别人等成不了环上的一环环从第一环就断。等待关系被排成一条单向直线头尾永远接不上。5. malloc/free 为什么不可重入给它加一把锁之后可重入了吗答推导malloc 用全局链表管理堆——空闲块挂在全局结构上申请和释放都要改链。第一次调用改链改到一半被信号打断处理函数里再进 malloc读到的是半新不旧的链表插节点可能把链插丢甚至插成环。加锁之后多线程并发安全了但信号重入时第二次调用撞上自己没解的锁——和上一题同一个结局线程安全到手可重入没到手。6. shared_ptr 的引用计数线程安全性从哪来答推导引用计数被多个线程同时增减而 /-- 是读、改、写三步非原子线程八的 ticket 已经证明过三步操作会被切走。加互斥锁能保安全但太重——标准库用原子操作CAS一步到位比较当前值、相等才替换成新值不等就重读重试。计数原子了各线程拷贝析构各自的副本就安全但它只保计数这一层所指对象的并发访问还得自己加锁。4.2 真题1. 死锁产生的四个必要条件是互斥、 、环路等待和不剥夺。选项释放和阻塞、请求和阻塞、请求和保持、请求和释放答推导 · 已对照解析转述正确答案是请求和保持——进程因请求资源被阻塞时对已获得的资源保持不放「请求」和「保持」两个动作缺一不可。四个选项全带「请求」差别全在后半截这题考的就是条件名里每个字的含义。【真题·转述自 牛客网题库】2. 请你说说互斥锁和自旋锁答推导 · 已对照解析转述加锁失败时互斥锁用线程切换应对——挂进等待队列睡回去自旋锁用忙等待应对——原地循环重试不放弃 CPU。互斥锁适合持锁时间长、竞争激烈的场景自旋锁适合临界区极短的场景。两者是锁的最基本处理方式更高级的锁都基于二者之一实现——读写锁既可以基于互斥锁也可以基于自旋锁。【真题·转述自 牛客网面经题】结语线程安全看执行流、可重入看函数死锁记牢四个必要条件——破坏任意一条就锁不成。Linux 系统篇到此收官评论区聊聊你排查过的死锁现场觉得有用点个赞。