双亲委派模型确保类加载的统一与安全：类加载器先委派父类加载，直至启动类加载器，仅当上级无法加载时才自行加载，防止核心类被篡改并避免重复加载；其通过loadclass流程实现，但spi和tomcat等场景会通过线程上下文类加载器或优先自身加载等方式打破该模型以满足特殊需求。
双亲委派模型，说白了，就是Java里类加载器在加载一个类时的一种策略。它不是直接就去加载，而是先问问自己的“爸爸”（父类加载器）：“嘿，这个类你加载过没？或者你能加载吗？”只有当“爸爸”和“爸爸的爸爸”……一直到最顶层的启动类加载器都说“我加载不了”的时候，它自己才会尝试去加载。这就像一个层层上报的机制，确保了类加载的统一性和安全性。
深入理解双亲委派模型的运作机制
在我看来，双亲委派模型是Java虚拟机类加载机制里一个非常核心且巧妙的设计。它的工作流程其实是这样的：当一个类加载器收到加载类的请求时，它并不会立刻动手。它会先检查这个类是否已经被加载过了（通过 findLoadedClass() 方法）。如果已经加载了，那就直接返回。如果没有，它会把这个加载请求委派给它的父类加载器去处理。这个委派过程会一直向上，直到启动类加载器（Bootstrap ClassLoader）。只有当父类加载器在它的搜索路径下也找不到并无法加载这个类时，当前的类加载器才会自己尝试去加载（通过 findClass() 方法）。如果它也加载失败，那最终就会抛出 ClassNotFoundException。这个过程有点像你找东西，先问你爸，你爸再问他爸，直到你爷爷，爷爷说没有，你爸才说那我自己找找看，如果还找不到，就告诉你没有。
双亲委派模型解决了哪些核心问题？
你可能会想，这玩意儿到底有啥用？为什么Java要搞这么一套复杂的机制？其实啊，它主要解决了两个非常关键的问题，而且这俩问题的重要性怎么强调都不过分。
第一个是安全性。想象一下，如果一个恶意程序可以随便定义一个 java.lang.Object 类，然后让你的JVM加载它，那整个Java系统的安全性就彻底崩塌了。双亲委派模型通过强制所有核心Java API类都由启动类加载器加载，确保了这些基础类的唯一性和不可篡改性。因为启动类加载器是JVM内置的，它只会加载 $JAVA_HOME/jre/lib 目录下的核心类库，任何用户自定义的同名类都会被它“拦截”掉，从而保证了Java运行时环境的稳定和安全。这就像是给核心系统文件加了一把锁，只有“官方”的钥匙才能打开。
第二个是避免类的重复加载。如果每个类加载器都各自为政，那同一个类可能在内存中被加载多次，这不仅浪费内存，更严重的是会导致各种 ClassCastException。比如，如果你有两个不同的类加载器都加载了 com.example.MyClass，虽然它们类名一样，但由于是由不同的类加载器加载的，JVM会认为它们是两个完全不同的类。双亲委派模型确保了类加载的唯一性，只要父类加载器已经加载过某个类，子类加载器就不会再重复加载，从而保证了类的全局唯一性，避免了许多潜在的运行时问题。
深入理解双亲委派模型的执行流程
要更具体地理解双亲委派模型的执行，我们得稍微看看 java.lang.ClassLoader 里的 loadClass 方法。这个方法是所有类加载请求的入口。它的基本逻辑是这样的：
-
检查是否已加载： 首先，它会调用
findLoadedClass(name)方法来检查请求的类是否已经被当前类加载器加载过了。如果加载过，直接返回对应的Class对象，省去了后续的步骤。 -
委派给父类： 如果当前类加载器没有加载过，它会尝试获取父类加载器。如果存在父类加载器，它就会调用父类加载器的
loadClass(name, resolve)方法，将加载请求委派给父类。这个过程会递归进行，直到达到顶层的启动类加载器。 -
自行加载： 如果父类加载器（包括启动类加载器）无法加载这个类（通常是因为在它们的搜索路径下找不到），那么当前的类加载器才会调用自己的
findClass(name)方法来尝试加载这个类。这个findClass方法才是真正根据类名查找并加载字节码的地方，通常会从文件系统、网络或其他来源加载字节码，然后通过defineClass方法将其转换为Class对象。 -
解析： 最后，如果
resolve参数为true，则会调用resolveClass方法对类进行解析，将符号引用转换为直接引用。
这个流程确保了任何一个类加载请求都会优先由更高级别的类加载器处理，形成一个自上而下的加载顺序，但实际的查找和定义过程却是自下而上的。
打破双亲委派模型的常见场景与考量
虽然双亲委派模型是Java类加载的基石，但任何规则都有例外，对吧？在一些特定的场景下，为了实现某些特殊功能或解决特定问题，我们确实需要“打破”或者说“绕过”这个模型。
一个最经典的例子就是SPI (Service Provider Interface) 机制，比如JDBC驱动加载。核心的Java API（java.sql 包里的接口）是由启动类加载器加载的，但具体的JDBC驱动实现（比如MySQL的驱动JAR包）通常是由应用类加载器加载的。问题来了：核心API需要去加载并使用应用层提供的实现类，这与双亲委派模型“父类加载器加载的类无法看到子类加载器加载的类”的原则是冲突的。为了解决这个问题，Java引入了线程上下文类加载器 (Thread Context ClassLoader, TCCL)。在SPI机制中，通常会把TCCL设置为应用类加载器，这样，由启动类加载器加载的API类就可以通过TCCL来加载应用层提供的服务实现类了。这有点像一个“反向委派”或者说“借道”加载。
另一个常见场景是Web服务器如Tomcat。Tomcat为了实现不同Web应用之间的类隔离，以及热部署（修改代码后无需重启服务器）的功能，它为每个Web应用创建了独立的类加载器（WebAppClassLoader）。这些 WebAppClassLoader 在加载类时，会优先加载Web应用自身的类，而不是像双亲委派模型那样先委派给父类（Tomcat的公共类加载器或系统类加载器）。只有当Web应用自身的类加载器找不到时，才会委派给父类。这种“优先自己加载”的策略，有效地打破了双亲委派模型，从而实现了Web应用之间的类隔离，使得不同的Web应用可以使用不同版本的同一个库而互不影响。这是一种非常实用的设计，它牺牲了部分严格的统一性，换取了强大的隔离能力和灵活性。
理解这些“例外”并不是为了否定双亲委派模型，而是为了更全面地认识到，在复杂的系统设计中，有时需要灵活变通，以满足特定的业务需求和架构目标。
