java 允许同一类文件被多个独立 classloader 分别加载，生成逻辑上互不兼容的 class 对象；这违背直觉但符合双亲委派模型的可扩展设计，常见于 web 容器等需隔离类版本的场景。
在 Java 中，类的唯一性不仅由全限定名决定，更由其加载它的 ClassLoader 实例共同定义。这意味着：example.ToBeLoaded 被 cl1 加载得到的 Class 对象，与被 cl2 加载得到的另一个 Class 对象，在 JVM 内部被视为两个完全不同的类型——即使它们字节码完全相同、来源一致。
你提供的代码中，cl1 和 cl2 均为 URLClassLoader 实例，且均以 Main.class.getClassLoader()（即应用类加载器）为父加载器。按双亲委派模型（Parent Delegation Model），当 cl1.loadClass("example.ToBeLoaded") 被调用时，cl1 会先委托父加载器尝试加载；若父加载器未找到该类（例如 ToBeLoaded 不在 classpath 中），cl1 才会自行从指定 JAR 中加载。同理，cl2 也会走相同流程。
关键点在于：双亲委派仅发生在“单个 ClassLoader 的加载链路中”，并不跨 ClassLoader 实例进行全局协调。cl1 和 cl2 是两个相互独立的对象，各自维护自己的已加载类缓存（definedClasses），彼此之间无共享、无通信。因此，即使它们拥有相同的父加载器、相同的资源路径，只要没有显式缓存或共享机制，就会各自完成一次完整的加载过程。
运行示例代码将输出：
立即学习“Java免费学习笔记（深入）”；
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
false false
说明 child1 与 child2 既不是同一个引用（== 为 false），也不是 equals 意义下的相等（Class.equals() 实际比较的是 ==），印证了二者是 JVM 中两个独立的类元数据实体。
⚠️ 注意事项：
- 类型强制转换失败：若尝试将 child1.newInstance() 得到的实例赋值给 child2 加载的类型变量（如 example.ToBeLoaded obj = (example.ToBeLoaded) instance;），将抛出 ClassCastException；
- 反射调用受限：通过 child1.getDeclaredMethod(...) 获取的方法无法直接作用于 child2 加载的实例；
- instanceof 判定失效：obj instanceof example.ToBeLoaded 的结果取决于 obj 实际所属的 ClassLoader，而非类名本身。
这种机制并非缺陷，而是 Java 类加载体系的关键弹性设计。典型应用场景包括：
- Servlet 容器（如 Tomcat）：每个 Web 应用拥有独立的 WebAppClassLoader，支持不同应用使用不同版本的 commons-collections 等库；
- OSGi 框架：基于精细的模块化类加载，实现动态安装/卸载 Bundle；
- 热部署与插件系统：通过创建新 ClassLoader 加载更新后的类，避免重启进程。
✅ 总结：判断两个 Class 是否“相同”，必须同时满足两个条件：
- 全限定类名完全一致；
- 加载它们的 ClassLoader 实例相同（class1.getClassLoader() == class2.getClassLoader()）。
仅比对类名或字节码内容（如 SHA256）在 JVM 运行时无意义——JVM 不做运行期字节码等价性校验。
