问题
问题描述：项目中发现，自定义切面注解在 Controller 层正常工作，在 Service 层却无法正常工作。为了便于分析，去掉代码中的业务逻辑，只留下场景。
自定义注解，打印时间
注解解析器
Controller层
Service层
spring.xml 配置文件，主要部分
springmvc.xml 配置文件，主要部分
以上为主要代码。项目运行之后，发现在 Service 层的注解切面未生效，而在 Controller 层正常。而当我将 springmvc.xml 中的
迁移至 spring.xml 中，发现 Service 层与 Controller 层的注解切面均可正常运行。WHY???
从源码的角度探究该问题
为了说清楚这个问题，咱们先看一下Spring容器是如何实现 Bean 自动注入（简化版）
Web 项目的入口是 web.xml，所以咱们从它开始。
web.xml 配置文件，主要部分
Spring 容器 Bean 加载流程
从 Spring 配置部分可以看出，ContextLoaderListener 监听器是 Spring 容器的入口，进入该文件：
ContextLoaderListener 监听器一共有四个方法，可以很容易地判断出来，进入该监听器后，会进入初始化方法：contextInitialized。继而进入 initWebApplicationContext 方法，方法注释中 “Initialize Spring’s web application context for the given servlet context”，明确表明了该方法的目的是初始化 Spring Web 应用。这段代码中有两句话比较关键：
创建 Web 应用容器，即创建了 Spring 容器；
配置并刷新Spring容器。后续发生的所有事，都是从它开始的。进入，里面的重点代码是：
refresh() 方法是spring容器注入bean的核心方法，每一行代码都很重要。代码结构也非常优美，每一行代码背后都完成了一件事，代码结构比较容易理解。由于内容较多，只讲里面跟主题相关的两句话：
获取 Bean 工厂，把你配置文件中的内容，放在 Bean 工厂中，留着后面创建 Bean 时用。
开始创建 Bean，即实现 Spring 中的自动注入功能。进入该方法后，末尾有这么一句话：
继续跟进，贴出该方法中的重点代码：
我们在 preInstantiateSingletons() 方法中，会发现有多个地方出现了 getBean() 方法，究竟咱们贴出来的是哪一句？无关紧要。跟进去之后，
这里调用了 doGetBean() 方法，Spring 中只要以 do 命名的方法，都是真正干活的。重点代码分段贴出分析：
直接获取单例 Bean，若没有取到，继续往下走：
这一段代码单独看，不知所云，里面提到了一个词：Parent。暂且跳过，后续会回来分析这一段。继续：
这段代码中有 createBean，咱们的目的是分析 Bean 的创建过程，此处出现了 create，毫不犹豫地跟进，进入实现类中的方法，有这么一句：
刚才咱们提了，Spring 中有 do 命名的方法，是真正干活的。跟进：
这句话是初始化 Bean，即创建了 Bean，等价于调用了一个类的空构造方法。此时，已经成功地创建了对象，下文需要做的是，给该对象注入需要的属性；
填充 Bean 属性，就是刚才咱们提的，初始化一个对象后，只是一个空对象，需要给它填充属性。跟进，看 Spring 是如何为对象注入属性的，或者说，看一下 Spring 是如何实现 Bean 属性的自动注入：
继续进入 AutowiredAnnotationBeanPostProcessor 的 postProcessPropertyValues 方法：
这句话中，出现了 inject，这个词的意思是“注入”。咱们可以断定，Spring 的自动注入，八成跟它有关了。进入该方法：
<code>element.inject(target, beanName, pvs); </code>
与上一句一样，只是做了一些参数处理，并没有开始注入。继续跟进看：
看到这里，大概明白了 Spring 是如何自动注入了。Java 反射相关的代码，通过反射的方式给 field 赋值。这里的 field 是 Bean 中的某一个属性，例如咱们开始时的 UserController 类中的 userService。getResourceToInject，获取需要赋予的值了，其实这里会重新进入 getBean 方法，获取 Bean 值（例如 UserController 对象中需要注入 userService。），然后赋予 field。至此，Spring容器已经初始化完成，Spring Bean注入的大概流程，咱们也已经熟悉了。回到开始初始化 Spring 容器的地方，ContextLoader 类 initWebApplicationContext 方法，
初始化 Spring 容器之后，将其放入了 servletContext 中。
咱们的问题是，“在项目中，自定义切面注解在 Controller 层正常工作，却在 Service 层无法正常工作？”看完这个，其实并没有解答该问题，咱们下面继续看 SpringMVC Bean的加载流程，看完 SpringMVC 后，答案会自动浮出水面。
SpringMVC 容器 Bean 加载流程
同样，从 web.xml 中的 SpringMVC 配置出发，里面有 DispatcherServlet，这是 SpringMVC 的入口，跟进之后发现方法较多，无法知道会执行哪个方法。但是咱们要记住，DispatcherServlet 本质上是一个 Servlet，通过它的继承关系图也可以证明：
DispatcherServlet继承关系图
看一下 Servlet 的接口：
从 Servlet 接口方法中可以看出，Servlet 的入口是 init 方法，层层跟进（一定要根据 DispatcherServlet 继承图跟进），进入到了 FrameworkServlet 的 initServletBean() 方法，进入方法，贴出重点代码：
字面理解，初始化 SpringMVC Web容器，进入探究：
前面咱们提到，Spring 容器初始化完成之后，放入了 servletContext 中。这里又从 servletContext 获取到了 Spring 容器；
字面理解创建 Web 应用容器，且参数是 Spring 容器。跟进方法：
创建web应用容器，即咱们所理解的 SpringMVC 容器在此创建了；
这里是重点，SpringMVC 容器将 Spring 容器设置成了自己的父容器。
这个方法刚才在分析 Spring Bean 加载流程时，分析过了。其中有一段，前面说，“暂且跳过，后续会回来分析这一段”。现在开始分析：
在 AbstractBeanFactory 类 doGetBean 方法，有这么一段：
这里其实是在获取父容器中的 Bean，若获取到，直接拿到 Bean，这个方法就结束了。结论：子容器可以使用父容器里的 Bean，反之则不行。
现在来解答咱们的问题
当上门这句话放在 springmvc.xml 中时，名为 “printTimeProcessor” 的 Bean 会存在于 SpringMVC 容器，那么 Spring 容器是无法获取它的。而 Service 层恰巧是存在于 Spring 容器中，所以 “printTimeProcessor” 切面对 Service 层不起作用。而 Controller 层本身存在于 SpringMVC 容器，所以 Controller 层可以正常工作。而当它放在 spring.xml 中时，”printTimeProcessor” 是存在于 Spring 容器中，SpringMVC 容器是 Spring 容器的子容器，子容器可以获取到父容器的 Bean，所以 Controller 层与 Service 层都能获取到该 Bean，所有都能正常使用它
欢迎学Java和大数据的朋友们加入java架构交流： 855835163
加群链接：https://jq.qq.com/?_wv=1027&k=5dPqXGI
群内提供免费的架构资料还有：Java工程化、高性能及分布式、高性能、深入浅出。高架构。性能调优、Spring，MyBatis，Netty源码分析和大数据等多个知识点高级进阶干货的免费直播讲解 可以进来一起学习交流哦