gilpython

① python gil 是线程安全的吗

GIL完全可以不在意，根本不是问题。 GIL是Python的全局锁，也就是有它在，同一时刻，只能一个线程访问一个全局资源。 所以Python的多线程，完全没办法利用多核CPU。

② python gil为什么还使用多线程

GIL 的作用是：对于一个解释器，只能有一个thread在执行bytecode。所以每时每刻只有一条bytecode在被执行一个thread。GIL保证了bytecode 这层面上是thread safe的。

但是如果你有个操作比如 x += 1，这个操作需要多个bytecodes操作，在执行这个操作的多条bytecodes期间的时候可能中途就换thread了，这样就出现了data races的情况了。

比如这小家伙就有很多条bytecodes：
>>> dis.dis(lambda x: x+1)
1 0 LOAD_FAST 0 (x)
3 LOAD_CONST 1 (1)
6 BINARY_ADD
7 RETURN_VALUE

③ 为什么说python性能差

python性能差具体原因如下：
1、python是动态语言
一个变量所指向对象的类型在运行时才确定，编译器做不了任何预测，也就无从优化。
2、python是解释执行，但是不支持JIT（just in time compiler）。虽然大名鼎鼎的google曾经尝试Unladen Swallow 这个项目，但最终也折了。
3、python中一切都是对象，每个对象都需要维护引用计数，增加了额外的工作。
4、python GIL
GIL是Python最为诟病的一点，因为GIL，python中的多线程并不能真正的并发。
5、垃圾回收，这个可能是所有具有垃圾回收的编程语言的通病。
python采用标记和分代的垃圾回收策略，每次垃圾回收的时候都会中断正在执行的程序，造成所谓的顿卡。

④ python为什么适合大数据

因为方便啊。
在大数据面前，用什么语言开发，执行起来都需要很长时间，都是慢。
那么，执行速度方面已经没有意义了，写起来舒服的好处就凸显出来了。
试想一下，对于一个大数据任务，你用C写的程序要跑两个小时，别人用python写的要跑四个小时，没人会盯首屏幕两个小时，所以一般都会晚上下班时开始跑，第二天早上来看结果。那么，对于一个晚上的时间来说，两个小时和四个小时，是没有差别的，第二天早上你都一样可以看到结果。
在这种情况下，python的方便灵活就比C的艰深晦涩有吸引力了。

⑤ python GIL 和 线程锁是不是同一个东西

今天看到一篇文章，讲述的是几个提升python性能的项目:传送门

在看的过程中，接触到一个名词，一个从学python开始就一直看到，但是从来都是一知半解的名词，心里不开心，必须把它搞明白，对了，这个词就是 GIL。网上搜索了一些资料，粗浅的理解了什么是GIL，自己感觉学习的过程比较好，感觉略有收获，老规矩，为了巩固知识，自己整片文章出来写一写，其实好多文章已经写的很完善了，所以这篇随笔，只做知识巩固，如有雷同，请各位原创作者原谅，小菜鸟一枚，如果哪里写的有问题，还请各位前辈不吝指正。

一句话：解决多线程之间数据完整性和状态同步的最简单方法自然就是加锁。

首先，GIL的全名，Global Interpreter Lock，鉴于英文水平，不做名词翻译，以免误导。大体解释一下，这个锁就是用来为了解决Cpython多线程中线程不安全问题引入的一个全局排它锁，它的作用就是在多线程情况下，保护共享资源，为了不让多个线程同时操作共享资源，导致不可预期的结果而加上的锁，在一个线程操作共享资源时，其他线程请求该资源，只能等待GIL解锁。这个设置在Cpython刚引入多线程概念的时候就有了，然后后续的各种包和组件开发都不可避免的受到了GIL的影响，所以有人会说，python在多线程处理的时候很慢。python GIL实现方式类似于如下伪代码：

if __name__ == '__main__':
GIL锁开始运作
主线程做操作
主线程完成操作
GIL锁释放资源

所以多线程共同操作共享资源的时候，有一个线程竞得了资源，它就被GIL锁保护起来，其他线程只能是在那里等着，但是这个时候，线程的休眠唤醒，全部会消耗CPU资源，所以嘞，就会慢。

看到这个时候，我又发现了一个名词：线程安全。这个名词，也是那种特别熟悉，但就是无法清晰的说出它是啥的概念。查了资料，在这记一下：

线程安全就是多线程访问时，采用了加锁机制，当一个线程访问该类的某个数据时，进行保护，其他线程不能进行访问直到该线程读取完，其他线程才可使用。不会出现数据不一致或者数据污染。 线程不安全就是不提供数据访问保护，有可能出现多个线程先后更改数据造成所得到的数据是脏数据。

我自己想了一下，大约就是这样，比如整个列表，俩个线程同时在列表中append操作，如果没有锁的保护，在机缘巧合之下，俩个线程同时先后申请了空间且没来得及插入数据，然后这时列表中只会有一个空间，那么在插入过程中只能有一个数据写入，会造成不可知后果，有可能报错终止，有可能有一个线程操作没成功，那么这个就是线程不安全了，大白话说，只要线程之间没有共享资源，那么就是线程安全的，有共享资源，为了保证线程安全，需要引进锁的机制。

