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 根为起点。路径差一个斜杠，结果可能全空
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
