你对Python 多线程有所了解的话。那么你对python 多线程在单cpu意义上的多线程与多cpu上的多线程有着本质的区别，如果你对Python 多线程的相关知识想有更多的了解，你就可以浏览我们的文章。
Python多线程是单cpu意义上的多线程，它和多cpu上的多线程有着本质的区别。
单cpu多线程：并发
多cpu多线程：并行内部包含并发
在Python 多线程当中，存在一个叫Global Interpreter Lock(GIL)的东西，直译就是全局解释器锁。它的作用在于让同一时刻只能有一个线程对于python对象进行操作。Python已经提供了各种机制让我们进行多线程同步，为什么又要整这个GIL呢？这是因为程序员控制的同步是对各个程序中可见的变量，而GIL同步的是解释器后台的不可见变量，比如为了进行垃圾回收而维护的引用计数。如果没有GIL，有可能出现由于线程切换导致的对同一个对象释放两次的情况。#t#
因此，任何一个CPython线程如果要执行，就必须先获取这个GIL。后果？就是在CPython中，本质上几乎是没有线程并行的，不论你开多少个线程，同一时刻只有获取GIL的那个线程能够执行。为什么要说几乎呢，这是因为提供给python的C库中，还是有解决方案的，比如
这段代码是sleep的代码，在执行sleep之前，通过一个宏来释放GIL，然后在睡眠结束执行其他代码前又获取GIL。其他一下操作，比如IO，也会有类似的操作，这样就使得对于IO密集型的程序，或者是使用C库进行计算的程序，还是可以在很大程度上避开GIL来取得线程并行的效果的。但对于纯python代码的程序，GIL恐怕还是躲不过去的。
还有一个问题，就是GIL怎么释放，我们看到在python/C API中提供了宏来进行释放，那么对于普通的python语句呢？解释器会在执行一百条python代码后强制释放GIL，这就使得其它线程得以执行。
最后需要说明的，就是这个GIL的问题是解释器相关的，而不是语言相关的。也就是说它只是对于python语言解释器的一种实现，并不是语言本身的特性。事实上，GIL就是解释器的一个非常粗粒度的锁，我们完全可以采用更细粒度的锁来增加并行性，而且Gindo就写过一个patch来取消GIL，不过好像最后的结果是细粒度锁导致了单线程程序的性能下降了两倍，所以最后还是决定优先保证单线程程序的性能，继续保留GIL。但是python的其他两个分支，Jython和IronPython，却都没有GIL的问题，从而可以实现线程的并行。
总结：
通常加锁也有2种不同的粒度的锁:
fine-grained(所谓的细粒度), 那么程序员需要自行地加,解锁来保证线程安全
coarse-grained(所谓的粗粒度), 那么语言层面本身维护着一个全局的锁机制,用来保证线程安全
Python 多线程 从语言层面本身维护着一个全局的锁机制,用来保证线程安全；而java, Jython则是细粒度的。
所以也就是说，由于gil的限制，python语言本身是不能够进行并行编程的，但是可以进行并发编程；而java则没有gil意义上的限制，因此java从java7开始已经开始往并行上偏移了。
