一· 线程互斥1.1 进程线程间的互斥相关背景概念共享资源临界资源多线程执⾏流被保护的共享的资源就叫做临界资源临界区每个线程内部访问临界资源的代码就叫做临界区互斥任何时刻互斥保证有且只有⼀个执⾏流进⼊临界区访问临界资源通常对临界资源起保护作⽤原⼦性后⾯讨论如何实现不会被任何调度机制打断的操作该操作只有两态要么完成要么未完成模拟抢票逻辑竞态条件不是因为usleep漫长而是因为检查与修改分离中间可能发生线程切换。即使没有usleep只要多线程并发访问共享变量且不加锁就会导致数据不一致。解决方案是使用互斥锁或原子操作保证临界区的原子性。代码如下#include stdio.h #include stdlib.h #include string.h #include unistd.h #include pthread.h int ticket 1000; void *route(void *arg) { char *id (char *)arg; while (1) { pthread_mutex_lock(lock); if (ticket 0) // 1. 判断 { usleep(1000); // 模拟抢票花的时间 printf(%s sells ticket:%d\n, id, ticket); // 2. 抢到了票 ticket--; // 3. 票数-- else { break; } } return nullptr; } int main(void) { pthread_t t1, t2, t3, t4; pthread_create(t1, NULL, route, (void *)thread 1); pthread_create(t2, NULL, route, (void *)thread 2); pthread_create(t3, NULL, route, (void *)thread 3); pthread_create(t4, NULL, route, (void *)thread 4); pthread_join(t1, NULL); pthread_join(t2, NULL); pthread_join(t3, NULL); pthread_join(t4, NULL); }运行结果会发现结果出现了负数如果真的是再买票的场景下不能出现负数的。原因如下多线程票数不一致的底层完整拆解1.首先明确一个结论单条ticket--在 CPU 层面是“非原子”的ticket--在 C 语言里是一行代码但在底层汇编里被编译器拆解为严格有序的 3 条机器指令Load读mov ticket, %eax将内存地址里的数值 100 加载到 CPU 寄存器%eax中。Sub减sub $1, %eax将寄存器里的数值减 1变成 99。Store写mov %eax, ticket将寄存器里的 99 写回内存地址。注意这 3 条指令之间CPU 随时可能被操作系统强行剥夺执行权发生线程切换。2.发生上下文切换时的精确操作细节重要a.线程 A 的初始动作A 执行了第 1 条指令把100读进寄存器接着执行了第 2 条寄存器变成99。关键截断点A尚未执行第 3 条写回内存此时时间片用完了或者触发了usleep系统调用。b.线程 A 被剥离 CPU 时发生了什么上下文保存操作系统内核立即冻结线程 A 的当前运行状态把它的%eax寄存器值此时是 99和程序计数器PC指针等上下文数据完整地存入线程 A 自己的内核栈或线程控制块TCB中。内存里的ticket此时依然是旧值 100。c.线程 B 疯狂执行减了 50 次线程 B 获得 CPU它也从内存读到了100。因为 B 运气好时间片较长它顺利完成了50 次完整的“读-减-写”循环。最终结果内存里的ticket被 B 从 100 精准减成了50并写回内存。随后B 的时间片也到了B 被挂起。d.线程 A 恢复执行问题发生操作系统调度到线程 A内核原封不动地把之前保存的上下文%eax 99恢复到 CPU 寄存器中。线程 A 的 PC 指针指回第 3 条指令写回内存。A 执行mov %eax, ticket把 99 覆写到了内存中。3.最终内存状态与逻辑错误内存现在的值是 99。但实际上票已经被卖掉 50 次了从 100 变 50线程 A 的 1 次减票操作本该基于 B 的结果50去减到 49而不是把 B 的成果抹掉重新回到 99。这就产生了数据覆盖丢失Write-after-Write竞态 导致最终票数完全错乱不仅大于实际剩余票数甚至在后续多轮叠加下直接变成负数。4.内核态返回用户态是诱发高频切换的关键usleep(1000)和printf都会触发系统调用。一旦触发系统调用线程会立刻从用户态陷入内核态。内核在完成系统调用处理、准备返回用户态的瞬间一定会检查调度队列。因为你的代码里有usleep这就意味着线程 A 在if判断成立后、执行ticket--前必定会经历一次“内核返回用户”的上下文切换。这种切换不是为了等而是因为usleep本身属于系统调用它插在了非原子的 3 条汇编指令中间人为把竞态窗口拉大从而让 B 更容易抢到 CPU 并执行 50 次最终触发上述的覆盖问题竞态全称是竞态条件理解就是两个或多个线程在“抢”同一个共享资源因为抢的顺序乱了导致最后的结果跟着乱了。小结一下线程 A 将tickets 100从内存读到 CPU 寄存器紧接着执行ticket--的减操作。但还没等线程 A 把减完的结果写回内存就被 CPU 剥夺了执行权。在剥离之前CPU 会将线程 A 当前的寄存器状态即上下文数据保存到它的内核栈或线程控制块中。随后 CPU 开始调度线程 B线程 B 同样从内存读到tickets 100然后运气较好连续执行了 50 次ticket--因为它的时间片较长或抢占较少。当线程 B 的时间片耗尽时它将tickets 50写回内存。接着 CPU 再次调度线程 A把之前保存的线程 A 的上下文数据恢复到 CPU 寄存器中线程 A 接着执行刚才未完成的步骤——将寄存器中减过 1 的结果也就是99写回物理内存。最终内存中的tickets被错误地改成了99原本的 50 次有效减票被覆盖丢失导致数据严重不一致。逻辑分析a.出现原子性问题竞态条件核心问题在于ticket--这一行 C 语言代码在底层汇编层面被拆分为“读内存”、“寄存器减 1”、“写回内存”三步这三步并非原子操作。当线程 A 执行if (ticket 0)判断结果为真后在它真正执行ticket--写回内存之前如果发生了线程切换无论是时间片耗尽还是因为执行了usleep、printf等系统调用而陷入内核线程 A 的上下文会被保存CPU 转而执行线程 B。此时线程 B 重新从内存读取ticket时读到的依然是线程 A 尚未修改的旧值因此 B 也顺利通过了if判断进入了临界区。这种“判断成立”与“实际修改”之间缺乏连贯性的状态会导致多个线程先后通过if检查最终都在执行ticket--。因为多个线程读取到的初始值相同所以最终内存中的票数会被多减甚至直接变成负数如从 100 直接减成 -1、-2。解决方法必须引入线程互斥锁将if判断和ticket--修改包裹成一个不可打断的原子临界区保证同一时刻只有一个线程能操作该共享变量。b. 未出现原子性问题1.2互斥量 mutex大多数情况下线程使用的数据都是局部变量。这类变量的地址空间分配在线程独立的栈空间内因此变量归属单个线程其他线程无法访问天然具有线程安全性。然而在实际应用中许多变量需要在线程间共享以便完成线程间的数据交互与协同工作这类变量称为共享变量或全局变量。它们通常存储在全局数据区或堆区可以被所有线程共同读写。当多个线程并发地操作同一个共享变量时由于线程调度的随机性和操作的非原子性会引发竞态条件。具体表现为数据不一致、逻辑混乱甚至程序崩溃。核心原因在于共享变量的“读-改-写”操作在底层不是原子的必须通过线程互斥如互斥锁或原子操作来保证临界区的安全性。为什么可能⽆法获得争取结果if 语句判断条件为真以后代码可以并发的切换到其他线程usleep 这个模拟漫⻓业务的过程在这个漫⻓的业务过程中可能有很多个线程会进⼊该代码段--ticket 操作本⾝就不是⼀个原⼦操作// 地址40064b 8b 05 e3 04 20 00 mov 0x2004e3(%rip), %eax # 600b34 ticket // 地址400651 83 e8 01 sub $0x1, %eax // 地址400654 89 05 da 04 20 00 mov %eax, 0x2004da(%rip) # 600b34 ticket-- 操作并不是原⼦操作⽽是对应三条汇编指令load 将共享变量ticket从内存加载到寄存器中update : 更新寄存器⾥⾯的值执⾏-1操作store 将新值从寄存器写回共享变量ticket的内存地址要解决以上问题需要做到三点代码必须要有互斥⾏为当代码进⼊临界区执⾏时不允许其他线程进⼊该临界区。如果多个线程同时要求执⾏临界区的代码并且临界区没有线程在执⾏那么只能允许⼀个线程进⼊该临界区。如果线程不在临界区中执⾏那么该线程不能阻⽌其他线程进⼊临界区。要做到这三点本质上就是需要⼀把锁。Linux上提供的这把锁叫互斥量。1.3互斥量的接口参数mutex初始化或释放的锁。attr锁的属性设置nullptr即不管1.初始化互斥量初始化互斥量有两种⽅法⽅法1静态分配:初始化不用 destroypthread_mutex_t mutex PTHREAD_MUTEX_INITIALIZER⽅法2动态分配:int pthread_mutex_init(pthread_mutex_t *restrict mutex, const pthread_mutexattr_t *restrict attr);2.销毁互斥量销毁互斥量需要注意使⽤ PTHREAD_ MUTEX_ INITIALIZER 初始化的互斥量不需要销毁不要销毁⼀个已经加锁的互斥量已经销毁的互斥量要确保后⾯不会有线程再尝试加锁int pthread_mutex_destroy(pthread_mutex_t *mutex)3.互斥量加锁和解锁a. 互斥量加锁int pthread_mutex_lock(pthread_mutex_t *mutex);返回值:成功返回0,失败返回错误号调⽤ pthread_ lock 时可能会遇到以下情况:互斥量处于未锁状态该函数会将互斥量锁定同时返回成功发起函数调⽤时其他线程已经锁定互斥量或者存在其他线程同时申请互斥量但没有竞争到互斥量那么pthread_ lock调⽤会陷⼊阻塞(执⾏流被挂起)等待互斥量解锁。b. 互斥量解锁int pthread_mutex_unlock(pthread_mutex_t *mutex);线程确实是绝对可以被随时切换的但关键在于线程是“拿着锁”走的。只要它手里攥着锁不撒手哪怕 CPU 中途把它切走干别的事去了这把锁也不会自己跑掉。别的线程过来申请这把锁也只能被堵在门外根本进不去抢票那一步。直到拿锁的线程把票卖完自己主动把锁释放了后面的线程才有机会拿到锁进去抢票。所以对于其他线程来说它们面对临界区的时候要么因为没抢到锁而压根没进去不执行要么等拿到锁再进去并执行完释放锁。正是因为这种“互斥排队的机制”才从逻辑上把一串本该被打断的操作变成了一气呵成的整体这就算间接完成了“原子性”。不过细想一下这把全局的锁所有线程都要先能看到它才能去抢。那这把锁本身也是一种被大家共享的临界资源啊要是两个线程同时来抢这把锁的控制权难道又要给这把锁再加一层锁吗那岂不是没完没了、无限套娃了其实不用。真正的解法是不需要用另一把锁来保护这把锁。我们只要保证在硬件底层层面上lock抢锁和unlock放锁这两个动作本身是绝对原子的就行。也就是说底层的 CPU 会保证同一时刻只会有一个线程能成功修改这把锁的状态。只要锁本身是安全的它就能去保护后面抢票那段代码的安全这就够了。代码如下但这里运行速度变慢了同时因为互斥没有出现原子性问题但是我开了4个线程为什么只有1个线程在干活原因如下原因1我把usleep(1000)放在了锁里面pthread_mutex_lock(lock); if (ticket 0) { usleep(1000); // 模拟抢票耗时 printf(...); ticket--; pthread_mutex_unlock(lock); }当thread 3抢到锁并进入if后它执行了usleep(1000)。此时它并没有解锁而是死死攥着锁在睡大觉。这 1 毫秒也是1000us对现代 CPU 来说是非常漫长的时间。在thread 3睡觉的这段时间里其他 3 个线程全都卡死在了pthread_mutex_lock(lock)这一行眼巴巴地等待锁被释放根本没法进入抢票流程。等你睡醒了它打印、减票、解锁紧接着下一轮循环它立刻又抢到了锁。结论usleep在锁内导致其他线程根本抢不到锁最终thread 3一个人包揽了全部 100 张票。上面的现象通常被称为调度运气问题在并发编程中有一个专门的学术名称——线程饥饿虽然例子中usleep被锁在临界区内是加剧“饥饿”的原因但即便没有usleep这种现象依然可能出现。例如当 CPU 的调度器因为线程的优先级、亲和性或是历史权重等原因持续将时间片分配给同一个线程时其他线程就会长期得不到 CPU 资源从而发生饥饿。错误代码while(1) { pthread_mutex_lock(mtx); if(tickets 0) { usleep(1000); printf(...); tickets--; } else { break; // 直接 break没解锁 } pthread_mutex_unlock(mtx); // 解锁代码在 else 外面永远跑不到 }else里break直接跳出了循环pthread_mutex_unlock在循环底部根本没机会执行。出现死锁退出的线程手里还死死攥着锁导致其他所有正在lock处等待的线程永久阻塞程序卡死结束不了。所以else里必须先pthread_mutex_unlock(mtx);然后再break;。4.改进上⾯的售票系统完整版代码如下#include stdio.h #include stdlib.h #include unistd.h #include pthread.h int ticket 100; pthread_mutex_t mutex; void *route(void *arg) { char *id (char*)arg; while ( 1 ) { pthread_mutex_lock(mutex); // 1.加锁互斥进入 if ( ticket 0 ) // 2.在锁保护下判断 { // 把 usleep 移出锁外 原因模拟抢票耗时如网络IO、打印应放在锁外否则会导致其它线程长时间排队并发变串行拖慢整体速度。 pthread_mutex_unlock(mutex); // 先解锁让别的线程有机会抢 usleep(1000); // 在锁外模拟耗时 pthread_mutex_lock(mutex); // 再次加锁准备修改数据 // ticket 可能在刚才的等待中被其他线程减光了 // 所以必须要再判断一次 if (ticket 0) { printf(%s sells ticket:%d\n, id, ticket); ticket--; // 3.在锁内安全减票 } pthread_mutex_unlock(mutex); // 4.解锁 } else { pthread_mutex_unlock(mutex); // 5.票卖完必须解锁再退出 break; } } return NULL; } int main( void ) { pthread_t t1, t2, t3, t4; pthread_mutex_init(mutex, NULL); pthread_create(t1, NULL, route, (void*)thread 1); pthread_create(t2, NULL, route, (void*)thread 2); pthread_create(t3, NULL, route, (void*)thread 3); pthread_create(t4, NULL, route, (void*)thread 4); pthread_join(t1, NULL); pthread_join(t2, NULL); pthread_join(t3, NULL); pthread_join(t4, NULL); pthread_mutex_destroy(mutex); return 0; }问题补充1加锁就代表多线程完全变成串行执行了吗是的但仅限于临界区。被互斥锁包裹的临界区代码同一时刻绝对只能有一个线程在执行。从宏观上看多线程并发抢票变成了严格的“排队串行”。这虽然牺牲了并发度但换来的是数据绝对安全。2线程在临界区中被 CPU 切换走会不会出问题绝对不会。线程被切走时是“带着锁”离开的。只要它手里还攥着锁不释放其他线程在申请锁时就会被阻塞住根本进不来。所以哪怕 CPU 切来切去临界区内的数据也绝对不会被其他人破坏。3如果线程不申请锁直接去读/写共享变量呢这是不被允许的错误编码方式也是引起脏读/脏写的根源。多线程编程的底层规律是所有访问共享资源的线程必须自觉遵守“先抢锁再操作后解锁”的规则。不遵守规则的线程进入临界区相当于不排队直接插队会导致锁的保护跟没有一样。进阶核心问题4锁本身也是所有线程都能看到的“共享内存”那谁来保证锁在抢的过程中不被“抢坏”对于没有持有锁的线程最有意义的情况只有两种1.当前没有线程持有锁它可以去申请2.持有锁的线程释放了锁它可以去申请。既然所有线程都得“看到”同一把锁去抢那锁本身必然也是一种共享资源。为了不陷入“给锁加锁”的无限套娃底层用pthread_mutex_lock和pthread_mutex_unlock这两个操作本身必须被设计为“绝对原子的”直接依赖 CPU 硬件提供的xchg或cmpxchg等单条指令。因为只有这样才能保证同一时刻只会有一个线程能成功更改锁的状态以此保护上层的数据安全。1.4互斥量实现原理探究经过上⾯的例⼦⼤家已经意识到单纯的 i 或者 i 都不是原⼦的有可能会有数据⼀致性问题为了实现互斥锁操作,⼤多数体系结构都提供了swap或exchange指令,该指令的作⽤是把寄存器和内存单元的数据相交换,由于只有⼀条指令,保证了原⼦性,即使是多处理器平台,访问内存的 总线周期也有先后,⼀个处理器上的交换指令执⾏时另⼀个处理器的交换指令只能等待总线周期。 现在我们把lock和unlock的伪代码改⼀下lock: movb $0, %al xchgb %al, mutex if(a1寄存器的内容 0){ return 0; } else{ 挂起等待; } goto lock; unlock: movb $1, mutex 唤醒等待mutex的线程; return 0;这个是我的一个原理图来说明问题蓝色箭头代表xchgb或类似的原子交换的过程。它把%alCPU寄存器和mutex内存中的值进行了互换。红色打叉图上画出了“把 1 置 0”的动作可能是mov并用红叉划掉了。单纯的写值如mov是不管用的必须用原子交换。状态展示寄存器拿到了mutex原来的值如果是 1 就代表抢锁成功而内存被写入了 0代表锁已被占用。mutex 本质上就是一个内存中的共享变量初始值设为 1。为了理解它我们看底层汇编的实现。线程在执行时寄存器和堆栈数据保存在线程的 TCB线程控制块中属于线程私有。而mutex变量在内存中所有线程都能读取。1. 加锁过程对应图中发生的交换线程 X 执行movb $0, %al将寄存器清零紧接着执行xchgb %al, mutex。如图所示这条xchgb是一条硬件级别的原子指令。它会瞬间将 CPU 寄存器%al中的0与内存mutex中的1进行互换。互换后对应图中虚线箭头结果内存中的mutex变成了0表示锁被占用了。线程 X 的寄存器%al变成了1。接着线程 X 判断%al的值发现大于 0说明它成功抢到了锁于是进入临界区。哪怕它在执行if前被 CPU 切走操作系统也会保存它%al:1的上下文这把锁依然在它手里。2. 为什么xchgb是原子的因为xchgb在底层被翻译成 CPU 机器码时就是单条指令。CPU 在执行这条指令时会在硬件层面锁住总线如图中交换过程是一条整体保证其它 CPU 核心或其它线程在这个周期内无法访问mutex内存地址。这就确保了“交换”这一下绝对不被干扰。3. 如果线程没抢到锁%al 为 0比如线程 Y 被切进来它也执行xchgb但此时内存mutex已经被 X 改成了 0。Y 交换后内存mutex还是 0Y 的%al也是 0。它判断%al不大于 0于是进入挂起等待直到被唤醒后跳回lock标签重新尝试。4. 解锁过程线程 X 临界区执行完毕调用unlock执行movb $1, mutex将互斥锁重新置为 1并唤醒所有等待该锁的线程。由于只有拥有锁的线程才能执行unlock所以unlock不需要像lock那样用xchgb普通的mov写回即可。5. 为什么不能只用movb $0, mutex来代替xchgb因为mov指令在 CPU 硬件层面不具备锁总线的原子属性。如果两个线程同时执行mov将mutex写成 0就会产生竞争导致两个线程都以为自己抢到了锁。必须借助xchgb或cmpxchg等硬件原子指令硬锁总线才能确保一把锁只被一个线程拿走。1.5互斥量的封装编译规则文件MakefiletestMutex:testMutex.cpp g -o $ $^ -stdc11 -lpthread .PHONY:clean clean: rm -f testMutex2. 互斥锁封装头文件Mutex.hpp#pragma once #include iostream #include pthread.h namespace MutexModule { class Mutex { public: Mutex() { pthread_mutex_init(_mutex, nullptr); } void Lock() { int n pthread_mutex_lock(_mutex); (void)n; } void Unlock() { int n pthread_mutex_unlock(_mutex); (void)n; } ~Mutex() { pthread_mutex_destroy(_mutex); } private: pthread_mutex_t _mutex; }; class LockGuard { public: LockGuard(Mutex mutex):_mutex(mutex) { _mutex.Lock(); } ~LockGuard() { _mutex.Unlock(); } private: Mutex _mutex; }; }3. 主程序测试文件testMutex.cpp#include iostream #include mutex #include string #include stdio.h #include stdlib.h #include string.h #include unistd.h #include pthread.h #include Mutex.hpp using namespace MutexModule; int ticket 100; class ThreadData { public: ThreadData(const std::string n, Mutex lock) : name(n), lockp(lock) { } ~ThreadData() {} std::string name; Mutex *lockp; }; void *route(void *arg) { ThreadData *td static_castThreadData *(arg); while (1) { // RAII风格的自动加解锁构造即加锁析构即解锁 LockGuard guard(*td-lockp); if (ticket 0) { usleep(1000); printf(%s sells ticket:%d\n, td-name.c_str(), ticket); ticket--; } else { break; } usleep(123); } return nullptr; } int main(void) { Mutex lock; pthread_t t1, t2, t3, t4; ThreadData *td1 new ThreadData(thread 1, lock); pthread_create(t1, NULL, route, td1); ThreadData *td2 new ThreadData(thread 2, lock); pthread_create(t2, NULL, route, td2); ThreadData *td3 new ThreadData(thread 3, lock); pthread_create(t3, NULL, route, td3); ThreadData *td4 new ThreadData(thread 4, lock); pthread_create(t4, NULL, route, td4); pthread_join(t1, NULL); pthread_join(t2, NULL); pthread_join(t3, NULL); pthread_join(t4, NULL); return 0; }在 C 语言里加锁和解锁是分开的两个步骤你必须写两行代码一行lock一行unlock。但实际写业务代码时逻辑里会有很多if、else、return、break等。一旦逻辑复杂了非常容易漏写unlock导致线程卡死死锁。为了解决这个问题我借用了 C 里一个非常有名的思想——RAII资源获取即初始化。它的核心思路是把锁当成一个普通的对象来管理。具体的做法是设计两个类1.Mutex类把底层的pthread_mutex_t包起来让锁的创建和销毁自动完成不需要手动调用init和destroy。2.LockGuard类这个才是灵魂。它在构造生成的时候自动调用加锁在析构销毁的时候自动调用解锁。只要使用了这个LockGuard我们就不需要手动去写unlock了。只要代码走出了当前的花括号{}这个临时对象就自动销毁锁就自动被释放了。二.线程安全和重⼊问题2.1 概念线程安全就是多个线程在访问共享资源时能够正确地执⾏不会相互⼲扰或破坏彼此的执⾏结果。⼀般⽽⾔多个线程并发同⼀段只有局部变量的代码时不会出现不同的结果。但是对全局变量或者静态变量进⾏操作并且没有锁保护的情况下容易出现该问题。重⼊同⼀个函数被不同的执⾏流调⽤当前⼀个流程还没有执⾏完就有其他的执⾏流再次进⼊我们称之为重⼊。⼀个函数在重⼊的情况下运⾏结果不会出现任何不同或者任何问题则该函数被称为可重⼊函数否则是不可重⼊函数。学到现在其实我们已经能理解重⼊其实可以分为两种情况多线程重⼊函数信号导致⼀个执⾏流重复进⼊函数2.2 常见的线程不安全的情况不保护共享变量的函数。函数状态随着被调用状态发生变化的函数。返回指向静态变量指针的函数。调用线程不安全函数的函数。2.3 常见的线程安全的情况每个线程对全局变量或者静态变量只有读取的权限而没有写入的权限一般来说这些线程是安全的。类或者接口对于线程来说都是原子操作。多个线程之间的切换不会导致该接口的执行结果存在二义性。2.4 常见不可重入的情况调用了 malloc/free 函数因为 malloc 函数是用全局链表来管理堆的。调用了标准 I/O 库函数标准 I/O 库的很多实现都以不可重入的方式使用全局数据结构。可重入函数体内使用了静态的数据结构。2.5 常见可重入的情况不使用全局变量或静态变量。不使用用 malloc 或者 new 开辟出的空间。不调用不可重入函数。不返回静态或全局数据所有数据都有函数的调用者提供。使用本地数据或者通过制作全局数据的本地拷贝来保护全局数据。2.6 结论可重入与线程安全联系函数是可重入的那就是线程安全的。函数是不可重入的那就不能由多个线程使用有可能引发线程安全问题。如果一个函数中有全局变量那么这个函数既不是线程安全也不是可重入的。可重入与线程安全区别可重入函数是线程安全函数的一种。线程安全不一定是可重入的而可重入函数则一定是线程安全的。如果将对临界资源的访问加上锁则这个函数是线程安全的但如果这个重入函数若锁还未释放则会产生死锁因此是不可重入的。三.常见锁概念死锁3.1概念死锁是指在一组进程或线程中每个执行流都持有了对方所需的资源同时又在等待对方释放自己所需的资源导致所有执行流均陷入永久阻塞且无法自行解开的一种状态。死锁发生的核心特征线程之间相互持有对方需要的锁。每个线程都不愿意放弃自己当前持有的锁互不相让。举个例子假设有两个人线程 A 和线程 B要开车出门。线程 A 手里握着车钥匙正等着线程 B 给他递方向盘才能开车线程 B 手里握着方向盘正等着线程 A 给他递车钥匙才能开车。结果就是因为 A 不肯先给钥匙怕没方向盘B 也不肯先给方向盘怕没钥匙两人手里攥着对方要的东西谁也不肯先松手最后谁的车也开不走陷入了无限僵持。3.2死锁的四个必要条件只要产生了死锁这四个条件必须同时满足缺一不可a. 互斥条件定义一个资源每次只能被一个执行流使用。即资源是独占的不能共享。(引入互斥锁的本质是为了保护临界资源将并发访问变成串行保证原子性。因为有了互斥线程在申请资源时如果资源已被占用就必定会产生阻塞等待。没有互斥也就没有死锁。)注意互斥本身不一定会导致死锁但死锁绝对建立在互斥的基础之上。b.请求与保持条件定义一个执行流在因请求新资源而阻塞时对自己已经获得的资源保持不放占着茅坑不拉屎。(我手里已经抓着一个资源了现在想申请你手里的新资源。但在我苦苦等你释放新资源的同时我绝不放开我已经抓在手里的资源。)c.不剥夺条件定义一个执行流已获得的资源在未使用完之前不能被其他执行流强行剥夺。资源只能由持有者自己主动释放。(我们互相使用“锁”作为保护机制时锁是“私人专属”的。就算别的线程再急只要我不解锁别人抢不走我手里的锁。)d. 循环等待条件定义若干执行流之间形成一种头尾相接的循环等待关系。(不是别人借我的我借别人的就一定会死锁而是“我要你的你也刚好要我的)例如线程 A 占着锁 1想申请锁 2,线程 B 占着锁 2想申请锁 1,A 等 B 释放B 等 A 释放这就会形成一条闭环导致双方无限等待。只要发生死锁这四个条件一定同时成立但反过来即便四个条件同时成立系统不一定立刻发生死锁。3.3避免死锁只要打破这四个条件里的任何一个就行。不过这四个条件里有的好打破有的不好打破第一个条件互斥这东西不好破。因为加锁就是为了不让别人同时用资源你要是破了互斥那锁就等于白加了。所以一般不去碰它。第二个条件请求并保持这个好破。要求每个线程在干活之前一次性把需要的资源全部拿到手少一个都不开始干。要么全拿到要么一个都不要这样就不会出现“手里捏着你的又等着要他的”这种情况。第三个条件不剥夺这个也好破。可以设计一个规则允许资源被抢走。比如高优先级的线程可以强行拿走低优先级手里的资源不用非得等低优先级自己慢慢用完。第四个条件循环等待这是工程上最常用、也最好破的。只要给所有的锁规定好一个固定的申请顺序大家都按一个顺序来比如规定“先拿锁A再拿锁B”谁都不能反过来。只要顺序一致就不会形成你等我、我等你的死循环了。3.4避免死锁算法A. 死锁检测算法了解死锁检测算法并不预防死锁而是在死锁发生后发现它。系统会定时检查资源分配图如果发现图中形成了一个闭环就说明发生了死锁。一旦检测到死锁系统会采取强制措施来解除死锁比如强行剥夺某个进程的资源或者直接终止某个进程。这个算法的特点是允许死锁发生但会在发生后及时处理。B. 银行家算法了解银行家算法是一种提前预防死锁的算法。系统在给进程分配资源之前会先模拟一下分配后的情况判断系统是否处于安全状态。如果把资源分配出去后还能保证至少有一个进程能顺利执行完毕并释放资源那么就分配如果分配后所有进程都可能卡住就拒绝本次分配。这个算法的核心思想是宁可不分配也不让系统进入死锁状态。