自治事务本身不锁死父事务，但若其操作父事务正修改的同一行，因Oracle锁机制冲突（如X锁互斥），自治事务无法获取锁而报错（如ORA-00054），若被忽略则导致父事务后续commit阻塞甚至死锁。
自治事务本身不会导致父事务锁死，真正卡住的是“在自治事务里操作了父事务正在修改的同一行”
为什么自治事务执行完，父事务还卡在UPDATE上？
常见现象是：父事务 UPDATE 了一行，自治事务里又对同一行做了 INSERT/UPDATE/DELETE，之后父事务 commit 时 hang 住，甚至超时抛出 ORA-00060（死锁）或 ORA-04021（timeout acquiring lock）。这不是自治事务“锁死了父事务”，而是 Oracle 的事务隔离机制在起作用：
- 自治事务和父事务完全独立，各自有独立的 SCN 和回滚段，但它们共享同一个会话（session）和底层数据块缓存
- 父事务已加 X 锁（排它锁）的行，自治事务无法再对其加 X 锁——除非父事务先释放（即 commit 或 rollback）
- 而自治事务又不能“等父事务提交”，它必须自己完成、提交或回滚；于是它会尝试获取锁，失败后立即报错（如
ORA-00054: resource busy），但很多人忽略了这个错误，继续往下走，导致父事务后续操作被阻塞
PRAGMA AUTONOMOUS_TRANSACTION 后第一个 BEGIN 就脱离父事务上下文
自治事务的边界非常明确：从 PRAGMA AUTONOMOUS_TRANSACTION 所在 PL/SQL 块中，**第一个 BEGIN 开始**，到对应 END 结束，整个块就是自治事务。注意几个关键点：
- DECLARE 部分声明的变量、游标、异常定义，仍属于父事务作用域；只有 EXECUTE 部分才进入自治事务
- 自治事务里调用的任何存储过程、函数、触发器，只要没显式再写
PRAGMA AUTONOMOUS_TRANSACTION，就自动归属当前自治事务，不是父事务 - 自治事务可以提交（
COMMIT）或回滚（ROLLBACK），但这些操作对父事务不可见——父事务看不到自治事务写的未提交数据，反之亦然（READ COMMITTED 下）
哪些写法最容易引发锁冲突？
典型高危组合：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
立即学习“Java免费学习笔记（深入）”；
- 父事务 UPDATE 表 A 的某条记录 → 自治事务 INSERT/UPDATE/DELETE 同一条记录（主键或唯一键相同）
- 父事务执行
SELECT ... FOR UPDATE锁住某行 → 自治事务对该行做 DML - 触发器里用自治事务写日志表，但日志表上有触发器、外键约束或物化视图日志，间接导致锁链延伸到父事务涉及的表
- 自治事务里调用了含隐式 COMMIT 的 DBMS_* 包（如
DBMS_MVIEW.REFRESH），虽不常见，但一旦发生，会强制结束当前自治事务，可能留下不一致状态
如何验证是不是自治事务引发的锁等待？
别只查 V$LOCKED_OBJECT，它不显示自治事务的锁持有者。要抓实时会话状态：
- 查锁等待链：
SELECT blocking_session, sid, serial#, event, sql_id FROM v$session WHERE blocking_session IS NOT NULL - 确认自治事务是否还在运行：
SELECT s.sid, s.serial#, s.status, t.start_time, t.used_ublk FROM v$transaction t JOIN v$session s ON s.taddr = t.addr—— 如果看到多个sid对应不同start_time且都未提交，大概率存在嵌套自治事务 - 在自治事务内部加日志（如写入
DBMS_APPLICATION_INFO.SET_MODULE），便于在V$SESSION中区分父/自治会话上下文
最常被忽略的一点：自治事务的“独立性”是逻辑上的，不是物理隔离的。它不绕过锁机制，也不跳过一致性读规则。想让它不干扰父事务，唯一可靠方式是——让它操作完全无关的数据集。
