Java的类加载器体系遵循双亲委派模型，不同层级的加载器之间存在明确的父子关系，这种关系直接决定了类之间的可见性范围。类加载器的可见性规则核心为：子加载器可以访问父加载器加载的所有类和资源，而父加载器无法访问子加载器加载的内容，这一规则是JVM类加载机制的重要组成部分。
类加载器的基本层级结构
Java默认的类加载器分为三层，从顶层到底层依次为：
- 启动类加载器（Bootstrap ClassLoader）：由C++实现，负责加载JAVA_HOME/lib目录下的核心类库，是所有类加载器的顶层父加载器。
- 扩展类加载器（Extension ClassLoader）：负责加载JAVA_HOME/lib/ext目录下的扩展类库，父加载器为启动类加载器。
- 应用程序类加载器（Application ClassLoader）：负责加载用户类路径（classpath）下的类，父加载器为扩展类加载器。
用户也可以自定义类加载器，其默认父加载器为应用程序类加载器，父子关系通过ClassLoader类的parent字段维护，而非继承关系。
可见性规则的核心逻辑
类加载器在加载类时，首先会委托父加载器尝试加载，只有父加载器无法加载时，子加载器才会自己尝试加载。这种加载顺序直接决定了类的可见性：
- 父加载器加载的类，对于子加载器来说是可见的，因为子加载器在加载类时会先向上查找，找到后直接使用父加载器返回的类对象。
- 子加载器加载的类，父加载器不会感知到，因为父加载器不会向下委托加载，自然无法获取子加载器加载的类信息。
ClassLoader的核心加载逻辑
我们可以通过ClassLoader的loadClass方法源码理解这一逻辑，以下是简化后的核心代码：
// ClassLoader类的loadClass方法核心逻辑
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized (getClassLoadingLock(name)) {
// 先检查当前加载器是否已经加载过该类
Class<?> c = findLoadedClass(name);
if (c == null) {
try {
if (parent != null) {
// 委托父加载器加载
c = parent.loadClass(name, false);
} else {
// 父加载器为null，说明是启动类加载器
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
// 父加载器无法加载，当前加载器自己尝试加载
}
if (c == null) {
c = findClass(name);
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
}
代码示例验证可见性规则
我们通过自定义类加载器来验证子父加载器的可见性差异，首先定义一个测试类TestClass，放在自定义加载器的加载路径下：
// 测试类，用于验证加载可见性
public class TestClass {
public String getName() {
return "TestClass";
}
}
然后自定义一个子类加载器，指定其加载路径为存放TestClass的目录：
import java.io.File;
import java.io.FileInputStream;
import java.io.IOException;
import java.lang.reflect.Method;
public class CustomClassLoader extends ClassLoader {
private String classPath;
public CustomClassLoader(String classPath, ClassLoader parent) {
super(parent);
this.classPath = classPath;
}
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
try {
String filePath = classPath + File.separator + name.replace(".", File.separator) + ".class";
FileInputStream fis = new FileInputStream(filePath);
byte[] bytes = new byte[fis.available()];
fis.read(bytes);
fis.close();
return defineClass(name, bytes, 0, bytes.length);
} catch (IOException e) {
throw new ClassNotFoundException(name);
}
}
public static void main(String[] args) throws Exception {
// 自定义加载器，父加载器为系统类加载器
CustomClassLoader customLoader = new CustomClassLoader("D:/test_classes", ClassLoader.getSystemClassLoader());
// 用自定义加载器加载TestClass
Class<?> testClass = customLoader.loadClass("TestClass");
Object instance = testClass.newInstance();
Method method = testClass.getMethod("getName");
System.out.println("子加载器加载的类调用结果：" + method.invoke(instance));
// 尝试用父加载器（系统类加载器）加载TestClass
try {
Class<?> parentLoadedClass = ClassLoader.getSystemClassLoader().loadClass("TestClass");
System.out.println("父加载器成功加载TestClass");
} catch (ClassNotFoundException e) {
System.out.println("父加载器无法加载子加载器路径下的TestClass：" + e.getMessage());
}
// 验证子加载器可以访问父加载器加载的类，比如java.lang.String
Class<?> stringClass = customLoader.loadClass("java.lang.String");
System.out.println("子加载器可以访问父加载器加载的String类：" + stringClass.getName());
}
}
运行上述代码会得到以下结果：
- 子加载器成功加载TestClass并调用其方法，说明子加载器可以正常加载自己路径下的类。
- 系统类加载器（父加载器）无法加载TestClass，因为TestClass不在系统类加载器的加载路径下，且父加载器不会向下委托，所以抛出ClassNotFoundException。
- 子加载器可以正常加载java.lang.String，因为String由启动类加载器加载，属于父层级的类，子加载器可以访问。
可见性规则的设计意义
这种单向可见性的设计主要有两方面作用：
- 保证核心类库的安全性：核心类库由顶层启动类加载器加载，子加载器可以访问这些核心类，但核心类无法访问用户自定义的类，避免用户自定义类篡改核心类库的逻辑。
- 避免类重复加载：双亲委派的加载顺序配合可见性规则，确保同一个类在各级加载器中只会被加载一次，不会出现不同加载器加载同一个类导致类型转换异常的问题。
常见误区说明
需要注意类加载器的父子关系是逻辑上的层级关系，不是Java继承关系，自定义类加载器继承ClassLoader类，但其父加载器是通过构造方法传入的parent字段指定的。另外，可见性规则只适用于遵循双亲委派模型的场景，如果自定义加载器重写了loadClass方法打破了双亲委派，那么可见性规则也可能被改变，但这种情况不符合JVM类加载的默认设计规范。
类加载器双亲委派模型类可见性ClassLoader修改时间：2026-07-10 01:27:29