Python手动中断(Ctrl-C)多线程程序

灵感来源依旧是爬虫框架项目pycrawler,爬虫作为子线程运行时不受键盘中断信号影响,Ctrl-C无法终止整个爬虫运行。另外的一个场景是多线程压力测试,需要提前终止的情况下,Ctrl-C依旧不能终止整个程序。除了简单粗暴的使用kill命令强行终止之外,本文将给出一个简单可行的解决方案。
值得注意的一点是,Python2、3两个版本在测试中的表现并不一致,所以使用两个版本分别进行测试。
博客原文

测试环境

  • Python2 2.7.9
  • Python3 3.4.2
  • Mac OS X Yosemite 10.10.3

子线程类

import time
from threading import Thread


class CountDown(Thread):
    def __init__(self):
        super(CountDown, self).__init__()

    def run(self):
        num = 100
        print('slave start')
        for i in range(10, 0, -1):
            print('Num: {0}'.format(num/i))
            time.sleep(1)
        print('slave end')

失败情况一

主线程代码

if __name__ == '__main__':
    print('main start')
    CountDown().start()
    print('main end')

使用Python2进行测试,在运行结束之前手动终止:

main start
slave start
 main end
Num: 10
Num: 11
^CNum: 12
Num: 14
Num: 16
Num: 20
Num: 25
Num: 33
Num: 50
Num: 100
slave end
Exception KeyboardInterrupt in <module 'threading' from '/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.pyc'> ignored

可以看到,运行到第三行时手动终止,主线程已经提前结束,子线程继续执行直到结束,然后抛出未捕获异常,值得注意的是,此时没有Traceback输出。
接下来使用Python3测试同样的代码:

main start
slave start
main end
Num: 10.0
Num: 11.11111111111111
Num: 12.5
^CException ignored in: <module 'threading' from '/usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/threading.py'>
Traceback (most recent call last):
  File "/usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/threading.py", line 1294, in _shutdown
    t.join()
  File "/usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/threading.py", line 1060, in join
    self._wait_for_tstate_lock()
  File "/usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/threading.py", line 1076, in _wait_for_tstate_lock
    elif lock.acquire(block, timeout):
KeyboardInterrupt

有趣的事情发生了,主线程依旧提前退出,子线程在手动终止后也被强行终止,虽然打印了Traceback信息,但和上例一样依旧是Exception ignored

失败情况二

主线程代码,现在调用join()方法使主线程等待子线程完成:

if __name__ == '__main__':
    print('main start')
    td = CountDown()
    td.start()
    td.join()
    print('main end')

同上,使用Python2进行测试:

main start
slave start
Num: 10
Num: 11
Num: 12
^CNum: 14
Num: 16
Num: 20
Num: 25
Num: 33
Num: 50
Num: 100
slave end
Traceback (most recent call last):
  File "multithread.py", line 23, in <module>
    td.join()
  File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 949, in join
    self.__block.wait()
  File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 340, in wait
    waiter.acquire()
KeyboardInterrupt

可以看出,主线程调用join()方法之后wait在一个锁上,等待子线程退出。子线程退出后,主线程获得锁并响应中断信号,抛出异常并打印信息,main end一行并没有被打印。
然后使用Python3进行测试:

main start
slave start
Num: 10.0
Num: 11.11111111111111
Num: 12.5
^CTraceback (most recent call last):
  File "multithread.py", line 23, in <module>
    td.join()
  File "/usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/threading.py", line 1060, in join
    self._wait_for_tstate_lock()
  File "/usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/threading.py", line 1076, in _wait_for_tstate_lock
    elif lock.acquire(block, timeout):
KeyboardInterrupt
Num: 14.285714285714286
Num: 16.666666666666668
Num: 20.0
Num: 25.0
Num: 33.333333333333336
Num: 50.0
Num: 100.0
slave end

神奇的事情再次发生了,主线程等待子线程过程中响应了中断信号,打印信息后退出,而此时子线程没有受影响,继续执行直到结束。

思考

