1. 别再手动打日志了先从痛点认识AOP聊AOP之前我先描述一个场景你大概率遇到过。一个老项目几十个Service方法每次业务改动或者排查线上问题都要在各个方法入口手动加日志。加也就罢了改一次业务代码日志逻辑跟着散落得到处都是。等你想把日志格式从param {}统一改成request {}的时候你会发现自己陷入了全局替换的泥潭。这还仅仅是日志。权限校验、事务管理、性能监控、参数校验这些横跨整个项目、和核心业务逻辑无关的公共关注点如果都靠手动在每个方法里重复编写后果不只是工作量爆炸更重要的是逻辑分散后极易漏写而且一旦规则变更整个代码库都要跟着改。你没办法保证十个人的团队提交的代码每一条调用链都带着同样严格的安全校验或监控埋点。这类问题就是典型的横切关注点。而AOPAspect Oriented Programming面向切面编程做的事情就是把这些散落在各个模块中的公共逻辑抽取出来通过预编译方式或运行期动态代理在不修改原业务代码的前提下统一织入。你只需要写一次切面类声明哪些类的哪些方法要执行什么逻辑剩下的重复劳动交给框架完成。这篇文章我想把这些年使用AOP的实际体会完整梳理一遍。从最基础的概念拆解到JDK动态代理和CGLIB的底层原理再到实际项目里的事务、日志、权限场景落地最后手写一个简化版AOP框架把整个知识体系串成闭环。无论你是准备面试还是要在项目中落地这篇内容都会比零散的技术碎片有用得多。2. 核心概念拆解AOP的七个关键词讲透2.1 连接点、切入点和通知三者关系先分清AOP体系里最容易混淆的是三个概念连接点Join Point、切入点Pointcut和通知Advice。我用一个生活化类比给拆开。假设你是一个商场经理商场里所有柜台都可以安装摄像头这些可以安装摄像头的位置就是连接点。但是出于成本考虑你只在黄金珠宝柜台安装这个你选中的具体位置集合就是切入点。摄像头录下来的画面以及你基于画面做的行为分析比如识别到可疑动作就报警这就是通知。放到代码里连接点被拦截到的具体方法Spring AOP中特指方法执行点。切入点匹配连接点的表达式例如execution(* com.example.service.*.*(..))它描述了哪些方法需要被增强。通知拦截到方法后要执行的逻辑比如Before、AfterReturning、Around。三者关系是递进的连接点是候选集合切入点从集合中筛选通知则是对筛选出的每一个方法绑定增强逻辑。切入点决定哪里切通知决定切了之后干什么。2.2 切面与织入AOP的组装方式**切面Aspect**是把切入点和通知结合起来的整体模块是横切逻辑的载体。在Spring中一个标注了Aspect的类通常就是一个切面里面既有Pointcut定义也有具体的通知方法。**织入Weaving**是将切面应用到目标对象并创建新的代理对象的过程。这个动作发生在什么时机决定了AOP的实现流派织入时机实现方式代表框架编译期特殊编译器修改字节码AspectJ类加载期加载时字节码增强AspectJ Load-time Weaving运行期动态生成代理对象Spring AOP看到这里你会明白Spring AOP本质上是一种运行期的AOP它通过代理对象来实现增强逻辑的动态组装而AspectJ是完整的AOP方案能在字节码层面直接修改。这也是很多人面试时被追问的差距点两者不是同一个层次的产物。2.3 五种通知类型与执行顺序通知类型决定了增强逻辑与目标方法的时间关系总结如下Before目标方法执行前调用适合参数校验、权限预检。After无论方法正常返回还是抛异常都会执行适合释放资源。AfterReturning方法正常返回后执行可以访问返回值适合结果加工。AfterThrowing方法抛出异常后执行适合异常监控、告警。Around最强大的通知在方法调用前后包裹执行可以完全控制方法是否执行、是否替换返回值、是否捕获异常。多个切面在同一连接点执行时顺序由Order注解控制数字越小优先级越高。这里有个细节Before的执行顺序是按优先级从小到大而AfterReturning的执行顺序恰好相反。很多人写多切面的时候死记规则却记错了方向实际调试时一旦出现顺序敏感的逻辑立刻翻车。我的建议是少用多个切面同时作用于同一方法如果必须用Around统一编排至少逻辑显式可控。3. 动态代理原理JDK Proxy与CGLIB深究3.1 JDK动态代理为什么必须面向接口Spring AOP默认使用JDK动态代理前提是目标类实现了接口。它的核心机制是在运行期通过java.lang.reflect.Proxy为接口生成一个代理类代理类实现了目标接口并把所有方法调用转发给InvocationHandler的invoke方法。我来简化一下底层流程public class JdkProxyHandler implements InvocationHandler { private final Object target; public JdkProxyHandler(Object target) { this.target target; } Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { // 前增强 System.out.println(before method: method.getName()); Object result method.invoke(target, args); // 后增强 System.out.println(after method: method.getName()); return result; } } // 生成代理 UserService proxy (UserService) Proxy.newProxyInstance( UserService.class.getClassLoader(), new Class[]{UserService.class}, new JdkProxyHandler(new UserServiceImpl()) );关键点在于代理对象是JDK在内存中动态构建的一个新类它和你的业务实现类并不存在继承关系而是通过实现同一接口来建立联系。所以如果目标类压根没有接口JDK Proxy就无从下手了。面试经常在这里挖坑如果目标类实现了接口但你想用CGLIBSpring怎么选默认策略是接口存在就用JDK Proxy除非你显式配置spring.aop.proxy-target-classtrue。JDK Proxy的反射调用有一定性能开销但现代JVM的反射优化已经让它足够快大部分业务场景感受不到差异。3.2 CGLIB基于继承的字节码增强CGLIBCode Generation Library通过生成目标类的子类来实现代理重写目标类的方法在重写逻辑中插入增强代码。这意味着两个限制目标类不能是final的否则无法继承。被代理的方法不能是final或static因为无法被重写。对比来看对比项JDK ProxyCGLIB实现原理基于接口的代理类基于继承的子类目标类要求必须实现接口不能是final类方法要求接口方法非final、非static方法性能特点创建快调用慢创建慢调用快Spring默认策略默认优先无接口或强制配置时CGLIB在低版本Spring中需要额外引入依赖Spring 3.2之后被整合进spring-core。实际项目中我倾向于全量开启proxy-target-classtrue理由有两个一是很多Service实现类确实没有抽取接口二是对象创建只发生一次CGLIB调用时的性能优势在长连接场景下更值得。当然如果追求极致的模块解耦和Mock测试便利接口风格依然保留JDK Proxy这个没有标准答案。3.3 Spring AOP与AspectJ的边界划分很多人误以为Spring AOP就是AspectJ这是概念混淆的重灾区。Spring AOP是一个基于代理的AOP实现只能在方法级别拦截而AspectJ是完整的字节码增强方案可以拦截字段访问、构造器调用、甚至控制方法执行的底层细节。Spring AOP的拦截完全发生在运行时对已有对象进行包裹AspectJ的织入则发生在编译期、编译后或加载期它修改的是类本身的字节码。一句话总结生产上大多数需求Spring AOP就够用了如果你真的需要拦截构造器、修改字节码结构再去考虑AspectJ。别为了技术上的炫技引入额外的编译期插件项目复杂度往往就是这么被抬高的。4. 真实场景落地事务、日志、权限一个不少4.1 声明式事务用的最多理解最少Spring的Transactional就是AOP实现的经典案例。声明式事务的本质是框架在方法执行前开启事务、执行成功后提交、抛出异常则回滚。这一切都不会侵入你的业务代码。但这里有一个长期困扰开发者的坑同类内部方法调用导致事务失效。Service public class OrderService { public void createOrder() { this.updateStock(); } Transactional public void updateStock() { // do something } }调用createOrder()时this.updateStock()是普通方法调用直通目标对象本身不走代理对象所以Transactional注解根本没有被解析。解决方案有三种把updateStock()拆分到另一个Bean中通过注入调用。在createOrder()中从ApplicationContext获取代理对象再调用。在createOrder()内部通过AopContext.currentProxy()获取当前代理。第三种方案需要EnableAspectJAutoProxy(exposeProxy true)开启暴露代码可读性差不太推荐。我实际使用的经验是优先拆分Bean让事务边界清晰独立这也符合单一职责的设计原则。4.2 切面日志从散落日志到统一埋点日志切面是AOP入门最友好的实践。需求很简单记录Controller层所有请求的入参、出参、耗时并且不影响原有业务代码。定义切面Aspect Component public class WebLogAspect { Around(execution(public * com.example.controller.*.*(..))) public Object logAround(ProceedingJoinPoint joinPoint) throws Throwable { long start System.currentTimeMillis(); String methodName joinPoint.getSignature().getName(); Object[] args joinPoint.getArgs(); log.info(request start, method: {}, args: {}, methodName, Arrays.toString(args)); Object result joinPoint.proceed(); long cost System.currentTimeMillis() - start; log.info(request end, method: {}, result: {}, cost: {}ms, methodName, result, cost); return result; } }有两点容易被忽略一是joinPoint.proceed()必须调用否则业务方法直接短路二是如果Controller方法的返回对象包含HttpServletResponse、文件流等不可序列化的字段直接toString会报错或刷屏记日志前要做类型判断。我在项目里会单独抽取一个LogIgnore注解作用于某些敏感字段所在的方法或参数上切面里检测到注解就跳过打印避免把用户手机号这类敏感信息打到日志系统里。4.3 自定义权限切面一套注解统管接口安全权限校验也是AOP的高频场景。开发一个后台管理系统时不同角色能访问的接口不一样如果每个接口都手写一遍权限判断代码不仅冗余还容易漏。用AOP可以优雅地解决。定义注解Target({ElementType.METHOD, ElementType.TYPE}) Retention(RetentionPolicy.RUNTIME) public interface RequirePermission { String value(); }编写切面逻辑Aspect Component public class PermissionAspect { Before(annotation(requirePermission)) public void checkPermission(JoinPoint joinPoint, RequirePermission requirePermission) { // 从上下文获取当前用户角色 String currentRole SecurityContextHolder.getContext().getAuthentication().getRole(); if (!requirePermission.value().equals(currentRole)) { throw new AccessDeniedException(无权限访问); } } }这里有个设计心得权限切面中抛出的异常必须交由全局异常处理器统一转成响应结构体不要让框架底层异常直接暴露。否则用户看到的是长达几十行的堆栈而不是友好的无权限提示。5. 手写一个简化版AOP框架原理即代码5.1 设计思路概述文字看一百遍不如代码跑一遍。为了真正理解AOP的织入机制我建议你亲自动手写一个简化版框架。目标不是替代Spring AOP而是用几十行代码复现它的核心流程扫描带有MyAspect注解的类解析切面中的Pointcut表达式生成代理对象在方法调用时执行通知逻辑。我会用JDK动态代理做运行期织入代码控制在核心范围方便你逐行理解。5.2 定义一个最简切面注解Target(ElementType.TYPE) Retention(RetentionPolicy.RUNTIME) public interface MyAspect { // 简单起见只支持通过类名匹配目标 String targetClass(); }5.3 实现代理工厂public class SimpleAopProxy { public static Object wrap(Object target, Class? aspectClass) throws Exception { // 解析切面类的通知方法 Method beforeMethod null; Method afterMethod null; for (Method method : aspectClass.getDeclaredMethods()) { if (method.isAnnotationPresent(MyBefore.class)) { beforeMethod method; } if (method.isAnnotationPresent(MyAfter.class)) { afterMethod method; } } Object aspectInstance aspectClass.getDeclaredConstructor().newInstance(); Class?[] interfaces target.getClass().getInterfaces(); return Proxy.newProxyInstance( target.getClass().getClassLoader(), interfaces, (proxy, method, args) - { if (beforeMethod ! null) { beforeMethod.invoke(aspectInstance); } Object result method.invoke(target, args); if (afterMethod ! null) { afterMethod.invoke(aspectInstance); } return result; } ); } }现在的代码只支持Before和After这已经足够展示核心织入机制。你可以在此基础上扩展Around支持、execution()表达式匹配、多个切面排序等工程量不大但每扩展一个功能对AOP运行机制的理解就加深一层。6. 常见问题与排查技巧实录6.1 切面不生效的几大元凶AOP开发中最常见的问题就是我明明写了切面但方法没有被拦截。排查顺序如下检查目标Bean是否由Spring容器管理切面只能代理容器中的对象new出来的对象永远不会被代理。检查是否走代理调用同类内部直接this.method()调用自研方法代理失效这是最隐蔽的问题。检查切点表达式是否匹配execution表达式写的太严或者包名错误都可能导致静默失效。检查切面类是否注册为Bean标注Aspect的同时必须标注Component或者通过配置类注册两者缺一不可。检查Spring AOP设施是否开启Spring Boot默认开启但原生Spring项目需要EnableAspectJAutoProxy。一个实测案例某项目把Controller所在的包写进了切点表达式但Controller里返回的是ResponseEntity入参对象里有的字段复杂嵌套。结果切面内记录日志时调用toString()触发了重重嵌套的引用关系日志是有了但接口响应时间多了几百毫秒。排查了很久才发现是日志切面导致的性能退化。切面代码的性能开销会被放大到所有匹配方法上写任何逻辑都必须按线上标准来要求。6.2 代理失效的三大经典场景第一类final方法。CGLIB无法重写final方法JDK Proxy不受影响因此当你用CGLIB时目标方法的final关键字就是代理失效点。第二类private方法。切点表达式无法匹配private方法因为代理子类无法继承它。第三类static方法。静态方法属于类而非实例动态代理基于实例生成因此无法拦截。解决办法都很直接去掉final/private/static修饰符或者把方法抽取到独立的被代理Bean中。6.3 多切面执行顺序的坑假设项目中有两个切面日志切面Order(1)和事务切面Order(2)逻辑上的期望是先记录日志然后开启事务方法结束时先提交事务再记录日志。但因为AfterReturning执行顺序倒序的特性如果日志的after逻辑里读取事务内的数据就会在事务提交前读取读到的是未提交数据。我的经验不要在AfterReturning里读取与事务强相关的数据需要读取就把整个逻辑搬到Around中并在proceed()返回后再处理。这样执行顺序完全由你自己控制不会受到多切面优先级反转的影响。6.4 与IoC的关系一道反复出现的面试题面试中经常被问IoC和AOP的原理和关系。我的理解是IoC负责对象的管理和依赖关系的注入AOP负责横切逻辑的织入两者是解耦手段但又是协作关系。AOP需要依赖IoC容器来获取切面实例和目标对象IoC中的代理对象生成又依赖AOP动态代理机制。Spring把这两个支柱结合之后才实现了从对象之间的松耦合到逻辑之间的解耦的飞跃。记忆锚点IoC解决对象创建与依赖的问题AOP解决公共逻辑复用的问题。前者改造的是对象的组装方式后者改造的是方法调用的链路。如果你能结合一段XML配置或者注解配置把两者串起来讲面试官基本就能判定你是真实用过的。7. 实操心得与进阶建议这套体系总结下来真正决定AOP使用水平高低的不是会背几个注解而是能不能判断这个场景适合AOP吗。我会在三个场景谨慎使用AOP一是切面逻辑本身有状态比如依赖了请求作用域的变量而管理不当二是切面链路过长五六个切面嵌套在同一点排查问题会非常痛苦三是团队内没有约定切面命名和职责边界什么逻辑都往切面里塞最后变成天坑。我自己的项目规范里有一条硬性约定每一个切面类都必须在第一行注释里写清楚它作用的方法范围、业务目的、处理了哪些异常并且只允许做一件事。日志归日志权限归权限事务归事务绝不混写。代码审查时优先检查新提交的切面因为切面破坏力比普通业务代码大得多不可见性导致风险蔓延。如果看到这里你想动手验证一下推荐做两个小练习第一在Spring Boot项目里实现一个Controller执行耗时统计的切面把耗时超过500ms的方法打印到独立日志第二针对Transactional同类调用失效问题做一次实操修复对比三种解决方式的差异。这两个练习做完你对AOP的掌握程度会超过一大半声称熟悉AOP的候选人。