江苏龙网

  1. 首页 > 人文 > >

Python | 多线程死锁问题的巧妙解决方法

今天是Python专题的第25篇文章 ， 我们一起来聊聊多线程开发当中死锁的问题 。
死锁死锁的原理非常简单 ， 用一句话就可以描述完 。 就是当多线程访问多个锁的时候 ， 不同的锁被不同的线程持有 ， 它们都在等待其他线程释放出锁来 ， 于是便陷入了永久等待 。 比如A线程持有1号锁 ， 等待2号锁 ， B线程持有2号锁等待1号锁 ， 那么它们永远也等不到执行的那天 ， 这种情况就叫做死锁 。
关于死锁有一个著名的问题叫做哲学家就餐问题 ， 有5个哲学家围坐在一起 ， 他们每个人需要拿到两个叉子才可以吃饭 。 如果他们同时拿起自己左手边的叉子 ， 那么就会永远等待右手边的叉子释放出来 。 这样就陷入了永久等待 ， 于是这些哲学家都会饿死 。
对于死锁的问题有多种解决方法 ， 这里我们介绍比较简单的一种 ， 就是对这些锁进行编号 。 我们规定当一个线程需要同时持有多个锁的时候 ， 必须要按照序号升序的顺序对这些锁进行访问 。 通过上下文管理器我们可以很容易实现这一点 。
上下文管理器【Python | 多线程死锁问题的巧妙解决方法】首先我们来简单介绍一下上下文管理器 ， 上下文管理器我们其实经常使用 ， 比如我们经常使用的with语句就是一个上下文管理器的经典使用 。 当我们通过with语句打开文件的时候 ， 它会自动替我们处理好文件读取之后的关闭以及抛出异常的处理 ， 可以节约我们大量的代码 。
同样我们也可以自己定义一个上下文处理器 ， 其实很简单 ， 我们只需要实现__enter__和__exit__这两个函数即可 。 __enter__函数用来实现进入资源之前的操作和处理 ， 那么显然__exit__函数对应的就是使用资源结束之后或者是出现异常的处理逻辑 。 有了这两个函数之后 ， 我们就有了自己的上下文处理类了 。
我们来看一个样例：
classSample:def__enter__(self):print('enterresources')returnselfdef__exit__(self,exc_type,exc_val,exc_tb):print('exit')#print(exc_type)#print(exc_val)#print(exc_tb)defdoSomething(self):a=1/1returnadefgetSample():returnSample()if__name__=='__main__':withgetSample()assample:print('dosomething')sample.doSomething()当我们运行这段代码的时候 ， 屏幕上打印的结果和我们的预期是一致的 。
实现上下文管理器并不一定要通过类实现 ， Python当中也提供了上下文管理的注解 ， 通过使用注解我们可以很方便地实现上下文管理 。 我们同样也来看一个例子：
importtimefromcontextlibimportcontextmanager@contextmanagerdeftimethis(label):start=time.time()try:yieldfinally:end=time.time()print('{}:{}'.format(label,end-start))withtimethis('timer'):pass在这个方法当中yield之前的部分相当于__enter__函数 ， yield之后的部分相当于__exit__ 。 如果出现异常会在try语句当中抛出 ， 那么我们编写except对异常进行处理即可 。
避免死锁了解了上下文管理器之后 ， 我们要做的就是在lock的外面包装一层 ， 使得我们在获取和释放锁的时候可以根据我们的需要 ， 对锁进行排序 ， 按照升序的顺序进行持有 。
这段代码源于Python的著名进阶书籍《Pythoncookbook》 ， 非常经典：
fromcontextlibimportcontextmanager#用来存储local的数据_local=threading.local()@contextmanagerdefacquire(*locks):#对锁按照id进行排序locks=sorted(locks,key=lambdax:id(x))#如果已经持有锁当中的序号有比当前更大的 ， 说明策略失败acquired=getattr(_local,'acquired',[])ifacquiredandmax(id(lock)forlockinacquired)>=id(locks[0]):raiseRuntimeError('LockOrderViolation')#获取所有锁acquired.extend(locks)_local.acquired=acquiredtry:forlockinlocks:lock.acquire()yieldfinally:#倒叙释放forlockinreversed(locks):lock.release()delacquired[-len(locks):]这段代码写得非常漂亮 ， 可读性很高 ， 逻辑我们都应该能看懂 ， 但是有一个小问题是这里用到了threading.local这个组件 。
它是一个多线程场景当中的共享变量 ， 虽然说是共享的 ， 但是对于每个线程来说读取到的值都是独立的 。 听起来有些难以理解 ， 其实我们可以将它理解成一个dict ， dict的key是每一个线程的id ， value是一个存储数据的dict 。 每个线程在访问local变量的时候 ， 都相当于先通过线程id获取了一个独立的dict ， 再对这个dict进行的操作 。
看起来我们在使用的时候直接使用了_local ， 这是因为通过线程id先进行查询的步骤在其中封装了 。 不明就里的话可能会觉得有些难以理解 。
我们再来看下这个acquire的使用：
defthread_1():whileTrue:withacquire(x_lock):withacquire(y_lock):print('Thread-1')defthread_2():whileTrue:withacquire(y_lock):withacquire(x_lock):print('Thread-1')运行一下会发现没有出现死锁的情况 ， 但如果我们把代码稍加调整 ， 写成这样 ， 那么就会触发异常了 。
defthread_1():whileTrue:withacquire(x_lock):withacquire(y_lock):print('Thread-1')defthread_2():whileTrue:withacquire(y_lock):withacquire(x_lock):print('Thread-1')因为我们把锁写成了层次结构 ， 这样就没办法进行排序保证持有的有序性了 ， 那么就会触发我们代码当中定义的异常 。
最后我们再来看下哲学家就餐问题 ， 通过我们自己实现的acquire函数我们可以非常方便地解决他们死锁吃不了饭的问题 。
importthreadingdefphilosopher(left,right):whileTrue:withacquire(left,right):print(threading.currentThread(),'eating')#叉子的数量NSTICKS=5chopsticks=[threading.Lock()forninrange(NSTICKS)]forninrange(NSTICKS):t=threading.Thread(target=philosopher,args=(chopsticks[n],chopsticks[(n+1)%NSTICKS]))t.start()总结关于死锁的问题 ， 对锁进行排序只是其中的一种解决方案 ， 除此之外还有很多解决死锁的模型 。 比如我们可以让线程在尝试持有新的锁失败的时候主动放弃所有目前已经持有的锁 ， 比如我们可以设置机制检测死锁的发生并对其进行处理等等 。 发散出去其实有很多种方法 ， 这些方法起作用的原理各不相同 ， 其中涉及大量操作系统的基础概念和知识 ， 感兴趣的同学可以深入研究一下这个部分 ， 一定会对操作系统以及锁的使用有一个深刻的认识 。
今天的文章到这里就结束了 ， 如果喜欢本文的话 ， 请来一波素质三连 ， 给我一点支持吧（关注、转发、点赞） 。
-END-
本文始发于公众号：TechFlow


    推荐阅读


    上一篇：太震撼了！马斯克再次创造历史：硬币大小芯片植入脑中，实时读取信息…

    下一篇：5449 元比电商便宜 罗永浩直播间 iPhone 11 256G 抢购一空