java类的唯一性由全限定名与加载它的类加载器实例共同决定；每个类加载器维护独立命名空间，相同字节码被不同加载器加载后互不可见、不可转换、不共享静态变量，这是jvm规范§5.3规定的二元判定原则。

Java 类加载器中，命名空间与类的唯一性判定标准是统一的：一个类在 JVM 中的唯一身份，由类的全限定名（例如 java.util.ArrayList）和定义它的类加载器实例共同决定。

每个类加载器维护独立命名空间

类加载器不是“按名字找类”的简单工具，而是为所加载的类构建了一个专属上下文——即命名空间。这个空间天然隔离：

• 同一份字节码文件，被两个不同的类加载器实例加载，会产生两个互不兼容的 Class 对象
• 它们不能互相强制转换（ClassCastException）
• 无法共享静态变量（各自拥有独立的类变量副本）
• 即使类名、包名、字节码内容完全一致，JVM 也视其为两个完全无关的类型

类的唯一性 = 全限定名 + 类加载器实例

这是 JVM 规范（§5.3）明确定义的二元判定原则。它不是 Java 语言层的约定，而是虚拟机底层运行时的硬性规则：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• MyService.class 由系统类加载器加载 → 是 MyService 类型
• MyService.class 由自定义 PluginClassLoader 实例 A 加载 → 是另一个类型，与前者不可赋值
• MyService.class 由另一个 PluginClassLoader 实例 B 加载 → 又是第三个独立类型

命名空间隔离的实际影响

这种机制直接支撑了模块化、热部署、沙箱安全等关键能力：

• Osgi、Spring Boot DevTools、Tomcat 的 webapp 隔离，都依赖此特性避免类冲突
• 插件系统可并行加载不同版本的 logback-core，互不影响
• 恶意代码无法通过伪造同名类覆盖核心类（如 java.lang.String），因为启动类加载器加载的类无法被用户加载器“重定义”

验证方式很简单

可通过 getClassLoader() 和 == 判断是否为同一类加载器实例，并用 isAssignableFrom 或 instanceof 测试类型兼容性：

• 若 obj.getClass().getClassLoader() != MyService.class.getClassLoader()，则 obj instanceof MyService 必为 false
• 即使 obj.getClass().getName().equals("MyService")，也不代表类型相同

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南