应配置JDBC的oracle.jdbc.thin.forceConnectionClose=true、连接池的泄露检测与优雅关闭，并通过ShutdownHook显式回滚事务，同时调优TCP Keepalive和SQLNET.EXPIRE_TIME以加速死连接清理。
Java应用重启时Oracle锁没及时释放，怎么办
java应用异常终止（比如kill -9、容器oom杀掉）后，事务未正常提交或回滚，连接断开但oracle端的行锁/表锁仍残留，而pmon进程默认最多120秒才清理死连接——这期间新请求可能直接卡在enq: tx - row lock contention上。
核心不是“等PMON”，而是让锁在连接断开那一刻就失效。关键在数据库连接层和JDBC配置：
-
oracle.net.CONNECT_TIMEOUT和oracle.net.READ_TIMEOUT要设为合理值（如3000ms），避免连接挂起太久拖住事务 - JDBC URL里必须加
oracle.jdbc.thin.forceConnectionClose=true（Oracle 12c+），否则JDBC驱动不会主动向服务端发送连接终止信号 - 应用容器（如Tomcat、Spring Boot）要配置连接池的
removeAbandonedOnBorrow=true（HikariCP用leak-detection-threshold+connection-timeout）
Spring Boot里怎么确保事务随JVM退出干净回滚
Spring的@Transactional依赖线程绑定的TransactionSynchronizationManager，JVM被强杀时根本来不及触发afterCompletion回调。不能指望注解自动兜底。
真正有效的做法是把事务控制权收回来，用显式管理+钩子兜底：
- 用
TransactionTemplate替代声明式事务，在关键业务方法内手动控制execute()和异常分支的rollback() - 注册
Runtime.getRuntime().addShutdownHook()，在钩子里调用DataSourceUtils.releaseConnection()并尝试connection.rollback()（注意：仅对当前线程有效，且需判断连接是否还活跃） - 更稳妥的是：所有写操作前先执行
SELECT * FROM V$SESSION WHERE SID = SYS_CONTEXT('USERENV', 'SID')，确认会话状态再继续，避免在僵尸连接上执行DML
查到锁了但V$LOCKED_OBJECT里没记录，为什么
常见错觉：查V$LOCKED_OBJECT为空就以为没锁。其实它只显示DML导致的**行级锁对象**，而死锁常发生在TX锁（事务锁）层面，得看V$LOCK和V$SESSION关联。
立即学习“Java免费学习笔记（深入）”；
正确排查链路：
- 先查
SELECT SID, SERIAL#, STATUS, SQL_ID FROM V$SESSION WHERE STATUS = 'ACTIVE' AND BLOCKING_SESSION IS NOT NULL - 再连
V$LOCK：SELECT * FROM V$LOCK l JOIN V$SESSION s ON l.SID = s.SID WHERE l.TYPE = 'TX' AND s.STATUS = 'INACTIVE' - 重点看
LMODE = 6（排他锁）且REQUEST > 0的记录，这类就是正在争抢但没拿到锁的会话 - 注意：
V$LOCKED_OBJECT不包含DDL锁（如TM锁），建索引/加字段卡住也得从V$LOCK查TYPE='TM'
PMON清理延迟能调短吗
不能直接调“PMON清理间隔”，因为PMON本身不按周期扫描，而是靠TCP Keepalive探测死连接后触发清理。真正可控的是网络层探测频率。
生效路径是：操作系统 → Oracle监听器 → 数据库实例：
- Linux侧改
/proc/sys/net/ipv4/tcp_keepalive_time（默认7200秒，建议调到600） - Oracle监听器配置
sqlnet.ora里加SQLNET.EXPIRE_TIME=10（单位分钟），让服务端每10分钟发一次probe包 - 数据库参数
resource_limit=TRUE必须开启，否则idle_time等资源限制不生效，死连接可能一直挂着
最易忽略的一点：Kubernetes里Pod重启时，如果Service没配sessionAffinity: ClientIP或没启用连接池的优雅关闭，旧连接的FIN包可能根本没发到Oracle服务器，PMON永远等不到断连信号。
