最近在深入阅读 Apache SeaTunnel Zeta Engine 相关代码时，顺着 ClassLoader 这一条线做了一次相对系统的梳理。

整体来看，当前的设计已经具备了比较清晰的基础骨架，尤其是 ClassLoaderService 这一层的集中管理思路，这在同类系统里其实是比较难得的👍。

我这边尝试换一个视角，从 “长生命周期运行时的类加载器治理” 出发，总结了一些观察点，也整理了一条可能的演进路径，未必完全准确，更多是抛出来一起讨论。

从“能用”到“可治理”的视角来看

当前 Apache SeaTunnel 已经可以很好地支持：

• 多 Connector 共存
• 动态加载执行

如果从“功能可用性”来看，这套机制是成立的。

但如果把目标稍微往前推一步，变成：

类加载器是否具备“可控生命周期 + 可验证回收”的能力

那么评判标准会发生一点变化。

几个观察点（偏运行时行为）

1. “释放”与“关闭”的语义差异

目前 releaseClassLoader() 在引用计数归零后，会移除缓存并做一些线程侧清理，但没有显式调用 URLClassLoader.close()。

例如：

• DefaultClassLoaderService.releaseClassLoader()（未看到 close 调用）
• DefaultClassLoaderService.close() 当前主要是清空内部缓存结构

这里带来的一个值得关注的点是：

• JAR 句柄释放依赖 GC 时机
• 在长时间运行或某些平台（如 Windows）上，可能出现文件无法及时释放的情况

👉 更接近“逻辑释放”，而不是“资源生命周期结束”

2. 类加载边界在运行期仍可能变化

在部分路径中，仍存在通过 addURL 向当前 ClassLoader 注入依赖的方式，例如：

• AbstractPluginDiscovery 中通过反射调用 addURL
• Flink 执行路径中存在将插件依赖注入当前 loader 的逻辑

这会带来一个比较有意思的现象：

类加载边界不仅由 loader 结构决定，也受到运行期行为影响

在单次任务中问题不大，但在以下情况下，边界可能会产生“历史残留影响”。：

• 多轮作业复用同一进程
• 不同插件组合切换

3. 一些残留面还没有完全收口

在代码中可以看到多种 TCCL 使用方式（同步 / 异步 / 跨线程），其中部分路径存在：

• 切换后未在 finally 中恢复
• 或跨线程恢复时基线不一致

例如：

• TaskExecutionService 中 cooperative worker 的 TCCL 使用
• 部分 operation（如 source / restore 相关）中存在未对称恢复的情况

另外像一些“典型 ClassLoader 持有点”，目前还没有一个统一的治理收口，比如：

• JDBC Driver 注册（如 TDengine 相关实现）
• Connector 内部直接设置 TCCL 未恢复

一个可能的演进方向（供参考）

基于上面的观察，我这边尝试整理了一条 渐进式的治理路径，不涉及大规模重构，可以分阶段推进：

Phase 1：让 ClassLoader 生命周期“闭合”

核心点：

• 对 SeaTunnel 自己创建的 URLClassLoader，在合适时机显式 close()
• 明确“谁创建，谁关闭”的 owner 关系

这样可以把：

“依赖 GC” → “受控释放”

Phase 2：让加载边界稳定下来

目标是：

• 尽量避免运行期 addURL
• 在 loader 创建前就确定完整 classpath

这样可以保证：

同一类 loader，在不同时间的行为是一致的

Phase 3：收口常见残留点

可以考虑统一几类模式：

• TCCL → 封装成 try-with-resources 使用
• JDBC Driver → 注册/反注册成对
• 线程 / ThreadLocal → 明确归属 loader

让这些“隐式引用”变成“可管理资源”。

Phase 4：引入“回收可验证性”

这一点作为增强项也许会比较有价值：

• 用 WeakReference + ReferenceQueue 跟踪 loader
• 或暴露一些简单的运行时指标（如 live loader 数量）

目标不是绝对精确，而是：

能够在工程上判断“是否大概率已经释放”

为什么这些点可能值得关注

在短生命周期任务中，这些问题通常不会显现。

但在以下场景下，这些“边界问题”会逐渐累积：

• 长时间运行的 Engine 节点
• 多任务反复调度
• 插件频繁切换

最终表现为：

• Metaspace 增长
• JAR 无法替换
• 偶发的类冲突

总结一句话

从“类能隔离”，走向“类加载器可治理、可验证释放”

以上只是我这边的一些理解和整理，有些地方可能不完全准确，欢迎大家拍砖或补充更实际的场景 🙌

如果社区对这个方向有兴趣，可以一起把这块能力打磨成一个更通用的基础设施。

附录：部分代码位置

（以下为本次分析过程中记录的一些代码位置，便于快速定位，但未必完整）

• DefaultClassLoaderService（release / close 相关）
• AbstractPluginDiscovery（addURL 相关）
• Flink starter 执行路径（插件注入）
• TaskExecutionService（TCCL 使用）
• 各类 Operation（source / restore 等）
• 部分 connector（Iceberg / Paimon / TDengine 等）