python signal

### 聊一聊 Python 的 signal：它到底是什么，能做什么，以及怎么用才不会出乱子

Signal 这个东西，听起来好像很底层，很“系统编程”。确实，它最初是 Unix 世界里的一个概念，就像一个传令兵，能跨进程给正在运行的程序递个小纸条。Python 作为一个“胶水”语言，很自然地把它封装成了signal模块。不过，这个模块用起来有它自己的脾气，如果当成普通函数来玩，很容易踩坑。

1. 它到底是什么？

你可以把 Python 程序想象成一个正在埋头算数的人。Signal 就是从他背后传来的一个声音，可能是“你有个新消息”（SIGUSR1），也可能是“时间到了，该交卷了”（SIGALRM），更可能是“外面有个炸弹，赶紧跑”（SIGINT，就是我们熟悉的 Ctrl+C）。

本质上，signal 是一种异步事件通知机制。它不是程序主动去轮询、去检查有没有消息，而是操作系统在特定时刻强行打断程序的执行流，让程序去执行一个预先设定好的“回调函数”（也就是信号处理器，handler）。处理完了，再回到之前被打断的地方继续干活。有点像深夜加班，突然有人拍你肩膀说“老板叫你”，你跑去办公室听完指示，回来继续码代码。

关键点在于“异步”和“打断”。这两个词决定了使用信号的所有规则。

2. 他能做什么？

最常见的用途是优雅退出。比如说，你写了一个长期运行的后台服务，跑在服务器上。运维人员想重启它，啪一个kill命令（默认发 SIGTERM）过来。你的程序应该在收到这个信号时，主动关闭数据库连接、保存当前数据、清理临时文件，然后再退出，而不是被操作系统强行杀掉。

另一个典型场景是超时控制。当你调一个可能会卡死的第三方 API 或者执行一条特别慢的 SQL 时，可以用signal.alarm()设置一个闹钟，比如 10 秒后自动发送 SIGALRM 信号。在信号处理器里抛出一个TimeoutError，就能跳出当前阻塞的函数，避免整个进程挂在那。

还有日志轮转或者重新读取配置文件。很多服务会监听 SIGHUP 信号，收到后重新加载配置，而不需要停机重启。这在生产环境中特别有用。

当然，也有人用它来做一些进程间通信的“简易版”，但说实话，现代 Python 框架已经提供了更优雅的方式（比如 asyncio 的事件循环或者多进程的队列），直接用 signal 做复杂通信需要非常小心。

3. 怎么使用？

Python 的signal模块使用起来比想象中简单，但陷阱也藏在这个“简单”里。基本套路就是三步：定义一个处理函数，用signal.signal()注册，然后等着信号来。

importsignalimporttimeimportsysdefhandle_sigterm(signum,frame):# signum 是收到的信号编号，frame 是当前堆栈帧print("收到 SIGTERM，正在优雅退出...")# 在这里做清理工作，比如关闭文件、释放锁sys.exit(0)# 注册 SIGTERM 的处理函数signal.signal(signal.SIGTERM,handle_sigterm)print("进程启动，等待信号...")# 假装在干重要的事情whileTrue:time.sleep(1)

看起来是不是很简单？发个kill -TERM <pid>试试，程序就会打出那条消息后退出。

signal.alarm(seconds)是另一个常用功能，它相当于一个一次性闹钟。注意，它按 Unix 的秒数计时，不是真实的墙上时间（如果你的程序被挂起，计时也会挂起）。而且，alarm只能在同一时间设置一个闹钟，后设置的会覆盖前一个。想要多组超时或者更精细控制，就得用signal.setitimer()，它可以设置间隔定时器和更短的计时精度。

处理SIGINT（Ctrl+C）则是另一个常见场景。默认情况下 Ctrl+C 会抛出KeyboardInterrupt异常。如果你希望捕捉它来做自定义行为，也像上面那样注册就行。但有个细节：如果程序正在执行一个 C 扩展模块的操作，信号可能不会被及时处理，要等到那个调用返回后才行。

4. 最佳实践

使用 signal 有个最重要的铁律：信号处理器里不要做太多事，尤其不能做线程不安全的事。信号处理器是在主线程被打断的瞬间运行的，状态非常微妙。如果这时候去操作一个全局的列表、打印日志、获取锁、甚至调print()，都可能引发死锁或者数据损坏。比较好的做法是：处理器里只设一个标志位（比如一个全局的Event对象或者一个简单的原子变量），然后让主循环定期检查这个标志位。

importsignalimportthreading shutdown_event=threading.Event()defhandle_sigterm(signum,frame):shutdown_event.set()signal.signal(signal.SIGTERM,handle_sigterm)# 主循环whilenotshutdown_event.is_set():# 干你的活time.sleep(0.5)# 循环结束，执行清理

另一个重要的点：信号处理在子线程中很不可靠。Python 的信号机制有一个特性：信号处理器永远只在主线程中执行，哪怕你把信号注册在子线程里。所以如果你写了多线程程序，signal.alarm()或者signal.signal()只会在主线程中的某次字节码间隙被执行。如果你想让一个子线程响应超时，应该用threading.Timer或者concurrent.futures的timeout参数，而不是信号。

说到signal.alarm()，在实际的多线程 Web 服务里，用它来做超时要特别小心。因为它是一个“全局”的闹钟，如果某个请求设置了闹钟，另一个请求没有处理完，闹钟响了，系统会不知所措。现代 Python 更推荐用asyncio.wait_for()来处理协程的超时，那是真正的“协程局部”超时。

还有一个容易被忽略的点：在调用signal.signal()之前，最好先确认当前操作系统的信号默认行为不是你想要的。比如SIGPIPE在某些场景下会导致程序默默退出，捕捉一下总没坏处。

5. 和同类技术对比

说到同类，其实没有完全一模一样的另一个东西，但有几个替代方案值得聊聊。

atexit模块是专门做“进程退出时清理”的。用法是在代码里注册一个函数，程序无论正常结束（exit()或走到末尾）还是因为异常崩溃，都会执行它。但有个区别：它是“捕获式”的，只能响应程序主动退出，收到SIGKILL（kill -9）就没辙了，因为SIGKILL连信号处理器都不给机会。而 signal 可以捕捉到SIGTERM、SIGHUP这些更温和的信号，给你留出清理时间。实际项目中，往往是两个配合使用：signal负责捕捉外部信号，atexit负责兜底。

threading.Timer和asyncio.wait_for是处理超时控制的现代方案。前者可以在子线程里设置延迟任务，后者是协程级别的超时。它们都比signal.alarm更灵活、更安全，适合多任务并发场景。当然，它们依赖于线程或事件循环，如果代码是纯同步、单线程、阻塞在 C 扩展调用里，那alarm反而是唯一能“真正打断”的办法。

进程间通信（IPC）方面，signal 能做的很有限。它就像个门铃，只能传个“叮咚”，没法传具体的数据包。如果想在两个 Python 进程间传递复杂指令，multiprocessing.Queue、Pipe、或者 Redis、ZeroMQ 这一类工具会更合适。Signal 只能作为“唤醒码”，让进程从阻塞状态中醒来，然后主动去读取消息通道。

总结一下，signal 是一个古老但精悍的工具，适合做轻量的、简单的信号通知。它不适合做复杂的数据交换，也不适合在多线程精细场景下使用。用之前想清楚：我要解决的到底是“打铃了到点该干嘛”这种问题，还是“赶紧把这个数据发给那边”的问题。边界弄清楚，程序就会稳定很多。