sys._current_frames 不检测死锁，仅提供线程调用栈快照；需人工分析依赖环，结合锁状态、持有者信息及跨层阻塞点综合判断。
死锁检测为什么不能只靠 sys._current_frames
直接说结论：sys._current_frames 本身不检测死锁，它只是快照当前所有线程的调用栈。你拿到一堆堆栈，但无法自动判断「哪几个线程在互相等待」——这需要你自己做依赖图分析。很多开发者误以为调用它就能“发现死锁”，结果只看到一堆 acquire() 停在锁上，却不知道谁持有什么、谁在等什么。
怎么用 sys._current_frames 辅助人工排查死锁
它最有用的场景是：服务卡住、CPU 低、响应停摆时，快速抓取现场。关键不是看单个栈，而是比对多个线程的阻塞点：
-
sys._current_frames()返回{thread_id: frame}字典，每个frame可用traceback.format_frame_summary()提取文件/行号/函数名 - 重点过滤含
threading.Lock.acquire、threading.RLock.acquire、queue.get、condition.wait的栈帧 - 逐个检查
frame.f_locals，看是否持有Lock或RLock对象（注意：RLock的_owner和_count能暴露持有状态） - 若线程 A 在等锁 X，线程 B 持有 X 却在等锁 Y，而线程 A 又持有 Y —— 这才是环路证据
真实死锁中容易被忽略的锁状态细节
光看 acquire 调用位置远远不够，必须确认锁的实际状态：
-
threading.Lock没有公开的「持有者」属性，但可通过lock._is_owned()（私有方法，仅限调试）粗略判断当前线程是否已持锁 -
threading.RLock的_owner是线程 ID（int），需和threading.get_ident()对齐；_count > 0才算真正被占用 - 第三方锁（如
redis.Redis.lock、zookeeper.Lock）完全不会出现在sys._current_frames的 Python 栈里，它们的阻塞发生在 C 层或网络层 - 协程（
asyncio）中的「锁」（如asyncio.Lock）也不会触发threading相关栈帧，得换asyncio.all_tasks()查
比手动查堆栈更靠谱的替代方案
除非你是在写一个轻量级调试工具，否则别把 sys._current_frames 当主力死锁检测手段：
立即学习“Python免费学习笔记（深入）”；
- 用
threading.set_trace_hook()（Python 3.12+）可实时捕获锁获取/释放事件，比事后快照更准 - 给所有锁包装一层带日志和持有者记录的代理类，例如重写
acquire记录threading.get_ident()和时间戳 - 生产环境推荐
faulthandler.dump_traceback()配合信号（如SIGUSR1）触发，比轮询sys._current_frames更低开销 - 涉及数据库或外部服务时，死锁往往不在 Python 层——得查 PostgreSQL 的
pg_locks或 MySQL 的INFORMATION_SCHEMA.INNODB_TRX
死锁的本质是资源依赖环，而 sys._current_frames 只给你一张静止的「照片」。要看出环，你得自己画图、标箭头、验闭环——这点没法跳过。
