Java反射与动态代理的核心概念与应用

Class.forName() 默认初始化类（执行 static 块），ClassLoader.loadClass() 默认不初始化；Proxy 要求接口因代理类已固定继承 Proxy 且 Java 不支持多重继承；CGLIB 报错多因版本冲突或非必要使用。

反射获取类信息时，Class.forName() 和 ClassLoader.loadClass() 有什么区别

关键区别在于是否触发类的初始化（即是否执行 static 块和静态字段赋值）。Class.forName() 默认会初始化类；ClassLoader.loadClass() 默认不初始化。

• Class.forName("com.example.MyClass")：加载并初始化，适合需要确保静态资源就绪的场景（如 JDBC 驱动注册）
• Thread.currentThread().getContextClassLoader().loadClass("com.example.MyClass")：仅加载，不初始化，适合按需解析、避免副作用
• 若需控制初始化行为，Class.forName(name, false, classLoader) 中第二个参数设为 false 可禁用初始化
• 注意：反射调用 newInstance()（已弃用）或 Constructor.newInstance() 本身不会触发类初始化——初始化只发生在首次主动使用该类时（如访问静态字段、调用静态方法、new 实例等）

为什么 Proxy.newProxyInstance() 要求目标类必须实现接口

Java 动态代理底层基于生成字节码的代理类（如 $Proxy0），而该类是 final 的、且**只能继承 java.lang.reflect.Proxy**。由于 Java 不支持多重继承，它无法再继承你的具体类，因此只能通过实现接口来“拼接”行为。

• 如果你的目标对象没有接口，Proxy.newProxyInstance() 会抛出 IllegalArgumentException: non-interface class
• 替代方案：用 CGLIB（基于子类继承），但它依赖字节码操作库，且不能代理 final 类或 final 方法
• 接口代理天然支持多接口，代理实例的 getClass().getInterfaces() 返回所有被代理的接口数组
• 注意：即使接口方法声明了受检异常，InvocationHandler.invoke() 中抛出未声明异常也不会编译报错，但运行时会包装为 UndeclaredThrowableException

InvocationHandler 中如何安全地转发方法调用

转发不是简单写 method.invoke(target, args) —— 必须处理访问权限、参数类型适配、异常包装等细节，否则容易在运行时报 IllegalAccessException 或 IllegalArgumentException。

• 调用前务必调用 method.setAccessible(true)，否则私有/包级方法会因权限失败
• 原始类型参数（如 int）传入 Object[] 时会被自动装箱，但目标方法若接收基本类型，反射仍能匹配；不过若方法重载存在歧义（如 foo(int

  

  ) 和 foo(Integer)），需显式用 getMethod("foo", int.class) 获取精确签名
• 捕获 InvocationTargetException 并解包其 getCause()，否则业务异常会被套一层包装，日志和断点调试都难定位
• 不要在 invoke() 中直接返回 null 表示 void 方法——void 方法的反射调用返回值本就是 null，无需特殊处理

public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
    if (method.getDeclaringClass() == Object.class) {
        return method.invoke(target, args);
    }
    method.setAccessible(true);
    try {
        return method.invoke(target, args);
    } catch (InvocationTargetException e) {
        throw e.getCause(); // 解包原始异常
    }
}

CGLIB Enhancer.create() 报 NoClassDefFoundError: net/sf/cglib/proxy/Callback

这不是类路径缺失 cglib，而是常见于混合使用了旧版 cglib（2.x）与新版 Byte Buddy 或 Spring（5.2+ 内部已替换为 Byte Buddy）导致的二进制不兼容。Spring Boot 2.2+ 默认不再拉取 cglib，spring-boot-starter-aop 使用的是 spring-aop + aspectjweaver，CGLIB 仅在显式配置 @EnableAspectJAutoProxy(proxyTargetClass = true) 且类无接口时才启用。

• 确认是否真的需要 CGLIB：多数 Spring AOP 场景下，优先走 JDK 动态代理（接口代理），只有加了 proxyTargetClass = true 才强制走 CGLIB
• 若必须用 CGLIB，排除传递依赖中的旧版：mvn dependency:tree | grep cglib，强制指定 cglib-nodep:3.3.0（不含 asm 冲突）
• 更现代的替代：用 ByteBuddy 直接构建子类，API 更清晰，对 Java 版本兼容性更好（如支持 record、sealed class）
• 注意：CGLIB 代理对象的 getClass() 返回的是生成的子类名（如 MyService$$EnhancerByCGLIB$$a1b2c3d4），不是原类名，做类型判断时别用 instanceof MyService 以外的方式

真实项目里最容易忽略的，是反射调用中对泛型擦除的误判，以及动态代理中 toString()、hashCode()、equals(Object) 这三个 Object 方法的默认转发逻辑——它们不走业务切面，却常被日志、缓存、序列化意外触发，造成 NPE 或性能毛刺。