双亲委派模型解决了安全性、类重复加载和命名空间冲突三个核心问题。其通过将类加载请求优先委托给父加载器，直到启动类加载器，确保核心类库由最可信的加载器加载，防止恶意代码替换系统类；同时避免同一类被多次加载，保证类的一致性和内存效率；并通过类加载器的层级结构隔离不同来源的类，解决命名空间冲突。jvm类加载器体系分为bootstrap classloader（负责加载核心类库）、extension classloader（加载扩展类库）和application classloader（加载应用类路径），并支持自定义类加载器。该模型在spi机制、web服务器类隔离等场景下会被打破或自定义，如通过线程上下文类加载器加载spi实现，或tomcat重写loadclass方法实现应用间类隔离，而自定义类加载器通常继承classloader并重写findclass方法，以实现动态加载、加密类解密或远程加载等功能。
JVM类加载机制的双亲委派模型，本质上是一种分层、安全的类加载策略。它规定了类加载器在加载一个类时，会优先将加载请求委托给父加载器，直到顶层的启动类加载器。只有当父加载器无法加载该类时，子加载器才会尝试自己去加载。这确保了核心类库的统一性和安全性，避免了类的重复加载和恶意代码的植入。
这个模型的核心逻辑其实很简单，但又极其精巧。当你需要加载一个类A时，当前的类加载器并不会立刻去自己的路径下找这个类。它会先“问”自己的父加载器：“老爸，你能加载这个类A吗？” 如果父加载器还有父加载器，这个请求就会一直向上递交，直到最顶层的启动类加载器（Bootstrap ClassLoader）。只有当某个父加载器明确表示“我加载不了这个类A”时，请求才会回退到它的子加载器，由子加载器尝试在自己的搜索路径下加载。如果子加载器也加载失败，才会继续回退到更底层的加载器。整个过程就像一个倒金字塔的查找过程，确保了像java.lang.Object这样的核心类始终由最受信任的启动类加载器加载，防止被用户自定义的同名类替换掉，从而维护了JVM运行环境的稳定和安全。这种“先问爹妈，爹妈不行自己再来”的模式，有效地解决了类加载的隔离性、命名空间冲突以及安全性问题。
双亲委派模型解决了哪些核心问题？
说实话，每次讲到JVM类加载，我脑子里首先浮现的就是那个严谨又有点“固执”的双亲委派模型。我个人觉得，这个模型最精妙的地方，就在于它把安全性和效率做到了一个相当好的平衡。它主要解决了几个核心问题：
第一个是安全性。想象一下，如果没有这个机制，你的应用程序里可能会出现两个甚至更多个java.lang.Object，那简直是灾难。恶意代码可能通过自定义一个java.lang.Object来劫持系统行为，这在沙箱安全模型下是绝对不允许的。双亲委派模型确保了核心类库（如java.lang.*）总是由最顶层的启动类加载器加载，这样就从根本上杜绝了这种安全隐患。它就像一个看门人，只允许“官方”的类进入核心区域。
第二个是避免重复加载。在一个大型复杂应用中，同一个类可能被多个地方引用，如果没有一套统一的加载机制，很容易出现内存中存在多个相同类的副本，这不仅浪费内存，还会导致类型转换异常等运行时问题。双亲委派模型通过委托机制，保证了每个类在JVM中只会加载一次。当父加载器已经加载过某个类时，子加载器就无需再次加载，直接使用父加载器加载的那个实例就行。这对于维护类的一致性、避免潜在的运行时错误至关重要。
JVM类加载器体系结构是怎样的？
要理解双亲委派，就得先弄清楚JVM里都有哪些“爹妈”和“孩子”。JVM的类加载器体系其实是分层的，主要有这么几种：
-
启动类加载器 (Bootstrap ClassLoader)：这是最顶层的加载器，由C++实现，它不是
java.lang.ClassLoader的子类。它负责加载JAVA_HOME/jre/lib目录下，或者被-Xbootclasspath参数所指定的路径中的核心类库，比如rt.jar（包含java.lang.*、java.util.*等）。它没有父加载器，可以说它是所有类加载器的“祖宗”。 -
扩展类加载器 (Extension ClassLoader)：这个加载器负责加载
JAVA_HOME/jre/lib/ext目录下的JAR包，或者被java.ext.dirs系统属性所指定的路径中的类库。它是由sun.misc.Launcher$ExtClassLoader实现的，它的父加载器就是启动类加载器。 -
应用程序类加载器 (Application ClassLoader)：也叫系统类加载器，它负责加载用户类路径（
CLASSPATH）上所指定的JAR包或目录中的类。我们平时写的大部分Java应用代码，都是由这个加载器加载的。它是由sun.misc.Launcher$AppClassLoader实现的，它的父加载器是扩展类加载器。你可以通过ClassLoader.getSystemClassLoader()获取到它。
除了这三种，我们还可以自定义类加载器，它们通常会以应用程序类加载器作为父加载器，或者自己指定一个。整个结构就像一个树状，每个节点都向上委托，直到根节点。
双亲委派模型在哪些场景下会被“打破”或自定义？
虽然双亲委派模型是JVM类加载的基石，但它并不是万能的，在某些特定场景下，我们确实需要“打破”它或者进行自定义。这听起来有点反常识，但确实是解决特定问题的有效手段。
一个最常见的“打破”场景是SPI (Service Provider Interface) 机制。比如JDBC驱动、JNDI等。这些接口定义在JDK核心库中（由启动类加载器加载），但它们的具体实现却是由第三方厂商提供的JAR包（由应用程序类加载器加载）。按照双亲委派，核心类库是看不到用户路径下的实现的。为了解决这个问题，JDK引入了线程上下文类加载器 (Thread Context ClassLoader)，通过Thread.currentThread().setContextClassLoader()来设置。核心类库在需要加载SPI实现时，会使用当前线程的上下文类加载器去加载，而不是它自身的父加载器。我记得有次调试一个老项目，就是因为Context ClassLoader的问题导致依赖冲突，那真是折腾了一晚上。
另一个典型例子是Web服务器（如Tomcat）的类加载器隔离机制。Tomcat为了实现不同Web应用之间的类隔离，每个Web应用都有一个独立的类加载器。这些Web应用自己的类加载器会优先加载Web应用内部的类，而不是先委托给父加载器（应用程序类加载器）。这允许不同应用使用不同版本的同一个库，互不干扰。这种“打破”通常是通过自定义loadClass方法来实现的，比如Tomcat的WebAppClassLoader就重写了loadClass，在某些情况下会先尝试自己加载。
至于自定义类加载器，我们通常不是为了“打破”委派模型，而是为了扩展它的能力。比如：
- 动态加载和卸载类：在运行时加载或卸载特定的类，这在热部署、插件化开发中非常有用。
-
加密和解密类文件：在加载前对加密的
.class文件进行解密。 - 从网络加载类：实现远程类加载，这在早期的Applet中很常见。
自定义类加载器时，我们通常会继承java.lang.ClassLoader，然后重写findClass(String name)方法。在这个方法里，我们定义自己的类查找逻辑（比如从特定路径、网络、数据库等）。而loadClass(String name, boolean resolve)方法则保留了双亲委派的逻辑，它会先调用父加载器的loadClass，如果父加载器无法加载，才会调用我们重写的findClass。当然，实际操作中，我们很少直接去改loadClass，那太危险了，通常是重写findClass，保持双亲委派的安全性，只在自己负责的范围内进行加载。
