【从0开始学习Java | 第23篇】动态代理

【从0开始学习Java | 第23篇】动态代理
在这里插入图片描述

文章目录

Java动态代理概述

在Java开发中,代理模式设计模式之一,而动态代理作为代理模式的进阶形式,在框架开发(如Spring AOP)、日志记录、权限控制等场景中发挥着关键作用。本文将从核心概念出发,拆解两种主流动态代理的实现逻辑,并分析其适用场景。

在这里插入图片描述

一、动态代理的核心概念

动态代理指在程序运行时,通过反射机制动态生成代理类,而非在编译期预先定义。其核心价值在于:无需为每个目标类手动编写代理类,即可统一为多个目标类添加横切逻辑(如日志、事务、异常处理),降低代码耦合度。

在这里插入图片描述

动态代理包含三个核心角色:

  1. 目标类(Target):被代理的原始类,包含核心业务逻辑;
  2. 代理类(Proxy):运行时动态生成的类,持有目标类引用,负责调用目标方法并增强逻辑;
  3. 增强逻辑(Advice):需统一添加的横切逻辑,如日志打印、参数校验等。

形象解释

在这里插入图片描述

二、两种主流动态代理实现

Java中动态代理主要有两种实现方式:JDK动态代理(原生API)和CGLIB动态代理(第三方库),二者在原理和使用上存在显著差异。

1. JDK动态代理(基于接口)

原理

JDK动态代理依赖java.lang.reflect包下的ProxyInvocationHandler接口,要求目标类必须实现至少一个接口。运行时,JVM会动态生成一个实现目标接口的代理类,代理类的方法调用会转发到InvocationHandlerinvoke方法中,在该方法中可嵌入增强逻辑并调用目标方法。

在这里插入图片描述
示例代码
// 1. 定义接口publicinterfaceUserService{voidaddUser(String name);}// 2. 实现目标类publicclassUserServiceImplimplementsUserService{@OverridepublicvoidaddUser(String name){System.out.println("添加用户:"+ name);}}// 3. 实现InvocationHandler(增强逻辑)publicclassLogInvocationHandlerimplementsInvocationHandler{privateObject target;// 目标类引用publicLogInvocationHandler(Object target){this.target = target;}// 代理类的所有方法调用都会触发invoke@OverridepublicObjectinvoke(Object proxy,Method method,Object[] args)throwsThrowable{// 增强逻辑:前置日志System.out.println("方法"+ method.getName()+"开始执行,参数:"+Arrays.toString(args));// 调用目标方法Object result = method.invoke(target, args);// 增强逻辑:后置日志System.out.println("方法"+ method.getName()+"执行结束");return result;}}// 4. 生成代理类并测试publicclassJdkProxyTest{publicstaticvoidmain(String[] args){// 目标对象UserService target =newUserServiceImpl();// 生成代理对象(需传入类加载器、目标接口、InvocationHandler)UserService proxy =(UserService)Proxy.newProxyInstance( target.getClass().getClassLoader(), target.getClass().getInterfaces(),newLogInvocationHandler(target));// 调用代理方法 proxy.addUser("张三");}}
优缺点
  • 优点:基于JDK原生API,无需依赖第三方库,轻量化;
  • 缺点:目标类必须实现接口,无法代理无接口的类。

2. CGLIB动态代理(基于子类)

原理

CGLIB(Code Generation Library)是一个第三方字节码生成库,通过生成目标类的子类作为代理类,无需目标类实现接口。其核心是MethodInterceptor接口,代理类的方法调用会被拦截到intercept方法中,在此处嵌入增强逻辑并调用目标方法。

示例代码(需引入CGLIB依赖)
<!-- Maven依赖 --><dependency><groupId>cglib</groupId><artifactId>cglib</artifactId><version>3.3.0</version></dependency>
// 1. 目标类(无需实现接口)publicclassOrderService{publicvoidcreateOrder(String orderId){System.out.println("创建订单:"+ orderId);}}// 2. 实现MethodInterceptor(增强逻辑)publicclassLogMethodInterceptorimplementsMethodInterceptor{// 拦截代理类方法调用@OverridepublicObjectintercept(Object o,Method method,Object[] args,MethodProxy methodProxy)throwsThrowable{// 增强逻辑:前置日志System.out.println("方法"+ method.getName()+"开始执行,参数:"+Arrays.toString(args));// 调用目标方法(推荐用methodProxy.invokeSuper,避免递归调用)Object result = methodProxy.invokeSuper(o, args);// 增强逻辑:后置日志System.out.println("方法"+ method.getName()+"执行结束");return result;}}// 3. 生成代理类并测试publicclassCglibProxyTest{publicstaticvoidmain(String[] args){// CGLIB核心类:EnhancerEnhancer enhancer =newEnhancer();// 设置父类(目标类) enhancer.setSuperclass(OrderService.class);// 设置方法拦截器 enhancer.setCallback(newLogMethodInterceptor());// 生成代理对象(子类实例)OrderService proxy =(OrderService) enhancer.create();// 调用代理方法 proxy.createOrder("ORDER_001");}}
优缺点
  • 优点:无需目标类实现接口,可代理任意类(除final类和final方法);
  • 缺点:依赖第三方库,生成代理类时需操作字节码,性能略低于JDK动态代理(JDK 8后差距已缩小)。

三、JDK与CGLIB动态代理对比

