查v$session时status='INACTIVE'但tempseg_used>0的会话实为JDBC僵尸，需连查v$sort_usage确认TEMP占用；若mb_used>0且blocks不降，应强杀OS进程并执行ALTER TABLESPACE temp COALESCE。
查v$session时status=INACTIVE但tempseg_used > 0
这种会话看着“安静”，其实还在占临时表空间——v$session.status = 'INACTIVE'不等于资源已释放。真正要盯的是它是否还在用TEMP段，否则杀掉后TEMP空间不回收，后续大排序照样报ORA-01652。
必须连查v$sort_usage确认：
SELECT s.sid, s.serial#, u.tablespace, u.blocks * 8 / 1024 AS mb_used FROM v$sort_usage u JOIN v$session s ON u.session_addr = s.saddr WHERE u.tablespace = 'TEMP' AND s.status = 'INACTIVE';
- 如果
mb_used > 0，说明该会话的排序/哈希结果还没被PMON清理，属于典型JDBC僵尸 -
blocks值长时间不降（比如持续5分钟以上），基本可判定客户端已断开但连接未归还给连接池 - 注意：某些ORM框架（如MyBatis）在异常分支里漏写
connection.close()，就会制造这类会话
ALTER SYSTEM KILL SESSION后状态卡在KILLED
执行ALTER SYSTEM KILL SESSION 'sid,serial#' IMMEDIATE后，v$session.status变成KILLED但TEMP没释放、OS进程还在，这是JDBC僵尸最顽固的表现。根本原因是JDBC驱动层没收到断连通知，或应用没触发连接池的失效检测逻辑。
此时不能等PMON自动清理——它可能卡住。得立刻做两件事：
- 查对应OS进程：
SELECT p.spid FROM v$session s JOIN v$process p ON s.paddr = p.addr WHERE s.sid = <your_sid> - 在数据库所在服务器上执行：
kill -9 <spid>（Linux）或orakill ORACLE_SID <spid>（Windows） - 强杀后观察
v$sort_usage是否清空；若仍有残留，需对TEMP表空间执行ALTER TABLESPACE temp COALESCE
JDBC连接池配置不当导致会话堆积
很多“僵尸”不是数据库问题，而是连接池把断开的连接当活跃连接反复复用。典型配置坑点：
- HikariCP的
connection-timeout设太长（如30秒），导致网络闪断后连接迟迟不标记为dead - 没开
leak-detection-threshold（建议设60000毫秒），无法捕获应用层忘记close()的连接 - Oracle JDBC URL里加了
characterEncoding=utf8这类无效参数，某些旧驱动会静默忽略，但影响连接健康检查逻辑 - Spring Boot中
spring.datasource.hikari.auto-commit=false没生效——得确认底层ojdbc8实际读到了该值，可用Connection.getAutoCommit()运行时验证
区分JDBC僵尸和RAC实例定位错误
RAC环境下，看到GV$SESSION里有会话，但ALTER SYSTEM KILL SESSION报ORA-00030: User session ID does not exist，大概率是命令没指定实例。JDBC连接可能连在节点2，你却在节点1上执行Kill。
必须用带实例ID的语法：
ALTER SYSTEM KILL SESSION 'sid,serial#,@inst_id';
其中@inst_id来自GV$SESSION.inst_id字段。漏掉@符号，Oracle默认操作当前实例，自然找不到目标会话。
更隐蔽的问题：某些负载均衡代理（如F5）会把JDBC连接随机分发到不同节点，而应用日志只记录SQL执行时间，不记录实际连接节点——这时得靠client_addr和program字段交叉比对，才能准确定位源头节点。
