多租户场景下必须使用独立类加载器实现命名空间隔离，确保租户间类元数据完全不可见、不可访问、不可污染；类加载器即租户边界容器，其生命周期须与Kubernetes Namespace对齐，否则将导致元空间OOM等隔离失效问题。
多租户场景下，独立类加载器 + 命名空间隔离，本质上是在 JVM 层面划出一条“元数据不可越界”的技术红线——它不是可选优化，而是防止租户间行为污染的底线保障。
类加载器即租户边界容器
每个租户对应一个独立的自定义类加载器（非系统三类加载器），该加载器加载的所有类（包括 Spring Bean 定义、Controller、实体类、甚至动态生成的代理类）都绑定在其生命周期内。JVM 规范明确要求：只有当类加载器自身被 GC 回收时，它所加载的 Class 元数据才可能从元空间卸载。这意味着——
- 租户 A 的
OrderService和租户 B 的OrderService是两个完全无关的 Class 对象，哪怕字节码一模一样； - 租户 A 修改配置触发热重载，只会重建自己的类加载器及其元数据，绝不会触碰租户 B 的任何类信息；
- 反射、
Class.forName()、序列化反序列化等操作，天然受限于当前线程使用的类加载器，无法跨租户访问对方的类型。
命名空间隔离是运行时执行约束
Kubernetes 中的 Namespace 不直接管 JVM，但它是部署侧的关键配合层：
- 每个租户独占一个 Namespace，配合 ResourceQuota 和 LimitRange，硬性限制 CPU、内存、Pod 数量；
- 这样即使某个租户的类加载器因泄漏持续增长（比如反复注册未清理的
BeanDefinitionRegistryPostProcessor），其元空间膨胀也被圈死在配额内，不会拖垮整个节点； - 更重要的是，Namespace 配合网络策略（NetworkPolicy）和 RBAC，阻止租户 Pod 之间直接通信，从源头杜绝“通过 JMX 或 RMI 跨租户读取对方 ClassLoader 状态”的可能。
元空间 OOM 就是隔离失效的报警灯
一旦出现 java.lang.OutOfMemoryError: Metaspace，说明至少有一条红线已被突破：
- 类加载器没被正确释放（比如静态持有、线程局部变量未清理、监听器未注销）；
- 或者多个租户共用了同一个类加载器（常见于误用
ApplicationClassLoader加载租户定制代码）； - 或者租户级资源配额设置过宽，掩盖了单租户元空间失控问题。
所以真正的底线是：
- 每个租户必须拥有专属类加载器，且该加载器必须能被完整回收；
- 所有租户代码的加载、初始化、销毁流程，必须与 Namespace 生命周期对齐（如 Pod 删除 → 类加载器置为可回收 → 元空间逐步释放）；
- 不能依赖“共享核心+隔离业务”的模糊设计，因为 JVM 不认“业务租户”，只认“类加载器实例”。
不复杂，但容易忽略。
