类加载隔离解决模块间类冲突问题，通过自定义ClassLoader使同名类在JVM中视为不同类型，实现插件、Web应用、多租户等场景的独立加载与热部署，但需注意跨隔离通信限制。
类加载隔离解决什么问题
Java 默认使用双亲委派模型，同一个类加载器加载的类才能互相识别。如果两个模块都包含 com.example.Service 类，但来自不同 JAR、不同版本，或需独立配置，不隔离就会冲突——比如方法签名不一致、静态变量互相覆盖、初始化顺序错乱。类加载隔离的本质是：让相同全限定名的类，在 JVM 中被视为不同类型，互不影响。
靠自定义 ClassLoader 实现隔离
Java 允许创建多个 ClassLoader 实例，每个实例可定义自己的加载路径和规则。只要两个类由不同的 ClassLoader 加载，哪怕字节码完全一样，JVM 也认为它们是“不同类”。这是隔离的底层机制。
- 每个插件、模块、租户可分配专属 ClassLoader
- 重写 loadClass(String name, boolean resolve)，避免委托给父加载器（打破双亲委派）
- 通常配合 URLClassLoader 或继承 SecureClassLoader 实现资源定位
典型应用场景
OSGi 插件系统：每个 Bundle 拥有独立 ClassLoader，导出/导入包显式声明依赖，实现细粒度类可见性控制。
Web 容器（如 Tomcat）：每个 Web 应用（WAR）使用独立的 WebAppClassLoader，共享 JDK 和容器类（通过父委托），但应用间类完全隔离，避免 Spring 版本冲突或 Log4j 配置干扰。
立即学习“Java免费学习笔记（深入）”；
多租户 SaaS 系统：不同租户加载各自定制的业务逻辑 JAR，类名可能相同，但行为与配置互不干扰。
热部署与动态更新：卸载旧 ClassLoader（配合弱引用+无强引用），加载新版本类，实现不停机升级。
隔离不是万能的，要注意边界
跨隔离边界的对象传递会失败——比如一个模块返回 com.example.User 对象，另一个模块拿不到该类的 Class 对象，强制转型会抛 ClassCastException。
- 推荐用接口或标准数据结构（如 Map、JSON 字符串）通信
- 若必须传领域对象，需统一由“共享类加载器”加载接口定义
- 注意线程上下文类加载器（Thread.currentThread().setContextClassLoader()）在回调中可能引发意外委托
基本上就这些。类加载隔离不是语法特性，而是基于 ClassLoader 机制的设计模式——用对了，解耦灵活；用错了，ClassCastException 和 NoClassDefFoundError 就接踵而至。
