学习python的进程和线程以来，对这两个概念一直都处于模糊状态，所以决定花点时间好好学习一下这块知识。以下是我自己在学习过程中形成的一些疑问以及搜集的一些相应的比较好的答案，整理如下，方便复习自查。

我们可能听过这样的说法：由于GIL的存在，在多个CPU情况下python的多线程是个鸡肋的存在。至于为什么会这样，下文转载的一篇博文中有比较详细的解说。

虽然python多线程鸡肋，但是在阅读python cookbook相关章节时，看到这么样的描述：“GIL带来的最明显的影响就是多线程的python程序无法充分利用多个CPU核心带来的优势(即，一个采用多线程技术的计算密集型应用只能在一个CPU上运行.....如果我们的程序主要是在做I/O操作，比如处理网络连接，那么选择多线程技术常常是一个明智选择。因为他们大部分时间都花在等待对方连接上了)”(来自python cookbook中文版第三版12.9小节，如何规避GIL带来的限制)。其实对于这句话的理解，同样在下面转发的博文中有解释，这里只是用一个更权威的描述来佐证博文中的论述。

所以说，多个CPU情况下，对于I/O密集型操作，使用多线程技术是有益无害的，但是，一旦某个线程是CPU密集型操作，那么该线程就可能长时间占用GIL，导致其他线程长期等待，也无法发挥多个CPU带来的优势，此时应该尽量使用多进程，而不是多线程。既然python多线程仍有用武之地，所以还是有必要好好学习一下这块知识。

I/O操作是否会一直占用CPU？

这个问题在刚开始学习python线程和五大I/O模型的时候困惑了我一段时间，因为我的认识中，所有程序都是由CPU由上到下一条一条执行的。但是在学习I/O模型时，比如下图的异步I/O模型，图左侧aio_read函数发出一个system call之后就return了，然后CPU接着搞事情，但是同时图右侧又注明wait for data，什么鬼，谁在等？难道CPU能分身不成？虽然猜测应该是有别的外设(好在曾经搞过嵌入式，知道外设这概念)在处理数据发送和接收，然后通过中断通知CPU处理结果，但是没有正经理论支撑还是放心不下，于是知乎了一下，果然还是得到了比较满意的答案，总的来说就是IO所需要的CPU资源非常少。大部分工作是分派给DMA(Direct Memory Access)直接内存存取完成的。我把知乎该条回答复制到了我的博客园，以便复习查看点击这里

明白了这个，也就明白了CPU密集型和I/O密集型在使用线程中的区别，CPU密集型代码段需要一直占用CPU，而I/O密集型代码，可以在进行I/O操作的时候让出CPU控制权，而I/O操作的过程是交给DMA处理的，并不需要CPU直接参与。

多核处理器，一个进程的多个线程能否在不同CPU中并行运行?

之前一直以为多核处理器每个CPU只能并行执行不同的进程，因为进程是资源分配的最小单位，如果一个进程的不同线程运行在不同CPU，那么线程间通讯应该比较困难，后来觉得如果这样的话，一个进程的多个线程只能在同一个CPU下轮流执行，对于任务不多的情况下，会导致其他CPU在那里空转，实在是浪费资源，百度了很久，都没有得到正面的回答，在StackOverflow上得到一个好一点的回答。

先把结论摆出来，那就是：同一进程的多个线程，是可以在不同CPU并行(不是并发)执行的。形象一点就是说，假设有一个进程的两个线程A和B，以及两个核CPU1和CPU2，操作系统可以把线程A分配给CPU1执行，同时线程B分配给CPU2执行，以达到并发执行的效果。