AppClassloader和SystemClassloader之间的区别

我对这两个类加载器非常困惑。 在谈到Java类加载器的层次结构时,通常会提到引导类加载器和ext类加载器以及第三个(系统类加载器或应用程序类加载器)。

为了更准确,我检查了JDK的源代码。 在类Launcher ,有代码:

 loader = AppClassLoader.getAppClassLoader(extcl); 

在类ClassLoader ,方法:

 getSystemClassloader() 

还说系统类加载器用于启动应用程序。

那么哪个是层次结构中的第三个,还是两个类加载器相同?

AppClassLoaderSystemClassLoader都是一样的。

看看层次结构。

ClassLoader遵循三个原则。

授权原则

ClassLoader hieraechy

Bootstrap ClassLoader负责从rt.jar加载标准JDK类文件,它是Java中所有类加载器的父级。 Bootstrap类加载器没有任何父级。

Extension ClassLoader将类加载请求委托给其父,Bootstrap,如果不成功,则加载类表单jre / lib / ext目录或java.ext.dirs系统属性指向的任何其他目录

System or Application class loader ,它负责从CLASSPATH环境变量,-classpath或-cp命令行选项,JAR内的Manifest文件的Class-Path属性加载特定于应用程序的类。

Application类加载器是Extension ClassLoader的子Extension ClassLoader ,它由sun.misc.Launcher$AppClassLoader类实现。

除了Bootstrap class loader (主要在C语言中使用本机语言实现)之外,所有Java类加载器都是使用java.lang.ClassLoader实现的。

看看这个博客,以便更好地理解这三个类加载器。

可见性原则

根据可见性原则, Child ClassLoader可以看到由Parent ClassLoader加载的 but vice-versa is not true

如果类Abc由Application class loader那么尝试使用Extension ClassLoader显式加载类ABC将抛出java.lang.ClassNotFoundException

唯一性原则

根据这个原则,父类加载的类不应再次由Child ClassLoader加载

类加载器层次结构中的第三个是SystemClassloader。 它在某些地方也称为ApplicationClassloader(或AppClassLoader)。 这个加载器加载我们在类路径中找到的应用程序代码和类。

关于Classloader中的以下方法:

public static ClassLoader getSystemClassLoader()

Javadoc说:

返回用于委派的系统类加载器。 这是新ClassLoader实例的默认委托父级,通常是用于启动应用程序的类加载器。

这里重要的是

这是新ClassLoader实例的默认委托父级,通常是用于启动应用程序的类加载器

这意味着,如果我们在应用程序中创建自己的Custom或新的类加载器 ,则System或Application类加载器将成为Custom或新类加载器的父级。 在Custom或new Classloader中调用getSystemClassLoader()方法将返回System(aka Application)类加载器。 这也与java类加载器委派模型一致。

System(aka Application)类加载器是从类路径加载我们的类或应用程序的类加载器。

系统类加载器是Application类加载器的不同名称。

资料来源: https : //blogs.oracle.com/sundararajan/entry/understanding_java_class_loading

应用程序类加载器……(混淆地)也称为“系统类加载器” – 不要与加载Java“系统”类的引导加载程序混淆。