Java类加载器双亲委派机制解析

编程并不是一个机械性的工作，而是需要有思考，有创新的工作，语法是固定的，但解决问题的思路则是依靠人的思维，这就需要我们坚持学习和更新自己的知识。今天golang学习网就整理分享《Java类加载器双亲委派机制详解》，文章讲解的知识点主要包括，如果你对文章方面的知识点感兴趣，就不要错过golang学习网，在这可以对大家的知识积累有所帮助，助力开发能力的提升。

双亲委派机制是Java类加载的核心规则：先委托父加载器加载，失败后才由当前加载器调用findClass；它通过parent引用形成委托链，而非继承，确保核心类不被替换、避免重复加载、保障类唯一性。

Java类加载器的双亲委派，核心就一句话：先让父加载器试，父不行再自己干。它不是靠继承实现的“父子”，而是每个加载器内部持有一个parent引用，形成逻辑上的委托链。

三类内置加载器的职责分工

JVM默认提供三个层级的类加载器，自上而下依次是：

• 启动类加载器（Bootstrap ClassLoader）：C++实现，不可在Java中直接获取（调用String.class.getClassLoader()返回null）。负责加载$JAVA_HOME/jre/lib下的核心类，如java.lang.*、java.util.*等。
• 扩展类加载器（Extension ClassLoader）：Java实现，类名是sun.misc.Launcher$ExtClassLoader。加载$JAVA_HOME/jre/lib/ext目录或java.ext.dirs指定路径下的JAR包。
• 应用程序类加载器（Application ClassLoader）：也叫系统类加载器，类名是sun.misc.Launcher$AppClassLoader。加载classpath路径下的所有类——也就是你写的代码、引入的第三方JAR（如log4j、spring-core）。

双亲委派的具体执行流程

当你调用MyClass.class.getClassLoader().loadClass("com.example.Service")时，实际走的是ClassLoader.loadClass(String, boolean)方法，内部逻辑如下：

• 先查缓存：findLoadedClass(name)，如果已加载过，直接返回Class对象；
• 没命中缓存，就向上委托：if (parent != null) parent.loadClass(name, false)；
• 若parent为null（即到达顶层），则调用findBootstrapClassOrNull(name)，由JVM底层尝试加载；
• 所有上级都返回ClassNotFoundException后，才轮到当前加载器调用findClass(name)——这个方法默认抛异常，需子类重写才能真正从文件、网络或数据库读取字节码。

为什么必须双亲委派？关键在三点

这个机制不是为了炫技，而是解决真实问题：

• 防止核心类被替换：比如你自己写个java.lang.String，放在classpath里。由于双亲委派，ApplicationClassLoader会先把请求交给Bootstrap，而Bootstrap早已加载了真正的String，所以你的假String根本不会被用到——避免恶意篡改基础API。
• 避免重复加载同一类：同一个全限定名的类，只要被任一层加载器成功加载，就会缓存在该加载器中。后续请求直接命中缓存，不走完整流程，节省内存和开销。
• 保证类的唯一性与一致性：JVM判定两个类是否相同，依据是“类全限定名 + 加载它的类加载器”。双亲委派确保像Object这种类永远由Bootstrap加载，不同模块拿到的Object.class一定是同一个Class对象，类型转换、反射、instanceof才不会出错。

怎么打破双亲委派？慎用！

想绕过默认流程，常见方式是自定义加载器并重写loadClass方法——跳过委托步骤，直接调用findClass。但要注意：

• Tomcat就是这么做的：每个Web应用用独立的WebAppClassLoader，优先加载WEB-INF/classes和lib，再委派给父加载器，实现应用间类隔离；
• OSGi、某些热部署框架也打破委派，但代价是复杂度陡增——可能引发NoClassDefFoundError、LinkageError或静态变量多份副本等问题；
• 除非明确需要类隔离或动态加载（如插件系统），否则不建议手动打破。

基本上就这些。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Java类加载器双亲委派机制解析》文章吧，也可关注golang学习网公众号了解相关技术文章。