企业官网建设流程全解析

网站可以分为哪些类型,老房装修改造哪家好,镇江网页,磁力蜘蛛种子搜索JVM 双亲委派模型#xff08;Parent Delegation#xff09;详解关键词#xff1a;ClassLoader、类的唯一性、安全、隔离、可替换/可插拔本文讲清楚三件事#xff1a; 双亲委派到底是什么规则#xff08;不是“父类加载器加载”这么一句话#xff09;。为什么 JVM 要这么设…JVM 双亲委派模型Parent Delegation详解关键词ClassLoader、类的唯一性、安全、隔离、可替换/可插拔本文讲清楚三件事双亲委派到底是什么规则不是“父类加载器加载”这么一句话。为什么 JVM 要这么设计安全 统一 隔离。现实里怎么被打破Tomcat / SPI / OSGi / 热部署等以及你排查 ClassLoader 问题的套路。1. 类加载器体系谁负责加载谁JVM 里“把.class变成Class?”的东西叫类加载器ClassLoader。常见三层Bootstrap ClassLoader启动类加载器用 C/C 实现HotSpot 里不是 Java 对象负责加载 JDK 核心类java.*、javax.*部分、jdk.*等类路径典型是jre/lib、jmodsJava 9Platform ClassLoader平台类加载器Java 9负责加载平台模块以前很多rt.jar里拆出来的东西Application ClassLoader应用类加载器负责加载你应用的 classpath-cp/CLASSPATH下的类另外还有自定义 ClassLoaderTomcat、Spring Boot、OSGi、插件框架、脚本引擎等经常自己搞一套。你可以在代码里看看当前环境publicclassLoaderDemo{publicstaticvoidmain(String[]args){ClassLoaderclLoaderDemo.class.getClassLoader();System.out.println(App: cl);System.out.println(Parent: cl.getParent());System.out.println(Grandparent: cl.getParent().getParent());// 通常为 null BootstrapSystem.out.println(String loader: String.class.getClassLoader());// null Bootstrap}}2. 双亲委派模型规则是什么一句话版本“一个类加载请求先交给父加载器父加载器不行才自己来。”更精确一点这个才是真正的“模型”先检查缓存这个 ClassLoader 是否已经加载过这个类避免重复定义。如果有父加载器把加载请求委派给父加载器递归向上。父加载器也加载不了抛ClassNotFoundException子加载器才会尝试调用自己的findClass()来加载。伪代码接近 JDKClassLoader#loadClass的逻辑protectedClass?loadClass(Stringname,booleanresolve)throwsClassNotFoundException{// 1) 已加载Class?cfindLoadedClass(name);// 2) 没加载过先委派父加载器if(cnull){try{if(parent!null){cparent.loadClass(name);}else{cfindBootstrapClassOrNull(name);}}catch(ClassNotFoundExceptione){// 父加载器加载不了走 3)}// 3) 父加载器不行我自己找if(cnull){cfindClass(name);}}if(resolve)resolveClass(c);returnc;}注意这不是“必须”的 JVM 规则而是“JDK 默认 ClassLoader 的实现策略”JVM 规范并不强制你必须委派父加载器。但 JDK 提供的ClassLoader默认实现就是这个策略。你可以通过重写loadClass()来改变这就是“打破双亲委派”的入口。3. 为什么要双亲委派设计动机3.1 安全防止核心类被替换/伪造如果没有委派机制你完全可以在应用 classpath 里放一个java.lang.String让 JVM 加载你的假 String —— 这会直接把安全边界打穿。有了双亲委派加载java.lang.String时应用类加载器先问父加载器父加载器一路到 BootstrapBootstrap 先把真正的java.lang.String加载了你的“假 String”根本没机会出场3.2 一致性同名核心类全 JVM 统一比如java.util.List在整个 JVM 里必须是同一个Class对象不然各种库之间根本没法协作。3.3 隔离不同层次的类彼此隔离又能共享基础能力上层应用依赖下层JDK 核心是常态下层不应该“反向”依赖上层委派天然保证“基础设施”稳定、“业务代码”可变4. 类的唯一性你踩坑多半都在这类在 JVM 中的唯一性不是只看“类的全限定名”而是Class (ClassLoader, FullyQualifiedName)也就是说同名同包的类只要由不同 ClassLoader加载就是两个完全不同的类型。你会看到经典报错java.lang.ClassCastException: A cannot be cast to A或者NoSuchMethodError/LinkageError例子两个不同 Loader 加载同一个字节码Class?c1loader1.loadClass(com.demo.User);Class?c2loader2.loadClass(com.demo.User);System.out.println(c1c2);// falseSystem.out.println(c1.getClassLoader());System.out.println(c2.getClassLoader());5. 什么时候会“打破双亲委派”现实世界双亲委派是默认策略但很多框架/容器为了功能必须“反着来”或“改一点”。5.1 TomcatWeb 应用隔离经典“WebAppClassLoader”需求多个 webapp 运行在同一个 JVM每个应用有自己的WEB-INF/lib不同应用可以用不同版本的同一个库但还得共享 servlet 规范 API做法简化对大多数业务类优先自己加载child-first保证隔离对 servlet/jsp 等容器 API仍然委派父加载器保证共享这就是部分 child-first部分 parent-first。5.2 SPIService Provider Interface父加载器反向用子加载器典型JDBC 驱动历史上尤为经典java.sql.DriverManager是 Bootstrap 或平台类加载器加载的在“父”里驱动实现类com.mysql.cj.jdbc.Driver在应用 classpath在“子”里如果严格双亲委派父加载器看不到子加载器的类DriverManager怎么加载驱动实现解决线程上下文类加载器TCCL, Thread Context ClassLoader让“父层的代码”临时使用“子层的加载器”去加载 SPI 实现获取方式ClassLoadertcclThread.currentThread().getContextClassLoader();很多框架JNDI、JAXP、日志门面等都用过这个套路。5.3 OSGi / 插件化多版本共存、按需可卸载OSGi 直接把“类可见性”做成模块依赖图A bundle 看不见 B bundle 的类除非显式导入/导出版本也能隔离同名包多版本共存这本质上就是一套更复杂的“类加载路由”。5.4 热部署/热加载替换 class比如某些脚本引擎、热更新框架通过“新建一个 ClassLoader”加载新版本 class旧 ClassLoader 及其 Class 变成“不可达”后才能被 GC 回收前提是没有泄漏引用6. 怎么“打破”双亲委派技术手段双亲委派之所以能被破坏是因为你可以重写loadClass()parent-first默认先委派父加载器再自己child-first先自己findClass()找不到再委派父加载器child-first 示例非常简化仅示意publicclassChildFirstClassLoaderextendsClassLoader{publicChildFirstClassLoader(ClassLoaderparent){super(parent);}OverrideprotectedClass?loadClass(Stringname,booleanresolve)throwsClassNotFoundException{synchronized(getClassLoadingLock(name)){Class?cfindLoadedClass(name);if(cnull){try{// 1) 先自己找打破委派cfindClass(name);}catch(ClassNotFoundExceptionignored){// 2) 自己找不到再问父csuper.loadClass(name,false);}}if(resolve)resolveClass(c);returnc;}}OverrideprotectedClass?findClass(Stringname)throwsClassNotFoundException{// 从自定义路径读取字节码然后 defineClass(...)thrownewClassNotFoundException(name);}}现实里不会这么“裸写”一般会配合 jar/目录扫描、缓存、黑白名单哪些包 parent-first哪些包 child-first。7. 排查 ClassLoader 问题的实战套路7.1 先看“谁加载的”任何诡异的类型转换/方法找不到第一件事System.out.println(SomeClass.class.getClassLoader());System.out.println(SomeInterface.class.getClassLoader());如果你看到接口由 A loader 加载实现类由 B loader 加载那基本就能解释很多ClassCastException。7.2 典型症状 - 典型原因ClassCastException: X cannot be cast to X99% 是不同 ClassLoader 加载了同名类NoSuchMethodError/NoSuchFieldError常见是依赖冲突编译时用的版本和运行时实际加载版本不一致也可能是类加载顺序导致“加载到了旧版本”LinkageError: loader constraint violation两个 loader 对同一个符号引用约束不一致复杂但本质还是类型不统一7.3 Tomcat / Spring Boot 常见坑web 容器里重复放了同一个 jarWEB-INF/lib 容器 shared libfat jar / 多层 classpath 导致版本 shadowing日志框架slf4j / logback / log4j2多实现共存导致冲突8. 一张图把双亲委派讲明白loadClass(com.demo.Foo) | ----------v----------- | AppClassLoader | --------------------- | 委派给 parent | ----------v----------- | PlatformClassLoader | --------------------- | 委派给 parent | ----------v----------- | BootstrapClassLoader | --------------------- | 找到/加载? yes - 返回 | no (CNF) | 回到子加载器 findClass()9. 记住这几句就够用了默认就是 parent-first先父后子。核心目的安全 一致性。类唯一性(ClassLoader, 类名)不是只有类名。打破委派的原因隔离、多版本、插件化、SPI。排查第一步打印getClassLoader()看是不是“同名不同 loader”。10. 延伸阅读建议想深入的话可以按这个顺序看java.lang.ClassLoader源码loadClass / findClass / defineClassTCCLThread#getContextClassLoaderTomcat ClassLoader 架构Common / Catalina / Shared / WebApp