中间排查过程比较长，可以直接跳过看结论。
一、问题描述
报错信息
2022-04-10 01:16:47.951 [Source: oraclereader -> Sink: gbasewriter (1/1)] ERROR org.apache.flink.runtime.taskexecutor.TaskManagerRunner - Fatal error occurred while executing the TaskManager. Shutting it down...
java.lang.OutOfMemoryError: Metaspace. The metaspace out-of-memory error has occurred. This can mean two things:
either the job requires a larger size of JVM metaspace to load classes or there is a class loading leak. In the first case 'taskmanager.memory.jvm-metaspace.size' configuration option should be increased. If the error persists (usually in cluster after several job (re-)submissions) then there is probably a class loading leak in user code or some of its dependencies which has to be investigated and fixed. The task executor has to be shutdown...
现象：flink standalone模式集群下跑flinkx 1.11版本的任务，一段时间后TaskManager就因为OOM去世了。。。走的时候很安详，并且提示我要对该参数调优
taskmanager.memory.jvm-metaspace.size
参数改完重启flink集群，提交了几十个任务，运行情况良好。
结果第二天又挂了。。taskmanager.memory.jvm-metaspace.size参数默认256mb，增加1G、3G都不能解决问题，只是暂缓了节点挂掉的时间。
二、问题排查
用jstat命令获取gc的信息，发现元空间占用飙升、频繁gc。
在flink 的TaskManager配置中加上jvm选项，准备看一下gc过程。
env.java.opts: -Xloggc:<LOG_DIR>/gc.log
-XX:+PrintGCApplicationStoppedTime
-XX:+PrintGCDetails
-XX:-OmitStackTraceInFastThrow
-XX:+PrintGCTimeStamps
-XX:+PrintGCDateStamps
-XX:+UseGCLogFileRotation
-XX:NumberOfGCLogFiles=20
-XX:GCLogFileSize=20M
-XX:+PrintPromotionFailure
-XX:+PrintGCCause
-XX:+PrintHeapAtGC
重启集群。
2022-04-14T00:07:39.813+0800: 49862.308: [Full GC (Metadata GC Threshold) [PSYoungGen: 448K->0K(1353728K)] [ParOldGen: 267109K->267210K(2708992K)] 267557K->267210K(4062720K), [Metaspace: 1025218K->1025215K(1966080K)], 0.3381885 secs] [Times: user=1.05 sys=0.00, real=0.34 secs]
Heap after GC invocations=600 (full 151):
PSYoungGen total 1353728K, used 0K [0x000000076dd80000, 0x00000007c0800000, 0x00000007c0800000)
eden space 1353216K, 0% used [0x000000076dd80000,0x000000076dd80000,0x00000007c0700000)
from space 512K, 0% used [0x00000007c0700000,0x00000007c0700000,0x00000007c0780000)
to space 512K, 0% used [0x00000007c0780000,0x00000007c0780000,0x00000007c0800000)
ParOldGen total 2708992K, used 267210K [0x00000006c8800000, 0x000000076dd80000, 0x000000076dd80000)
object space 2708992K, 9% used [0x00000006c8800000,0x00000006d8cf2878,0x000000076dd80000)
Metaspace used 1025215K, capacity 1033714K, committed 1048576K, reserved 1966080K
class space used 127315K, capacity 128684K, committed 131248K, reserved 1048576K
}
一段Metaspace的full gc显示，经过gc后并没有降低多少元空间的占用率。
在flink的官方问题上看到说是类加载泄漏，这个问题一直存在。
https://issues.apache.org/jira/browse/FLINK-11205
https://issues.apache.org/jira/browse/FLINK-16408
把Flink的内存模型拿回来重新研究：
JVM堆内存Framework Heap以及Task Heap。
Framework Heap存储的是Flink框架运行的时候产生的对象，Task Heap 存的是Flink的算子和用户自己创建的对象。
Off-Heap Memory中，Managed Memory，托管内存，用于存储RocksDBStateBackend，还有一些批处理作业的中间缓存结果BAtchisonOperator。
Task Off-Heap和Framework Off-Heap主要根据对外内存是否计入Slot资源进行区分。
Network是Task 与Task通信时用的本地缓存
JVM特定内存是不在Flink的总内存范围内的，其中JVM Metaspace用来存储JVM加载类的元数据，如果加载的类越多，需要的内存空间越大。
flinkx程序运行的时候每次会向集群提交flinkx-release_1.11.0.jar和插件包（各种connector），对于源类型和目标类型总是相同的一种作业（oracle->gbase)，如果每次提交的jar包都加载到Metaspace，肯定会导致空间不断攀升。
flink1.14的官方文档中建议我们在用户的代码中释放加载的类，或者将jdbc的类加入到flink集群的lib文件中，避免元空间溢出。
文中提供了RuntimeContext.registerUserCodeClassLoaderReleaseHookIfAbsent()的钩子方法，可以主动去释放元空间，但1.11里没有。所以不能通过改造flinkx的代码实现释放元空间。我们使用第二中方法，把flinkx的包都放进集群的lib下，选用parentfirst类加载器。
spark和flink的standalone模式对比：
Flink与Spark的应用调度和执行的核心区别是Flink不同的job在执行时，其task同时运行在同一个进程TaskManager进程中,Spark的不同job的task执行时，会启动不同的executor来调度执行，job之间是隔离的。
三、问题解决
结论：由于任务是跑在flink的standalone模式下，job在TaskManager中是运行在同一个jvm，并且用完后并不会像YARN per job 模式一样释放资源，集群的类加载模式选用childfirst类加载器，客户端每次重复提交jar包，就会不停的加载插件类class到元空间中，然后元空间就会不断上升，直到溢出。
解决方法： 把flinkx的三种包，flinkx-launcher-1.6.jar，flinkx-release_1.11.0.jar，以及插件包，放入flink集群的lib中，使用parentfirst类加载器，重启集群，内存溢出不再出现。
提示：一些插件包直接放入集群lib中会跟flink的依赖包产生冲突，例如hive，需要手动管理重复依赖，重新编译flinkx后再放入lib。