而后的文章中，有前辈做过实验：

过程证明了因为GIL的存在，导致python在使用多线程的时候反而不如顺序执行快。

此处我又温习了一下python线程：

线程的顺序执行还是多线程并发，取决于join函数的位置。join函数的作用是等待当前线程结束，所以每一个线程创建之后，调用start函数，这是在后面跟上该线程的join函数，那么就是顺序执行，如果多个线程先完成创建和start，最后加上join函数，那么就变成了多线程并发。

这就是今天的学习内容，其实所有知识网上都能找到，更想分享的是一种学习的方法，一种本身很不推荐的学习方法，那就是类似于探索性测试的学习，啥不懂就去看啥，有些时候，我们学习东西确实不能非要究其内在，软件行业的学习本身在非本行人事看来就特别神奇且枯燥，所以最初的学习，我们需要整个图形界面，让我们学到的东西有了成就感，如果上来先去研究机器码，那么没几个人愿意学下去，但是不管怎样，既然走上了软件行业的道路，这种探索性，打破砂锅问到底的学习，在我的感觉里应该是必经之路，也就是所谓的底层研究。以安卓开发举例，如果做安卓开发的，虽然能写出很漂亮的界面，解决所有的bug，如果不了解安卓系统linux层的知识，在我的眼里，从未把这种研发看做大牛。当然我并不觉得不了解linux底层的安卓研发可以解决任何bug

当下的软件行业进入了一个神奇的阶段，我已经听过无数遍的理论，培训机构出来就能赚钱，大学读着没用，在这里不讨论教育体制问题，从个人情感上，我觉得大学教育虽然没有教给学生直接找工作的技能，但是给了所有学生一个能够了解基础知识的园地，换而言之，作为行业的一员，总应该有将行业发展起来的觉悟，行业内整体风气，缺乏静下心来的沉淀。在大谈敏捷，行为驱动，机器学习的同时，自己需要静下心来回头看看，基础已然不牢，再走下去是否有些危险。是不是学习软件技术，就是为了获取互联网行业那虚高的工资，是否已经局限于第三方框架，一旦框架出现问题，只能打给客服而束手无策，是否有过没有做任何尝试就将bug归咎于安卓系统，阿里中间件等等，是不是旧技术还没用明白，为了新技术就可以不再去研究。

还是小菜鸟，在此大谈行业发展难免有些放肆，如有不对的地方，还请各位前辈不吝指正

⑥ python gil对多进程有影响吗

GIL对多进程完全没有影响，只对多线程产生影响，在这里建议：计算密集型使用多进程，I/0密集型使用对线程

⑦ Python 的 GIL 是什么鬼，多线程性能究竟如何

GIL是什么

首先需要明确的一点是 GIL
并不是Python的特性，它是在实现Python解析器(CPython)时所引入的一个概念。就好比C++是一套语言（语法）标准，但是可以用不同的编译器来编译成可执行代码。有名的编译器例如GCC，INTEL
C++，Visual
C++等。Python也一样，同样一段代码可以通过CPython，PyPy，Psyco等不同的Python执行环境来执行。像其中的JPython就没有GIL。然而因为CPython是大部分环境下默认的Python执行环境。所以在很多人的概念里CPython就是Python，也就想当然的把
GIL 归结为Python语言的缺陷。所以这里要先明确一点：GIL并不是Python的特性，Python完全可以不依赖于GIL

那么CPython实现中的GIL又是什么呢？GIL全称 Global Interpreter Lock 为了避免误导，我们还是来看一下官方给出的解释：

In CPython, the global interpreter lock, or GIL, is a mutex that
prevents multiple native threads from executing Python bytecodes at
once. This lock is necessary mainly because CPython’s memory management
is not thread-safe. (However, since the GIL exists, other features have
grown to depend on the guarantees that it enforces.)

好吧，是不是看上去很糟糕？一个防止多线程并发执行机器码的一个Mutex，乍一看就是个BUG般存在的全局锁嘛！别急，我们下面慢慢的分析。

为什么会有GIL

由于物理上得限制，各CPU厂商在核心频率上的比赛已经被多核所取代。为了更有效的利用多核处理器的性能，就出现了多线程的编程方式，而随之带来的就是线程间数据一致性和状态同步的困难。 即使在CPU内部的Cache也不例外 ，为了有效解决多份缓存之间的数据同步时各厂商花费了不少心思，也不可避免的带来了一定的性能损失。

Python当然也逃不开，为了利用多核，Python开始支持多线程。 而解决多线程之间数据完整性和状态同步的最简单方法自然就是加锁。 于是有了GIL这把超级大锁，而当越来越多的代码库开发者接受了这种设定后，他们开始大量依赖这种特性（即默认python内部对象是thread-safe的，无需在实现时考虑额外的内存锁和同步操作）。

