在专栏《教你用 Python 进阶量化交易》的《多进程和多线程的分析》中我们讲到过GIL（Global Interpreter Lock全局解释器锁）。
我们知道Python的线程是封装了底层操作系统的线程，在Linux系统中是Pthread(全称为POSIX Thread)，在Windows中是Windows Thread。因此Python的线程是完全受操作系统的管理的。但是在计算密集型的任务中多线程反而比单线程更慢。
这是为什么呢？
在CPython 解释器中执行线程时，每一个线程开始执行时，都会锁住 GIL，以阻止别的线程执行。同样的，每一个线程执行完一段后，会释放 GIL，以允许别的线程开始利用资源。毕竟，如果Python线程在开始的时候锁住GIL而不去释放GIL，那别的线程就没有运行的机会了。
为什么要这么处理呢？
我们先来介绍下竞争条件（race condition）这个概念。竞争条件是指两个或者多个线程同时竞争访问的某个资源（该资源本身不能被同时访问），有可能因为时间上存在先后原因而出现问题，这种情况叫做竞争条件（Race Condition）。（Python中进程是有独立的资源分配，线程是共用资源分配）
回到CPython上，CPython是使用引用计数器来管理内存的，所有创建的对象，都会有一个引用计数来记录有多少个指针指向它。如下所示：
a_val = []
def ReferCount():
print(sys.getrefcount(a_val)) # 2
b = a_val
c = a_val
print(sys.getrefcount(a_val)) # 4
当引用计数为0时，CPython解释器会自动释放内存。这样一来，如果有两个Python线程同时引用了一个变量，就会造成引用计数的竞争条件（race condition）。因此引用计数变量需要在两个线程同时增加或减少时从竞争条件中得到保护。如果发生了这种情况，可能会导致泄露的内存永远不会被释放，更严重的是当一个对象的引用仍然存在的情况下错误地释放内存，导致Python程序崩溃或带来各种诡异的问题。
以下是官方给的解释：
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.)
如何绕过GIL的限制？
目前像NumPy的矩阵运算这些高性能的应用场景是通过C/C++来实现Python库，可以避免CPython解释器的GIL限制。另一方面，当涉及到对性能非常严格的应用场景时，可以把关键代码用C/C++来实现，然后通过Python调用这些程序，以此摆脱GIL的限制。
有了GIL机制是否还需要考虑竞争条件吗？
GIL的设计是为了方便CPython解释器层面的编写者，而不是Python应用层面的程序员。作为Python的使用者，我们还是需要用Lock等工具来锁住资源，来确保线程安全。
接下来我们就介绍下如何使用Lock机制。
Lock的使用主要有以下几个方法：
mutex = threading.Lock() # 创建锁
mutex.acquire([timeout]) # 锁定
mutex.release() # 释放
例如以下例程：
g_count = 0
def func(str_val):
global g_count
for i in range(1000000):
g_count += 1
print(str_val+':g_count=%s' % g_count)
def test_func_lock():
t1 = threading.Thread(target=func,args=['func1'])
t2 = threading.Thread(target=func,args=['func2'])
t1.start()
t2.start()
t1.join()
t2.join()
最终返回的结果有这些情况：
func2:g_count=1509057 func1:g_count=1489782
func1:g_count=1305421 func2:g_count=1684556
func2:g_count=1545063 func1:g_count=1547995
……
理论上最后的结果应该是2000000，由于线程被调用执行的顺序并不确定，同时存在执行递增语句时切换线程，导致最后的结果并不是正确结果。
我们通过建立一个线程锁来解决这个问题。如下所示：
g_count = 0
lock = threading.Lock()
def func(str_val):
global g_count
for i in range(1000000):
lock.acquire()
g_count += 1
lock.release()
print(str_val+':g_count=%s' % g_count)
执行结果为：func2:g_count=1988364 func1:g_count=2000000
比如线程t1使用lock.acquire()获得了这个锁，那么线程t2就无法再获得该锁了，只会阻塞在 lock.acquire()处，直到锁被线程t1释放，即执行lock.release()。如此一来就不会出现执行了一半就暂停去执行别的线程的情况，最后结果是正确的2000000。
最后给大家推荐一个更精简的锁的用法：
def threading_lock_test():
# 创建锁
lock = threading.Lock()
# 使用锁的老方法
lock.acquire()
try:
print('Critical section 1')
print('Critical section 2')
finally:
lock.release()
# 使用锁的新方法
with lock:
print('Critical section 1')
print('Critical section 2')
·····························
欢迎大家订阅《教你用 Python 进阶量化交易》专栏！