父加载器看不到子加载器加载的类是JVM主动设计的命名空间隔离机制，由双亲委派模型保障，旨在确保安全性、模块边界和避免循环依赖；验证现象包括Class.forName失败和ClassCastException；需反向访问时应使用线程上下文类加载器。
父加载器看不到子加载器加载的类，不是技术实现上的“做不到”，而是 JVM 主动设计的可见性限制——它由类加载器的命名空间隔离机制和双亲委派模型共同保障，核心目的是安全与稳定。
可见性限制的本质是命名空间隔离
每个类加载器实例在 JVM 方法区中拥有独立的命名空间。它只认自己加载过的类，以及通过 parent 链向上委托成功加载的类。子加载器加载的类被登记在它自己的命名空间里，父加载器既不维护该命名空间，也无法遍历或查询它。
- 比如 Tomcat 中，两个 WebApp 各用一个
WebAppClassLoader实例，即使都加载了com.example.User，它们在 JVM 中是两个完全无关的 Class 对象。 - AppClassLoader（应用类加载器）查不到你用自定义加载器加载的
MyService，不是因为它“找不到路径”，而是它压根没权限进入那个命名空间。
为什么不能反向开放？三大刚性约束
允许父加载器访问子加载器的类，会直接冲击 JVM 的根基：
-
破坏核心类安全性：若 AppClassLoader 能随意使用某个 Web 容器加载器提供的
java.util.ArrayList替代版本，JDK 基础行为就可能被绕过或篡改。 - 瓦解模块边界：Spring Boot DevTools 的热重载、OSGi 的 bundle 隔离、甚至多租户 SaaS 应用，都依赖这种单向可见性来防止静态变量共享、版本冲突或意外覆盖。
- 诱发循环依赖死锁：A 加载器的类调用 B 加载器的类，B 又反射调用 A 的类——双亲委派下能靠向上委托化解；一旦允许反向访问，类解析过程可能陷入无法判定依赖顺序的僵局。
怎么验证这个限制？两个典型现象
运行时表现非常明确，不需要源码也能观察：
- Class.forName("xxx") 报 ClassNotFoundException：当前线程上下文类加载器（通常是 AppClassLoader）尝试主动加载子加载器的类，失败——因为不在这条 parent 链上。
- 类型转换异常（ClassCastException）：同一个类名，由不同加载器加载后，在方法参数或返回值中混用，JVM 认为它们是不同类，强制转型必抛异常。
那需要父用子类时怎么办？ContextClassLoader 是标准解法
当高层组件（如 JDBC DriverManager）需加载低层实现（如 MySQL Driver），JVM 提供了绕过双亲委派的“协商通道”：
- 线程启动时，默认把当前应用类加载器设为 context class loader；
- 框架代码显式调用
Thread.currentThread().getContextClassLoader().loadClass(...)，等于把加载权临时“下放”给子加载器； - 这不破坏原有模型，只是在特定场景下补充一条可控的反向路径。
