导读：很多朋友问到关于python多少毫秒释放gil的相关问题，本文首席CTO笔记就来为大家做个详细解答，供大家参考，希望对大家有所帮助！一起来看看吧！
为什么很多人对Python的GIL耿耿于怀
在python的原始解释器CPython中存在着GIL（Global Interpreter Lock，全局解释器锁），因此在解释执行python代码时，会产生互斥锁来限制线程对共享资源的访问，直到解释器遇到I/O操作或者操作次数达到一定数目时才会释放GIL。
所以，虽然CPython的线程库直接封装了系统的原生线程，但CPython整体作为一个进程，同一时间只会有一个获得GIL的线程在跑，其他线程则处于等待状态。这就造成了即使在多核CPU中，多线程也只是做着分时切换而已。
谈下python的GIL
GIL是python的全局解释器锁，同一进程中假如有多个线程运行，一个线程在运行python程序的时候会霸占python解释器(加了一把锁即GIL)，使该进程内的其他线程无法运行，等该线程运行完后其他线程才能运行。如果线程运行过程中遇到耗时操作，则解释器锁解开，使其他线程运行。所以在多线程中，线程的运行仍是有先后顺序的，并不是同时进行。
多进程中因为每个进程都能被系统分配资源，相当于每个进程有了一个python解释器，所以多进程可以实现多个进程的同时运行，缺点是进程系统资源开销大。
为什么在Python里推荐使用多进程而不是多线程
首先强调背景：
1. GIL是什么？
GIL的全称是Global Interpreter Lock(全局解释器锁)，来源是python设计之初的考虑，为了数据安全所做的决定。
2. 每个CPU在同一时间只能执行一个线程
在单核CPU下的多线程其实都只是并发，不是并行，并发和并行从宏观上来讲都是同时处理多路请求的概念。但并发和并行又有区别，并行是指两个或者多个事件在同一时刻发生；而并发是指两个或多个事件在同一时间间隔内发生。
在Python多线程下，每个线程的执行方式：
获取GIL
执行代码直到sleep或者是python虚拟机将其挂起。
释放GIL
可见，某个线程想要执行，必须先拿到GIL，我们可以把GIL看作是“通行证”，并且在一个python进程中，GIL只有一个。拿不到通行证的线程，就不允许进入CPU执行。
在Python2.x里，GIL的释放逻辑是当前线程遇见IO操作或者ticks计数达到100（ticks可以看作是Python自身的一个计数器，专门作用于GIL，每次释放后归零，这个计数可以通过 sys.setcheckinterval 来调整），进行释放。
而每次释放GIL锁，线程进行锁竞争、切换线程，会消耗资源。并且由于GIL锁存在，python里一个进程永远只能同时执行一个线程(拿到GIL的线程才能执行)，这就是为什么在多核CPU上，python的多线程效率并不高。
那么是不是python的多线程就完全没用了呢？
在这里我们进行分类讨论：
CPU密集型代码(各种循环处理、计数等等)，在这种情况下，由于计算工作多，ticks计数很快就会达到阈值，然后触发GIL的释放与再竞争（多个线程来回切换当然是需要消耗资源的），所以python下的多线程对CPU密集型代码并不友好。
IO密集型代码(文件处理、网络爬虫等)，多线程能够有效提升效率(单线程下有IO操作会进行IO等待，造成不必要的时间浪费，而开启多线程能在线程A等待时，自动切换到线程B，可以不浪费CPU的资源，从而能提升程序执行效率)。所以python的多线程对IO密集型代码比较友好。
而在python3.x中，GIL不使用ticks计数，改为使用计时器（执行时间达到阈值后，当前线程释放GIL），这样对CPU密集型程序更加友好，但依然没有解决GIL导致的同一时间只能执行一个线程的问题，所以效率依然不尽如人意。
请注意：多核多线程比单核多线程更差，原因是单核下的多线程，每次释放GIL，唤醒的那个线程都能获取到GIL锁，所以能够无缝执行，但多核下，CPU0释放GIL后，其他CPU上的线程都会进行竞争，但GIL可能会马上又被CPU0拿到，导致其他几个CPU上被唤醒后的线程会醒着等待到切换时间后又进入待调度状态，这样会造成线程颠簸(thrashing)，导致效率更低。
回到最开始的问题：经常我们会听到老手说：“python下想要充分利用多核CPU，就用多进程”，原因是什么呢？
原因是：每个进程有各自独立的GIL，互不干扰，这样就可以真正意义上的并行执行，所以在python中，多进程的执行效率优于多线程(仅仅针对多核CPU而言)。
所以在这里说结论：多核下，想做并行提升效率，比较通用的方法是使用多进程，能够有效提高执行效率
为什么在Python里推荐使用多进程而不是多
最近在看Python的多线程，经常我们会听到老手说：“Python下多线程是鸡肋，推荐使用多进程！”，但是为什么这么说呢？
要知其然，更要知其所以然。所以有了下面的深入研究：
首先强调背景：
1、GIL是什么？
GIL的全称是Global Interpreter Lock(全局解释器锁)，来源是python设计之初的考虑，为了数据安全所做的决定。
2、每个CPU在同一时间只能执行一个线程（在单核CPU下的多线程其实都只是并发，不是并行，并发和并行从宏观上来讲都是同时处理多路请求的概念。但并发和并行又有区别，并行是指两个或者多个事件在同一时刻发生；而并发是指两个或多个事件在同一时间间隔内发生。）
在Python多线程下，每个线程的执行方式：
1、获取GIL
2、执行代码直到sleep或者是python虚拟机将其挂起。
3、释放GIL
可见，某个线程想要执行，必须先拿到GIL，我们可以把GIL看作是“通行证”，并且在一个python进程中，GIL只有一个。拿不到通行证的线程，就不允许进入CPU执行。
在Python2.x里，GIL的释放逻辑是当前线程遇见IO操作或者ticks计数达到100（ticks可以看作是Python自身的一个计数器，专门做用于GIL，每次释放后归零，这个计数可以通过 sys.setcheckinterval 来调整），进行释放。
而每次释放GIL锁，线程进行锁竞争、切换线程，会消耗资源。并且由于GIL锁存在，python里一个进程永远只能同时执行一个线程(拿到GIL的线程才能执行)，这就是为什么在多核CPU上，python的多线程效率并不高。
那么是不是python的多线程就完全没用了呢？
在这里我们进行分类讨论：
1、CPU密集型代码(各种循环处理、计数等等)，在这种情况下，由于计算工作多，ticks计数很快就会达到阈值，然后触发GIL的释放与再竞争（多个线程来回切换当然是需要消耗资源的），所以python下的多
Python GIL 和 Flask
Python有个GIL ( Global Interpreter Lock )， 使得同一个 Python 解释器下的多线程任务只能串行执行.
据 UnderstandingGIL 介绍， 有GIL的情况下， 将一个大任务分拆成小任务并调度到多个线程执行， 效率反而大大降低。 这就是GIL的直接后果， 后面Python3.2版本优化GIL之后， 也只能接近单线程的性能。想想 Java 平台的 fork-and-join 等框架， 在Python世界里压根不可能。
在 time.sleep()、IO 操作等会自动释放 GIL， 给其他线程机会切换运行， 有时候造成并行执行的假象。 对于 cpu 计算型任务， 通过 sys.setcheckinterval() 设置上下文切换的频率。
Flask 1.0 版本， Flask.run() 默认采用多线程方式运行， 每个并发接入的用户都会 fork 一个线程来响应， 结合上文的分析， Python并不是真正的多线程， 但 epoll IO模型， 对单线程友好(如 Node.js)。因此， 对Flask程序进行改造：
在我的机器上， 在 100 线程、每个线程循环6次的情况下， 平均响应330ms左右， 多线程 和 gevent 的实现差不多， 但 线程数加到 200 时， gevent的版本还稳定在 330ms， 但 多线程已经到 600ms了， 线程调度的负担越来越重， 请求失败的情况也出现了。
借助 gevent， 不采用生产的WSGI服务器实现， Flask应用性能也能得到不错的提升。 实际上， gunicorn、tornado 等均采用了epoll IO模型。
为什么有人说 Python 的多线程是鸡肋
因为 Python 中臭名昭著的 GIL。
那么 GIL 是什么？为什么会有 GIL？多线程真的是鸡肋吗？ GIL 可以去掉吗？带着这些问题，我们一起往下看，同时需要你有一点点耐心。
多线程是不是鸡肋，我们先做个实验，实验非常简单，就是将数字 “1亿” 递减，减到 0 程序就终止，这个任务如果我们使用单线程来执行，完成时间会是多少？使用多线程又会是多少？show me the code
单线程
在我的4核 CPU 计算机中，单线程所花的时间是 6.5 秒。可能有人会问，线程在哪里？其实任何程序运行时，默认都会有一个主线程在执行。（关于线程与进程这里不展开，我会单独开一篇文章）
多线程
创建两个子线程 t1、t2，每个线程各执行 5 千万次减操作，等两个线程都执行完后，主线程终止程序运行。结果，两个线程以合作的方式执行是 6.8 秒，反而变慢了。按理来说，两个线程同时并行地运行在两个 CPU 之上，时间应该减半才对，现在不减反增。
是什么原因导致多线程不快反慢的呢？
原因就在于 GIL ，在 Cpython 解释器（Python语言的主流解释器）中，有一把全局解释锁（Global Interpreter Lock），在解释器解释执行 Python 代码时，先要得到这把锁，意味着，任何时候只可能有一个线程在执行代码，其它线程要想获得 CPU 执行代码指令，就必须先获得这把锁，如果锁被其它线程占用了，那么该线程就只能等待，直到占有该锁的线程释放锁才有执行代码指令的可能。
因此，这也就是为什么两个线程一起执行反而更加慢的原因，因为同一时刻，只有一个线程在运行，其它线程只能等待，即使是多核CPU，也没办法让多个线程「并行」地同时执行代码，只能是交替执行，因为多线程涉及到上线文切换、锁机制处理（获取锁，释放锁等），所以，多线程执行不快反慢。
什么时候 GIL 被释放呢？
当一个线程遇到 I/O 任务时，将释放GIL。计算密集型（CPU-bound）线程执行 100 次解释器的计步（ticks）时（计步可粗略看作 Python 虚拟机的指令），也会释放 GIL。可以通过设置计步长度，查看计步长度。相比单线程，这些多是多线程带来的额外开销
CPython 解释器为什么要这样设计？
多线程是为了适应现代计算机硬件高速发展充分利用多核处理器的产物，通过多线程使得 CPU 资源可以被高效利用起来，Python 诞生于1991年，那时候硬件配置远没有今天这样豪华，现在一台普通服务器32核64G内存都不是什么司空见惯的事
但是多线程有个问题，怎么解决共享数据的同步、一致性问题，因为，对于多个线程访问共享数据时，可能有两个线程同时修改一个数据情况，如果没有合适的机制保证数据的一致性，那么程序最终导致异常，所以，Python之父就搞了个全局的线程锁，不管你数据有没有同步问题，反正一刀切，上个全局锁，保证数据安全。这也就是多线程鸡肋的原因，因为它没有细粒度的控制数据的安全，而是用一种简单粗暴的方式来解决。
这种解决办法放在90年代，其实是没什么问题的，毕竟，那时候的硬件配置还很简陋，单核 CPU 还是主流，多线程的应用场景也不多，大部分时候还是以单线程的方式运行，单线程不要涉及线程的上下文切换，效率反而比多线程更高（在多核环境下，不适用此规则）。所以，采用 GIL 的方式来保证数据的一致性和安全，未必不可取，至少在当时是一种成本很低的实现方式。
那么把 GIL 去掉可行吗？
还真有人这么干多，但是结果令人失望，在1999年Greg Stein 和Mark Hammond 两位哥们就创建了一个去掉 GIL 的 Python 分支，在所有可变数据结构上把 GIL 替换为更为细粒度的锁。然而，做过了基准测试之后，去掉GIL的 Python 在单线程条件下执行效率将近慢了2倍。
Python之父表示：基于以上的考虑，去掉GIL没有太大的价值而不必花太多精力。
结语：以上就是首席CTO笔记为大家整理的关于python多少毫秒释放gil的相关内容解答汇总了，希望对您有所帮助！如果解决了您的问题欢迎分享给更多关注此问题的朋友喔～