ClassLoader本身不解决版本冲突，而是通过类加载器隔离机制使不同ClassLoader加载的同名类视为独立类型，其唯一性由“全限定名+ClassLoader实例”共同决定。
Java 类加载器本身不“解决”版本冲突，而是通过类加载隔离机制让不同版本的同名类共存——前提是它们由不同的类加载器实例加载。关键在于：JVM 认为“类的唯一性 = 全限定类名 + 加载它的 ClassLoader 实例”。所以哪怕两个类字节码完全一样、包名类名一模一样，只要加载它们的 ClassLoader 不是同一个实例，JVM 就视其为两个独立类型，互不干扰。
靠隔离而非覆盖
传统依赖管理（如 Maven）只能选一个版本放进 classpath，导致旧代码调用新方法时抛 NoSuchMethodError，或新代码用旧类时出 IncompatibleClassChangeError。ClassLoader 的思路不是去“选一个”，而是“各用各的”：
- 插件模块用独立的
URLClassLoader加载自己的 JAR，含自己版本的 Guava、POI 等 - Web 应用在 Tomcat 中由
WebAppClassLoader加载/WEB-INF/lib下的库，与共享库（lib目录）物理隔离 - OSGi 或自定义 ClassLoader + 接口契约，实现模块间只依赖抽象（如
ExcelProcessor），不感知具体实现类路径
必须配合接口和调用边界
光换 ClassLoader 不够，否则仍会因静态引用、线程上下文或硬编码加载器引发泄漏：
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 不能让 A 模块的类直接 new B 模块的实现类——要用反射或统一接口工厂
- 避免在已加载类中访问跨 ClassLoader 的静态字段或调用其静态方法
- 显式设置
Thread.currentThread().setContextClassLoader()仅影响后续Class.forName(...)等委托行为，不影响MyClass.class.getClassLoader()这种硬绑定
比 ClassLoader 更轻量的替代方案
对多数业务项目，定制 ClassLoader 成本高、易出错。更务实的做法是提前规避冲突：
立即学习“Java免费学习笔记（深入）”；
-
Shaded Jar + 包重命名：用 Maven Shade Plugin 把 Guava 重定位成
com.yourapp.shaded.guava，彻底脱离原始包名空间 - jarjar 工具：在打包前批量改写字节码中的内部引用，适合嵌入式或 SDK 场景
-
依赖收敛 + exclusion：用
mvn dependency:tree -Dincludes=groupId:artifactId定位冲突源，显式排除低版本传递依赖
排查与验证手段
运行时确认是否真隔离成功，不能只看编译通过：
- 加 JVM 参数
-verbose:class，观察报错类究竟从哪个 JAR 加载 - 打印类的 ClassLoader：
MyClass.class.getClassLoader()，对比不同模块实例是否不同 - 捕获 ClassCastException（如
A$Service cannot be cast to A$Service）——这是典型“同一类被两个 ClassLoader 加载”的信号
