类加载器和双亲委派机制、全盘委托机制的关系
一. 类加载器
1.1 类加载器rt.jar中 sun.misc.Launcher.class
public class Launcher {
static class AppClassLoader extends URLClassLoader {}
static class ExtClassLoader extends URLClassLoader {}
}
JVM 加载任意一个类时，委托至顶级加载器 Bootstrap ClassLoader， Bootstrap 会加载Launcher.class（不需要编译，直接存在于rt.jar中）
也即是Bootstrap 启动完成， AppClassLoader，ExtClassLoader已成为可用状态
1.2 两大类加载器的基类 URLClassLoader
public class URLClassLoader extends SecureClassLoader implements Closeable {}
public class SecureClassLoader extends ClassLoader {}
1.3 native 底层加载.class文件 ClassLoader.defineClass()
protected final Class<?> defineClass(String name, byte[] b, int off, int len){
return defineClass(name, b, off, len, null);
}
native 方法读取字节数组, 也就是我们平常说的字节码文件，也可以根据字节流换成来读取一个资源
native 原生就支持加载编译好的.class文件，网络传输中的.class文件, 甚至是自己new 出来的字节数组
二. 双亲委派机制
2.1 双亲委派组成之一： loadClass()
2.1.1 ClassLoader.loadClass()
public Class<?> loadClass(String name) throws ClassNotFoundException {
return loadClass(name, false);
}
// native 读取是否已经加载了类
private native final Class<?> findLoadedClass0(String name);
// 除了BootStrap的loadClass, 特指ExtClassLoader和AppClassLoader
protected Class<?> loadClass(String name, boolean resolve) {
// First, check if the class has already been loaded
Class<?> c = findLoadedClass(name);
if (c == null) {
try {
// 递归寻找父加载器
if (parent != null) {
c = parent.loadClass(name, false);
else
//parent == null 时 访问到顶级加载器
c = findBootstrapClassOrNull(name);
} catch (ClassNotFoundException e) {
}
if (c == null) {
// findClass找到class文件后将调用defineClass方法把字节码导入方法区，同时缓存结果
c = findClass(name);
}
}
}
AppClassLoader 和 ExtClassLoader 都使用的是变双亲委派的规则
2.1.2 不同类加载器的执行目录
- 启动（Bootstrap）类加载器：负责装载%Java_Home%/lib下面的核心类库或-Xbootclasspath选项指定的jar包。由native方法实现加载过程，程序无法直接获取到该类加载器，无法对其进行任何操作。
- 扩展（Extension）类加载器：扩展类加载器由sun.misc.Launcher.ExtClassLoader实现的。负责加载%Java_Home%/lib/ext或者由系统变量-Djava.ext.dir指定位置中的类库。程序可以访问并使用扩展类加载器。
- 系统（System）类加载器：系统类加载器是由sun.misc.Launcher.AppClassLoader实现的，也叫应用程序类加载器。负责加载系统类路径-classpath或-Djava.class.path变量所指的目录下的类库。程序可以访问并使用系统类加载器。
非常重要的匹配关系：-classpath的类当且仅当只能要AppClassLoader加载
2.2 双亲委派组成之二：findClass()
2.2.1 ClassLoader.findClass()
protected Class<?> findClass(String name) throws ClassNotFoundException {
throw new ClassNotFoundException(name);
}
2.2.2 AppClassLoader 和 ExtClassLoader 的 findClass()
// 搜索路径
private final URLClassPath ucp;
protected Class<?> findClass(final String name) {
final Class<?> result;
result = AccessController.doPrivileged(new PrivilegedExceptionAction<Class<?>>(){
public Class<?> run() throws ClassNotFoundException {
String path = name.replace('.', '/').concat(".class");
// 找自己路径下的class文件
Resource res = ucp.getResource(path, false);
if (res != null) {
// 找到了就注入
return defineClass(name, res);
} else {
return null;
}
}
}, acc);
if (result == null) {
throw new ClassNotFoundException(name);
}
return result;
}
- findclass 在指定的目录找到class文件
- loadclass 委托给父类进行初始化
总的来说，就是双亲委派需要findclass 和 loadclass一起协同合作，打破该规则可以想着从这两个角度入手。
2.3 为什么需要双亲委派机制？
2.3.1 解决依赖问题
保证最核心的类最先加载，核心类加载了，其他用户自定义的类才不会出现依赖问题。
2.3.2. 不重复加载，保证核心类不被篡改
Bootstrap ClassLoader 是对用户不可见的类加载器，也是顶级加载器，%Java_Home%/lib下面的核心类会优先加载，如果用户自己定义了java.lang.Integer， 程序只能使用AppClassLoader来进行加载，一旦执行到其父类URLClassLoader的findClass()`中的语句时，会跳过加载同名的类
Class<?> c = findLoadedClass(name);
值得一提的是，类加载器加载网络中的java.lang.Integer，这个时候需要另外一个机制来检测
URLClassLoader extends SecureClassLoader, jdk自带的classLoader都拥有这个能力。覆盖重名
public final Class<?> loadClass(String name, boolean resolve){
// First check if we have permission to access the package. This
// should go away once we've added support for exported packages.
SecurityManager sm = System.getSecurityManager();
if (sm != null) {
int i = name.lastIndexOf('.');
if (i != -1) {
sm.checkPackageAccess(name.substring(0, i));
}
}
return super.loadClass(name, resolve);
}
使用自定义类加载器不继承 SecureClassLoader 是可以实现与 核心类同名的类共存，
原因：JVM 识别类的完全一致，需要全限定名 + 加载该类的类加载器
但是一般不这么做，所以也就有网上的一说:
建议自定义类加载器继承 URLClassLoader 理由之一是继承了 SecureClassLoader 尽可能保证安全性。
2.3.3 可不可以不遵循双亲委派？
当然可以
- 自定义一个类加载器并且重写
loadClass能够不遵循 - 更简单的方法，使用Class.forName(全限定名) ，实际上走的就是全盘委托机制
三. JVM如何加载编译好的.class文件
Class.forName()
- 默认直接使用调用者的ClassLoader来加载类
@CallerSensitive
public static Class<?> forName(String className)
throws ClassNotFoundException {
Class<?> caller = Reflection.getCallerClass();
return forName0(className, true, ClassLoader.getClassLoader(caller), caller);
}
- 也可以指定指定的类加载器 —— 突破口，直接用AppClassLoader 的classloder就能加载classpath的内容。
private static native Class<?> forName0(String name, boolean initialize,
ClassLoader loader,
Class<?> caller)
throws ClassNotFoundException;
ClassLoader.loadClass()
public Class<?> loadClass(String name) throws ClassNotFoundException {
return loadClass(name, false);
}
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);
}
} catch (ClassNotFoundException e) {
// 抛异常证明当前ClassLoader目录下不存在目标类
// 使用catch调度程序继续执行
}
if (c == null) {
// findClass 暴露给子类实现，让破坏双亲委派成为了可能
c = findClass(name);
}
}
return c;
}
}
用户使用 ClassLoader.loadClass() 实质上就是在使用双亲委派模型
findClass(name) 组合了 findClass(name), findClass()只是双亲委派的拓展，可以自己拓展类的检索路径
四. 打破双亲委派机制
4.1 Class.forName()
如上文提到，class.forName()调用的是native方法，不走双亲委派的代码
4.2 借助Launcher的构造方法和 setContextClassLoader()
public class Launcher {
static class AppClassLoader extends URLClassLoader {}
static class ExtClassLoader extends URLClassLoader {}
public Launcher() {
try {
this.loader = Launcher.AppClassLoader.getAppClassLoader(var1);
}
// 把AppClassLoader设置为线程的加载器
Thread.currentThread().setContextClassLoader(this.loader);
}
}
Launcher实例化后会将AppClassLoader 设置在 AppClassLoader ExtClassLoader 的线程上下文中
也就是加载核心类后，加载自定义类前，这个加载类的线程，能够拿到AppClassLoader
setContextClassLoader(this.loader); 在SPI打破双亲委派模型起关键的作用
402
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
