动态代理的“动态性”本质依赖类加载机制：Proxy.newProxyInstance()在内存生成字节码后，必须经ClassLoader的defineClass()加载为Class对象，完整经历加载、验证、准备、解析、初始化五阶段，且加载器需能访问被代理接口，体现双亲委派约束与JVM类加载开放性的直接应用。
动态代理和类加载机制在 Java 中紧密耦合——动态代理的“动态性”本质上依赖于类加载机制在运行时完成字节码到 Class 对象的转换。
动态代理需要运行时生成并加载新类
Java 的 Proxy.newProxyInstance() 不是直接使用已有的 class 文件，而是根据传入的接口数组，在内存中生成符合 JVM 字节码规范的代理类二进制数据（比如形如 $Proxy0.class 的字节流），然后必须通过类加载器将其加载为 Class 对象，才能创建实例。这个过程跳过了磁盘文件阶段，但依然完整走完类加载的五个阶段：加载 → 验证 → 准备 → 解析 → 初始化。
- 加载阶段：由指定的
ClassLoader调用defineClass()方法，把生成的字节码数组注册为一个合法的Class实例 - 验证与解析：JVM 确保字节码结构合规，并将符号引用（如接口方法名）解析为实际内存地址
- 初始化：执行代理类的静态代码块（虽然 JDK 动态代理生成的类通常没有静态初始化逻辑）
类加载器选择直接影响代理能否成功
调用 newProxyInstance() 时必须显式传入 ClassLoader，它决定了代理类由谁来加载。这个加载器需能“看见”所有被代理的接口——否则会抛出 IllegalArgumentException: interface is not visible from class loader。
- 若接口由应用类加载器加载，代理也必须用同一个或其子加载器（不能用启动类加载器，因其无法访问用户路径下的类）
- 双亲委派模型在此处起约束作用：父加载器看不到子加载器加载的类，所以不能随意混用加载器
- Web 容器或 OSGi 环境中，常因类加载器隔离导致代理失败，本质是接口与代理类不在同一命名空间
动态代理是类加载机制能力的典型体现
它不是语法糖，而是对 JVM 类加载开放性的直接利用。除了 JDK 原生基于接口的代理，CGLIB、Javassist 等框架更进一步：它们直接操作字节码（如修改已有类的字节流），再交由自定义类加载器加载，从而实现对具体类的代理——这完全建立在“类可以在运行时被构造并加载”这一底层能力之上。
立即学习“Java免费学习笔记（深入）”；
- 没有类加载机制的可扩展性（如
defineClass()可被子类重写），就没有真正的动态性 - 反射（
Method.invoke）、注解处理、热部署等高级特性，也都共享这一基础
说到底，动态代理不是游离于类加载之外的黑盒，它是类加载机制在业务层最常用、最直观的一次落地实践。
