JDK动态代理原理：调用代理对象方法为何会先进入InvocationHandler.invoke？

如果你读过Spring AOP、MyBatis的Mapper代理或者自己写过一段Proxy.newProxyInstance的小Demo，大概率会产生同一个疑问：我明明调用的是业务对象的方法，为什么断点一打，代码最先停在了handler.invoke方法里？尤其是看调用栈时，栈顶往往是com.sun.proxy.$Proxy0.xxx()，下一秒就切到了InvocationHandler.invoke()，看起来就像所有方法都被什么东西拦了一道。

标题里写的“对应方式”我理解成“对应方法”。其实这个现象并不神秘，真正的原因是：**代理对象内部根本没有你写的那个业务方法体，它是JDK在运行时“造”出来的一个类，造的时候就把所有方法体都写成了转发给handler.invoke。**所以不是“先经过”某个拦截器，而是代理类的方法体本身就是一段“转交代码”。这篇文章我从newProxyInstance怎么做、字节码长什么样、invoke里的递归坑，到框架里为什么依赖这套机制，一次性讲清。

1. newProxyInstance背后：代理类是在运行时被“造”出来的

1.1 先跑一个最简Demo

要理解为什么先进handler.invoke，先看最基础的用法。我经常用下面这段代码演示：

java复制public class ProxyDemo {

    interface Greeting {
        String greet(String name);
    }

    static class GreetingImpl implements Greeting {
        @Override
        public String greet(String name) {
            return "hello, " + name;
        }
    }

    static class LogInvocationHandler implements InvocationHandler {
        private final Object target;

        public LogInvocationHandler(Object target) {
            this.target = target;
        }

        @Override
        public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
            System.out.println("before: " + method.getName());
            Object result = method.invoke(target, args);
            System.out.println("after: " + method.getName());
            return result;
        }
    }

    public static void main(String[] args) {
        Greeting target = new GreetingImpl();
        Greeting proxy = (Greeting) Proxy.newProxyInstance(
                Greeting.class.getClassLoader(),
                new Class<?>[]{Greeting.class},
                new LogInvocationHandler(target));

        proxy.greet("world");
    }
}

运行结果是：

code复制before: greet
after: greet

这个输出顺序已经能说明问题：proxy.greet("world")这一句，实际执行的并不直接是GreetingImpl.greet()。先执行的是LogInvocationHandler.invoke()里的逻辑，然后才是反射调用目标对象的方法。

1.2 三要素缺一不可

Proxy.newProxyInstance(ClassLoader loader, Class<?>[] interfaces, InvocationHandler h)里面三个参数，每个都有不可替代的作用：

其中最关键的理解点是：第三个参数h并不是什么“切面管理器”，而是代理类实例内部会保存的一个字段。Proxy.newProxyInstance在底层拿到代理类的Class后，会用这个Class的构造器把h传给代理实例。代理类内部保存这个h，方法被调用时，方法体就去找h.invoke。

1.3 代理类不是每次调用现场生成的

很多人以为代理对象是调用时动态生成的一个轻量包装。实际上JVM第一次遇到某一组接口时，会生成一个真正的.class文件对应的字节码，然后通过类加载器defineClass成一个类。以后同样接口组合的代理类会从缓存里取，不会每次重新生成。

代理类名字通常是com.sun.proxy.$Proxy0、$Proxy1这样的递增序号。同一组接口、同一个类加载器，对应同一个代理类。接口顺序不同也会影响缓存key，例如new Class<?>[]{A.class, B.class}和new Class<?>[]{B.class, A.class}会被当成不同的key。

现在你可以理解这句话：代理对象就是一个普通对象，只不过它的类是由JDK生成出来的，类里的方法完全不是业务实现，而是转发到handler的入口。

2. 反编译代理类：方法体里根本没有业务逻辑，只有一行invoke转发

2.1 怎么把生成的代理类导出来

Java本身提供过导出代理类文件的开关。JDK 8里常见写法是：

java复制System.setProperty("sun.misc.ProxyGenerator.saveGeneratedFiles", "true");
Proxy.newProxyInstance(...);

执行后项目目录下会出现类似com/sun/proxy/$Proxy0.class的文件。不同JDK版本这个开关名字略有差异，新版JDK可能需要找jdk.proxy.ProxyGenerator.saveGeneratedFiles之类的参数，不过目的都一样：把JVM内存中生成的字节码落盘，方便我们用javap分析。

拿到class后执行：

bash复制javap -c -p com.sun.proxy.$Proxy0

