Java 如何查找和加载类，如何加载来自网络的字节码？

核心回答

Java 查找类不是扫描整块磁盘，而是由相应类加载器根据类的二进制名称，在自己的查找范围内找到或生成字节码，再交给 JVM 定义类。 字节码可以来自目录、JAR、模块，也可以来自网络或运行时生成的数据。

以普通应用加载 com.example.Plugin 为例，默认的 ClassLoader.loadClass 大致按以下顺序处理：

1. 检查当前加载器是否已经是这个名称对应类的发起加载器，是则返回已有的 Class。
2. 尝试交给父加载器加载；父加载器引用为 null 时，尝试虚拟机内置的启动加载器。
3. 父加载器找不到时，再调用自己的 findClass。普通 classpath 场景可以把类名映射为 com/example/Plugin.class，在配置的目录或 JAR 中查找；自定义加载器也可以采用别的来源。
4. 得到字节码后，通过 defineClass 交给 JVM 创建对应的类；后续还涉及链接，并在需要时初始化。

从网络加载，通常只需要自定义 ClassLoader，重写 findClass 来获取字节数组，再调用带类名的 defineClass，不必因此打破双亲委派。

加载、链接、初始化和双亲委派是什么关系？

它们描述的是不同问题：

• 加载：取得定义类的二进制数据，在 JVM 中创建相应的运行时类和 Class 对象。
• 链接：包括验证、准备、解析。验证检查结构与字节码约束；准备建立静态字段并设置默认值；解析把符号引用确定为具体的类、字段、方法等目标。解析可以按需进行，不要求所有引用都在初始化前一次性解析完。
• 初始化：执行类的静态初始化逻辑，例如静态字段的显式初始化、静态代码块对应的 <clinit>。加载成功并不表示已经执行这些逻辑，loadClass 本身也不等于初始化。
• 双亲委派：回答“优先让哪个加载器寻找和定义这个类”，是默认类加载器的协作策略，不是上述阶段中的一个阶段。

以 Java SE 25 的内置加载器为例，有启动、平台和应用加载器。JDK 9 引入模块系统后，不能继续把 JDK 8 的 rt.jar、扩展目录和扩展加载器结构原样套用；普通 classpath 查找也不能代表所有模块加载过程。

网络字节码怎样落到这个流程中？

假设应用需要从插件仓库加载 com.example.Plugin，可以这样设计：

1. 入口仍调用加载器的 loadClass，让已加载检查和默认委派规则先工作。
2. 在自定义 findClass 中，将允许的类名映射到仓库资源地址，获取完整字节数组，并处理下载失败、超时和内容版本。
3. 对收到的数据核对来源与完整性，再交给 defineClass。传入的类名需要与字节码声明匹配，Class 格式、版本和后续验证也必须满足运行时要求。
4. 后续由 JVM 按需要完成链接与初始化。插件引用的其他类，也需要通过适当的加载器找到；加载主类并不等于所有依赖都已齐全。

因此，HTTP 请求拿到 200 或文件名以 .class 结尾，都不足以说明加载成功。反过来，字节码验证通过主要说明满足 JVM 的相应约束，也不表示其中的业务逻辑可以无条件信任。

这里的 loadClass 负责组织流程，findClass 负责扩展查找，defineClass 负责从字节创建类。通常重写 findClass 就够了；只有需要改变父优先等委派规则时，才考虑定制 loadClass。

常见追问：同名类一定是同一个类型吗？

不是。运行时类型身份由“二进制名称 + 定义它的类加载器”共同确定。 两个独立加载器分别定义相同字节、相同名称的类，仍可能是两个不同类型，不能直接互相强制转换。

插件系统中通常让公共接口由双方都能委派到的公共加载器定义，再由各插件加载器定义自己的实现。这样既能隔离插件实现，又能通过共同接口交互。仅仅让两个接口文件的内容相同，不能代替共享同一个运行时类型。

参考资料