为何极小的线程切换间隔不会拖慢Python3的CPU密集型多线程？

这个问题的核心其实和Python的GIL（全局解释器锁）以及它在Python 3中的改进密切相关，咱们一步步拆解来看：

先澄清一个关键前提：Python CPU密集型多线程的本质 #

因为GIL的存在，同一时刻只有一个线程能执行Python字节码——哪怕你是四核CPU，Python的多线程在CPU密集场景下也只是在单核上做时间分片，并不是真正的并行执行。这意味着线程切换是在同一个CPU核心的用户态完成的上下文切换，而不是跨核的操作系统级休眠/唤醒（那种操作开销才大）。

关于sys.setswitchinterval()的实际作用 #

你设置的这个参数，控制的是GIL的主动释放间隔：当一个线程持有GIL的时间达到这个阈值时，会主动释放GIL，让其他线程有机会竞争。但对于CPU密集型线程来说，它们并不会进入休眠状态（休眠通常发生在IO等待、主动sleep或者被操作系统强制挂起时），而是一直在GIL的竞争队列里等待。

所以你担心的“更多休眠/唤醒操作”其实并没有发生——这里的切换只是解释器层面的字节码执行权移交，属于轻量级操作，开销非常低。

Python 3.5的GIL优化放大了这个效果 #

Python 3.2之后对GIL做了重大重构，采用了基于时间片的轮换策略，同时优化了GIL的竞争逻辑，大幅降低了CPU密集型线程间的切换开销。在你的测试中，把切换间隔从1秒调到0.001秒，额外的切换开销在总执行时间里占比极小，所以最终结果只差了0.02秒，几乎可以忽略。

你的理解误区来自哪里？ #

你从《NewGIL.pdf》里得到的“较小切换间隔导致更多休眠/唤醒”的结论，可能混淆了两种不同的线程切换：

• 一种是操作系统级的线程休眠唤醒：当线程被挂起（比如IO阻塞）再唤醒，需要涉及内核态的上下文切换，开销很大；
• 另一种是Python解释器层面的GIL切换：CPU密集型线程一直在竞争GIL，没有被操作系统挂起，只是在用户态做轻量级的上下文切换，开销可以忽略不计。

补充测试建议 #

如果想看到切换间隔对性能的明显影响，可以试试用multiprocessing做真正的并行计算——进程的切换是操作系统级的，这时候如果把切换间隔（操作系统的时间片）调得极小，才会明显拖慢总执行时间。

你的测试代码格式化后： #

from threading import Thread
def countdown(start, end):
    while end > start:
        end -= 1
def multi_thread(n):
    t1 = Thread(target=countdown, args=(0, n // 2))
    t2 = Thread(target=countdown, args=(n // 2, n))
    t1.start()
    t2.start()
    t1.join()
    t2.join()
if __name__ == '__main__':
    import timeit
    import sys
    sys.setswitchinterval(1)
    print(timeit.timeit("""import gil;gil.multi_thread(10000000);""", number=1)) # 1.07s
    sys.setswitchinterval(0.001)
    print(timeit.timeit("""import gil;gil.multi_thread(10000000);""", number=1)) # 1.09s

内容的提问来源于stack exchange，提问作者Jeffery