除了顶层的启动类加载器,其余所有类加载器都有自己的父类加载器。父子关系不以继承实现,而是以组合关系来复用父类加载器。
工作过程: 类加载器接到类加载请求–>将请求委派给父类加载器(直到最顶层启动类加载器)–>父类尝试加载,加载失败反馈给子类加载器–>子类加载器尝试加载
双亲委派模型的好处:保证java底层API的稳定,避免加载和基本类重名(Object)的自定义类导致出现多个不同的重名的类(Object),从而造成java基础行为的混乱。
双亲委派模型源码:
方法加同步锁保证线程安全,首先检查该类是否被加载过,如果没有加载则调用父类加载器的loadClass()方法,若父类加载器为空说明是启动类加载器,则调用启动类加载器。
如果父类加载失败会抛出ClassNotFoundException,在调用自己的findClass()方法进行加载。
protected Class> loadClass(String name, boolean resolve) throws ClassNotFoundException { //同步锁 synchronized (getClassLoadingLock(name)) { // 首先检车这个类是不是已被加载 Class> c = findLoadedClass(name); if (c == null) { long t0 = System.nanoTime(); try { if (parent != null) { //如果父类不为空则调用父类加载器的loadClass方法 c = parent.loadClass(name, false); } else { //没有父类则默认调用启动类加载器加载 c = findBootstrapClassOrNull(name); } } catch (ClassNotFoundException e) { //如果父类加载器找不到这个类则抛出ClassNotFoundException } if (c == null) { // 父类加载器失败时调用自身的findClass方法加载 long t1 = System.nanoTime(); c = findClass(name); //记录 sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0); sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1); sun.misc.PerfCounter.getFindClasses().increment(); } } if (resolve) { resolveClass(c); } return c; } }
三、破坏双亲委派模型
1.第一次破坏
双亲委派模型出现在JDK1.2之后,而类加载器和抽象类java.lang.ClassLoader已经存在。
因此为了向前兼容,JDK1.2之后在ClassLoader中添加了一个新的protected方法findClass。用户把自己的类加载逻辑写在findClass方法中,而不是重写loadClass方法,从而保证自定义的类加载符合双亲委派模型。
2.第二次破坏
模型自身有缺陷。双亲委派可以确保各个类加载器的基础类的统一,这是在用户代码调用基础类的情况下,如果出现基础类回调用户代码那就不适用了。比如涉及到SPI的场景去加载所需要的SPI代码。
SPI机制的介绍参考其他文章。
为了解决这个问题,引入了线程上下文加载器(Thread Context ClassLoader),这个类加载器就可以通过java.lang.Thread类中的setContextClassLoader()方法进行设置,如果创建线程时未设置将会从父线程中继承一个,如果全局都没有则默认就是应用程序类加载器,利用这个加载器可以完成父类加载器请求子类加载器加载的动作。
3.第三次破坏
由于对程序动态性追求导致,如热部署,热替换等。
比如模块化标准OSGi R4.2中将双亲委派的树形结构变成了更复杂的网状结构。
java文章教程推荐:java入门教程
以上就是深入理解java之类加载器的详细内容,更多请关注其它相关文章!