虚拟机之双亲委托模型
程序员文章站
2022-04-03 14:54:40
...
类加载器
虚拟机设计团队把类加载阶段中的“通过一个全限定性名获取二进制字节流”这个动作的实现放到 java 虚拟机外部去实现,以便让程序自己决定如何去获取所需要的类. 这个动作的代码模块称为“类加载器”。
任何一个类,都是由加载它的类加载器和这个类本身一同确立其在 java 虚拟机中的唯一性,每一个类加载器,都拥有一个独立的类名称空间.
换句话说,比较两个类是否相等,只有在这两个类在同一个类加载器加载的前提下才有意义.否则就是同一个类,但是用不同的类加载器加载,那么必然也是不相等的.
这里说的相等,包括代表类的 Class 对象的 equals() 方法、isAssignableFrom() 方法、isInstance() 方法的返回结果,也包括 instanceof 关键字做对象所属关系判定等情况.
双亲委派模型
从 java 虚拟机的角度上将,只存在两种加载器,一种是启动类加载器,这个类加载器由c++实现,还有就是其他的类加载器,这些类加载器由java语言实现,独立于虚拟机外部,并全部继承自抽象类 java.lang.ClassLoader.
启动类加载器:负责 java_hone/lib 目录中的,或者被 -Xbootclasspath 参数指定的路径
扩展类加载器:负责 java_home/lib/ext 目录中的,或者被 java.ext.dirs 系统变量所指定的(sun.misc.Launcher$ExtClassLoader实现).
应用程序类加载器:这个类加载器是 ClassLoader 中的 getSystemClassLoader() 方法的返回值,所以又称系统类加载器.(sun.misc.Launcher$App-ClassLoader)
双亲委托机制(使用组合关系来复用父加载器的代码)
双亲委派模型的工作过程:如果一个类加载器收到了一个类的加载请求,它首先不会自己去尝试加载这个类,而是把请求委托给父类加载器去完成,每个层次的加载器都是如此,因此所有的加载请求最终都会到启动类加载器那. 只有当父类加载器反馈自己无法完成这个加载请求时,子类加载器才会尝试自己去加载.
这样做的好处是保证核心类在虚拟机中只会出现一次,保证了虚拟机的安全.
双亲委托模型的实现:
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized (getClassLoadingLock(name)) {
// First, check if the class has already been loaded
Class<?> c = findLoadedClass(name);
if (c == null) {
long t0 = System.nanoTime();
try {
if (parent != null) {
c = parent.loadClass(name, false);
} else {
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
// ClassNotFoundException thrown if class not found
// from the non-null parent class loader
}
if (c == null) {
// If still not found, then invoke findClass in order
// to find the class.
long t1 = System.nanoTime();
c = findClass(name);
// this is the defining class loader; record the stats
sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
sun.misc.PerfCounter.getFindClasses().increment();
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
}
我们可以看到,在 loadClass 中实现了双亲委托的核心代码,然后调用 findClass 方法. 所以,如果我们只是改变查找类的话,可以直接重写 findClass 方法.
破坏双亲委托模型
双亲委托模型并不是一个强制性约束模型,而是 java 设计者推荐的一种.
双亲委托模型第一次被破坏: JDK1.2发布之前,由于双亲委托模型是在 JDK1.2之后才被引入的,而 ClassLoader 在 JDK1.0 时已经存在,所以 java 设计者不得不做出一些妥协,添加了 protected 方法 findClass().
双亲委托模型第二次被破坏:是由模型自身缺陷导致的,比如说基础类要回调用户代码,该怎么办了?比如典型的例子JNDI服务,它的代码由启动类加载器加载,但是它要加载厂商放在 classpath 的实现,该怎么办了?为了解决这个问题,java 设计团队引入了一个不太优雅的设计:线程上下文类加载器(Thread Context ClassLoader). 这个类加载器可以通过 Thread 类的 setContextClassLoader() 方法进行设置,如果线程创建时还没有设置,它将从父线程中继承一个,如果在引用程序的全局都没有设置过,那这个类加载器默认就是应用程序类加载器.
第三次被破坏:由于用户对程序动态性的追求所导致.每个程序模块(OSGI 中称 Bundle)都有一个自己的类加载器,当需要更换一个 Bundle 时,就把 Bundle 连同类加载器一起换掉以实现代码的热替换.
可以参考:https://www.zhihu.com/question/49667892
在 OSGI 环境下,类加载器不再是双亲委托模型中的树状结构,而是更加复杂的网状结构,当收到类加载请求时,OSGI 将按照下面的顺序进行类搜索:
1.将以 java.* 开头的类委派给父类加载器加载
2.否则,将委派列表名单内的类委派给父类加载器加载
3.否则,将 Import 列表中的类委派给 Export 这个类的 Bundle 的类加载器加载
4.否则,查找当前 Bundle 的 ClassPath,使用自己的类加载器加载
5.否则,查找类是否在自己的 Fragment Bundle 中,如果在,则委派给 Fragment Bundle 的类加载器加载
6.否则,查找 Dynamic Import 列表的 Bundle,委派给对应的 Bundle 的类加载器加载
7.否则,查找失败
虚拟机设计团队把类加载阶段中的“通过一个全限定性名获取二进制字节流”这个动作的实现放到 java 虚拟机外部去实现,以便让程序自己决定如何去获取所需要的类. 这个动作的代码模块称为“类加载器”。
任何一个类,都是由加载它的类加载器和这个类本身一同确立其在 java 虚拟机中的唯一性,每一个类加载器,都拥有一个独立的类名称空间.
换句话说,比较两个类是否相等,只有在这两个类在同一个类加载器加载的前提下才有意义.否则就是同一个类,但是用不同的类加载器加载,那么必然也是不相等的.
这里说的相等,包括代表类的 Class 对象的 equals() 方法、isAssignableFrom() 方法、isInstance() 方法的返回结果,也包括 instanceof 关键字做对象所属关系判定等情况.
双亲委派模型
从 java 虚拟机的角度上将,只存在两种加载器,一种是启动类加载器,这个类加载器由c++实现,还有就是其他的类加载器,这些类加载器由java语言实现,独立于虚拟机外部,并全部继承自抽象类 java.lang.ClassLoader.
启动类加载器:负责 java_hone/lib 目录中的,或者被 -Xbootclasspath 参数指定的路径
扩展类加载器:负责 java_home/lib/ext 目录中的,或者被 java.ext.dirs 系统变量所指定的(sun.misc.Launcher$ExtClassLoader实现).
应用程序类加载器:这个类加载器是 ClassLoader 中的 getSystemClassLoader() 方法的返回值,所以又称系统类加载器.(sun.misc.Launcher$App-ClassLoader)
双亲委托机制(使用组合关系来复用父加载器的代码)
双亲委派模型的工作过程:如果一个类加载器收到了一个类的加载请求,它首先不会自己去尝试加载这个类,而是把请求委托给父类加载器去完成,每个层次的加载器都是如此,因此所有的加载请求最终都会到启动类加载器那. 只有当父类加载器反馈自己无法完成这个加载请求时,子类加载器才会尝试自己去加载.
这样做的好处是保证核心类在虚拟机中只会出现一次,保证了虚拟机的安全.
双亲委托模型的实现:
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized (getClassLoadingLock(name)) {
// First, check if the class has already been loaded
Class<?> c = findLoadedClass(name);
if (c == null) {
long t0 = System.nanoTime();
try {
if (parent != null) {
c = parent.loadClass(name, false);
} else {
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
// ClassNotFoundException thrown if class not found
// from the non-null parent class loader
}
if (c == null) {
// If still not found, then invoke findClass in order
// to find the class.
long t1 = System.nanoTime();
c = findClass(name);
// this is the defining class loader; record the stats
sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
sun.misc.PerfCounter.getFindClasses().increment();
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
}
我们可以看到,在 loadClass 中实现了双亲委托的核心代码,然后调用 findClass 方法. 所以,如果我们只是改变查找类的话,可以直接重写 findClass 方法.
破坏双亲委托模型
双亲委托模型并不是一个强制性约束模型,而是 java 设计者推荐的一种.
双亲委托模型第一次被破坏: JDK1.2发布之前,由于双亲委托模型是在 JDK1.2之后才被引入的,而 ClassLoader 在 JDK1.0 时已经存在,所以 java 设计者不得不做出一些妥协,添加了 protected 方法 findClass().
双亲委托模型第二次被破坏:是由模型自身缺陷导致的,比如说基础类要回调用户代码,该怎么办了?比如典型的例子JNDI服务,它的代码由启动类加载器加载,但是它要加载厂商放在 classpath 的实现,该怎么办了?为了解决这个问题,java 设计团队引入了一个不太优雅的设计:线程上下文类加载器(Thread Context ClassLoader). 这个类加载器可以通过 Thread 类的 setContextClassLoader() 方法进行设置,如果线程创建时还没有设置,它将从父线程中继承一个,如果在引用程序的全局都没有设置过,那这个类加载器默认就是应用程序类加载器.
第三次被破坏:由于用户对程序动态性的追求所导致.每个程序模块(OSGI 中称 Bundle)都有一个自己的类加载器,当需要更换一个 Bundle 时,就把 Bundle 连同类加载器一起换掉以实现代码的热替换.
可以参考:https://www.zhihu.com/question/49667892
在 OSGI 环境下,类加载器不再是双亲委托模型中的树状结构,而是更加复杂的网状结构,当收到类加载请求时,OSGI 将按照下面的顺序进行类搜索:
1.将以 java.* 开头的类委派给父类加载器加载
2.否则,将委派列表名单内的类委派给父类加载器加载
3.否则,将 Import 列表中的类委派给 Export 这个类的 Bundle 的类加载器加载
4.否则,查找当前 Bundle 的 ClassPath,使用自己的类加载器加载
5.否则,查找类是否在自己的 Fragment Bundle 中,如果在,则委派给 Fragment Bundle 的类加载器加载
6.否则,查找 Dynamic Import 列表的 Bundle,委派给对应的 Bundle 的类加载器加载
7.否则,查找失败