Java动态代理之原理与应用场景_Java实现非侵入式编程的关键技术-java教程-PHP中文网

java动态代理解决了代码重复和高耦合的痛点，通过在不修改原有业务逻辑的前提下，实现日志、事务、权限等横切关注点的集中管理；2. 其核心实现方式为jdk动态代理和cglib动态代理，前者基于接口，后者基于继承，适用于无接口的类；3. 使用jdk动态代理时需确保目标类实现接口，注意object类方法如tostring、equals等也会被拦截，需特殊处理以避免异常行为；4. 代理中应正确捕获并重新抛出异常，保证原始方法的异常行为不变；5. 尽管存在轻微性能开销，但在大多数场景下可忽略，选择时优先使用jdk动态代理，若无接口则选用cglib，而spring等框架会自动根据条件切换。

Java动态代理之原理与应用场景_Java实现非侵入式编程的关键技术

Java动态代理，本质上是一种在运行时为接口或类创建代理对象的能力，它的核心价值在于实现了代码的非侵入式增强。这意味着我们可以在不修改原有业务逻辑代码的情况下，为其添加额外的功能，比如日志记录、事务管理、权限校验等，这在构建灵活、可维护的系统时至关重要。

解决方案

Java动态代理主要通过两种方式实现：JDK动态代理和CGLIB动态代理。

JDK动态代理是Java语言自带的代理机制，它依赖于接口。当我们需要为一个或多个接口生成代理对象时，JDK动态代理是首选。它的工作原理是，在运行时动态生成一个实现了目标接口的代理类，并创建该代理类的实例。这个代理类会把所有对接口方法的调用都转发给一个

InvocationHandler

登录后复制

的实例。在

InvocationHandler

登录后复制

的

invoke

登录后复制

方法中，我们就可以在调用原始方法之前或之后，甚至替代原始方法，插入我们自己的逻辑。

立即学习“Java免费学习笔记（深入）”；

CGLIB动态代理则是一个第三方库（Code Generation Library），它弥补了JDK动态代理只能代理接口的局限性。CGLIB通过继承目标类的方式来创建代理，它在运行时生成一个目标类的子类，并重写父类的所有非final方法。同样，它也提供了一个回调接口（

MethodInterceptor

登录后复制

），在代理方法被调用时，会触发

intercept

登录后复制

方法，我们可以在这里加入增强逻辑。

这两种代理机制都利用了Java的反射能力，在运行时动态地构建和操作类。它们共同构成了Java实现非侵入式编程的关键技术，让开发者能够优雅地处理横切关注点（Cross-cutting Concerns），将业务逻辑与系统级服务分离，大大提升了代码的模块化和可维护性。

动态代理在实际开发中究竟解决了哪些痛点？

说起来，动态代理这东西，它真正解决的，是那些我们日常开发中无处不在的“重复劳动”和“耦合之痛”。你有没有遇到过这样的场景：每个业务方法开始前都要打个日志，每个数据库操作方法前后都要写事务的

begin

登录后复制

、

commit

登录后复制

、

rollback

登录后复制

，或者每次调用前都得做个权限校验？如果这些逻辑散落在各个业务方法里，那简直是维护的噩梦。

动态代理，就像一个隐形的“守卫者”，它悄悄地站在你的业务逻辑前面。当外部调用你的业务方法时，请求会先经过这个守卫者。守卫者可以在请求到达业务方法前（前置增强）、请求离开业务方法后（后置增强），甚至在业务方法抛出异常时（异常增强），插入统一的处理逻辑。这样一来，那些与核心业务逻辑无关但又必不可少的“横切关注点”，比如日志、事务、安全、性能监控、缓存等，就可以被集中管理和处理，而你的业务代码依然保持着它的纯粹和简洁。

我个人觉得，它最显著的价值在于：

解耦： 将系统服务（如事务、日志）与业务逻辑彻底分离，降低了代码间的耦合度。
复用： 同样的增强逻辑可以应用到多个不同的业务方法上，避免了大量的代码复制粘贴。
维护性： 当需要修改或移除某个横切关注点时，只需修改代理逻辑，无需触碰成百上千的业务方法。
灵活性： 可以在不修改现有代码的情况下，为旧代码添加新功能，这对于遗留系统改造尤其有用。