你会看到代理类继承了java.lang.reflect.Proxy，并实现了接口Greeting。最核心的逻辑是，代理类有多个静态Method字段，比如m1代表toString，m2代表hashCode，m3代表接口里的greet方法。静态初始化块里通过这些字段绑定JDK的Method对象。

2.2 还原成等价Java源码

为了便于阅读，我把生成的代理类逻辑简化成下面的伪代码：

java复制public final class $Proxy0 extends Proxy implements Greeting {

    private static Method m3;

    static {
        try {
            m3 = Class.forName("...Greeting")
                    .getMethod("greet", String.class);
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
    }

    public $Proxy0(InvocationHandler h) {
        super(h);
    }

    @Override
    public final String greet(String name) throws Throwable {
        try {
            return (String) h.invoke(this, m3, new Object[]{name});
        } catch (RuntimeException | Error e) {
            throw e;
        } catch (Throwable e) {
            throw new UndeclaredThrowableException(e);
        }
    }
}

注意，实际字节码和JDK内部生成的格式跟我这里的伪代码会有细节差异，但核心意图完全一致。

这段代码回答了你最初的疑问：不是“某个框架要求先进入handler.invoke”，而是**代理类的greet方法体里只写了这么一件事：调用handler.invoke，把当前代理对象this、代表greet方法的Method对象、参数包装后的Object数组传进去。**不管谁调用代理对象，进来之后第一行执行的一定是这段转发逻辑。

2.3 为什么参数要包装成一个Object[]

这里顺带解释一个细节：invoke方法签名是：

java复制Object invoke(Object proxy, Method method, Object[] args)

args为什么是Object[]而不是一个可变参数？因为代理类要处理的接口方法可能有0个、1个、多个参数，参数类型各不相同。JDK生成器统一把多个参数包装成Object[]，这样InvocationHandler的invoke方法签名永远是固定的，不需要为不同方法生成不同的handler接口。

Method m3为什么要预先反射获取而不是方法被调用时现场查？为了性能。方法一旦被调用，每次都会经过invoke，但如果Method对象在每个代理类里只初始化一次，后面每次调用只是直接读取静态字段，比每次用Class.forName再getMethod快很多。

2.4 hashCode、equals、toString也会进invoke

代理类不只是把接口方法转给handler，它还重写了Object类里的hashCode、equals、toString。所以当你调用proxy.toString()时，同样会先进handler.invoke。

这个特性经常坑人。后面第4节我会详细说：如果在handler的invoke里不小心打印了proxy，就可能导致无限递归。

3. JDK为什么要把入口收敛到一个handler.invoke上

3.1 代理对象不需要知道“怎么干”，只需要知道“交给谁”

设计动态代理时，核心问题是怎么让一个“什么业务都不懂”的类去冒充某个接口。

常规静态代理会把每个方法都手写一遍：

java复制class GreetingStaticProxy implements Greeting {
    private final Greeting target;

    public GreetingStaticProxy(Greeting target) {
        this.target = target;
    }

    @Override
    public String greet(String name) {
        System.out.println("before");
        String result = target.greet(name);
        System.out.println("after");
        return result;
    }

    @Override
    public void bye() {
        System.out.println("before");
        target.bye();
        System.out.println("after");
    }
}

接口里有10个方法，就要手写10个方法，方法一多就很烦。JDK动态代理换了一个思路：不管有多少方法，代理类把方法调用统一转给一个InvocationHandler，由handler在invoke里通过method.getName()、参数类型、注解等信息决定要不要转发给真实对象、转发前做什么、转发后做什么。

所以InvocationHandler.invoke本质上就是一个“行为分派中心”。调用代理对象的任何一个方法，都会变成一次“代理对象发送事件”的操作。你写的不是方法的实现，而是响应事件的回调。

3.2 为什么JDK只能代理接口，不能代理普通类

这是新手最容易卡住的地方。为什么Proxy.newProxyInstance第二个参数必须是接口数组，传一个普通类会直接抛IllegalArgumentException？

最直接的原因是：JDK生成出来的代理类已经继承了java.lang.reflect.Proxy。

Java是单继承的，一个类只能有一个父类。代理类一旦继承了Proxy，就不可能再继承某个具体的业务类。如果JDK想通过继承目标类的方式去代理一个类，目标类的父类位置已经被Proxy占住，这条路走不通。

还有一个原因：接口天然是抽象方法集合。代理类不需要关心目标类里私有字段、构造器、protected方法那些实现细节，只需要老老实实“长成接口的样子”。生成字节码时，只需照搬接口的方法签名，然后每个方法体统一生成h.invoke(...)的逻辑。

接口方法可以通过java.lang.reflect.Method完整描述自身：方法名、参数类型、返回类型、注解、泛型信息都在。InvocationHandler拿到Method对象后，既可以转发，也可以做增强，非常灵活。

3.3 和其他代理实现方式的对比

对比后你会发现，JDK动态代理的代价是“只能面向接口”，但收益是统一、可复用。一个InvocationHandler可以根据Method的不同做完全不同的逻辑，这是静态代理做不到的。

像MyBatis的Mapper，接口背后根本没有一个写好的实现类，但你可以直接调用userMapper.selectById(1)，原因就是JDK生成了一个代理类，代理类的selectById方法体等于h.invoke(...)，而那个h是MyBatis的MapperProxy，它拿到Method后去MapperRegistry里找到对应的SQL并执行。没有这套机制，框架就不可能做到“定义接口就能自动执行SQL”。

4. invoke里的反射转发与两个最容易绕晕的递归场景

4.1 正确姿势：method.invoke(target, args)转发给真实对象

最常见、最标准的InvocationHandler写法是：

java复制public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
    Object result = method.invoke(target, args);
    return result;
}

