python queue死锁_python(一)：multiprocessing——死锁

前言

近年来，使用python的人越来越多，这得益于其清晰的语法、低廉的入门代价等因素。尽管python受到的关注日益增多，但python并非完美，例如被人诟病最多的GIL(值得注意的是，GIL并非python特性，它是在实现Python解析器(CPython)时所引入的一个概念，而CPython是大部分环境下默认的Python执行环境)，全称Global Interpreter Lock。从官方定义来看，GIL无疑就是一把全局排他锁，会严重影响python多线程的效率，甚至几乎等于Python是个单线程程序。

为了满足开发者的需求，python社区推出了multiprocessing。顾名思义，multiprocessing使用了多进程而不是多线程，每个进程有自己的独立的GIL，因此也不会出现进程之间的GIL争抢。当然multiprocessing也并非完美，例如增加了数据通讯的难度等方面。讲了这么多背景，下面分享一下使用multiprocessing踩过的坑。由于这篇博客偏向实际工程，主要分享应用经验，相关基础知识可以查阅Python Documentation。

系统

>>> import sys

>>> print(sys.version)

3.6.0 |Anaconda 4.3.1 (64-bit)| (default, Dec 23 2016, 12:22:00) \n[GCC 4.4.7 20120313 (Red Hat 4.4.7-1)]

1

2

3

死锁

百度百科对死锁的定义

死锁是指两个或两个以上的进程在执行过程中，由于竞争资源或者由于彼此通信而造成的一种阻塞的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程1。

从定义可知，永远互相等待是死锁的一个重要特征。在multiprocessing中，你稍不留神，也会犯这种错误，例如：

from multiprocessing import Process, Queue

def f(q):

q.put('X' * 1000000)

if __name__ == '__main__':

queue = Queue()

p = Process(target=f, args=(queue,))

p.start()

p.join() # this deadlocks

1

2

3

4

5

6

7

8

9

10

结果是死锁。当一个进程被join时，Python会检查被放入Queue中的数据是否已经全部删除(例如Queue.get)，若没有删除，则进程会一直处于等待状态。发现这种情况时，一方面感叹“你让我找的好苦啊”，另一方面思考python的开发者怎么会对这种情况坐视不理呢？是否做了某些尝试？例如若Queue小于某个阈值，进程join会将其视为空Queue。基于这种猜想，做了以下实验

from multiprocessing import Process, Queue

import time

def f(q):

num = 10000

q.put('X' * num)

print("Finish put....")

if __name__ == '__main__':

queue = Queue()

p = Process(target=f, args=(queue,))

p.start()

print("Start to sleep...")

time.sleep(2)

print("Wake up....")

p.join()

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

结果是程序正常结束，一定程度上验证了我的猜想。为了进一步确定猜想的正确性，我又做了num=1000、num=100和num=1的实验，结果均是程序正常结束，证明进程join时的确会判断Queue的大小，从而避免死锁。尽管这种策略有一定效果，但并不能根治死锁，所以进程join时一定要保证Queue中数据已经被全部取走。

除了上述的情况外，进程join自身、终止带锁的进程等情况也会导致死锁，以后会慢慢分享给大家。

结语

尽管multiprocessing对死锁有一定的容错能力，但并不完善，优化代码才是正道。

---------------------

作者：cptu

来源：CSDN

原文：https://blog.csdn.net/AckClinkz/article/details/78409301

版权声明：本文为博主原创文章，转载请附上博文链接！