想象一下，如果Spring AOP没有动态代理，那我们每次要加个事务，都得手动写

try-catch-finally

登录后复制

，那开发效率得低多少？简直不敢想。

JDK动态代理与CGLIB动态代理，我们该如何选择？

这个问题其实挺有意思的，很多时候，特别是在用Spring这样的框架时，你可能根本不用手动去选，框架已经帮你做了最优决策。但从原理层面去理解，这两种代理方式各有各的适用场景和特点。

核心区别：

JDK动态代理： 基于接口。它要求你的目标对象必须实现至少一个接口。代理对象和目标对象会实现相同的接口。
CGLIB动态代理： 基于继承。它可以代理没有实现接口的普通类（只要不是final类或final方法）。它通过生成目标类的子类来实现代理。

选择考量：

是否有接口：
- 如果你要代理的对象实现了接口，那么JDK动态代理通常是更简洁、更自然的选择。它是Java标准库的一部分，不需要引入额外的依赖。
- 如果你的目标类没有实现接口，或者你只想代理一个具体的类而不是它的接口，那么CGLIB就是你唯一的选择。例如，很多时候我们有一些纯粹的POJO类，并没有设计接口，但又想给它们的方法加点增强，CGLIB就能派上用场。
性能：
- 在早期，CGLIB通常被认为比JDK动态代理性能更高，因为它直接操作字节码，避免了反射带来的额外开销。但随着JVM的优化，JDK动态代理的性能也得到了显著提升，在大多数业务场景下，两者的性能差异几乎可以忽略不计。所以，性能通常不是决定选择哪个的主要因素。
限制：
- JDK动态代理不能代理
  final
  登录后复制
  登录后复制
  登录后复制
  登录后复制
  类或
  final
  登录后复制
  登录后复制
  登录后复制
  登录后复制
  方法。
- CGLIB也不能代理
  final
  登录后复制
  登录后复制
  登录后复制
  登录后复制
  类（因为它需要继承），也不能代理
  final
  登录后复制
  登录后复制
  登录后复制
  登录后复制
  方法（因为它需要重写）。

我个人的看法是，如果能用JDK动态代理，尽量用它，因为它更“原生”，依赖更少。但在实际项目里，尤其是在Spring Boot这种生态下，你往往不会直接去手动选择。Spring AOP默认情况下会优先使用JDK动态代理（如果目标对象实现了接口），如果目标对象没有实现接口，它会自动切换到CGLIB。这种无感知的切换，其实也是框架设计者对这两种代理机制深思熟虑后的结果。所以，作为开发者，理解它们的原理和区别，更多是为了在遇到问题时能够定位，而不是每次都去手动选择。

编写一个简单的JDK动态代理实现，以及需要注意的陷阱

要亲手写一个JDK动态代理，其实并不复杂，但有些细节确实容易被忽略。

我们先定义一个简单的服务接口和实现类：

// 服务接口
public interface MessageService {
    String sendMessage(String message);
    void greet(String name);
}

// 服务实现
public class MessageServiceImpl implements MessageService {
    @Override
    public String sendMessage(String message) {
        System.out.println("发送消息: " + message);
        return "消息已发送: " + message;
    }

    @Override
    public void greet(String name) {
        System.out.println("你好, " + name + "!");
    }
}

登录后复制

接着，我们来创建核心的

InvocationHandler

登录后复制

，它决定了代理的行为：

import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;

public class MyServiceProxyHandler implements InvocationHandler {
    private Object target; // 目标对象

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

    // 获取代理对象
    public Object getProxy() {
        // ClassLoader: 决定了代理类由哪个类加载器加载
        // interfaces: 代理类要实现的接口列表
        // InvocationHandler: 代理类方法调用时要执行的处理器
        return Proxy.newProxyInstance(target.getClass().getClassLoader(),
                                      target.getClass().getInterfaces(),
                                      this);
    }

    @Override
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        // 在调用目标方法之前执行的逻辑
        System.out.println("--- 代理开始: 调用方法 " + method.getName() + " ---");

