JVM规范类加载器分类与启动时类加载器的矛盾疑问

问题背景 #

根据JVM规范所述：

类加载器分为两类：Java虚拟机提供的bootstrap class loader（启动类加载器），以及user-defined class loaders（用户自定义类加载器）。所有用户自定义类加载器都是抽象类ClassLoader的子类实例。

此外JVM启动时会默认初始化三类类加载器：

• Bootstrap class loader（启动类加载器）
• Extension or Platform class loader（扩展或平台类加载器）
• System or Application class loader（系统或应用类加载器）

这看起来存在矛盾：JVM规范只定义了两类加载器，但实际启动却有三类，该如何解释？

核心解释 #

这是抽象规范定义和具体实现细节的差异，本质不存在矛盾：

1. 规范的分类逻辑
   JVM规范的分类是从「类加载器的归属与实现层面」出发的：

   • 第一类是启动类加载器（Bootstrap）：它是JVM虚拟机核心的一部分，由原生代码（如C/C++）编写，不属于Java类体系，也不是ClassLoader的子类，这是JVM必须提供的核心加载器。
   • 第二类是用户自定义类加载器：所有基于Java代码实现、继承自ClassLoader抽象类的加载器都属于这一类——这里的「用户自定义」并非指必须由开发者自行编写，而是指它们遵循Java层面的类加载器模型，哪怕是JDK官方提供的标准实现也归为此类。

2. 平台/应用类加载器的定位
   平台类加载器（Platform）和应用类加载器（Application）是JDK在规范之上提供的标准实现：

   • 它们都是ClassLoader的子类，完全符合规范中「用户自定义类加载器」的定义，并非JVM虚拟机核心层面提供的加载器。
   • JVM启动时自动初始化这两个加载器，是为了实现双亲委派的分层加载策略，将JDK扩展类、应用程序类等不同来源的类进行隔离加载，属于JDK为开发者提供的便利实现，而非JVM规范强制要求的内容。

简单总结：规范划定了类加载器的核心边界，JDK在这个边界内预置了几个常用的工具类加载器，它们属于「用户自定义类加载器」阵营，和启动类加载器分属不同范畴，因此不存在矛盾。

内容的提问来源于stack exchange，提问作者gaurs