SeaTunnel把ClassLoader藏了3年

Apache SeaTunnel的Zeta引擎跑久了会"内存漏"吗？一个被忽略的API调用，可能让生产环境的JAR文件锁死到重启。

这事要从ClassLoader的生命周期说起。大多数开发者觉得"释放"就是结束，但在SeaTunnel的代码里，release和close是两个从未碰面的平行线。

「释放」了，但没完全释放

SeaTunnel的ClassLoaderService设计确实扎实，集中式管理在同类系统里算少见的。但当你盯着DefaultClassLoaderService.releaseClassLoader()的源码看，会发现一个细节：引用计数归零时，缓存条目清了，线程清理做了，唯独没调用URLClassLoader.close()。

这带来什么后果？JAR文件的句柄释放完全看GC心情。Linux上可能蒙混过关，Windows上直接锁死文件，想热更新插件都得先重启进程。说白了，这叫"逻辑释放"——你觉得资源自由了，实际上操作系统还在攥着。

更隐蔽的是AbstractPluginDiscovery里的反射调用。它用addURL往当前ClassLoader里注依赖，边界不是设计好的，是运行时动态长出来的。单次作业没问题，但同一进程反复跑不同任务，类加载边界会攒下"历史包袱"。

线程上下文的三重人格

TCCL（线程上下文类加载器）在SeaTunnel里有三种活法：同步、异步、跨线程。问题出在"恢复"这个动作上。

TaskExecutionService的协作worker里，TCCL被切换后没包在finally里；source/restore操作里，恢复逻辑不对称。更麻烦的是JDBC Driver注册——TDengine这类实现直接把驱动塞进系统，还有connector自己改TCCL却不还原。

这些不是功能bug，是治理盲区。系统能跑，但跑得越久，ClassLoader的"幽灵引用"越多。

一条可能的进化路

从"能用"到"可控"，SeaTunnel的ClassLoader治理还差三层：生命周期显式化（release必须触发close）、边界固化（禁止运行时addURL）、残留清理（TCCL全路径finally保护+Driver统一管理）。

作者提了个思路：把ClassLoader变成"租约制"——每个作业申请时打标，归还时强制审计，超期自动熔断。这在大数据长运行场景里，比靠GC兜底靠谱得多。

Apache SeaTunnel社区已经注意到这类反馈。下一个版本会不会把close补进release的调用链？生产环境的热更新能不能告别"重启大法"？