慢慢的这种实现方式被发现是蛋疼且低效的。但当大家试图去拆分和去除GIL的时候，发现大量库代码开发者已经重度依赖GIL而非常难以去除了。有多难？做个类比，像MySQL这样的“小项目”为了把Buffer
Pool
Mutex这把大锁拆分成各个小锁也花了从5.5到5.6再到5.7多个大版为期近5年的时间，本且仍在继续。MySQL这个背后有公司支持且有固定开发团队的产品走的如此艰难，那又更何况Python这样核心开发和代码贡献者高度社区化的团队呢？

所以简单的说GIL的存在更多的是历史原因。如果推到重来，多线程的问题依然还是要面对，但是至少会比目前GIL这种方式会更优雅。

GIL的影响

从上文的介绍和官方的定义来看，GIL无疑就是一把全局排他锁。毫无疑问全局锁的存在会对多线程的效率有不小影响。甚至就几乎等于Python是个单线程的程序。那么读者就会说了，全局锁只要释放的勤快效率也不会差啊。只要在进行耗时的IO操作的时候，能释放GIL，这样也还是可以提升运行效率的嘛。或者说再差也不会比单线程的效率差吧。理论上是这样，而实际上呢？Python比你想的更糟。

下面我们就对比下Python在多线程和单线程下得效率对比。测试方法很简单，一个循环1亿次的计数器函数。一个通过单线程执行两次，一个多线程执行。最后比较执行总时间。测试环境为双核的Mac
pro。注：为了减少线程库本身性能损耗对测试结果带来的影响，这里单线程的代码同样使用了线程。只是顺序的执行两次，模拟单线程。

顺序执行的单线程(single_thread.py)
#! /usr/bin/python
from threading import Thread
import time
def my_counter():
i = 0
for _ in range(100000000):
i = i + 1
return True
def main():
thread_array = {}
start_time = time.time()
for tid in range(2):
t = Thread(target=my_counter)
t.start()
thread_array[tid] = t
for i in range(2):
thread_array[i].join()
end_time = time.time()
print("Total time: {}".format(end_time - start_time))
if __name__ == '__main__':
main()

同时执行的两个并发线程(multi_thread.py)
#! /usr/bin/python
from threading import Thread
import time
def my_counter():
i = 0
for _ in range(100000000):
i = i + 1
return True
def main():
thread_array = {}
start_time = time.time()
for tid in range(2):
t = Thread(target=my_counter)
t.start()
thread_array[tid] = t
for i in range(2):
thread_array[i].join()
end_time = time.time()
print("Total time: {}".format(end_time - start_time))
if __name__ == '__main__':
main()

⑧ python 什么是全局解释器锁gil

什么是Python全局解释器锁(GIL)?
每个CPU在同一时间只能执行一个线程，那么其他的线程就必须等待该线程的全局解释器，使用权消失后才能使用全局解释器，即使多个线程直接不会相互影响在同一个进程下也只有一个线程使用CPU，这样的机制称为全局解释器锁(GIL)。GIL的设计简化了CPython的实现，使得对象模型包括关键的内建类型，如：字典等，都是隐含的，可以并发访问的，锁住全局解释器使得比较容易的实现对多线程的支持，但也损失了多处理器主机的并行计算能力。
Python全局解释器锁(GIL)是一种互斥锁或锁，仅允许一个线程持有Python解释器的控制权。
全局解释器锁的好处
1、避免了大量的加锁解锁的好处;
2、使数据更加安全，解决多线程间的数据完整性和状态同步。
全局解释器锁的劣势
多核处理器退化成单核处理器，只能并发不能并行。
Python全局解释器锁(GIL)的作用
多线程情况下必须存在资源的竞争，GIL是为了保证在解释器级别的线程唯一使用共享资源(cpu)。

⑨ python有了GIL，为什么还有线程锁

在python的原始解释器CPython中存在着GIL（Global Interpreter Lock，全局解释器锁），因此在解释执行python代码时，会产生互斥锁来限制线程对共享资源的访问，直到解释器遇到I/O操作或者操作次数达到一定数目时才会释放GIL。

所以，虽然CPython的线程库直接封装了系统的原生线程，但CPython整体作为一个进程，同一时间只会有一个获得GIL的线程在跑，其他线程则处于等待状态。这就造成了即使在多核CPU中，多线程也只是做着分时切换而已。

不过muiltprocessing的出现，已经可以让多进程的python代码编写简化到了类似多线程的程度了。

⑩ Python的GIL是什么，怎么来的，对性能的影响

#!/usr/bin/python

fromthreadingimportThread
importtime

defmy_counter():
i=0
for_inrange(100000000):
i=i+1
returnTrue

defmain():
thread_array={}
start_time=time.time()
fortidinrange(2):
t=Thread(target=my_counter)
t.start()
t.join()
end_time=time.time()
print("Totaltime:{}".format(end_time-start_time))

if__name__=='__main__':
main()