oracle jdbc驱动内存泄漏根源是drivermanager强引用链与threadlocal残留双因素导致webappclassloader无法回收,须在contextdestroyed()中安全反注册驱动并升级至ojdbc8+。

Java 11 下 Oracle JDBC 驱动引发的内存泄漏,不是因为你忘了关 Connection,而是驱动在类加载器卸载阶段没清理自己注册的全局资源——DriverManager 强引用 + ThreadLocal 残留双杀,直接卡死 WebAppClassLoader 回收。
DriverManager.registerDriver() 造成的类加载器强引用链
Oracle 驱动(如 ojdbc6~ojdbc8)初始化时会执行 DriverManager.registerDriver(new OracleDriver())。而 DriverManager 是 BootstrapClassLoader 加载的系统类,它内部用 CopyOnWriteArrayList<driverinfo></driverinfo> 持有所有已注册驱动实例。由于 OracleDriver 是由当前 WebAppClassLoader 加载的,这就形成了一条不可打断的强引用链:
BootstrapClassLoader → DriverManager → DriverInfo → OracleDriver 实例 → WebAppClassLoader
只要这条链存在,整个应用的类加载器及其加载的所有类(包括 oracle.sql.*、oracle.jdbc.*)就永远无法被 GC,Metaspace 持续上涨,热部署几次后必报 java.lang.OutOfMemoryError: Metaspace。
ojdbc6/7 的 ThreadLocal 工厂残留问题
ojdbc6 和 ojdbc7 中,oracle.sql.AnyData、oracle.sql.TypeDescriptor 等类的静态块会向当前线程(比如 Tomcat 的 worker 线程)写入工厂实例到 ThreadLocal。这些 ThreadLocal 值绑定在线程生命周期上,Web 应用停止时不会自动清除。
常见表现:
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- Tomcat 日志出现 “The web application [] registered the JDBC driver [oracle.jdbc.driver.OracleDriver] but failed to unregister it…”
-
jmap -histo:live <pid> | grep oracle.jdbc.driver.OracleDriver</pid>显示实例数随热部署次数线性增长 - 即使你全程用
try-with-resources,泄漏照样发生
根本原因:驱动没提供清理入口,且 JVM 不负责回收第三方 ThreadLocal。
ojdbc8+ 仍需手动 deregisterDriver()
虽然 ojdbc8(Oracle 12c+)默认禁用了 ThreadLocal 缓存(即 -Doracle.jdbc.useThreadLocal=false 生效),但它依然会调用 DriverManager.registerDriver(),所以类加载器泄漏路径仍在。
必须在 ServletContextListener.contextDestroyed() 中安全反注册:
public void contextDestroyed(ServletContextEvent sce) {
Enumeration<driver> drivers = DriverManager.getDrivers();
while (drivers.hasMoreElements()) {
Driver driver = drivers.nextElement();
if (driver instanceof oracle.jdbc.driver.OracleDriver) {
try {
DriverManager.deregisterDriver(driver);
} catch (SQLException ignored) {}
}
}
}
</driver>
注意:不能直接遍历并 deregisterDriver() 后抛异常就中断,要逐个捕获 SQLException,否则 H2、PostgreSQL 等其他驱动异常会导致 Oracle 驱动跳过反注册。
为什么简单 kill java 进程有时“有效”?
你看到的“结束 Java(TM) Platform SE binary 进程后重启就好了”,只是绕过了泄漏——进程一杀,所有线程、ThreadLocal、类加载器全清空。但这不是修复,是重置。真正上线环境没法每次热部署都重启 JVM。
关键点容易被忽略:泄漏只在应用卸载(undeploy)时暴露,运行中完全无感;但一旦发生,Metaspace 就再也收不回去,下次部署必然更早 OOM。别等报错才处理,ojdbc8 + deregisterDriver() + 清理监听三者缺一不可。
Java免费学习笔记:立即使用
解锁 Java 大师之旅:从入门到精通的终极指南










