Flink TaskManager重复执行作业触发MetaSpace OOM原因咨询

这个内存泄漏和作业处理的数据量无关，本质是JDBCInputFormat 存在类加载器泄漏缺陷，具体逻辑如下：

• Flink 常驻 Session 集群模式下，每次执行作业都会为当前作业生成独立的UserCodeClassLoader（用户代码类加载器），用来加载作业自身代码、第三方依赖（包括引入的JDBC驱动）的类。JVM MetaSpace 存储的类元数据生命周期和对应的类加载器强绑定，只有类加载器本身被GC回收时，它加载的所有类元数据才会被从MetaSpace中清理释放。
• 1.13版本前的Flink JDBCInputFormat存在资源清理遗漏：作业初始化JDBC连接时，MySQL、Oracle等主流JDBC驱动内部会通过反射、动态代理生成连接管理、结果集映射相关的动态类，这些类会隐式持有当前作业UserCodeClassLoader的引用；但作业执行完成、InputFormat调用close()方法时，没有主动从java.sql.DriverManager中注销当前类加载器加载的JDBC驱动实例，也没有清理动态代理类的全局引用，导致整个UserCodeClassLoader的引用链无法断开，永远无法被GC回收。
• 每重复执行一次作业，就会新增一个无法回收的UserCodeClassLoader，它加载的所有类元数据会持续驻留在TaskManager进程的MetaSpace中。哪怕每次作业仅读取2行数据，MetaSpace占用也会随作业执行次数线性攀升，最终耗尽空间触发MetaSpace OOM，导致TaskManager进程宕机。

修复方案 #

• 优先升级Flink JDBC Connector版本到1.13及以上，官方已经修复该泄漏问题：作业关闭生命周期中会主动注销对应类加载器加载的JDBC驱动，清理动态类持有引用，保证UserCodeClassLoader可以被正常GC，对应的类元数据会被正常回收。
• 若暂时无法升级版本，可以将JDBC驱动jar包放到Flink各节点的lib目录下，让JDBC驱动被Flink平台级的AppClassLoader加载，而不是每个作业的UserCodeClassLoader单独加载，从根源上避免每个作业重复加载驱动类、生成动态类带来的泄漏问题。
• 注意：仅调大TaskManager JVM参数-XX:MaxMetaspaceSize只能延缓OOM触发时间，无法解决本质泄漏问题，不推荐作为长期方案。

内容的提问来源于stack exchange，提问作者Hemant Dhakate