核心在于绕过双亲委派，为每个租户或模块定制独立urlclassloader：重写loadclass优先本地加载租户专属类，系统类仍委派；绑定唯一实例、管理生命周期、切换线程上下文类加载器，并配合spi或序列化隔离第三方依赖。
Java 中实现多租户隔离与多版本第三方依赖共存，核心在于**绕过默认的双亲委派机制，为每个租户或模块定制独立的类加载器**。这不是靠 Spring 或应用框架层面的配置能解决的，必须深入 ClassLoader 层设计隔离边界。
自定义类加载器打破双亲委派
默认的 AppClassLoader 会向上委托给 Bootstrap 和 Extension 加载器，导致所有租户共享同一份 jar（如 commons-lang3-3.12.jar），无法并存 3.12 和 3.14。要解耦，需：
- 继承 URLClassLoader（不推荐直接继承 ClassLoader，避免重复实现资源查找逻辑）
- 重写 loadClass(String name, boolean resolve) 方法：对租户专属包（如 com.tenant.a.*）跳过父加载器，优先本加载器加载；对 java.*、javax.*、sun.* 等系统类仍委派，保障 JVM 稳定性
- 构造时传入租户专属的 URL[]（指向 tenant-a/lib/ 下的 jar），确保类路径物理隔离
租户级类加载器生命周期管理
每个租户应绑定唯一 ClassLoader 实例，且需支持热卸载（如租户下线）：
- 用 WeakReference
缓存加载器，避免 ClassLoader 泄漏（它持有所加载类的 Class 对象，而 Class 持有静态字段，易导致内存泄漏） - 配合 Thread.setContextClassLoader() 在处理租户请求前切换上下文类加载器，确保 new Object()、Class.forName() 等操作命中正确环境
- 卸载时清空其 URL 资源、关闭 JarFile 流，并触发一次 Full GC（虽不能强求回收，但释放引用是前提）
第三方依赖版本冲突的显式隔离策略
仅靠类加载器隔离还不够，需配套约束和工具：
- 禁止跨租户传递非基础类型对象（如不能把 tenant-a 加载的 com.fasterxml.jackson.databind.ObjectMapper 传给 tenant-b 的代码），否则运行时报 ClassCastException: com.fasterxml.jackson.databind.ObjectMapper cannot be cast to com.fasterxml.jackson.databind.ObjectMapper（相同 FQCN 但不同 ClassLoader 加载，JVM 视为不同类）
- 统一使用字符串、Map、JSON 等序列化格式做租户间交互，或通过接口抽象 + SPI 机制（接口由系统类加载器加载，实现类由租户类加载器加载）
- 构建时用 Shade Plugin 重命名敏感依赖（如将 tenant-b 的 guava 重命名为 com.tenant.b.shaded.guava），彻底避免运行时符号冲突
与主流容器协同的关键点
在 Tomcat、Spring Boot 等环境中落地需适配其加载模型：
- Tomcat：利用 WebAppClassLoader 的 delegate=false 配置，再在其基础上扩展租户维度，避免被 Catalina 加载器劫持
- Spring Boot：禁用 spring-boot-devtools（它会干扰类加载器层次），用 @EnableLoadTimeWeaving(aspectjWeaver = false) 避免字节码增强越界
- 慎用 ThreadLocal
存储上下文——异步线程（如 @Async、CompletableFuture）会丢失，必须显式传递或封装工具类透传
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
