java命名空间隔离的核心机制是每个类加载器拥有独立命名空间，由其自身及所有父加载器加载的类共同构成；同名类由不同加载器加载即视为不同class对象，彼此不可见、不可转换；子加载器可访问父加载器的类，反之不成立。
Java 中命名空间隔离的核心机制，是每个类加载器自带一个独立的命名空间，这个空间由它自身及其所有父加载器所加载的类共同构成。同一个类加载器实例下，不会重复加载同名类；而不同类加载器（无父子关系）加载的同名类，在 JVM 看来是完全不同的 Class 对象，彼此不可见、不可转换、不可共享。
命名空间由类加载器定义，不是由类名决定
即使两个类字节码完全一致、包名类名一模一样，只要由不同类加载器加载，它们就属于不同命名空间。JVM 用 ClassLoader 实例 + 类全限定名 作为唯一标识来区分 Class 对象。例如：
- 租户 A 的
com.example.OrderService由TenantALoader加载 → 是 Class 对象 A - 租户 B 的
com.example.OrderService由TenantBLoader加载 → 是 Class 对象 B - A 和 B 不能互相转型（
(OrderService)obj会抛ClassCastException） - A 中反射调用
Class.forName("com.example.OrderService")只能找到自己命名空间里的那个
父子加载器之间存在可见性单向约束
子加载器的命名空间包含父加载器的所有已加载类，因此子可访问父的类；但父加载器看不到子加载的类：
- AppClassLoader 加载了
com.example.Parent - CustomClassLoader（以 AppClassLoader 为父）加载了
com.example.Child -
Parent中 newChild()会触发类加载 → 父加载器找不到Child→ 报NoClassDefFoundError - 反过来，
Child中使用String或Parent没问题，因为启动类加载器和 AppClassLoader 的类都在其命名空间中
无关系的类加载器之间彻底隔离
两个自定义加载器若互不为父子（比如都以 Bootstrap 为父），它们的命名空间完全正交：
- Loader1 加载的
MyUtil和 Loader2 加载的MyUtil无法强转、无法 instanceof、无法共用静态变量 - 序列化/反序列化失败：Loader1 序列化的对象，用 Loader2 反序列化时因找不到对应 Class 而报
ClassNotFoundException - 线程上下文类加载器（TCCL）若未显式设置，通常继承自父线程，默认是 AppClassLoader，不会自动切换到租户专属加载器
隔离生效的前提是类加载器本身能被回收
命名空间隔离不是静态快照，而是运行时动态边界。只有当类加载器实例不再被任何对象引用，才能被 GC 回收，其所加载的类元数据才可能从元空间卸载：
- 静态持有类加载器（如缓存 map 中 key 是 loader）、线程局部变量未清理、监听器未注销 → loader 泄漏 → 命名空间持续膨胀
- 多个租户复用同一个类加载器 → 命名空间混杂 → 失去隔离意义
- Kubernetes Namespace 配合资源配额，把单个租户的元空间增长限制在可控范围内，防止拖垮节点
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
