XA事务锁死本质是Oracle无法及时感知连接中断导致TX锁滞留，因PMON清理延迟且XA分支不走常规清理路径；setTransactionTimeout()仅触发JTA层回滚，无法作用于已断连的数据库端。
xa事务 在 java 应用与 oracle 之间锁死，本质不是“事务太长”，而是分布式事务分支在异常中断后，oracle 无法及时感知连接已断、事务未结束，导致 tx 锁长期滞留。pmon 默认最多等 120 秒才清理，而 xa 分支又不走普通会话的清理路径——这会让锁卡住数分钟甚至更久。
为什么 setTransactionTimeout() 对 XA 锁死基本无效
setTransactionTimeout() 控制的是 JTA 事务管理器（如 Atomikos、Narayana）本地的超时倒计时，它只触发 xa_rollback() 调用；但若底层 JDBC 连接已断开（比如容器被 kill -9）、或 Oracle 端 XA END 未成功发出，这个超时根本到不了数据库层。此时 Oracle 仍认为该 XA 分支处于 ACTIVE 状态，持续持有行锁/表锁。
- 现象：JTA 事务已超时回滚，
V$GLOBAL_TRANSACTION里仍能看到STATE = 'PREPARED'或'ACTIVE'的 XID - 根本原因：XA 协议要求两阶段提交必须由应用显式调用
xa_prepare()→xa_commit()/xa_rollback()，任何一环中断都会让分支悬停 - Oracle 不会主动 abort 悬停的 XA 分支，除非 DBA 手动执行
EXECUTE DBMS_XA.XA_END(...)+DBMS_XA.XA_ROLLBACK(...)
必须配置的 JDBC 与连接池参数
仅靠 Spring @Transactional(timeout = ...) 或 JTA 超时设置，解决不了 XA 锁死。真正起效的是网络层和驱动层的强制清理信号：
- JDBC URL 中必须包含：
oracle.jdbc.thin.forceConnectionClose=true（Oracle 12c+），否则驱动不会在 Socket 关闭时向 Oracle 发送LOGOFF包 - 加上
oracle.net.CONNECT_TIMEOUT=3000和oracle.net.READ_TIMEOUT=6000，避免连接挂起阻塞整个连接池 - HikariCP 需设：
leak-detection-threshold=60000（检测连接泄露）、connection-timeout=30000（获取连接超时），并禁用auto-commit - Atomikos 场景下，
com.atomikos.icatch.max_timeout=300000（5 分钟）是硬上限，超过此值事务管理器将拒绝开启新 XA 事务
如何快速识别和清理残留 XA 分支
别只查 V$LOCKED_OBJECT ——它对 XA 锁完全不敏感。真正反映 XA 悬停的是 V$GLOBAL_TRANSACTION 和 V$SESSION 关联：
- 查悬停分支：
SELECT * FROM V$GLOBAL_TRANSACTION WHERE STATE IN ('ACTIVE', 'PREPARED') AND GLOBAL_TRAN_ID IS NOT NULL - 关联会话：
SELECT s.sid, s.serial#, s.status, g.state, g.global_tran_id FROM V$GLOBAL_TRANSACTION g JOIN V$SESSION s ON g.xidusn = s.taddr（注意：taddr并非总能准确匹配，需结合sql_id和prev_sql_id辅助判断） - 强制清理（慎用）：
EXECUTE DBMS_XA.XA_END(XA_XID(1, hextoraw('...'), hextoraw('...')), DBMS_XA.TMNOFLAGS);后再DBMS_XA.XA_ROLLBACK，XID 的三段需从V$GLOBAL_TRANSACTION中提取
自动化脚本应定期扫描 STATE = 'PREPARED' 且 START_TIME 超过 5 分钟的记录，并告警而非自动清理——因为 PREPARED 状态可能正等待二阶段提交，误杀会导致数据不一致。
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
立即学习“Java免费学习笔记（深入）”；
应用层唯一可控的兜底动作：ShutdownHook + 显式 XA 回滚
Spring 的 @PreDestroy 或 DisposableBean 在 JVM 被强杀时完全不执行。唯一可靠的是 Runtime.getRuntime().addShutdownHook()，但它只能作用于当前线程持有的连接：
- 钩子内不能依赖 Spring 容器（可能已销毁），需直接通过
DataSource获取连接 - 拿到连接后，先执行
conn.getMetaData().getURL()确认是否为 Oracle，再尝试 cast 为oracle.jdbc.OracleConnection - 调用
oracleConnection.logoff()（非标准 JDBC 方法，但可强制通知服务端断连） - 若已知 XA 分支 ID，可用
DBMS_XA匿名块远程回滚（需提前授权EXECUTE ON DBMS_XA）
最现实的做法是：所有 XA 事务入口处，先查 SELECT COUNT(*) FROM V$GLOBAL_TRANSACTION WHERE GLOBAL_TRAN_ID = ? AND STATE = 'ACTIVE'，若存在同 XID 的活跃分支，直接拒绝本次请求——避免在僵尸事务上叠加新操作。
