python多线程缺点_为什么有人说 Python 的多线程是鸡肋呢？

这句话也对也不对，因为GIL的存在，GIL就是全局线程锁，所以虽然python有多线程，但是并不能真正的使用多核。

比如说Python创建4个线程A,B,C,D. 假如这个CPU有4个核，按说一个线程一个核刚好，A,B,C,D轮流各一个CPU内核并发执行，能把4个核都用起来。

但是因为GIL的存在，Python的每个线程执行bytecode之前，先check下Mutex，如果有线程已经在运行，那这个线程就要等着, 比如上面说一个PYTHON创建4个线程：A,B,C,D。 A,B,CD这4个进程不能使用CPU内核去运行，A运行的时候，B,C,D就要等着，等A用完,就把锁解开,B,C,D看到锁解开了，就赶紧上去执行，比如B抢占了锁，C,D一样就只能等锁开。

用一个LOW一点比喻，一个办公室配备了4个洗手间，正常情况下，可以4个人同时上厕所，但是在Python里，它坑爹的只留一筒卷纸，4个洗手间，只有一筒卷纸：Python的GIL就像这样

所以Python的4个洗手间并不能真正的发挥并行的作用，当第一个洗手间在用的时候，B,C,D都在等卷纸，4个一起去洗手间，第一个洗手间抢到卷纸，可以正常工作，其他3个只能在洗手间各自等卷纸。。。。。多个洗手间，一筒卷纸，GIL让我们很尴尬啊。。。

但是，多线程并不只有使用多核这一个功效，多线程还常常用于IO密集的程序，就比如以上的洗手间的例子，虽然4个洗手间，一个卷纸，你也不能说4个洗手间一个卷纸，还不如一个洗手间一个卷纸对吧，比如在4个洗手间，1个人在里面使用“大“的时候（使用cpu），其他3个洗手间在里面用“小的”（调用IO，比如接受网络，读取大文件），不那么依赖卷纸，还是能发挥到并行的作用的，因为大家都不用等，对吧。

至于为什么Python要搞出这样一出“N个洗手间一个卷纸“的设计，有多个原因，但是最重要的原因，Python有大量库是C/C++开发，这些C/C++的库不是线程安全的，一旦没有全局锁，很可能带来很多意想不到BUG，所以现在Python就是默认线程安全，这样所有给Python开发库的人和使用python第三方库的人都更简单，天然有一个保障。就像上厕所的人正常人没问题，但是架不住有些“变态猴子”，用完后的“卷纸“，也不冲走，直接拿起来往其他洗手间扔，结果把别人的衣服衣服弄脏了，把洗手间也影响，所以Python就只安排一筒卷纸，用完冲走，剩余的卷纸上缴，给下个洗手间用，这样”严格“管理下，所以我们使用python的默认就可以放心，不会有变态从其他洗手间扔脏卷纸过来。早期Python第三方库大量是通过封装的C/C++的各种库得来的，”一筒卷纸“的管理模式，虽然有缺点，还是确实让Python一开始就有大量的第三方库可以用。Python的发展离不开各种第三方库，这些第三方库不少是这样不安全的会扔Shit猴子。。。。。

后来Python社区也讨论过去GIL，包括GOOGLE很多年想搞一个牛B的解释器，号称要去掉GIL,提高10倍性能，后来无果，项目也合并到了PyPy.

倒是Java版本的Python的Jython和C Sharp版本的Python的Ironpython是没有GIL，因为他们对很多由C/C++打包而成的第三方库本来就不支持，换句话说，他们每个洗手间都给了一筒卷纸，是因为Jython和Ironpython压根不让上面那帮throw shit的猴子进办公楼。。。。

另外，Ruby你别笑，你也只给了“一筒卷纸”！！