线程深入篇之 GIL专题

说说GIL

Process and Thread Test

利用共享库来扩展

C系扩展

Go扩展

运行在其他编译器上

说说GIL

Code：

尽管Python完全支持多线程编程， 但是解释器的C语言实现部分在完全并行执行时并不是线程安全的，所以这时候才引入了GIL

解释器被一个全局解释器锁保护着，它确保任何时候都只有一个Python线程执行(保证C实现部分能线程安全) GIL最大的问题就是Python的多线程程序并不能利用多核CPU的优势 （比如一个使用了多个线程的计算密集型程序只会在一个单CPU上面运行）

注意：GIL只会影响到那些严重依赖CPU的程序（比如计算型的）如果你的程序大部分只会涉及到I/O，比如网络交互，那么使用多线程就很合适~ 因为它们大部分时间都在等待（线程被限制到同一时刻只允许一个线程执行这样一个执行模型。GIL会根据执行的字节码行数和时间片来释放GIL，在遇到IO操作的时候会主动释放权限给其他线程）

所以Python的线程更适用于处理 和其他需要并发执行的阻塞操作，而不是需要多处理器并行的计算密集型任务（对于IO操作来说，多进程和多线程性能差别不大）【计算密集现在可以用Python的 框架】

网上摘取一段关于 的说明：（IO密集型可以结合异步）

Process and Thread Test

其实用不用多进程看你需求，不要麻木使用，Linux下还好点，Win下进程开销就有点大了（好在服务器基本上都是Linux，程序员开发环境也大多Linux了）这边只是简单测了个启动时间差距就来了，其他的都不用测试了

测试Code：

运行时间：

操作系统几千个进程开销还是有点大的（毕竟进程是有上线的）

测试Code：

运行时间：

里面的Process上面也说过了，就是在线程基础上加点东西使得用起来和 的 编程风格基本一致（本质还是线程）

测试Code:

运行时间：

其实Redis就是使用单线程和多进程的经典，它的性能有目共睹。所谓性能无非看个人能否充分发挥罢了。不然就算给你轰炸机你也不会开啊？扎心不老铁～

PS：线程和进程各有其好处，无需一棍打死，具体啥好处可以回顾之前写的进程和线程篇～

3.利用共享库来扩展C系扩展

GIL是Python解释器设计的历史遗留问题，多线程编程，模型复杂，容易发生冲突，必须用锁加以隔离，同时，又要小心死锁的发生。Python解释器由于设计时有GIL全局锁，导致了多线程无法利用多核。计算密集型任务要真正利用多核，除非重写一个不带GIL的解释器（ ）如果一定要通过多线程利用多核，可以通过C扩展来实现（Python很多模块都是用C系列写的，所以用C扩展也就不那么奇怪了）

只要用C系列写个简单功能（不需要深入研究高并发），然后使用 导入使用就行了：

编译成共享库：

使用Python运行指定方法：（ ）

看看这时候HTOP的信息：（充分利用多核）【ctypes在调用C时会自动释放GIL】

Go扩展

利用Go写个死循环，然后编译成so动态链接库（共享库）：

非常重要的事情： 一定要写，不然就被自动改成其他名字（我当时被坑过）

Python调用和上面一样：

效果：

题外话～如果想等CPython的GIL消失可以先看一个例子：MySQL把大锁改成各个小锁花了5年。在是在MySQL有专门的团队和公司前提下，而Python完全靠社区重构就太慢了

速度方面微软除外，更新快本来是好事，但是动不动断层更新，这学习成本就太大了(这也是为什么Net能深入的人比较少的原因：人家刚深入一个，你就淘汰一个了...)

可能还有人不清楚，贴下官方推荐技术吧（ 、 、 、 、 ）

课外拓展：

4.运行在其他编译器上

先看最重要的一点，一旦运行在其他编译器意味着很多Python第三方库 就不能用了，相对来说 兼容性是最好的了

如果是 系列我推荐谷歌的grumpy

如果是 系列，可以使用等等

PyPy:https://bitbucket.org/pypy/pypy

Net方向：

Java方向：

Other：

：平时基本上多线程就够用了，如果想多核利用-多进程基本上就搞定了（分布式走起）实在不行一般都是分析一下性能瓶颈在哪，然后写个扩展库

如果需要和其他平台交互才考虑上面说的这些项目。如果是Web项目就更不用担心了，现在哪个公司还不是混用？ 。基本上上点规模的公司都会用到Python，之前都是 搭配使用，这几年开始慢慢变成 搭配使用了~

下集预估： and