从Python3的Traceback信息可以看出,即使没有显式调用join()方法,主线程执行完成后依然会自动调用一个join()逻辑(line 1294, in _shutdown),而且个方法对子线程的影响并不一致:显式调用时子线程不受影响继续执行;而自动调用时,子线程随主线程一起退出。
根据Traceback信息查看Python3源代码:

def _shutdown():
    # Obscure:  other threads may be waiting to join _main_thread.  That's
    # dubious, but some code does it.  We can't wait for C code to release
    # the main thread's tstate_lock - that won't happen until the interpreter
    # is nearly dead.  So we release it here.  Note that just calling _stop()
    # isn't enough:  other threads may already be waiting on _tstate_lock.
    tlock = _main_thread._tstate_lock
    # The main thread isn't finished yet, so its thread state lock can't have
    # been released.
    assert tlock is not None
    assert tlock.locked()
    tlock.release()
    _main_thread._stop()
    t = _pickSomeNonDaemonThread()
    while t:
        t.join()
        t = _pickSomeNonDaemonThread()
    _main_thread._delete()

def _pickSomeNonDaemonThread():
    for t in enumerate():
        if not t.daemon and t.is_alive():
            return t
    return None

从源代码可以看出,主线程调用了_stop()方法,然后循环等待所有非daemon进程执行结束,最终调用_delete()方法结束运行。所以主线程虽然执行完了所有的代码,但是其实并未真正退出,而是等待所有非daemon子线程全部执行完毕后才释放资源退出程序(所有daemon线程也随之被销毁),这个过程中,主线程仅仅占有资源但并没有执行逻辑(这里我的理解是,不会响应中断信号)。
所以,得出结论:

  • 没有调用join()的情况下,主线程退出执行逻辑但没有释放资源,且不响应中断信号,此时中断信号由子线程响应,于是在失败情况一中,程序成功被终止。
  • 显式调用join()的情况下,主线程没有执行后续代码,而是等待子线程释放锁,因此可以响应中断信号,于是在失败情况二中,主线程响应中断信号并执行退出逻辑(进入上一种情况),子线程并未受影响,执行完毕后程序退出。

但是对于Python2和Python3之间的差别,我现在依旧没有想明白,初步的想法是2和3对于异常的处理逻辑(或者说顺序)不一致,导致2中所有的异常都在主线程真正退出时才被捕获。打算去知乎问一下,之后会补上问题链接

解决方案

说了这么多终于到解决方案了。思路是:设置子线程为daemon线程,启动子线程后主线程调用isAlive()方法手动模拟join过程。
代码如下:

if __name__ == '__main__':
    print('main start')
    td = CountDown()
    td.setDaemon(True)
    td.start()
    try:
        while td.isAlive():
            pass
    except KeyboardInterrupt:
        print('stopped by keyboard')
    print('main end')

测试输出(Python2、3执行结果一致):

main start
slave start
Num: 10
Num: 11
Num: 12
Num: 14
Num: 16
^Cstopped by keyboard
main end

此方案另一优点是主线程可以继续执行之后的善后逻辑。

  • 感觉这种解决方案算是非主流小技巧了,我想了好久才想出来,具体应用中实不实用还不知道,毕竟现在接触的项目都太小了。
  • 从这个例子看出,Python2和Python3之间除了官网提到的关键区别,还有很多细微的差别,这些差别对某些特定程序可能会产生一定影响,只能慢慢摸索着发现了。
  • 这篇文章算是多线程tricky技巧第一篇。多线程程序中另一个重要问题是主线程如何捕获子线程产生的异常,我构思了一个方案,有时间测试一下。
  • 如果有哪些不对的地方或者有更好的解决方案,欢迎讨论。
  • 谢谢~
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 194,088评论 5 459
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 81,715评论 2 371
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 141,361评论 0 319
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 52,099评论 1 263
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 60,987评论 4 355
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 46,063评论 1 272
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 36,486评论 3 381
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 35,175评论 0 253
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 39,440评论 1 290
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,518评论 2 309
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,305评论 1 326
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,190评论 3 312
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 37,550评论 3 298
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 28,880评论 0 17
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,152评论 1 250
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 41,451评论 2 341
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 40,637评论 2 335

推荐阅读更多精彩内容