Python信号处理技巧与实战方法

Python信号处理远比表面复杂：signal.signal()仅在主线程有效，子线程注册无效；阻塞调用（如time.sleep、queue.get或C扩展中的等待）常导致SIGINT延迟甚至丢失；真正可靠的中断方案是用threading.Event轮询或timeout接口，而非依赖信号打断；signal.pause()虽简洁却无法兼顾周期性任务，生产环境应优先采用带超时的循环；多线程中信号处理器总在主线程执行，易引发竞态，务必避免在其中做打印、日志或资源操作，只设标志位由主逻辑响应；setitimer()精度差、跨平台受限，实时性要求高的场景应转向threading.Timer或asyncio；归根结底，信号的“不可靠性”恰恰藏在那些你以为它一定生效的时刻——跨平台、混用C库、线程与信号交织时，一句print("got SIGINT")可能永远无法输出。

signal.signal() 为什么收不到 Ctrl+C？ Python 的 signal.signal() 默认只在主线程生效，子线程里调用它没用，而且即使主线程注册了 SIGINT，如果当前正阻塞在某些 C 扩展调用（比如 time.sleep()、queue.get()、某些数据库驱动的等待）中，信号也可能被延迟甚至丢弃。

- 主线程外注册 signal.signal() 是无效的，别白费劲
- 不要依赖“信号一定能打断阻塞”，尤其在使用 requests、psycopg2 或 cv2.waitKey() 这类底层阻塞调用时
- 真正可靠的中断方式是：用 threading.Event 配合轮询，或改用支持 timeout 的接口（如 queue.get(timeout=1)）
- 如果必须用信号，确保在主线程注册，并且避免长时间无检查的阻塞调用

用 signal.pause() 还是 while True + time.sleep()？signal.pause() 看起来简洁，但它会让进程完全挂起、只响应信号，无法做任何周期性检查（比如健康检查、心跳、状态更新），实际生产中几乎不用。

- signal.pause() 适合写一次性监听脚本，比如等某个信号就退出，不干别的
- 大多数服务场景该用带超时的循环：while not exit_event.is_set(): time.sleep(0.1)
- Python 3.3+ 的 signal.sigwait() 更可控，但仅支持 Linux/macOS，且要求信号被设为阻塞态（signal.pthread_sigmask(signal.SIG_BLOCK, [signal.SIGINT])）
- Windows 下 sigwait() 不可用，别写跨平台代码时硬套

多线程里怎么安全地处理信号？ 信号本质是进程级的，没法发给指定线程；Python 的信号处理器总是在主线程执行。如果你在子线程里修改了全局变量、释放了资源，而信号处理器也去操作同一份数据，大概率出竞态。

- 不要在信号处理器里做复杂操作：别调用 print()（可能死锁）、别操作 logging（非线程安全）、别修改共享对象
- 推荐模式：信号处理器只设置一个 threading.Event，主逻辑轮询它
- 别在信号处理器里调用 sys.exit()，它会跳过 finally 和 atexit 注册函数
- 如果用了 concurrent.futures，记得在 shutdown 前先 cancel 正在运行的 future，否则线程池可能卡住

signal.setitimer() 定时触发不稳定？signal.setitimer() 基于系统 setitimer(2)，精度受系统调度和 Python GIL 影响，实际触发时间常比设定值晚几十毫秒，且不能保证每次都在同一个线程上下文执行。

- 它不适合需要亚秒级精度的任务（比如音频采样、实时控制）
- 在容器环境或 CPU 负载高时，定时器可能严重漂移甚至丢失一次触发
- 替代方案更可靠：用 threading.Timer（单次）或 asyncio.call_later()（异步场景）
- 如果坚持用 setitimer()，务必配合 signal.siginterrupt(False) 防止系统调用被中断后不重试

信号处理最麻烦的不是注册，而是「你以为它发生了，其实没有」——尤其是跨平台、混用 C 扩展、或者信号和线程一起上时。留个 print("got SIGINT") 日志，不一定真能打出来。

今天关于《Python信号处理技巧与实战方法》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！