双亲委派机制不自动避免包名和类名冲突，而是通过强制统一加载源头暴露冲突；真正起作用的是加载路径唯一性与委派顺序确定性，即同一类加载器不重复定义同名类，且子加载器必须先委托父加载器加载。
Java 类加载机制中，包名和类名冲突（比如两个 JAR 都含 com.fasterxml.jackson.databind.ObjectMapper）不是靠双亲委派“自动避免”的，而是靠它强制统一加载源头来暴露并限制冲突——真正起规避作用的是加载路径的唯一性和委派顺序的确定性。
关键点在于：JVM 不允许同一个类加载器重复定义同名类；而双亲委派确保了谁有资格最先定义它。
包名+类名冲突的本质是“同名类被不同加载器加载”
当两个模块各自打包了 com.example.User，或依赖了不同版本的 Jackson，就可能出现：
- 编译时用的是 v2.15 的
ObjectMapper - 运行时加载的是 v2.12 的
ObjectMapper（因为旧版 JAR 被父加载器先加载了） - 结果抛
NoSuchMethodError或字段缺失
这不是“没避免”，而是双亲委派已生效，但你没控制好委派链的起点和内容。
立即学习“Java免费学习笔记（深入）”；
如何利用双亲委派机制减少这类冲突
✅ 控制类加载的“入口加载器”层级
- 应用类默认由 AppClassLoader 加载，它会把
java.*、javax.*委派给 Bootstrap/Ext，把业务类留给自己。 - 如果你把多个含同名类的 JAR 全丢进 classpath，AppClassLoader 会在自己的 URL 列表里按顺序扫描 —— 谁在前，谁的类就被先加载（不跨加载器），这就隐含了优先级。
举例：
jackson-databind-2.15.jar放在jackson-databind-2.12.jar前面，且两者都由 AppClassLoader 加载 → 2.15 版本胜出。
✅ 禁止子加载器覆盖父加载器已加载的类
- Bootstrap 和 Ext 加载器加载的类（如
java.lang.String、javax.servlet.http.HttpServlet）不可能被你的自定义类覆盖。 - 因为双亲委派要求：子加载器必须先问父加载器“你有没有？”，父加载器一旦返回 Class 实例，子加载器直接用，不再调用
findClass()。
所以只要核心类/标准 API 类不被你打进业务包，就不会出现
java.util.List被你重写导致崩溃的情况。
✅ 用独立类加载器隔离冲突来源（主动打破委派）
当确实需要共存不同版本（如插件系统加载不同版 MySQL 驱动）：
- 创建新
URLClassLoader(urls, null)，显式切断父委派 - 或重写
loadClass()：只对java./javax./sun.等安全包才委派，其余全由自己findClass() - 这样
com.mysql.cj.jdbc.Driver就不会被 AppClassLoader 提前加载，避免版本错位
注意：不是“避免冲突”，而是“把冲突关进沙盒”——每个插件用自己加载器，互不看见对方的同名类。
真正该做的：别等双亲委派救你，先从构建阶段掐断源头
- 用
mvn dependency:tree -Dverbose查重复引入，加<exclusion></exclusion>干掉传递依赖里的老版本 - 统一声明关键依赖版本（如 Spring Boot 的
spring-boot-dependenciesBOM） - 避免在多个模块中定义相同包结构的类（如
com.mycompany.dto.User出现在 service 和 api 两个 jar 中） - 构建 fat jar 时确认依赖顺序，或用
maven-shade-plugin重定位（relocation）第三方包
双亲委派本身不解决“我引入了两个 Jackson”，它只保证“一旦某个加载器加载了 Jackson，其他同级加载器就不能再加载同名类”。冲突是否发生，取决于你把哪些字节码放到了哪个加载器的视野里。
