从刚把 Spring 和 SpringMVC 的 SSM 项目跑通到真正弄明白容器初始化背后的机制中间隔着一整段“特征驱动开发”的距离——配置能跑、但说不清为什么一旦换个环境、换套配置就抓瞎。这篇文章我想把这个过程完整拆开两个容器到底怎么创建的、父子关系从哪来、Bean 为什么放错位置就报错以及排查时的完整思路。1. 从 web.xml 那两行配置说起双容器的第一印象很多 SSM 项目里web.xml 的开头都是固定套路一段 context-param 配 root 配置文件的路径然后挂一个 ContextLoaderListener再往下是 DispatcherServlet 的 servlet 声明带上 springmvc.xml 的 init-param。这两段配置看起来平平无奇但项目启动时所有的初始化逻辑全都藏在这几行 XML 里。我刚接触这套东西的时候也以为项目里只有一个 Spring 容器——反正 Bean 都能拿到管它几个容器呢。直到有一次把事务配置挪了个位置启动时不报错Service 里的事务却集体失效了才被迫认真去看这背后发生了什么。实际上一个典型的 SpringMVC 项目里至少有两个独立的 Spring 容器一个由 ContextLoaderListener 创建的根容器一个由 DispatcherServlet 创建的子容器。两者以父子关系挂在一起共同撑起整个请求链路。1.1 启动那一刻Servlet 容器看见了什么在服务器启动时Servlet 容器比如 Tomcat负责三步走读取 web.xml、实例化各类 Web 组件、按顺序触发它们的生命周期回调。Spring 就是在这套生命周期钩子上借两个组件完成了容器初始化ContextLoaderListener 实现了 ServletContextListener 接口在 ServletContext 刚创建时触发 contextInitialized此时 Spring 的根容器被初始化并且被绑定到 ServletContext 的属性里。DispatcherServlet 本质上是一个 Servlet默认在第一次请求到达时才初始化如果配置了 load-on-startup则在容器启动阶段就初始化。它的初始化动作里会创建第二个容器并把根容器作为 parent 挂上去。这个过程对环境是“无侵入”的Tomcat 根本不关心你用的是不是 Spring它只负责在正确的时间调用监听器和 Servlet 的回调方法。Spring 的所有初始化逻辑都在这些回调内部完成。1.2 加载顺序与分工一张表说清阶段执行者做了什么关键产物1Tomcat 解析 web.xml识别 context-param、listener、servlet 等标签配置元数据2ContextLoaderListenercontextInitialized创建 root WebApplicationContext加载 spring.xml根容器父容器3DispatcherServlet若配置 load-on-startup创建子 WebApplicationContext加载 springmvc.xml子容器parent 指向根容器4DispatcherServletonRefresh初始化 HandlerMapping、HandlerAdapter、ViewResolver 等Web 层核心组件5请求到达子容器处理请求找不到 Bean 时向上查找父容器请求-响应链路这里最重要的不是记住步骤而是理解一个设计意图根容器承载全项目的公共服务子容器专注 Web 层。Controller 在子容器里Service、DAO 在父容器里子容器需要 Service 时能往上看但父容器永远不会被要求往下找任何东西。2. ContextLoaderListener根容器在后台做的前置工作根容器是整个 SpringMVC 项目的地基。它在 ServletContext 创建后立即初始化不依赖任何请求因此在监听器里能安全地访问 ServletContext 并装载配置。这个过程的核心源码链路值得从头到尾走一遍。2.1 源码视角的初始化链路ContextLoaderListener 的入口是public void contextInitialized(ServletContextEvent event) { initWebApplicationContext(event.getServletContext()); }initWebApplicationContext的逻辑大致如下检查 ServletContext 里有没有已经存在的 ROOT WebApplicationContext如果有直接复用或报错没有则继续。根据配置的 contextClass不配时默认 XmlWebApplicationContext反射创建容器实例。调用configureAndRefreshWebApplicationContext完成配置装载设置容器 ID默认是WebApplicationContext.ROOT绑定 ServletContext读取 context-param 中contextConfigLocation的值按逗号、空格、分号切分成多个配置文件路径最后调用refresh()进入容器的核心初始化流程。容器初始化完成后把这个 WebApplicationContext 实例放到 ServletContext 的属性中属性名是WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE。这就是根容器在后台的全部动作。如果你打开 debug 日志会看到类似 “Root WebApplicationContext: initialization started” 的日志紧接着是一堆 BeanDefinition 的解析和注册日志。2.2 refresh() 的十三个步骤不只是背给面试官听refresh()是 AbstractApplicationContext 中最核心的模板方法。它不是一段“看似高深其实无用”的源码而是真正决定了容器行为顺序、也决定了哪些扩展点何时生效的逻辑。关键节点如下prepareRefresh准备容器环境设置启动时间、初始化属性源并标记容器为激活状态。这个阶段非常早Environment 相关的自定义属性在这里做初步准备。obtainFreshBeanFactory这一步决定了你改 XML 后是不是真正生效了。它会销毁已有 BeanFactory重新创建并解析配置把bean和context:component-scan扫出来的类全部转成 BeanDefinition 注册进容器。prepareBeanFactory给容器设置类加载器、SpEL 解析器、默认的 Environment 等基础设施同时注册一些必要的 BeanPostProcessor比如 ApplicationContextAwareProcessor、ServletContextAwareProcessor在 Web 容器中会有额外扩展。invokeBeanFactoryPostProcessors执行所有 BeanDefinitionRegistryPostProcessor 和 BeanFactoryPostProcessor。context:component-scan的核心处理器 ConfigurationClassPostProcessor 就是在这个阶段被调用配置类里的 Bean 方法也会在这里解析出来。registerBeanPostProcessors实例化并注册所有 BeanPostProcessor。注意这里是注册不是执行真正的执行要等 Bean 创建时。initMessageSource、initApplicationEventMulticaster初始化国际化资源和事件广播器。onRefresh留给子类的扩展点。在 Web 容器里各类 Web 特定组件挂在更后面的阶段初始化但对普通的父容器而言这里通常没太大动作。registerListeners把容器里找到的 ApplicationListener 注册到广播器上。finishBeanFactoryInitialization实例化所有非懒加载的单例 Bean。这是你 Service、DAO、配置类里的大部分普通 Bean 真正 new 出来的时机。finishRefresh发布 ContextRefreshedEvent 事件初始化生命周期处理器。流水线的顺序不是随意的。BeanFactoryPostProcessor 必须在 BeanPostProcessor 之前执行因为配置的解析必须先于 Bean 的创建事件广播器必须先于 Listener 的注册所有准备工作必须在单例实例化之前完成。如果你自定义过 BeanFactoryPostProcessor却总在 Bean 属性注入阶段被覆盖多半就是没搞清楚这个执行顺序。2.3 根容器加载了什么又没加载什么根容器里通常放的是 spring.xml典型内容包括dataSource、事务管理器、SqlSessionFactorycontext:component-scan base-packagecom.xxx.service, com.xxx.dao, com.xxx.config /这类服务层扫描AOP 配置、异步配置、事件监听器但根容器不应该包含Controller、RestController的扫描这是子容器负责的HandlerMapping、HandlerAdapter 等 Web 层组件视图解析器、MultipartResolver、消息转换器为什么因为根容器是公共服务容器它不直接处理请求也不知道“请求”长什么样。把 Web 层组件硬塞进来不仅多余还会让父子容器职责混乱引发后续一大堆 Bean 可见性问题。3. DispatcherServlet 的子容器请求处理器真正安家的地方DispatcherServlet 的初始化比 ContextLoaderListener 更复杂因为它有两个层次FrameworkServlet抽象层负责容器的创建与合并DispatcherServlet 本身负责 Web 组件的装配。两个层次各司其职构成了完整的子容器初始化链。3.1 从 FrameworkServlet 到 DispatcherServlet 的初始化链FrameworkServlet 的initWebApplicationContext()逻辑可以概括为从 ServletContext 的属性中获取 rootContext作为即将创建的子容器的 parent。判断是否有现成的 WebApplicationContext 可以复用。这里有个细节如果你在某个地方手动 new 了一个 WebApplicationContext 并通过 servlet 的 init-param 传入Spring 会尝试复用否则就创建一个新容器。新建容器时根据 init-param 中的 contextClass 选择容器类型默认 XmlWebApplicationContext设置 parent 为 rootContext读取 init-paramcontextConfigLocation把它作为配置文件路径传给容器如果这个参数没有配置Spring 会默认去 WEB-INF 下找[servlet-name]-servlet.xml这个默认行为导致过很多新手困惑——明明没写配置文件为什么启动时还是报了文件找不到调用refresh()触发完整的容器初始化。初始化完成后把子容器放入 ServletContext再调用onRefresh(ApplicationContext context)这个钩子是 FrameworkServlet 为 DispatcherServlet 准备的。如果 Web.xml 里没有配置load-on-startup那么以上所有逻辑都会推迟到第一个请求进来时才执行。所以在开发阶段经常出现“打完包部署完以为好了刷第一个页面时日志才刷出初始化过程”的现象。3.2 onRefresh 阶段HandlerMapping 与 HandlerAdapter 的“自动发现”子容器创建完成后DispatcherServlet 的初始化才真正开始。onRefresh()中一系列 initXxx 方法负责装配 Web 组件initMultipartResolver处理文件上传的解析器默认没有需要手动在 springmvc.xml 里注册 MultipartResolver否则取不到 MultipartFile。initLocaleResolver、initThemeResolver国际化和主题支持一般用默认实现即可。initHandlerMappings把容器中所有 HandlerMapping 类型的 Bean 找出来按 Order 排序后保存。默认会有 RequestMappingHandlerMapping 和 BeanNameUrlHandlerMapping通常前者排在前面。initHandlerAdapters同上负责找到能执行 Handler 的适配器。initHandlerExceptionResolvers异常处理器ControllerAdvice ExceptionHandler 在这里被桥接。initViewResolvers视图解析器。注意这里只找容器中的 ViewResolver Bean不是找 JSP 文件本身。initFlashMapManager支持重定向时 Flash 属性传递。其中值得特别注意的是detectAllHandlerMappings这个参数默认 true意味着只要是容器中 HandlerMapping 类型不管 bean 叫什么名字都会收集进来如果改成 false则只找名为handlerMapping的 Bean。这个参数在排障时很关键——有些团队用自定义 HandlerMapping 并改了 bean 名却忘了调整这个开关。3.3 子容器为什么还要“向上看”子容器创建时设置了 parent这带来一个关键能力子容器中查不到 Bean 时会递归地到父容器中查找。Controller 注入 Service本质上是子容器在getBean(service)时发现没有于是向上找到根容器里的那个实例。这对 SpringMVC 来说是刚需。因为 Web 层与业务层天然是分层依赖关系Controller 必须能拿到 Service。但反过来不行父容器不向下查找。所以如果你在 Service 里注入了 Controller那么无论怎么配置启动时都会直接报 NoSuchBeanDefinitionException——因为父容器找不到子容器里的 Bean。4. 父子容器分治的真正边界Controller 归哪、Service 归哪关于两个容器的归属有一句老话Controller 放子容器Service、DAO 放父容器。但绝大多数人只是记住了这个结论并不理解为什么。如果只知道结论而不知道边界规则一旦项目里的 Bean 互相注入变复杂就会踩到各种“配置看起来都对但就是报错”的坑。4.1 单向可见性规则决定 Bean 不能放错位置先明确一条规则子容器可见父容器父容器不可见子容器。这句简单的话是几乎所有 SSM 配置问题的根源。顺着这条规则推演Controller子容器注入 Service父容器可行因为子容器向上能看到。Service父容器注入 Controller子容器不可行父容器向下看不到。Controller子容器注入另一个 Controller子容器可行两者在同一容器内。Service父容器注入另一个 Service父容器可行同一容器内。如果把这条规则和“扫描范围”结合起来你就会明白为什么约定俗成都把 Controller 放子容器因为 Controller 天生只属于 Web 层它的依赖几乎全是业务层服务而业务层服务不应该依赖任何 Web 组件如果把 Controller 误扫进父容器它的依赖都被迫要在父容器里存在这个项目的分层就乱了。4.2 双扫描的隐患同一个 Service 出现两份代理一个经典坏味道是在两个配置文件里都写上context:component-scan一个扫 Controller另一个扫 Service自以为“两边互补”。比如 spring.xml 扫描了com.xxx.dao, com.xxx.servicespringmvc.xml 扫描了com.xxx.controller, com.xxx.service。两个配置文件都扫了 service 包会发生什么父容器创建时扫入一份 Service 实例并且因为事务配置在父容器里这份实例经过 BeanPostProcessor 处理生成了带有事务增强的代理对象。子容器创建时又扫入一份 Service 实例。注意子容器里的事务配置通常没有所以这份 Service 只是个原始对象或者只套了一层和事务无关的代理。Controller 注入 Service 时子容器优先用自己容器里的那份原始 Service。事务配置不但没生效而且如果子容器那份没有经过代理所有 Transactional 方法相当于裸奔。这个坑极其隐蔽启动不报错、请求不报错只是事务悄悄失效。数据多写入了半截却不会回滚排查半天最后发现是配置扫重了。所以务实的做法是springmvc.xml 只扫描Controller或者干脆用mvc:annotation-driven搭配最小范围扫描service、dao、component、config 全部留给父容器。4.3 事务与 AOP 失效的现场还原再展开一个更常见的 AOP 失效场景。假设你做了登录鉴权切面切点表达式是execution(* com.xxx.service.*.*(..))。切面定义在 spring.xml父容器Service 也放在父容器AOP 生效。看起来没问题但如果某个同事为了跑通一个快速 Demo把 Service 的扫描也放到了 springmvc.xml那个 Service 的实例就“被复制”进了子容器。Controller 调用的是子容器里的那个副本切面在父容器里无法织入它于是日志里切面逻辑一次都没执行。这种问题在 SSM 项目里相当常见原因几乎都是双容器里出现了重复 Bean而 Controller 在子容器的“就近查找”遮住了真正带有增强逻辑的父容器 Bean。排障方法可以简单验证在 Service 的无参构造函数里打印一行日志看启动过程它被实例化了几次如果打印了两次几乎可以认定是双扫描。5. 初始化阶段最容易踩的五个坑与排查链路容器初始化问题有个共同特点报错时机比问题真正的产生时机晚很多。你明明改的是配置文件结果报错发生在启动末尾的 Bean 实例化阶段或者启动时一切正常请求到某个接口才突然炸掉。这是因为 IoC 容器把对象创建时机推迟到了一起表象和根因分离。下面这几个坑是我在真实项目里反复遇到过的。各有各的“伪装”但排查链路是有规律可循的。5.1 坑一NoSuchBeanDefinitionException 的三种可能这类异常最常见的三种根因扫描路径写错导致 Bean 根本没有注册看 BeanDefinition 的数量就能发现。Bean 在另一个容器里而当前容器单向不可见。Service 注入 Controller 是典型代表。Bean 是懒加载或在特定 Profile 下创建当前上下文里还没实例化。排查时不要死磕报错的那一行先打印一下容器中相关 Bean 的注册情况。在启动类里临时加一个 ApplicationRunner 或 CommandLineRunner遍历beanFactory.getBeanDefinitionNames()看目标类是否在其中。如果不在再检查是否容器选错了还是扫描路径不对。5.2 坑二容器初始化了两次配置被重复加载表现启动日志中看到两次 “Root WebApplicationContext: initialization started”。根因一般有两个web.xml 里重复配置了 ContextLoaderListener或者部署描述符在打包时被合并某处在代码中手动调用了new ClassPathXmlApplicationContext(spring.xml)又同时依赖了 ContextLoaderListener 启动的容器。第二种情况更隐蔽。如果代码里有new ClassPathXmlApplicationContext的全局容器事务、Service、DAO 都被加载两次一旦和 Web 容器里的根容器不是同一个实例Controller 拿到的 Service 永远是手动创建的那份事务自然失效。排查方法在AbstractApplicationContext.refresh()打上断点或 debug 日志观察触发栈看是谁触发了第二次 refresh。如果是自定义代码优先重构为把 Bean 注入现有容器而不是另起炉灶。5.3 坑三getBeanNamesForType 查不到父容器的 Bean很多框架代码里会用applicationContext.getBeansOfType(SomeInterface.class)来做扩展点收集但在 SSM 双容器环境下这个方法有一个隐藏行为它默认只在当前容器的 BeanDefinition 中查找不会递归父容器。如果你在子容器里执行这个方法想拿到父容器中所有 Service 的实现类结果只会拿到空集合。这不是 bug而是 Spring 的设计getBean会向上查找但getBeanNamesForType系列方法不会。子容器内部也有自己的getBeanNamesForType缓存机制而且不会越过容器边界。解决方案也简单在子容器场景下需要先拿到根容器再分别查询或者直接在父容器里做扩展点收集。写框架代码时尤其要注意这一点不然你收集的总是“半个容器”的内容。5.4 坑四自定义 BeanFactoryPostProcessor 被多次触发你写了一个自定义 BeanFactoryPostProcessor想在容器启动时修改某些 Bean 定义。结果发现它被执行了两次修改的效果也被叠加出现诡异数据。原因还是双容器BeanFactoryPostProcessor 是在refresh()期间执行的根容器 refresh 一次、子容器 refresh 一次如果这个 PostProcessor 在两个容器里都被注册了就会执行两次。更复杂的情况是你把它定义在某个公共配置类里这个配置类被两个容器都扫描了。最直接的做法是把这类全局处理器只放在父容器的扫描范围内或者在处理逻辑里判断当前容器的 ID只对特定容器执行。5.5 坑五日志里看不到初始化过程无法判断进度很多人遇到启动挂起、加载缓慢却看不到任何日志原因是 Spring 默认日志级别可能是 INFO而容器初始化的大量调试信息在 DEBUG 级别。如果你不是用 logback、log4j2 管理日志只是依赖 Spring 自带的 JUL可以把org.springframework.web.context、org.springframework.beans.factory、org.springframework.context.support这几个包的日志级别调整到 DEBUG。启动过程中你会看到每一步的详细日志哪个配置文件被加载扫描到了多少 BeanDefinitionBeanFactoryPostProcessor 执行了什么单例实例化进度。这对排查“到底是卡在扫描阶段还是卡在 Bean 初始化阶段”特别有用。你可以在日志里明确看到容器创建和刷新过程的关键节点。6. 注解配置与 Spring Boot 时代初始化过程去哪了现在很多新项目已经不用 web.xmlSpring Boot 更是把开箱即用贯彻到底。有人会问既然 Boot 里这些配置都没了这套双容器初始化过程还有必要学吗我的看法是没有了不等于不存在而是被框架消化掉了。理解旧机制能让你在新框架下遇到问题时不发怵。6.1 WebApplicationInitializer 重构起了一套新启动链Servlet 3.0 之后web.xml 可以不存在了替代者是ServletContainerInitializer和WebApplicationInitializer机制。Spring MVC 通过AbstractDispatcherServletInitializerAbstractAnnotationConfigDispatcherServletInitializer是它的子类在容器启动时自动注册 ContextLoaderListener 和 DispatcherServlet。从机制上与 web.xml 没有本质变化只是位置搬到了 Java 类里getRootConfigClasses()返回根容器需要的配置类getServletConfigClasses()返回子容器需要的配置类getServletMappings()指定 DispatcherServlet 映射路径。容器加载顺序仍然是先根容器后子容器父容器与子容器的边界规则完全沿用传统 SSM 的那套。6.2 Spring Boot 为何不再需要父子容器Spring Boot 默认是把所有 Bean 放进同一个上下文不再手动分成父子两层。DispatcherServlet 会被注册但要扫描的 Bean 都在同一个 ApplicationContext 里。这种简化不是随意为之而是因为 Boot 的自动配置统一接管了依赖管理把 Controller、Service、DAO、数据源全部装进一个容器后通过 BeanPostProcessor 和 Conditional 配置来分层管理。好处是显而易见的不会再有“Service 在两个容器里出现两份实例”的问题事务配置也更不容易因为扫描重复而失效。坏处是一些从旧项目迁移来的配置尤其是依赖根容器与子容器隔离特性的老代码迁移时会遇到 Bean 可见性变化带来的报错。6.3 旧机制的知识复用价值即便你只用 Spring Boot也会遇到需要理解容器初始化原理的场景排查启动时 Bean 循环依赖理解为什么某些配置类会被重复初始化理解ApplicationContext在 Web 环境中的生命周期与普通环境不同编写基于 Servlet 容器的自定义集成比如自行注册多个 DispatcherServletBoot 天然支持多 DispatcherServlet 扩展只是知道父子容器机制的人更清楚各组件归属。框架在简化但底层的 BeanFactory 生命周期、refresh 模板方法、BeanPostProcessor 扩展点这些东西只要存在理解旧机制就不会白费。个人习惯是每次在项目里遇到 Bean 找不到、事务不生效、切面不拦截这类问题都会先回到两个问题我这些类分别在哪个容器里注册的它们在运行时又是从哪个容器里取出来的只要这两个问题能准确回答大半初始化阶段的坑都能绕开。如果还想省点事启动脚本里可以临时加一句-Dlogging.level.org.springframework.web.contextDEBUG亲眼看看两个容器各自的启动日志比背多少遍文档都管用。