1. 项目概述从一次线上故障说起那天晚上报警信息突然炸了锅。一个核心服务的健康检查接口连续报错导致整个服务集群被负载均衡器摘除线上流量瞬间中断。紧急登录服务器排查发现服务进程还在但所有HTTP端口都处于TIME_WAIT状态新的连接根本进不来。重启服务后一切恢复正常。复盘时我们盯着日志里那句“Tomcat started on port(s): 8080 (http) with context path ‘’”突然意识到一个问题Spring Boot的嵌入式Web容器它到底是什么时候被加载、初始化和启动的这个看似简单的问题背后牵扯到整个应用的启动生命周期、Bean的加载顺序以及我们日常配置的server.port、server.servlet.context-path究竟在哪个环节生效。对于任何一个使用Spring Boot的开发者尤其是需要处理高并发、定制化启动流程或解决诡异启动失败问题的朋友理解嵌入式Web容器的加载时机不再是“锦上添花”而是“雪中送炭”的必备知识。它决定了你的RestController何时能对外提供服务你的Filter和Servlet在什么阶段被注册以及当端口冲突或SSL证书加载失败时你该从哪段日志开始排查。今天我们就抛开官方文档那高度概括的流程图深入到SpringApplication.run()的源码深处结合实际的调试案例和性能优化场景把Web容器从“静默”到“轰鸣”的全过程彻底拆解清楚。2. 核心流程全景解析一个请求的“诞生前夜”要理解Web容器的加载我们必须先建立一个宏观视角它并非一个孤立事件而是Spring Boot应用启动交响乐中的一个关键乐章。整个流程可以划分为几个清晰的阶段而Web容器的故事贯穿其中。2.1 启动阶段划分与容器角色定位Spring Boot应用的启动粗略来看经历了环境准备 - 应用上下文创建 - Bean加载与刷新 - 容器启动 - 后置处理这几个核心阶段。嵌入式Web容器如Tomcat, Jetty, Undertow的生命周期紧密嵌入在“应用上下文刷新”这个最复杂的阶段中。它的特殊之处在于它既是一个被Spring管理的Bean更准确地说是一个ServletWebServerApplicationContext中的特殊组件又是整个应用对外提供HTTP服务的基石。这种双重身份决定了它的加载时机必须精心设计既要确保依赖的Bean如数据源、配置中心客户端先就绪又要保证在一切准备妥当后能够迅速拉起端口开始服务。2.2 关键组件交互图概念模型虽然我们不能画图但可以通过文字描述来构建这个心智模型。想象一下在ApplicationContext的刷新过程refresh()方法中有一个名为onRefresh()的模板方法被调用。对于Web应用ServletWebServerApplicationContext重写了这个方法。在这里它触发了一个核心动作创建Web服务器。这个动作的执行者是一个实现了ServletWebServerFactory接口的Bean例如TomcatServletWebServerFactory。工厂Bean会根据application.properties中的server.*配置实例化一个Web服务器对象TomcatWebServer但请注意此时服务器只是被创建出来并未启动。紧接着在刷新过程的后续阶段Spring会初始化所有单例Bean。这包括了你的RestController、Service以及所有的Filter和Servlet通过ServletRegistrationBean或FilterRegistrationBean注册。这些组件被创建、装配并注册到刚刚创建的Web服务器实例中。最后在刷新方法即将结束前会触发另一个关键方法finishRefresh()。在这里那个早已准备就绪、装满了各种Servlet和Filter的Web服务器才正式调用start()方法打开网络端口开始监听请求。至此一个HTTP请求才有了被接收和处理的物理通道。3. 深度时序拆解源码中的关键脚印理论说再多不如代码看一眼。我们深入到几个最关键的源码节点看看Web容器加载的“决定性瞬间”。3.1 SpringApplication.run() 的旅程起点一切始于SpringApplication.run(YourApplication.class, args)。这个方法内部会创建一个SpringApplication实例并调用其run方法。在run方法中前期的重点是准备环境prepareEnvironment和创建应用上下文createApplicationContext。对于Web应用这里通过DeducedWebApplicationType推断出应用类型为SERVLET从而决定创建AnnotationConfigServletWebServerApplicationContext实例。请注意此时上下文对象是空的Web容器连影子都没有。3.2 刷新上下文onRefresh() 的魔法时刻应用上下文创建后会调用其refresh()方法。这是Spring框架最核心、最复杂的方法之一。对于我们关注的问题其中第7步onRefresh()是真正的起点。ServletWebServerApplicationContext类重写了它protected void onRefresh() { super.onRefresh(); try { createWebServer(); // 关键方法 } catch (Throwable ex) { throw new ApplicationContextException(Unable to start web server, ex); } }createWebServer()方法做了以下几件事获取工厂从Spring容器中获取ServletWebServerFactoryBeanSpring Boot通过自动配置已经为我们配置好了基于当前classpath的工厂比如引入了spring-boot-starter-web默认就是Tomcat。创建服务器调用工厂的getWebServer(ServletContextInitializer... initializers)方法。这个方法会实例化一个Web服务器例如Tomcat并应用所有server.*配置端口、上下文路径、连接器、SSL等。此时Tomcat对象存在了端口绑定了吗并没有。对于Tomcat它只是创建了Server、Service、Connector、Engine、Host等一堆内部对象并设置了参数但Connector负责网络通信的组件还没有开始监听端口。注册初始化器将一组ServletContextInitializer其中包含了所有通过Bean方式注册的Servlet、Filter、Listener的初始化逻辑传递给服务器。服务器会保存这些初始化器留待后续调用。重要提示createWebServer()发生在单例Bean初始化之前。这意味着ServletWebServerFactory本身必须是一个提前初始化的Bean通常通过自动配置完成而你的业务Bean如Service此时还未被创建。3.3 Bean初始化与Servlet注册的先后顺序refresh()方法继续执行来到了第11步finishBeanFactoryInitialization(beanFactory)。这一步负责初始化所有剩余的单例Bean非懒加载的。你的RestController、Component、Service、Repository以及那些ServletRegistrationBean和FilterRegistrationBean都在这个阶段被实例化和初始化。ServletRegistrationBean和FilterRegistrationBean是特殊的Bean它们实现了ServletContextInitializer接口。在它们被创建后其初始化逻辑并不会立刻执行。相反它们被“收集”起来等待时机。这个时机就是Web服务器启动前。3.4 容器启动的临门一脚finishRefresh()refresh()方法的最后一步是finishRefresh()。ServletWebServerApplicationContext再次重写了它protected void finishRefresh() { super.finishRefresh(); WebServer webServer startWebServer(); // 启动服务器 if (webServer ! null) { publishEvent(new ServletWebServerInitializedEvent(webServer, this)); } }startWebServer()方法会获取之前在onRefresh()阶段创建的WebServer对象然后调用其start()方法。以Tomcat为例TomcatWebServer.start()会启动Tomcat的Server。关键动作在启动过程中Tomcat会触发其ServletContext的初始化。这时之前保存的那些ServletContextInitializer包括所有ServletRegistrationBean和FilterRegistrationBean封装的逻辑会被逐个调用。你的Servlet和Filter正是在这个时刻被注册到Tomcat的ServletContext中的。最后Tomcat的Connector开始启动绑定到配置的IP和端口例如0.0.0.0:8080并开始接受网络连接。此时日志中才会打印出那句熟悉的“Tomcat started on port(s): 8080”。所以完整的顺序是创建Web服务器对象 - 初始化所有业务Bean包括注册Bean- 启动Web服务器在启动过程中注册Servlet/Filter- 打开端口监听。4. 配置生效时机与自定义扩展点理解了核心时序我们就能明白各种配置和自定义逻辑在何时起作用。4.1 server.* 配置的生效阶段application.properties或application.yml中的server.port、server.servlet.context-path、server.tomcat.*等配置是在哪个阶段被读取的呢它们主要在两个阶段生效工厂Bean创建阶段ServletWebServerFactory这个Bean本身是通过自动配置如ServletWebServerFactoryAutoConfiguration创建的。在创建这个工厂Bean的过程中Spring会通过ConfigurationProperties将server.*前缀的配置绑定到ServerProperties这个配置类上。工厂Bean如TomcatServletWebServerFactory会读取ServerProperties中的值来配置自己。因此当你通过Bean方式自定义一个ServletWebServerFactory时你必须手动将ServerProperties注入进去或者自己处理这些配置否则server.*配置将失效。Web服务器创建阶段在createWebServer()方法中调用factory.getWebServer()时工厂会利用已经设置好的配置去实例化并配置具体的Web服务器对象如设置Tomcat的Connector端口。4.2 关键扩展点ServletContextInitializer如果你想在Servlet容器初始化时做一些事情例如注册原生的Servlet、Filter或Listener最佳实践不是直接实现Servlet API的接口而是使用Spring Boot提供的ServletContextInitializer接口或者更便捷地使用其实现类ServletRegistrationBean、FilterRegistrationBean、ServletListenerRegistrationBean。Configuration public class MyServletConfig { Bean public ServletRegistrationBeanMyServlet myServlet() { ServletRegistrationBeanMyServlet bean new ServletRegistrationBean(new MyServlet(), /myPath/*); bean.setLoadOnStartup(1); return bean; } }为什么这样好因为如前所述这些RegistrationBean也是普通的Spring Bean它们享受依赖注入、条件化配置等所有Spring Bean的特性。并且它们的初始化逻辑即onStartup方法会被延迟到Web服务器启动前的那一刻才执行确保了执行时机绝对正确。4.3 监听容器事件ApplicationListenerSpring Boot提供了丰富的事件机制允许我们在生命周期的特定节点插入逻辑。与Web容器启动相关的重要事件有ApplicationStartedEvent在run()方法一开始上下文还未刷新时触发。此时Web容器未创建。ApplicationPreparedEvent在环境已准备、上下文已创建但未刷新时触发。此时Web容器未创建。ApplicationReadyEvent在refresh()完成并且任何CommandLineRunner和ApplicationRunnerBean被调用之后触发。这是一个非常重要的信号它表明应用已完全就绪可以对外提供服务了。此时Web容器肯定已经启动。ServletWebServerInitializedEvent在finishRefresh()中Web服务器成功启动后立即发布。这个事件携带了WebServer对象你可以从中获取端口等信息。如果你的初始化逻辑依赖于Web容器已经就绪例如需要向注册中心报告自己的IP和端口那么监听ApplicationReadyEvent或ServletWebServerInitializedEvent是安全的选择。5. 常见问题场景与排查实战理论结合实战下面我们看几个典型问题如何利用对加载时机的理解来快速定位。5.1 端口绑定失败Address already in use这是最常见的问题。错误通常发生在finishRefresh()阶段Tomcat的Connector尝试绑定端口时。根据我们的时序分析此时所有的Bean包括你的业务逻辑都已经初始化完毕。所以如果你在某个Bean的PostConstruct方法或构造方法里启动了一个线程池或者连接了某个外部服务这些操作都已经完成了。问题可能在于另一个进程占用了端口。同一个应用的前一个实例没有完全关闭僵尸进程或shutdown钩子未执行。排查技巧不要只看最后一句报错。查看更早的日志确认应用是否尝试了多次启动比如在onRefresh失败后Spring可能会尝试重启上下文。使用命令行工具如lsof -i:8080或netstat -ano | findstr 8080锁定占用端口的进程ID。5.2 静态资源或首页无法访问假设你配置了spring.web.resources.static-locations但访问/或/index.html却得到404。这可能是因为你的静态资源路径配置有误但更深层的原因可能与加载顺序有关。负责映射静态资源的WelcomePageHandlerMapping和ResourceHttpRequestHandler是在DispatcherServlet初始化过程中注册的而DispatcherServlet的初始化又是在ServletWebServerInitializedEvent发布之前。如果有一个自定义的Filter或Servlet拦截了所有路径/*并且处理不当就可能阻止对静态资源的请求到达Spring MVC的DispatcherServlet。排查技巧开启Spring Boot的Actuator访问/actuator/mappings端点查看所有已注册的HTTP映射确认你的静态资源路径是否在其中。检查是否有全局Filter做了不恰当的拦截。5.3 自定义Filter/Servlet不生效你定义了一个FilterRegistrationBean但请求过来发现它没起作用。根据时序FilterRegistrationBean的初始化逻辑是在Web服务器启动过程中被调用的。如果它不生效可能的原因有顺序问题Filter有执行顺序order可能被其他Filter提前拦截并结束了请求链。URL模式错误setUrlPatterns配置的路径与请求路径不匹配。Bean未被扫描到你的配置类不在主应用类的同级或子级包下且未使用ComponentScan显式指定。条件化配置冲突你的Configuration类上可能有ConditionalOnXXX条件在某种环境下不满足导致整个配置类被跳过。排查技巧在FilterRegistrationBean的Bean定义方法上打上断点或者在其onStartup方法内打上断点观察它是否被Spring创建和调用。同时检查应用启动日志看是否有关于Filter注册的提示信息。5.4 启动缓慢分析与优化应用启动慢Web容器加载占了大部分时间。优化可以从以下几个点入手懒加载Lazy Initialization在application.properties中设置spring.main.lazy-initializationtrue。这会让所有Bean变为懒加载直到第一次被请求时才创建。这可以显著加快启动速度因为createWebServer和大部分Bean初始化都被推迟了。但代价是第一个请求的延迟会变高并且需要确保你的Bean没有错误的循环依赖在懒加载下更容易暴露。减少类路径扫描使用SpringBootApplication的scanBasePackages属性明确指定要扫描的包避免扫描整个classpath。排查耗时的Bean使用Actuator的/actuator/startup端点需要依赖spring-boot-starter-actuator并配置management.endpoints.web.exposure.includestartup它可以以树状结构展示启动过程中每个Bean的初始化耗时帮你找到瓶颈。Tomcat优化对于Tomcat可以调优server.tomcat.threads.max不要盲目设大、connection-timeout等参数。但通常这不是启动慢的主因。实操心得在微服务架构下尤其是使用Kubernetes的滚动更新或弹性伸缩时启动速度直接影响到服务的可用性和弹性。将非核心的、重量级的客户端如某些报表生成SDK改为懒加载是我们在多个项目中验证过的有效手段。但务必在预发环境充分测试确保懒加载不会引发NullPointerException因为Bean可能还未初始化。6. 不同容器Tomcat/Jetty/Undertow的细微差异Spring Boot的抽象做得很好大部分情况下切换容器无需关心加载时机。但底层实现仍有细微差别了解它们有助于深度排错。Tomcat最常用也是默认容器。它的Connector启动是同步的绑定端口失败会直接抛出异常。其线程模型BIO/NIO/APR对启动阶段影响不大主要影响运行时性能。Jetty启动速度通常被认为比Tomcat稍快。Jetty的Server启动过程也是类似的。需要注意的是Jetty的线程池和连接器配置方式与Tomcat不同对应的配置属性前缀是server.jetty.*。Undertow一个高性能、非阻塞的容器。由于基于XNIO它的启动和IO处理模型与Tomcat/Jetty不同。在finishRefresh()阶段启动Undertow时它内部会启动XNIO的工作线程。Undertow没有传统的ServletContext初始化回调但Spring Boot通过适配器仍然在相同的时机服务器启动前调用ServletContextInitializer。共同点无论哪种容器Spring Boot都通过ServletWebServerFactory和WebServer接口进行了统一抽象。createWebServer()和finishRefresh()的调用时机是完全一致的。差异主要体现在工厂Bean如何配置底层容器参数以及容器自身启动的细节上。当你遇到容器特有的原生错误比如Undertow的XNIO线程创建失败Jetty的QueuedThreadPool耗尽就需要查阅对应容器的文档但问题的触发阶段依然在我们的时序框架内。7. 高级话题在容器启动前后执行自定义逻辑有时我们需要在Web容器启动前或刚刚启动后执行一些特定的初始化逻辑。启动前如果你想在Web容器创建之前做一些事情例如检查某个外部配置中心是否可用可以实现ApplicationContextInitializer接口并在SpringApplication上注册。或者更简单的方法是在Bean方法中返回一个ServletWebServerFactory并在创建工厂Bean的过程中加入你的逻辑。但请注意此时ServerProperties可能还未完全绑定取决于你的Bean方法执行顺序要小心处理。启动后接收请求前这是更常见的需求。例如预热缓存、初始化连接池、加载大数据字典。最佳实践是使用CommandLineRunner或ApplicationRunner接口。它们的run方法会在ApplicationReadyEvent发布之前被调用但此时Web容器已经启动ServletWebServerInitializedEvent已发布。所以在这里执行预热逻辑是安全的。Component public class MyCacheWarmuper implements CommandLineRunner { Override public void run(String... args) throws Exception { // 此时Web容器已启动可以安全地进行需要网络端口的操作 warmUpCache(); } }优雅关闭理解启动顺序对优雅关闭也至关重要。当收到关闭信号如SIGTERM时Spring Boot会发布ContextClosedEvent然后开始销毁Bean。Web容器的关闭是销毁过程的一部分。确保你的Bean在PreDestroy方法中不依赖Web容器因为容器可能已关闭对于需要完成正在处理的HTTP请求的场景要合理配置server.shutdowngraceful并设置合适的spring.lifecycle.timeout-per-shutdown-phase。整个Spring Boot嵌入式Web容器的加载过程就像一场精心编排的戏剧。从环境准备、工厂创建、服务器实例化到Bean装配、初始化器注册最后在finishRefresh()的指挥棒下服务器启动、端口打开大幕正式拉开。理解每一个环节的时机不仅能让你在出现问题时快速定位更能让你在设计和优化应用时做出更合理、更稳健的决策。下次当你再看到“Tomcat started on port(s)”这行日志时希望你的脑海中能清晰地浮现出它背后这一整套复杂而精妙的启动图谱。
Spring Boot嵌入式Web容器启动时序深度解析：从源码到实战
发布时间：2026/5/20 19:30:22
1. 项目概述从一次线上故障说起那天晚上报警信息突然炸了锅。一个核心服务的健康检查接口连续报错导致整个服务集群被负载均衡器摘除线上流量瞬间中断。紧急登录服务器排查发现服务进程还在但所有HTTP端口都处于TIME_WAIT状态新的连接根本进不来。重启服务后一切恢复正常。复盘时我们盯着日志里那句“Tomcat started on port(s): 8080 (http) with context path ‘’”突然意识到一个问题Spring Boot的嵌入式Web容器它到底是什么时候被加载、初始化和启动的这个看似简单的问题背后牵扯到整个应用的启动生命周期、Bean的加载顺序以及我们日常配置的server.port、server.servlet.context-path究竟在哪个环节生效。对于任何一个使用Spring Boot的开发者尤其是需要处理高并发、定制化启动流程或解决诡异启动失败问题的朋友理解嵌入式Web容器的加载时机不再是“锦上添花”而是“雪中送炭”的必备知识。它决定了你的RestController何时能对外提供服务你的Filter和Servlet在什么阶段被注册以及当端口冲突或SSL证书加载失败时你该从哪段日志开始排查。今天我们就抛开官方文档那高度概括的流程图深入到SpringApplication.run()的源码深处结合实际的调试案例和性能优化场景把Web容器从“静默”到“轰鸣”的全过程彻底拆解清楚。2. 核心流程全景解析一个请求的“诞生前夜”要理解Web容器的加载我们必须先建立一个宏观视角它并非一个孤立事件而是Spring Boot应用启动交响乐中的一个关键乐章。整个流程可以划分为几个清晰的阶段而Web容器的故事贯穿其中。2.1 启动阶段划分与容器角色定位Spring Boot应用的启动粗略来看经历了环境准备 - 应用上下文创建 - Bean加载与刷新 - 容器启动 - 后置处理这几个核心阶段。嵌入式Web容器如Tomcat, Jetty, Undertow的生命周期紧密嵌入在“应用上下文刷新”这个最复杂的阶段中。它的特殊之处在于它既是一个被Spring管理的Bean更准确地说是一个ServletWebServerApplicationContext中的特殊组件又是整个应用对外提供HTTP服务的基石。这种双重身份决定了它的加载时机必须精心设计既要确保依赖的Bean如数据源、配置中心客户端先就绪又要保证在一切准备妥当后能够迅速拉起端口开始服务。2.2 关键组件交互图概念模型虽然我们不能画图但可以通过文字描述来构建这个心智模型。想象一下在ApplicationContext的刷新过程refresh()方法中有一个名为onRefresh()的模板方法被调用。对于Web应用ServletWebServerApplicationContext重写了这个方法。在这里它触发了一个核心动作创建Web服务器。这个动作的执行者是一个实现了ServletWebServerFactory接口的Bean例如TomcatServletWebServerFactory。工厂Bean会根据application.properties中的server.*配置实例化一个Web服务器对象TomcatWebServer但请注意此时服务器只是被创建出来并未启动。紧接着在刷新过程的后续阶段Spring会初始化所有单例Bean。这包括了你的RestController、Service以及所有的Filter和Servlet通过ServletRegistrationBean或FilterRegistrationBean注册。这些组件被创建、装配并注册到刚刚创建的Web服务器实例中。最后在刷新方法即将结束前会触发另一个关键方法finishRefresh()。在这里那个早已准备就绪、装满了各种Servlet和Filter的Web服务器才正式调用start()方法打开网络端口开始监听请求。至此一个HTTP请求才有了被接收和处理的物理通道。3. 深度时序拆解源码中的关键脚印理论说再多不如代码看一眼。我们深入到几个最关键的源码节点看看Web容器加载的“决定性瞬间”。3.1 SpringApplication.run() 的旅程起点一切始于SpringApplication.run(YourApplication.class, args)。这个方法内部会创建一个SpringApplication实例并调用其run方法。在run方法中前期的重点是准备环境prepareEnvironment和创建应用上下文createApplicationContext。对于Web应用这里通过DeducedWebApplicationType推断出应用类型为SERVLET从而决定创建AnnotationConfigServletWebServerApplicationContext实例。请注意此时上下文对象是空的Web容器连影子都没有。3.2 刷新上下文onRefresh() 的魔法时刻应用上下文创建后会调用其refresh()方法。这是Spring框架最核心、最复杂的方法之一。对于我们关注的问题其中第7步onRefresh()是真正的起点。ServletWebServerApplicationContext类重写了它protected void onRefresh() { super.onRefresh(); try { createWebServer(); // 关键方法 } catch (Throwable ex) { throw new ApplicationContextException(Unable to start web server, ex); } }createWebServer()方法做了以下几件事获取工厂从Spring容器中获取ServletWebServerFactoryBeanSpring Boot通过自动配置已经为我们配置好了基于当前classpath的工厂比如引入了spring-boot-starter-web默认就是Tomcat。创建服务器调用工厂的getWebServer(ServletContextInitializer... initializers)方法。这个方法会实例化一个Web服务器例如Tomcat并应用所有server.*配置端口、上下文路径、连接器、SSL等。此时Tomcat对象存在了端口绑定了吗并没有。对于Tomcat它只是创建了Server、Service、Connector、Engine、Host等一堆内部对象并设置了参数但Connector负责网络通信的组件还没有开始监听端口。注册初始化器将一组ServletContextInitializer其中包含了所有通过Bean方式注册的Servlet、Filter、Listener的初始化逻辑传递给服务器。服务器会保存这些初始化器留待后续调用。重要提示createWebServer()发生在单例Bean初始化之前。这意味着ServletWebServerFactory本身必须是一个提前初始化的Bean通常通过自动配置完成而你的业务Bean如Service此时还未被创建。3.3 Bean初始化与Servlet注册的先后顺序refresh()方法继续执行来到了第11步finishBeanFactoryInitialization(beanFactory)。这一步负责初始化所有剩余的单例Bean非懒加载的。你的RestController、Component、Service、Repository以及那些ServletRegistrationBean和FilterRegistrationBean都在这个阶段被实例化和初始化。ServletRegistrationBean和FilterRegistrationBean是特殊的Bean它们实现了ServletContextInitializer接口。在它们被创建后其初始化逻辑并不会立刻执行。相反它们被“收集”起来等待时机。这个时机就是Web服务器启动前。3.4 容器启动的临门一脚finishRefresh()refresh()方法的最后一步是finishRefresh()。ServletWebServerApplicationContext再次重写了它protected void finishRefresh() { super.finishRefresh(); WebServer webServer startWebServer(); // 启动服务器 if (webServer ! null) { publishEvent(new ServletWebServerInitializedEvent(webServer, this)); } }startWebServer()方法会获取之前在onRefresh()阶段创建的WebServer对象然后调用其start()方法。以Tomcat为例TomcatWebServer.start()会启动Tomcat的Server。关键动作在启动过程中Tomcat会触发其ServletContext的初始化。这时之前保存的那些ServletContextInitializer包括所有ServletRegistrationBean和FilterRegistrationBean封装的逻辑会被逐个调用。你的Servlet和Filter正是在这个时刻被注册到Tomcat的ServletContext中的。最后Tomcat的Connector开始启动绑定到配置的IP和端口例如0.0.0.0:8080并开始接受网络连接。此时日志中才会打印出那句熟悉的“Tomcat started on port(s): 8080”。所以完整的顺序是创建Web服务器对象 - 初始化所有业务Bean包括注册Bean- 启动Web服务器在启动过程中注册Servlet/Filter- 打开端口监听。4. 配置生效时机与自定义扩展点理解了核心时序我们就能明白各种配置和自定义逻辑在何时起作用。4.1 server.* 配置的生效阶段application.properties或application.yml中的server.port、server.servlet.context-path、server.tomcat.*等配置是在哪个阶段被读取的呢它们主要在两个阶段生效工厂Bean创建阶段ServletWebServerFactory这个Bean本身是通过自动配置如ServletWebServerFactoryAutoConfiguration创建的。在创建这个工厂Bean的过程中Spring会通过ConfigurationProperties将server.*前缀的配置绑定到ServerProperties这个配置类上。工厂Bean如TomcatServletWebServerFactory会读取ServerProperties中的值来配置自己。因此当你通过Bean方式自定义一个ServletWebServerFactory时你必须手动将ServerProperties注入进去或者自己处理这些配置否则server.*配置将失效。Web服务器创建阶段在createWebServer()方法中调用factory.getWebServer()时工厂会利用已经设置好的配置去实例化并配置具体的Web服务器对象如设置Tomcat的Connector端口。4.2 关键扩展点ServletContextInitializer如果你想在Servlet容器初始化时做一些事情例如注册原生的Servlet、Filter或Listener最佳实践不是直接实现Servlet API的接口而是使用Spring Boot提供的ServletContextInitializer接口或者更便捷地使用其实现类ServletRegistrationBean、FilterRegistrationBean、ServletListenerRegistrationBean。Configuration public class MyServletConfig { Bean public ServletRegistrationBeanMyServlet myServlet() { ServletRegistrationBeanMyServlet bean new ServletRegistrationBean(new MyServlet(), /myPath/*); bean.setLoadOnStartup(1); return bean; } }为什么这样好因为如前所述这些RegistrationBean也是普通的Spring Bean它们享受依赖注入、条件化配置等所有Spring Bean的特性。并且它们的初始化逻辑即onStartup方法会被延迟到Web服务器启动前的那一刻才执行确保了执行时机绝对正确。4.3 监听容器事件ApplicationListenerSpring Boot提供了丰富的事件机制允许我们在生命周期的特定节点插入逻辑。与Web容器启动相关的重要事件有ApplicationStartedEvent在run()方法一开始上下文还未刷新时触发。此时Web容器未创建。ApplicationPreparedEvent在环境已准备、上下文已创建但未刷新时触发。此时Web容器未创建。ApplicationReadyEvent在refresh()完成并且任何CommandLineRunner和ApplicationRunnerBean被调用之后触发。这是一个非常重要的信号它表明应用已完全就绪可以对外提供服务了。此时Web容器肯定已经启动。ServletWebServerInitializedEvent在finishRefresh()中Web服务器成功启动后立即发布。这个事件携带了WebServer对象你可以从中获取端口等信息。如果你的初始化逻辑依赖于Web容器已经就绪例如需要向注册中心报告自己的IP和端口那么监听ApplicationReadyEvent或ServletWebServerInitializedEvent是安全的选择。5. 常见问题场景与排查实战理论结合实战下面我们看几个典型问题如何利用对加载时机的理解来快速定位。5.1 端口绑定失败Address already in use这是最常见的问题。错误通常发生在finishRefresh()阶段Tomcat的Connector尝试绑定端口时。根据我们的时序分析此时所有的Bean包括你的业务逻辑都已经初始化完毕。所以如果你在某个Bean的PostConstruct方法或构造方法里启动了一个线程池或者连接了某个外部服务这些操作都已经完成了。问题可能在于另一个进程占用了端口。同一个应用的前一个实例没有完全关闭僵尸进程或shutdown钩子未执行。排查技巧不要只看最后一句报错。查看更早的日志确认应用是否尝试了多次启动比如在onRefresh失败后Spring可能会尝试重启上下文。使用命令行工具如lsof -i:8080或netstat -ano | findstr 8080锁定占用端口的进程ID。5.2 静态资源或首页无法访问假设你配置了spring.web.resources.static-locations但访问/或/index.html却得到404。这可能是因为你的静态资源路径配置有误但更深层的原因可能与加载顺序有关。负责映射静态资源的WelcomePageHandlerMapping和ResourceHttpRequestHandler是在DispatcherServlet初始化过程中注册的而DispatcherServlet的初始化又是在ServletWebServerInitializedEvent发布之前。如果有一个自定义的Filter或Servlet拦截了所有路径/*并且处理不当就可能阻止对静态资源的请求到达Spring MVC的DispatcherServlet。排查技巧开启Spring Boot的Actuator访问/actuator/mappings端点查看所有已注册的HTTP映射确认你的静态资源路径是否在其中。检查是否有全局Filter做了不恰当的拦截。5.3 自定义Filter/Servlet不生效你定义了一个FilterRegistrationBean但请求过来发现它没起作用。根据时序FilterRegistrationBean的初始化逻辑是在Web服务器启动过程中被调用的。如果它不生效可能的原因有顺序问题Filter有执行顺序order可能被其他Filter提前拦截并结束了请求链。URL模式错误setUrlPatterns配置的路径与请求路径不匹配。Bean未被扫描到你的配置类不在主应用类的同级或子级包下且未使用ComponentScan显式指定。条件化配置冲突你的Configuration类上可能有ConditionalOnXXX条件在某种环境下不满足导致整个配置类被跳过。排查技巧在FilterRegistrationBean的Bean定义方法上打上断点或者在其onStartup方法内打上断点观察它是否被Spring创建和调用。同时检查应用启动日志看是否有关于Filter注册的提示信息。5.4 启动缓慢分析与优化应用启动慢Web容器加载占了大部分时间。优化可以从以下几个点入手懒加载Lazy Initialization在application.properties中设置spring.main.lazy-initializationtrue。这会让所有Bean变为懒加载直到第一次被请求时才创建。这可以显著加快启动速度因为createWebServer和大部分Bean初始化都被推迟了。但代价是第一个请求的延迟会变高并且需要确保你的Bean没有错误的循环依赖在懒加载下更容易暴露。减少类路径扫描使用SpringBootApplication的scanBasePackages属性明确指定要扫描的包避免扫描整个classpath。排查耗时的Bean使用Actuator的/actuator/startup端点需要依赖spring-boot-starter-actuator并配置management.endpoints.web.exposure.includestartup它可以以树状结构展示启动过程中每个Bean的初始化耗时帮你找到瓶颈。Tomcat优化对于Tomcat可以调优server.tomcat.threads.max不要盲目设大、connection-timeout等参数。但通常这不是启动慢的主因。实操心得在微服务架构下尤其是使用Kubernetes的滚动更新或弹性伸缩时启动速度直接影响到服务的可用性和弹性。将非核心的、重量级的客户端如某些报表生成SDK改为懒加载是我们在多个项目中验证过的有效手段。但务必在预发环境充分测试确保懒加载不会引发NullPointerException因为Bean可能还未初始化。6. 不同容器Tomcat/Jetty/Undertow的细微差异Spring Boot的抽象做得很好大部分情况下切换容器无需关心加载时机。但底层实现仍有细微差别了解它们有助于深度排错。Tomcat最常用也是默认容器。它的Connector启动是同步的绑定端口失败会直接抛出异常。其线程模型BIO/NIO/APR对启动阶段影响不大主要影响运行时性能。Jetty启动速度通常被认为比Tomcat稍快。Jetty的Server启动过程也是类似的。需要注意的是Jetty的线程池和连接器配置方式与Tomcat不同对应的配置属性前缀是server.jetty.*。Undertow一个高性能、非阻塞的容器。由于基于XNIO它的启动和IO处理模型与Tomcat/Jetty不同。在finishRefresh()阶段启动Undertow时它内部会启动XNIO的工作线程。Undertow没有传统的ServletContext初始化回调但Spring Boot通过适配器仍然在相同的时机服务器启动前调用ServletContextInitializer。共同点无论哪种容器Spring Boot都通过ServletWebServerFactory和WebServer接口进行了统一抽象。createWebServer()和finishRefresh()的调用时机是完全一致的。差异主要体现在工厂Bean如何配置底层容器参数以及容器自身启动的细节上。当你遇到容器特有的原生错误比如Undertow的XNIO线程创建失败Jetty的QueuedThreadPool耗尽就需要查阅对应容器的文档但问题的触发阶段依然在我们的时序框架内。7. 高级话题在容器启动前后执行自定义逻辑有时我们需要在Web容器启动前或刚刚启动后执行一些特定的初始化逻辑。启动前如果你想在Web容器创建之前做一些事情例如检查某个外部配置中心是否可用可以实现ApplicationContextInitializer接口并在SpringApplication上注册。或者更简单的方法是在Bean方法中返回一个ServletWebServerFactory并在创建工厂Bean的过程中加入你的逻辑。但请注意此时ServerProperties可能还未完全绑定取决于你的Bean方法执行顺序要小心处理。启动后接收请求前这是更常见的需求。例如预热缓存、初始化连接池、加载大数据字典。最佳实践是使用CommandLineRunner或ApplicationRunner接口。它们的run方法会在ApplicationReadyEvent发布之前被调用但此时Web容器已经启动ServletWebServerInitializedEvent已发布。所以在这里执行预热逻辑是安全的。Component public class MyCacheWarmuper implements CommandLineRunner { Override public void run(String... args) throws Exception { // 此时Web容器已启动可以安全地进行需要网络端口的操作 warmUpCache(); } }优雅关闭理解启动顺序对优雅关闭也至关重要。当收到关闭信号如SIGTERM时Spring Boot会发布ContextClosedEvent然后开始销毁Bean。Web容器的关闭是销毁过程的一部分。确保你的Bean在PreDestroy方法中不依赖Web容器因为容器可能已关闭对于需要完成正在处理的HTTP请求的场景要合理配置server.shutdowngraceful并设置合适的spring.lifecycle.timeout-per-shutdown-phase。整个Spring Boot嵌入式Web容器的加载过程就像一场精心编排的戏剧。从环境准备、工厂创建、服务器实例化到Bean装配、初始化器注册最后在finishRefresh()的指挥棒下服务器启动、端口打开大幕正式拉开。理解每一个环节的时机不仅能让你在出现问题时快速定位更能让你在设计和优化应用时做出更合理、更稳健的决策。下次当你再看到“Tomcat started on port(s)”这行日志时希望你的脑海中能清晰地浮现出它背后这一整套复杂而精妙的启动图谱。
