Python线程阻塞通常不是因为“死循环”或“CPU耗尽”，而是卡在I/O、锁、队列、条件变量等同步原语上。排查关键在于快速定位线程当前停在哪一行、持有哪些锁、等待什么资源。
查看线程堆栈（最直接）
用 threading.settrace() 或信号中断+sys._current_frames() 获取各线程当前执行位置。生产环境推荐轻量方式：
- 发送 SIGUSR1（Linux/macOS）触发堆栈打印：注册信号处理器，遍历 threading.enumerate()，对每个线程调用 traceback.print_stack(frame)
- 用 faulthandler.dump_traceback()（Python 3.3+），支持定时/信号触发，输出清晰易读
- 调试时可直接用 pdb.set_trace() 在可疑函数入口打断点，配合 threading.current_thread().name 区分线程
检查常见阻塞原语状态
很多阻塞源于对标准同步对象的误用，需主动检查其内部状态：
- Lock/Rlock：用 lock.locked() 判断是否已被占用；Rlock 可查 _is_owned()（非公开但稳定）；注意嵌套 acquire 未配对 release
- Queue.get()/put()：检查 q.qsize()、q.empty()、q.full()，但注意这些方法本身不原子，仅作参考；更可靠的是设置超时（如 q.get(timeout=0.1)）捕获 queue.Empty 或 queue.Full
- Condition.wait()：确认 notify() 是否被正确调用，且发生在 wait() 之后；可用 condition._waiters（私有属性，仅调试）看等待线程数
识别隐式I/O阻塞
看似纯逻辑的代码可能因底层库陷入系统调用阻塞：
立即学习“Python免费学习笔记（深入）”；
- 文件操作（open(), read()）、socket（recv(), accept()）、subprocess（wait()）默认都是阻塞的
- 用 strace -p
（Linux）观察系统调用，若长期停在 epoll_wait、recvfrom、futex，说明卡在I/O或锁 - 数据库驱动（如 pymysql、psycopg2）的 execute() 或 fetch() 也可能阻塞，尤其网络延迟高或查询未优化时
避免GIL误判：区分“真阻塞”和“假等待”
Python GIL 不是阻塞根源，但它会让CPU密集型线程“看起来像卡住”：
- 用 top -H -p
查看各线程CPU使用率：若某线程CPU≈0%，大概率真阻塞；若持续100%，可能是纯计算未让出，需检查是否有长循环或未设 time.sleep() - GIL只影响CPU-bound线程切换，I/O阻塞时GIL会自动释放，此时其他线程可运行——所以阻塞线程不等于整个程序卡死
- 怀疑GIL争抢？换用 concurrent.futures.ProcessPoolExecutor 或 multiprocessing 验证是否改善
不复杂但容易忽略：多数阻塞问题其实源于超时缺失、锁范围过大、或未处理异常导致 release 缺失。加 timeout、缩小临界区、用 with 语句管理锁，能规避八成问题。
