Java类加载机制与反射机制分属不同层面：前者是JVM将.class载入内存并生成Class对象的过程，含加载、链接（验证/准备/解析）、初始化三阶段；后者是运行期通过Class对象操作类结构的能力，依赖类加载结果。
Java类加载机制和反射机制不是同一层面的概念，不能混为一谈：类加载机制是JVM在运行时把.class文件载入内存并生成Class对象的过程；反射机制则是程序在运行期通过已有的Class对象去获取类结构、调用方法或访问字段的能力。二者有依赖关系——没有类加载，就没有Class对象；没有Class对象，反射就无从谈起。
类加载的三个阶段：加载、链接、初始化
类加载不是“读完字节码就完事”，而是严格分阶段推进：
- 加载（Loading）：通过类全限定名定位
.class文件（可能来自本地磁盘、JAR、网络甚至动态生成），读取字节码，生成java.lang.Class对象。此时类还未进入方法区，也未分配静态变量内存。 - 链接（Linking）又分三步：
– 验证：检查字节码是否符合JVM规范（如魔数、版本号、常量池结构）；
– 准备：为类变量（static字段）分配内存并设默认值（如int→0，Object→null），但不执行static块或赋值语句；
– 解析：将符号引用（如MyClass.methodName）替换为直接引用（如内存地址）。 - 初始化（Initialization）：真正执行类构造器
static字段赋值、static代码块。这是类加载过程的最后一步，也是唯一允许用户代码介入的阶段。
反射获取Class对象的三种方式及区别
反射操作的前提是拿到Class对象，但不同获取方式触发的类加载行为不同：
Class.forName("com.example.Foo")：会触发类的初始化（即执行static块），因为其默认调用forName(String, true, ClassLoader)，第二个参数为true。Foo.class：不会触发初始化，仅完成加载和链接；适用于编译期已知类名的场景，性能最好。fooInstance.getClass()：同样不触发初始化，但要求已有实例；注意它返回的是运行时实际类型（可能为子类），不是声明类型。
常见错误：用Class.forName()加载工具类时意外执行了其static初始化逻辑（比如注册驱动、启动线程），导致副作用或阻塞。
反射调用方法/字段时的权限与性能代价
反射绕过编译期访问控制，但运行期仍受安全管理器（如果启用）约束，且有明显开销：
- 调用
setAccessible(true)可无视private修饰符，但JDK 12+对关键系统类（如java.lang.String）限制更严，可能抛InaccessibleObjectException。 - 反射调用比直接调用慢约3–5倍（HotSpot JVM优化后），主要因跳过内联、丢失类型推导、需额外安全检查；频繁调用建议缓存
Method或Field对象，避免重复getDeclaredMethod()查找。 - 泛型擦除导致反射无法获取泛型实际类型参数（如
List<String>在运行时只剩List），需借助ParameterizedType从字段或方法签名中间接提取。
类加载器双亲委派模型的实际破绽
双亲委派不是强制规范，而是JDK推荐模型；打破它不难，但容易引发ClassNotFoundException或LinkageError：
- 自定义
ClassLoader重写loadClass()时，若跳过super.loadClass()直接findClass()，可能导致同一个类被不同类加载器重复加载，造成instanceof失效、ClassCastException（例如两个org.json.JSONObject类虽同名同包，但属于不同ClassLoader实例）。 - OSGi、Spring Boot Fat Jar、Tomcat都打破了双亲委派：前者用“平级委托”隔离模块，后者用
LaunchedURLClassLoader优先从BOOT-INF/classes加载，避免与JRE自带类冲突。 - 热部署、插件化场景下，必须显式管理类加载器生命周期，否则旧
Class对象残留会导致内存泄漏（ClassLoader持有着所有已加载类的静态引用）。
真正棘手的从来不是“怎么写反射”或“怎么写自定义类加载器”，而是弄清某段代码里Class对象究竟由谁加载、是否已被初始化、以及它和当前线程上下文类加载器（Thread.currentThread().getContextClassLoader()）的关系——这三个问题没理清，90%的类加载和反射相关故障都解不开。
