Java类加载需理解加载器行为与运行现象的映射关系：一查加载器链与路径，二验证双亲委派及打破方式，三通过三个实验掌握类加载唯一性、多加载器隔离性及资源路径差异。

Java 类加载不是“背概念”，而是要能看懂行为、预判结果、动手验证。通关演练的关键，不是记住七个阶段的名称，而是建立**加载行为—类加载器—运行现象**之间的映射关系。下面直击实战要点，分三步带你真正“通关”。

一、先搞清“谁在加载？从哪来？”

每次 new 一个对象、调用静态方法、访问静态字段，JVM 都会触发类加载——但真正干活的是哪个类加载器？它从哪找 .class 文件？

• 查加载器链：用 MyClass.class.getClassLoader() 查当前类由谁加载；再用 .getParent() 逐级向上，直到返回 null（即 Bootstrap）
• 看加载路径：
  • System.getProperty("sun.boot.class.path") → Bootstrap 加载范围（如 rt.jar）
  • System.getProperty("java.ext.dirs") → ExtClassLoader 路径
  • System.getProperty("java.class.path") → AppClassLoader 的 classpath（含 jar 和目录）
• 注意陷阱：String、Object 等核心类永远由 Bootstrap 加载，返回 null；自定义类默认由 AppClassLoader 加载，除非你显式用了新加载器

二、重点验证“双亲委派是否生效？”

双亲委派不是理论，是可观察、可打破、可调试的行为。关键验证点：

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

• 复现委派过程：写一个类 com.example.MyUtil，把它打包进 mylib.jar，再放到 $JAVA_HOME/jre/lib/ext/ 下。运行时你会发现——它被 ExtClassLoader 加载，而不是你的 AppClassLoader。这就是委派在起作用
• 主动打破委派：重写 loadClass(String, boolean)，把 super.loadClass(...) 调用去掉，改为直接调用 findClass(...)。这时你就能让子加载器优先加载，绕过父加载器（典型用于热替换、插件隔离）
• 验证冲突根源：出现 NoClassDefFoundError 时，别急着加 jar；先用 -verbose:class 启动 JVM，看日志里“[Loaded xxx from …]”那行——它告诉你类到底是谁加载的、从哪来的，往往问题就出在这里

三、动手做三个最小闭环实验

每个实验 5 分钟内可完成，但能打通关键认知断点：

• 实验1：类只加载一次
  写一个类 Counter，含静态变量 count = 0 和静态块 count++；在 main 中连续 Class.forName("Counter") 三次，打印 count ——结果是 1，不是 3。说明类加载有缓存，且初始化只执行一次
• 实验2：不同加载器可加载同名类
  写两个相同包名+类名的 Worker.class（内容不同），用两个自定义 ClassLoader 分别加载它们。然后分别 newInstance()，你会发现它们是不同 Class 对象，彼此不兼容（instanceof 返回 false）
• 实验3：getResourceAsStream 路径真相
  在 resources 目录放 config.properties，用 getClass().getResourceAsStream("/config.properties") 和 getClass().getClassLoader().getResourceAsStream("config.properties") 对比——前者以类所在路径为基准，后者以 classpath 根为起点。路径差一个斜杠，结果可能全空

不复杂但容易忽略