        Object result = null;
        try {
            // 调用目标对象的方法
            result = method.invoke(target, args);
            // 在调用目标方法之后执行的逻辑
            System.out.println("--- 代理结束: 方法 " + method.getName() + " 调用成功 ---");
        } catch (Exception e) {
            // 异常处理逻辑
            System.err.println("--- 代理异常: 方法 " + method.getName() + " 抛出异常: " + e.getMessage() + " ---");
            throw e; // 重新抛出异常，保持原有异常行为
        }
        return result;
    }
}

登录后复制

最后，是使用代理：

public class ProxyDemo {
    public static void main(String[] args) {
        MessageService realService = new MessageServiceImpl();
        MyServiceProxyHandler handler = new MyServiceProxyHandler(realService);

        // 获取代理对象
        MessageService proxyService = (MessageService) handler.getProxy();

        // 通过代理对象调用方法
        String response = proxyService.sendMessage("Hello Dynamic Proxy!");
        System.out.println("收到响应: " + response);

        System.out.println("\n--- 再次调用另一个方法 ---");
        proxyService.greet("世界");
    }
}

登录后复制

运行这段代码，你会看到

--- 代理开始 ---

登录后复制

和

--- 代理结束 ---

登录后复制

的日志，这表明我们的增强逻辑已经成功注入。

需要注意的陷阱：

接口是必须的： 这是JDK动态代理最核心的限制。如果你尝试代理一个没有实现任何接口的类，
```
Proxy.newProxyInstance
```
登录后复制
登录后复制
会抛出
```
IllegalArgumentException
```
登录后复制
。很多人初次接触时会在这里卡住，因为它不像CGLIB那样能直接代理具体类。
Object
登录后复制
登录后复制
登录后复制
类方法的拦截：代理对象的所有方法调用，包括从
```
Object
```
登录后复制
登录后复制
登录后复制
类继承来的
```
equals()
```
登录后复制
,
```
hashCode()
```
登录后复制
,
```
toString()
```
登录后复制
等方法，都会被
InvocationHandler
登录后复制
登录后复制
登录后复制
登录后复制
的
invoke
登录后复制
登录后复制
登录后复制
登录后复制
登录后复制
登录后复制
方法拦截。如果你在
invoke
登录后复制
登录后复制
登录后复制
登录后复制
登录后复制
登录后复制
方法中没有对这些方法进行特殊处理，那么它们也会被你的增强逻辑包裹。通常情况下，我们希望这些方法保持其默认行为，或者至少与目标对象的行为一致。例如，你可能需要在
invoke
登录后复制
登录后复制
登录后复制
登录后复制
登录后复制
登录后复制
方法里加上类似这样的判断：
```
if (method.getName().equals("toString")) {
    return "Proxy of " + target.getClass().getName();
}
// ... 其他逻辑
```
登录后复制
否则，如果你直接调用
```
proxyService.toString()
```
登录后复制
，它也会走你的
invoke
登录后复制
登录后复制
登录后复制
登录后复制
登录后复制
登录后复制
方法，可能输出一些意想不到的代理日志。
性能考量（微小）： 虽然现代JVM对反射进行了大量优化，但相较于直接方法调用，动态代理仍然存在一定的性能开销。在对性能极其敏感，且调用频率极高的场景下，需要谨慎评估。不过，对于绝大多数业务系统而言，这种开销通常可以忽略不计。
异常处理： 在
invoke
登录后复制
登录后复制
登录后复制
登录后复制
登录后复制
登录后复制
方法中，如果目标方法抛出异常，你需要捕获并重新抛出，以确保代理行为与原始行为一致。如果你不重新抛出，外部调用者将无法感知到内部发生的异常。
代理对象类型转换：
```
Proxy.newProxyInstance
```
登录后复制
登录后复制
返回的是
```
Object
```
登录后复制
登录后复制
登录后复制
类型，你需要将其强制转换为目标接口的类型。如果转换失败（例如，你尝试转换为一个目标对象没有实现的接口），会抛出
```
ClassCastException
```
登录后复制
。