不同 ClassLoader 为什么可能产生多个单例？

简化版

Java 运行时类型由类的二进制名称和定义它的 ClassLoader 共同确定，同名类被不同定义类加载器加载后是不同的类对象，各自拥有静态字段。因此传统单例通常只能保证每个定义类加载器一份实例，不能直接保证整个 JVM、更不能保证跨进程唯一。

详细版

单例实例通常存放在类的静态字段中，而静态字段属于具体的 Class 对象。应用服务器、插件系统或热部署框架可能使用彼此隔离的类加载器分别定义同一个类，于是会得到：

两个不同的 Class<?> 对象；
两套独立的静态字段；
两个各自合法的单例实例；
即使类名相同，实例之间也可能无法直接类型转换。

要共享实例，可以把接口和实例持有者放到共同的父类加载器中，或者由外部容器、服务注册表统一管理。双亲委派有助于复用父加载器已经定义的类，但自定义加载器、模块隔离和热部署仍可能形成多个定义边界。

若要求跨 JVM 或跨节点唯一，应使用数据库唯一约束、分布式锁、选主等分布式机制。

完整版教学

一、类名不是类型身份的全部

两个类文件都叫 com.example.Registry，并不意味着 JVM 一定把它们视为同一个类型。决定运行时类型身份的关键还包括定义类加载器。

(com.example.Registry, PluginClassLoader-A)
(com.example.Registry, PluginClassLoader-B)

这两个组合可以对应两个独立的 Class 对象。

二、静态字段跟随类对象

private static final Registry INSTANCE = new Registry();

INSTANCE 并不是按文本类名存进一个全 JVM 字典，而是属于某个已定义类。两个定义类加载器各自定义类后，各自执行类初始化，也就各自产生一个静态实例。

所以“线程安全”没有失效：每个类对象内部仍只初始化一次，只是系统里存在两个初始化边界。

三、常见出现位置

多类加载器常见于：

应用服务器隔离多个 Web 应用；
插件系统为每个插件建立加载器；
热部署重新加载新版本类；
测试框架或脚本引擎隔离运行环境；
容器与业务代码使用不同加载层级。

类加载器被替换后，如果旧单例仍被线程、缓存或回调引用，还可能阻止旧加载器回收，形成类加载器泄漏。

四、如何设计共享边界

若多个子加载器必须共享能力，可以把稳定接口和共享实例注册点放在共同父加载器可见的位置，让子模块通过接口访问；也可以把生命周期交给应用服务器、依赖注入容器或进程外服务。

但把所有类都上移到父加载器会削弱插件隔离，还可能造成版本冲突。正确方案取决于目标究竟是共享还是隔离。

五、从 JVM 扩展到分布式系统

即使整个 JVM 只有一个实例，启动第二个 JVM 后仍有第二份静态字段。在微服务多副本环境中，进程内单例只能实现节点内共享。全局唯一资源必须由具备跨节点一致性能力的组件维护。

六、用两个定义类加载器观察两份静态字段

假设插件 A、B 都携带 com.example.Registry，并由两个互不委派该类的加载器定义。JVM 看到的不是“同名类的一份副本”，而是两个运行时类型；每个类型都有自己的类初始化状态和静态字段。

PluginClassLoader-A -> define Registry(A)
Registry(A).<clinit> -> INSTANCE-A
PluginClassLoader-B -> define Registry(B)
Registry(B).<clinit> -> INSTANCE-B
Registry(A).class != Registry(B).class
INSTANCE-A.getClassLoader() != INSTANCE-B.getClassLoader()
两个实例在各自边界内都满足单例

这条时序必须同时检查“谁负责创建”和“其他线程或调用方从哪里取得实例”。只看到最终引用相同还不够；若构造副作用执行了两次、发布了半初始化状态，或者作用域边界之外又创建了一份，就已经违反了本题讨论的保证。

七、保证范围与失效边界

评审维度	本题结论
唯一性/正确性保证	同一个定义 ClassLoader 所定义的同一个类，按所选实现维护一份静态实例。
作用域边界	类型身份是“二进制类名 + 定义类加载器”；进程、节点又是更外层边界。
仍未解决的问题	插件隔离、热部署、父子容器和跨 JVM 唯一性都不能仅靠静态字段解决。
更合适的替代方案	共享点上移到共同父加载器、交给容器注册；跨进程则使用数据库约束、锁或选主。

设计模式的保证必须带作用域。把“某个类初始化边界只创建一次”说成“整个系统永远只有一个”，或把“安全发布引用”说成“对象所有方法都线程安全”，都会把不同层次的问题混在一起。

八、工程落地时的验证方法

为构造过程增加可观察计数，使用 32 个并发任务同时获取实例，构造计数应符合本题保证。
比较引用身份时使用 ==，不要让重写后的 equals() 掩盖实际存在的多个对象。
若涉及类加载器，记录 instance.getClass().getClassLoader()，同时比较类对象和加载器身份。
若涉及序列化，至少执行一次“序列化 → 反序列化”，并核对返回引用及外部副作用。
若涉及 Spring，分别检查 Bean 名称、ApplicationContext 身份和作用域，而不只检查 Java 类名。
对共享可变字段另做并发测试；实例创建正确并不能替代业务状态的原子性测试。
对初始化失败、重复调用和资源关闭分别设计用例，确认生命周期语义可解释。

记忆钩子：先问“哪一个 Class 对象持有这个 static”，再谈这个单例到底有几份。

九、常见误区与追问

误区：全限定类名相同就一定是同一个运行时类型。 JVM 类型身份还包含定义类加载器。
误区：双亲委派能绝对阻止同名类被重复定义。 自定义加载器可采用子优先或隔离策略，热部署也会产生新加载边界。
误区：两个实例不能强转只是因为版本不同。 即使字节码完全相同，只要定义加载器不同，JVM 也视为不同类型。
追问：把单例类放到父加载器就一定正确吗？ 能共享类型和静态字段，但会降低隔离性，并可能引入依赖版本冲突。
追问：类加载器泄漏与单例有什么关系？ 长生命周期静态引用、线程或回调若指向子加载器对象，会阻止整棵加载器对象图回收。
追问：如何做到集群范围唯一？ 进程内单例不具备跨节点一致性，需要外部协调机制。

十、加强记忆

单例的真实边界不是类名，而是定义类加载器、进程和部署节点逐层限定的作用域。遇到插件、热部署或分布式系统时，先画清边界，再决定由父加载器、容器还是外部一致性机制维护唯一性。

简化版

详细版