双亲委派机制是类加载器间的协作约定，确保核心类由BootstrapClassLoader加载以避免替换；它不提供加密或字节码校验，也非自动安全开关。
双亲委派机制不是Java的“安全开关”，而是类加载器之间的协作约定
它不自动防止恶意代码，也不加密或校验字节码；它的作用是通过固定加载顺序，让核心类（比如 java.lang.String）只能由 BootstrapClassLoader 加载，避免被用户自定义类加载器替换——这才是“安全”的实际含义。
常见错误现象：NoClassDefFoundError 或 ClassCastException 在模块间传递对象时突然出现，往往是因为两个类加载器各自加载了同名类，JVM 视为不同类型。
- 所有自定义类加载器必须重写
loadClass()时先调用parent.loadClass(name)，不能直接覆盖默认逻辑 - 想绕过双亲委派？只有在
findClass()阶段自己读取字节码并调用defineClass()，但loadClass()里仍要保留委托链 - OSGi、Tomcat、Spring Boot 的
LaunchedURLClassLoader都是显式打破双亲委派的典型，但它们各自实现了更细粒度的隔离规则，不是简单“禁用”
为什么 Thread.getContextClassLoader() 经常成为破环双亲委派的入口
很多框架（如 JDBC、JAXB、SLF4J）依赖线程上下文类加载器去加载用户提供的实现类，而这个加载器通常是 AppClassLoader 或自定义加载器，它和当前类的加载器（可能是 BootstrapClassLoader）不在同一条委托链上。
使用场景：你写了一个数据库驱动 com.example.MyDriver，放在 WEB-INF/lib 下，但 java.sql.DriverManager 是 Bootstrap 加载的，它必须通过 Thread.currentThread().getContextClassLoader() 去找你的驱动类。
立即学习“Java免费学习笔记（深入）”；
- 不要在静态初始化块或
ClassLoader.getSystemClassLoader()中硬编码加载业务类——它可能找不到你放的 jar - Web 应用中，
ServletContext.getClassLoader()和Thread.currentThread().getContextClassLoader()通常一致，但不能假设永远相等 - Spring Boot 的
LaunchedURLClassLoader把BOOT-INF/classes和BOOT-INF/lib加入自己的路径，但它仍把parent设为AppClassLoader，所以对java.*还是委托上去
defineClass() 和 findClass() 的分工容易混淆
defineClass() 是 JVM 提供的本地方法，负责把字节数组转成 Class 对象，它不做任何验证，也不触发链接；findClass() 是模板方法，由子类实现“从哪读字节码”，然后交给 defineClass() 处理。
错误写法：loadClass() 里直接 new 字节数组再 defineClass()，跳过了委托，也绕过了双亲委派检查。
- 正确流程：重写
findClass(String name)→ 读取字节码 → 调用defineClass(name, b, off, len)→ 返回Class -
defineClass()不会解析常量池、不校验签名，这些在后续链接阶段才做；如果字节码非法，会在resolveClass()或首次使用时抛VerifyError - 自定义类加载器若需热替换，必须确保旧
Class实例已无引用，否则defineClass()生成的新类无法被 GC，容易 OOM
模块系统（JPMS）下双亲委派基本失效，但替代机制更严格
JDK 9+ 引入模块后，ClassLoader 不再是唯一类来源，ModuleLayer 和 Configuration 控制哪些模块能看见哪些包。此时 loadClass() 可能返回 ClassNotFoundException，不是因为没委托，而是模块未导出或未读取。
典型报错：java.lang.NoClassDefFoundError: javax/xml/bind/annotation/XmlRootElement —— 不是类加载器问题，是 java.xml.bind 模块默认不开启，且未加到 --add-modules。
- 模块路径（
--module-path）上的 jar 不进AppClassLoader，而是由ModuleClassLoader管理，它不参与传统双亲委派 -
Class.forName("xxx")默认使用当前类的类加载器，不是上下文类加载器；跨模块反射需显式用Module.addOpens() - Spring Boot 2.3+ 默认排除
javax.*相关 starter，就是为适配 JPMS 的模块拆分，不是“兼容性补丁”
真正难处理的，是双亲委派与模块系统的交界处：比如一个模块内定义了服务接口，另一个模块提供实现，而类加载器链和模块读取关系不一致，这时 ServiceLoader 就可能找不到实现类——这已经不是“要不要委托”的问题，而是“谁有权限看到谁”的问题。
