Python subprocess 为什么容易阻塞？

冰川箭仙 2026-01-21 00:00:00 次阅读

subprocess 阻塞主因是子进程 stdout/stderr 缓冲区填满后挂起，因父进程未及时读取；需用 communicate()、实时读取或 asyncio 替代裸 Popen。

Python 的 subprocess 容易阻塞，核心原因在于**子进程的 stdin/stdout/stderr 缓冲区未及时读写，导致管道填满后挂起**。这不是 bug，而是 Unix 管道机制的自然行为——当一端不消费数据时，另一端写入就会被系统暂停。

stdout/stderr 缓冲区填满是主因

子进程输出（尤其是大量输出）会先写入内核管道缓冲区（通常只有 64KB 左右）。如果父进程没调用 communicate()、readline() 或 iter(proc.stdout, ...) 主动读取，缓冲区很快占满，子进程在下一次 print 或 write 时就会阻塞等待空间释放。

常见于运行 ping、ffmpeg、日志输出密集的脚本等场景
proc.stdout.read() 在无 EOF 时会一直等，而很多命令不会主动关 stdout
即使只重定向了 stdout=PIPE，若忽略 stderr，stderr 仍连到父进程终端或默认管道，也可能造成干扰

wait() 和 poll() 不等于“不阻塞”

proc.wait() 会阻塞直到子进程退出；proc.poll() 虽非阻塞，但仅检查退出状态，**完全不处理 I/O 流**。如果你没同步读取输出，子进程早就在 stdout 写入时卡住了，poll() 返回 None 只说明它还在跑——可能正堵在管道上。

错误做法：proc = subprocess.Popen(...); proc.wait()（没读输出）
正确思路：要么用 communicate()（自动读完再 wait），要么边运行边实时读（如用线程或 select）

交互式命令需要额外注意换行和 flush

运行 python -i、gdb 或自定义 CLI 时，子进程常依赖行缓冲或手动 flush。若 Python 发送命令后不加 \n，或子进程因 stdout 未 flush 而不响应，就会看似“卡住”。

发送输入后务必加换行符：proc.stdin.write(b'print(1)\n')
必要时调用 proc.stdin.flush() 强制送出
对交互式程序，推荐用 pexpect 或 pty 模块替代裸 Popen

跨平台差异放大问题

Windows 默认管道缓冲区更小，且 select 不支持管道，导致 subprocess 在 Windows 上更容易出现“假死”。Linux/macOS 虽支持 select 或 poll，但若未正确使用（比如只监控 stdout 却忽略 stderr），依然会因 stderr 填满而阻塞。