对比维度JDK动态代理CGLIB动态代理
依赖JDK原生API(无第三方依赖)需引入CGLIB库
代理原理实现目标接口生成目标类子类
目标类要求必须实现接口无接口要求(不能是final类)
方法限制仅代理接口中的方法不能代理final方法
性能(JDK 8+)生成快,调用效率高生成慢,调用效率略低

四、实际应用场景

  1. Spring AOP:默认优先使用JDK动态代理(目标类有接口时),无接口时使用CGLIB;
  2. 日志记录:统一记录方法的入参、出参、执行时间;
  3. 权限控制:方法调用前校验用户权限,无权限则抛出异常;
  4. 事务管理:方法执行前开启事务,执行后提交/回滚事务。

五、总结

动态代理是Java中“解耦横切逻辑”的核心技术,JDK动态代理和CGLIB各有适用场景:若目标类已实现接口,优先选择JDK动态代理(轻量化、无依赖);若目标类无接口或需代理类的所有方法,选择CGLIB。


如果我的内容对你有帮助,请 点赞 , 评论 , 收藏 。创作不易,大家的支持就是我坚持下去的动力!

在这里插入图片描述

Read more

Flutter for OpenHarmony:cider 自动化版本管理与变更日志生成器(发布流程标准化的瑞士军刀) 深度解析与鸿蒙适配指南

Flutter for OpenHarmony:cider 自动化版本管理与变更日志生成器(发布流程标准化的瑞士军刀) 深度解析与鸿蒙适配指南

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net 前言 在 App 的迭代过程中,维护 pubspec.yaml 中的版本号和编写 CHANGELOG.md 是一件既繁琐又容易出错的事情。 * “这次发布是 1.0.1 还是 1.1.0?” * “昨天的 bug fix 有没有写进变更日志?” * “谁不小心把 build number 搞错了,导致应用商店上传失败?” 对于 OpenHarmony 应用来说,更加严格的版本管控(如 HAP 包的版本对应)使得这一环节尤为重要。 Cider 是一个专为 Dart/Flutter 项目设计的命令行工具,它可以自动化地处理版本升级、变更日志维护以及发布的检查。它就像是你的“发布管家”

By Ne0inhk

Flutter for OpenHarmony: Flutter 三方库 plugin_platform_interface 规范鸿蒙插件跨端接口契约(插件开发标准指南)

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net 前言 在进行 OpenHarmony 插件开发时,一个核心挑战是如何确保你的插件在 Android、iOS 和鸿蒙等多端表现一致。为了保证扩展的可测试性和规范性,Flutter 团队提出了一套“基于接口”的插件架构规范。 plugin_platform_interface 正是实现这一架构的官方基石。它通过强行校验开发者是否继承了特定的基类,确保任何三方开发者(或你自己在进行鸿蒙适配时)在模拟或重写平台库时,都能遵循严格的协议契约,防止因漏写方法而导致的运行时崩溃。 一、标准分层插件架构 该库致力于定义中间的“平台接口层(Platform Interface)”。 注册实现 注册实现 通过校验器 Flutter App 插件 API (面向用户) Platform Interface (定义契约) 鸿蒙特定实现 (ArkTS 交互) Android 特定实现

By Ne0inhk
Flutter 三方库 metalink_advanced_final 的鸿蒙化适配指南 - 在 OpenHarmony 打造极致、安全的 P2P 下载与资源分发底座

Flutter 三方库 metalink_advanced_final 的鸿蒙化适配指南 - 在 OpenHarmony 打造极致、安全的 P2P 下载与资源分发底座

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 三方库 metalink_advanced_final 的鸿蒙化适配指南 - 在 OpenHarmony 打造极致、安全的 P2P 下载与资源分发底座 在大数据传输、大型游戏资源更新以及分布式固件升级场景中,传统的单点 HTTP 下载往往面临带宽压力和校验失效的风险。metalink 协议(RFC 5854)通过整合多个源地址与强校验机制,提供了一套工业级的资源分发方案。metalink_advanced_final 库为 Flutter 开发者提供了该协议的终极解析与执行引擎。本文将深度解析如何在 OpenHarmony(鸿蒙)环境下,结合鸿蒙的并发架构,完美适配这一强大的下载工具。 前言 随着鸿蒙系统(HarmonyOS)跨终端特性的普及,应用在不同设备间流转时的资源同步速度成为了用户体验的“胜负手”。metalink_advanced_final

By Ne0inhk
Flutter for OpenHarmony:dart_ipify 一行代码获取公网 IP 地址,不再自己维护接口(IP 查询服务) 深度解析与鸿蒙适配指南

Flutter for OpenHarmony:dart_ipify 一行代码获取公网 IP 地址,不再自己维护接口(IP 查询服务) 深度解析与鸿蒙适配指南

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net 前言 在做 P2P 应用、日志记录或地域限制功能时,经常需要知道用户的真实公网 IP。虽然可以自己写个后端 API 返回 request.ip,或者爬取 icanhazip.com,但这些方法要么麻烦,要么不稳定。 dart_ipify 封装了著名的 ipify.org 公共 API,它不仅提供 IPv4/IPv6 查询,还能返回 ISP(运营商)和地理位置信息(需 API Key)。最重要的是,它极其简单稳定,永久免费(基础查询)。 一、概念介绍/原理解析 1.1 基础概念

By Ne0inhk