Oracle JDBC驱动（ojdbc6等）卸载时因ThreadLocal持有AnyDataFactory等实例引发内存泄漏，根源是驱动静态初始化注册的线程上下文未清理，与ResultSet/Connection关闭无关；须升级ojdbc8+、添加-Doracle.jdbc.useThreadLocal=false参数，并配置ServletContextListener调用OracleDriver.close()清理。
oracle jdbc驱动（尤其是 ojdbc6 及早期版本）在 tomcat 环境下卸载应用时，确实会因 threadlocal 持有 oracle.sql.anydatafactory、oracle.sql.typedescriptorfactory 等类实例而引发内存泄漏——这不是你代码没关 resultset/statement/connection 导致的，而是驱动自身注册的线程局部变量未清理。
为什么关掉 ResultSet/Statement/Connection 无法解决这个泄漏
这类资源泄漏属于「应用层资源管理」，而 Tomcat 报出的 ThreadLocal 警告是「JDBC 驱动内部静态初始化器注册的线程上下文残留」。即使你用 try-with-resources 保证了所有 JDBC 对象被关闭，只要 Oracle 驱动类被加载过、且线程（如 Tomcat 的 worker 线程）执行过任意 Oracle 相关逻辑（哪怕只是调用 DriverManager.getConnection()），就可能触发该泄漏。
- 根本原因：ojdbc6 中
oracle.sql.AnyData和oracle.sql.TypeDescriptor的静态块会向当前线程的ThreadLocal写入工厂实例，但驱动未提供显式清理入口 - 表现时机：仅在 Web 应用停止（undeploy）时由
WebappClassLoader检测到，运行中不会报错，但会阻止 classloader 卸载，造成 PermGen/Metaspace 持续增长 - 影响范围：所有使用 ojdbc6 + Tomcat 7/8 的 JNDI 数据源场景，与 Spring/JPA 是否参与无关
必须做的三件事：驱动升级 + JVM 参数 + Context 清理监听
单纯靠代码规范无法根治，需组合干预：
- 升级到
ojdbc8.jar（对应 Oracle 12c+）或ojdbc11.jar（Oracle 21c+）——官方已修复多数ThreadLocal泄漏路径；ojdbc7仍存在部分残留，不建议跳过 - 启动 Tomcat 时添加 JVM 参数：
-Doracle.jdbc.useThreadLocal=false（适用于 ojdbc6/7；ojdbc8+ 默认禁用该机制） - 在应用中注册
ServletContextListener，在contextDestroyed()中主动清理 Oracle 线程上下文：public void contextDestroyed(ServletContextEvent sce) { try { Class.forName("oracle.jdbc.driver.OracleDriver").getMethod("close") .invoke(null); } catch (Exception ignored) {} }注意：该调用仅对 ojdbc6/7 有效，ojdbc8+ 已移除此方法
Tomcat 连接池要不要放弃？
不用放弃，但要确认配置方式：
- 若用
Tomcat JNDI（Resource定义在context.xml），确保removeAbandonedOnBorrow="true"和removeAbandonedTimeout="60"已启用（Tomcat 7+ 改为removeAbandonedOnBorrow+removeAbandonedTimeout） - 避免在应用内手动 new
OracleDataSource或调用DriverManager.registerDriver()——这会绕过连接池，且更容易触发驱动静态初始化 - Spring 用户检查是否误配了
LocalSessionFactoryBean或EntityManagerFactory的dataSource属性指向了非 JNDI 的裸连接源
真正难处理的是驱动加载后、应用停止前，那些被 Tomcat 线程池复用的 worker 线程——它们持有的 ThreadLocal 值不会随应用卸载自动清空。所以升级驱动 + 关键 JVM 参数 + listener 清理，三者缺一不可。单独做任何一项，都可能在高频率 redeploy 场景下积累泄漏。
立即学习“Java免费学习笔记（深入）”；