这里的target是你构造handler时传进来的真实业务对象。method是那个代表接口方法的java.lang.reflect.Method对象，不是代理类的方法，而是通过Class.forName、getMethod等环节拿到的Greeting.greet对应的方法。

method.invoke(target, args)会真正调用目标对象的greet方法，这和我们直接调用target.greet("world")结果一致，只不过多了反射的一层开销。对比第1节Demo里的输出你就会发现：LogInvocationHandler.invoke先执行，然后才进入GreetingImpl.greet()。

4.2 经典坑：在invoke里再调用proxy的方法会导致栈溢出

我看过不少初学者在写invoke时写出这样的代码：

java复制public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
    System.out.println("before");
    Object result = method.invoke(proxy, args); // 错误！
    return result;
}

看起来只是把target换成了proxy，为什么运行后立刻StackOverflowError？

因为method.invoke(proxy, args)中的proxy是代理对象。调用代理对象上的greet方法，等于再次进入代理类$Proxy0.greet()，而该方法体里的代码又一次调用h.invoke(this, m3, args)，于是形成无限循环：

text复制proxy.greet()
  -> $Proxy0.greet()
    -> handler.invoke(proxy, m3, args)
      -> method.invoke(proxy, args)
        -> $Proxy0.greet()
          -> handler.invoke(...)
            -> 无限循环

所以务必记住：在handler.invoke里做“真实方法调用”时，反射的目标对象必须是普通业务对象，而不是proxy自己。只有在少数场景下，比如代理接口的某一个方法需要返回代理对象本身时，才可能使用proxy参数，但那也不是调method.invoke(proxy, args)。

还有一个经典连环坑：不要在invoke里通过System.out.println(proxy)来打印代理对象。因为打印一个对象会触发字符串拼接，Java会调用String.valueOf(Object)，最终调用proxy.toString()。而toString()又会被代理类转发到handler.invoke，如果你在invoke里又打印了proxy，就会再次触发toString，最后一样爆栈。

4.3 目标对象内部的自调用为什么不会被代理拦到

理解了方法体的原理后，还有一个高频疑问：为什么Spring AOP里类内部this.a()调用this.b()时，b方法的切面逻辑不生效？

原因和代理机制完全一致。Spring容器注入给你的对象如果是代理对象，外部调用proxy.a()时，代理类把A方法调用转发给了handler.invoke，handler把它们转发给target实现。真正执行时是在target对象内部调用了this.a()，这里的this是目标对象本身，不是代理对象。

因此，在target对象里再执行this.b()时，走的是普通Java方法调用，根本不会经过代理类，也就不会再次进入handler.invoke。AOP切面不生效不是缓冲区问题，而是“第二跳”已经不在代理对象身上了。

5. 用调用栈验证链路，顺便解释框架中“先进入invoke”的表现

5.1 Debug时调用栈到底长什么样

在LogInvocationHandler.invoke第一行打一个断点，然后执行proxy.greet("world")，你会在IDE的Debugger里看到类似下面这样的栈帧：

text复制LogInvocationHandler.invoke(ProxyDemo.java:20)
$Proxy0.greet(Unknown Source)
ProxyDemo.main(ProxyDemo.java:36)

上面是常规显示顺序，如果IDE自底向顶看，从底部的main开始，第一层是$Proxy0.greet，第二层就切到了LogInvocationHandler.invoke。这说明调用代理对象方法后，程序立刻进入了代理类方法，然后代理类方法体马上调用了handler.invoke。

你如果继续往下单步，会看到真正的GreetingImpl.greet是在method.invoke之后才进入的。所以“为什么代理对象执行方法先进handler.invoke”这个问题，本质上是在问“为什么代理类的方法体里只有handler.invoke这一件事”。字节码和源码都回答了这一点。

