场景描述

有一个控制层类OutStoreOverController（简称controller），依赖了XsCustomorExpenseOperateServiceImpl(简称service)类。controller在2个不同方法中分别调用了service的siteDeliverySettlement和stockDownAccounts方法（分别简称为m1和m2）。m1和m2在具体实现的时候又调用了service的内部方法createExpense(申明为public，简称为m3)

方法调用的时序图如下：

现在有一个切面StorageOperateOMSAopServiceImpl，需要切createExpense（m3）方法,在m3方法执行前做点事情。经过配置后，运行发现m3方法并没有被切到

问题分析

当controller构建实例的时候，注入service实例的时候，发现其有切面，产生了代理类serviceProxy并注入给了controller

实际调用的时序图如下

这样就导致m3方法根本没有被切面切入。虽然controller第一次调用的是代理类，但是在调用m3方法的时候是调用的service实例内部的m3方法，所以切面没有生效象

解决问题

XXXXXXXXXX;
m3();
XXXXXXXX;
修改后的写法为：
XXXXXXXX;
Service serviceTemp=ApplicationContextUtil.getBean(Service.class);
serviceTemp.m3();
XXXXXX;

修改后调用的时序图为

总结

真正使切面生效的就是:Service serviceTemp=ApplicationContextUtil.getBean(Service.class); 这一行代码。向spring容器拿的实例，实际上是代理类servciceProxy。调用代理类的m3方法就会去先执行aop中前置切面代码，再会调用真正service实例的m3方法。最终，aop才有效果了。需要理解基于动态代理的aop原理