Oracle死锁本质是循环等待资源，需通过v$session的blocking_session、final_blocking_session及递归查询定位完整锁链，结合sql_text和业务逻辑判断是否kill，而非仅依赖lockwait字段。
oracle死锁不是“有没有”的问题，而是“谁卡住谁、卡在哪条语句、要不要杀”的判断问题。直接查 v$session 能看到表象，但真正定位根源得结合锁链路径和会话上下文——否则容易 kill 错会话，甚至让应用反复重试加剧阻塞。
查 v$session 时为什么 lockwait 字段为空却仍有死锁？
因为 lockwait 只在会话处于“等待锁”状态（即被阻塞）时非空；而死锁发生后，Oracle 通常已自动检测并标记其中一个会话为牺牲者（status = 'KILLED' 或 'INACTIVE'），此时它的 lockwait 可能已清空。不能只依赖这个字段判断是否正在死锁。
- 更可靠的信号是：
sid出现在v$locked_object中，且对应会话的status = 'ACTIVE'、sql_id非空、event是enq: TX - row lock contention或类似事务类等待 - 如果用的是 RAC 环境，必须查
gv$session而非v$session，否则可能漏掉其他节点上的阻塞源头 -
v$session的blocking_session和final_blocking_session字段才是关键——它们不依赖人工 join，是 Oracle 内置的阻塞关系快照
用 blocking_session 追踪锁链时要注意什么？
Oracle 从 10g 起在 v$session 中内置了阻塞关系字段，但它们只反映“当前一级阻塞”，不是完整树。比如 A → B → C → D 的锁链，blocking_session 对 D 来说只显示 C，对 C 显示 B，不会直接暴露 A。
- 要一次性看到整条链，必须用
connect by递归查询：gv$session+blocking_session+blocking_instance - 注意
final_blocking_session字段：它指向最上层的源头会话（即真正持有资源、没在等别人的那个），比层层递归更省事，但仅在 11gR2+ 且启用_kill_blocker相关参数时才稳定可靠 - 如果
blocking_session为 null，但会话仍卡在TX等待上，大概率是它自己持有了锁却没提交（比如未 commit 的 UPDATE），这时要重点看它的sql_id和logon_time
查到源头会话后，alter system kill session 怎么写才安全？
直接执行 alter system kill session 'sid,serial#' 是最常用方式，但它只是“标记终止”，会话可能仍在清理事务，客户端看到的仍是 ORA-00028: your session has been killed，而非立即消失。
使用 Playwright 为 jimeng.jianying.com 管理浏览器会话，导入 cookies/localStorage 以自动化视频生成工作流，支持图片上传等功能
- 加
immediate后缀（alter system kill session 'sid,serial#' immediate）可跳过等待，强制中断，适用于长时间卡死的会话 - 如果会话在远程实例（RAC），必须带上
@inst_id，例如：alter system kill session '123,456,@2' immediate - 不要仅靠
username或program判断该不该杀——同一个应用可能有多个合法长事务；优先确认该会话的sql_text是否是未提交的 DML，以及last_call_et是否远大于业务预期（比如 > 300 秒）
真正难的不是查出谁在锁，而是判断“这个锁该不该等、这条 SQL 该不该提交、这个 session 是不是业务关键流”。v$session 提供的是线索，不是结论；所有 kill 操作前，最好先用 v$sql 查出 sql_text，再跟开发确认逻辑——否则你解决了一个死锁，可能制造了下一个数据不一致。