5.2 Spring AOP和MyBatis Mapper也复用同一个机制

Java动态代理不只是教学Demo在用。Spring AOP对接口型Bean的默认代理方式就是JDK动态代理。Spring内部有一个JdkDynamicAopProxy类，它也实现了InvocationHandler，整个代理Bean的方法调用流程是：

text复制proxy.业务方法()
  -> JdkDynamicAopProxy.invoke(...)
    -> 构造拦截器链，执行切面逻辑
      -> method.invoke(target, args) 真正调用Bean方法

如果你配了事务注解，事务拦截的逻辑也在这个invoke里。 MyBatis则更极端：Mapper接口根本没有实现类。我们调用userMapper.selectById()，实际是调用一个MapperProxy生成出来的代理对象。代理方法体调用了MapperProxy的invoke，MapperProxy拿到Method后去和MapperMethod关联起来，再执行SQL，最后把结果映射成对象返回。

所以你在看这些框架源码时，不断看到“所有方法先进入invoke”，就是因为它们都建立在JDK动态代理这条路上。理解了这一点，你就不会被各种框架包装出的概念吓到，底层都是同一个事件分派模型。

5.3 排查切面不生效时有什么用

如果你在Spring里遇到切面没生效，第一步可以先查“这个Bean到底是不是代理对象”。可以用下面这样的代码在运行时判断：

java复制System.out.println(AopUtils.isAopProxy(bean));
System.out.println(bean.getClass().getName());

如果打印出来的类名是com.sun.proxy.$Proxy...，说明Bean确实是JDK动态代理生成的对象，理论上方法调用会先进invoke。切面仍然不生效时，要重点检查是不是发生了内部自调用、方法是不是private或final、切点表达式是否匹配等。

如果打印出来的类名直接就是你自己的类名，比如com.example.MyServiceImpl，说明当前拿到的根本不是一个代理对象，很有可能是你自己通过new创建的对象，不是Spring容器里的那个Bean。

6. 我对这个机制的三个记忆锚点和一条调试忠告

6.1 一句话记忆法

代理对象不等于业务对象，它更像业务对象的一扇门。你调用这扇门上的任意一个按钮，门铃就会响一声，响铃的入口就是handler.invoke。真正进屋干活的是你在invoke里通过method.invoke找到的那个目标对象。想让这门铃不响都不行，因为生成代理类时，门上的每个按钮内部接线都已经被固化成“先响铃”。

6.2 几个容易忽略的细节清单

• 代理类是运行时生成的类，类名通常带$Proxy前缀，不能直接在代码里引用它。
• 同一组接口和类加载器会复用代理类，但每次newProxyInstance产生的新实例是不同的，因为每个实例持有自己的handler。
• InvocationHandler.invoke的返回值必须适配接口方法的返回类型。返回基本类型时如果invoke返回null，代理类在拆箱时可能抛NullPointerException。
• 当handler.invoke抛出受检异常，但接口方法并没声明该异常时，JDK会将其包装成UndeclaredThrowableException再抛出。这解释了为什么代理对象有时会抛出一个你没见过的RuntimeException。
• 可以用Proxy.getInvocationHandler(proxy)拿到代理对象背后的handler实例，这适合在调试时确认handler是谁。
• 接口里如果存在default方法或静态方法，JDK代理对这些方法的处理和对普通抽象方法不同。通常我们讨论的是普通抽象方法，实际业务中也大量使用这一类，不必一上来纠结default方法。

6.3 写代码时我养成的几个习惯

我在自己写动态代理或看框架代码时，会特别注意两点。第一，InvocationHandler的invoke里绝不直接打印proxy对象，也绝不让method.invoke的目标变成proxy，避免无意义的递归。第二，真正要定位“谁调用了代理对象、handler是哪一步设置的”，不要靠猜，直接用Proxy.getInvocationHandler(proxy)把handler拿出来打印它的Class。

还有一次排查MyBatis Mapper问题时，我一度以为是某个Mapper接口的动态代理没有生成成功，后来发现是方法重载导致Method匹配时无法准确区分。调试时可以在invoke开头把method.toString()打出来，就能看到传入的确实是一个带完整参数类型签名的方法。这种输出对理清代理调用顺序特别管用。

很多人看到“先进handler.invoke”会觉得动态代理是一层魔法。其实把代理类反编译出来看一眼，就知道它和普通类没有本质区别，只是方法体被固定成统一的转发逻辑。搞懂了这一步，后面看Spring AOP、拦截器、Mapper代理，都会顺畅很多。