1. 项目概述为什么嵌入式Web Server和优雅停机如此重要如果你正在使用SpringBoot开发Web应用那么你几乎每天都在和嵌入式Web Server打交道只是你可能没有特别留意它。与传统的Java Web应用部署到独立的Tomcat、Jetty等应用服务器不同SpringBoot默认将Web服务器如Tomcat、Netty、Undertow内嵌到了应用本身。这意味着你的应用就是一个可执行的JAR包里面自带了一个“迷你版”的服务器。这种设计带来了极致的便捷性但也引入了一些新的配置和运维考量尤其是在应用的生命周期管理上比如“优雅停机”。简单来说嵌入式Web Server配置决定了你的应用如何对外提供服务包括端口、线程池、连接数、SSL加密等它直接关系到应用的性能、安全性和稳定性。而优雅停机则关乎应用在关闭时如何体面地“谢幕”——它需要确保正在处理的请求不被粗暴中断数据不会丢失连接能够被妥善关闭。想象一下一个电商应用在关闭时如果直接杀死进程可能会导致用户支付成功但订单未生成或者后台任务写到一半的数据损坏这种体验是灾难性的。因此深入理解并正确配置这两部分是每一个SpringBoot开发者从“能用”走向“好用”、“稳定”的必经之路。本文将从一个有多年踩坑经验的开发者视角带你彻底搞懂嵌入式Web Server的核心配置项并手把手教你实现生产级别的优雅停机方案避开那些文档里不会写的“坑”。2. 嵌入式Web Server的深度配置与调优实战SpringBoot支持多种嵌入式Web服务器默认是Tomcat你也可以轻松切换到Jetty或Undertow。选择哪个往往取决于具体的性能指标和场景需求但无论选哪个其配置哲学是相通的通过application.properties或application.yml文件进行外部化配置。下面我们以最常用的Tomcat为例拆解那些关键且易被忽略的配置项。2.1 基础连接与线程池配置性能的基石很多人配置服务器只改个端口这远远不够。线程池和连接器的配置是吞吐量和响应时间的决定性因素。server: port: 8080 tomcat: # 连接器Connector配置处理HTTP请求 max-connections: 10000 # 服务器接受的最大连接数Tomcat 8.5。超过此值的连接将被放入等待队列。 accept-count: 100 # 等待队列的长度。当所有可用线程都被占用且连接数达到max-connections后新连接进入此队列等待。 threads: max: 200 # 最大工作线程数。决定了并发处理请求的能力。 min-spare: 10 # 最小空闲工作线程数。Tomcat启动时会初始化的线程数用于快速响应请求。 # 连接超时控制 connection-timeout: 20000 # 连接超时时间毫秒。指从接受连接到请求行request line到达的时间。 keep-alive-timeout: 20000 # Keep-Alive连接在空闲多久后关闭毫秒。长连接复用减少TCP握手开销。 max-keep-alive-requests: 100 # 单个Keep-Alive连接上最多处理的请求数防止无限复用。配置逻辑与经验之谈max-connections、accept-count与threads.max的关系这是最容易出错的点。假设threads.max200max-connections10000accept-count100。那么并发模型是这样的最多有200个请求被线程同时处理当200个线程都忙时新来的连接会占用连接槽直到总连接数达到10000当连接数也达到10000后新连接才会进入长度为100的等待队列。如果队列也满了服务器将直接返回Connection refused错误。所以max-connections通常要远大于threads.max以应对突发流量和慢请求。threads.min-spare的设置在生产环境建议设置一个合理的值如10-50避免流量突增时临时创建线程的开销影响响应时间。connection-timeout这个不是Socket读取超时。如果客户端建立连接后迟迟不发送HTTP请求头超过这个时间连接会被关闭。对于公网服务设置一个合理的值如20-30秒可以防止恶意连接或网络问题导致的资源占用。Keep-Alive配置对于API服务器或内部微服务适当调高keep-alive-timeout如30秒和max-keep-alive-requests能显著提升性能。但对于面向公众的、连接来源复杂的服务不宜设置过长以防耗尽连接资源。2.2 高级调优应对大流量与慢请求当你的应用面临高并发或者存在文件上传、复杂计算等慢操作时以下配置至关重要。server: tomcat: # 针对慢请求或大请求的配置 max-swallow-size: 20MB # POST请求体最大大小字节。超过此值Tomcat将在读取请求体后中断连接。 max-http-form-post-size: 10MB # HTTP表单POST数据最大大小。 # 内部缓冲区配置 max-http-header-size: 8KB # 单个HTTP请求/响应头的最大大小。 # 静态资源缓存对于内嵌Tomcat服务静态文件有用 background-processor-delay: 10 # 静态资源缓存后台处理线程的延迟秒。max-swallow-size的坑这个参数名字有点怪它控制的是Tomcat“吞下”的请求体大小。如果客户端上传了一个超过这个限制的文件Tomcat会先完整读取整个请求体然后再返回400错误并关闭连接。这意味着一个1GB的大文件上传即使被拒绝也会占满你的网络I/O和内存。对于有上传功能的接口一定要根据业务需要合理设置并考虑在前置网关如Nginx或应用层进行更早的拦截。max-http-header-size如果你的请求头里夹带了大量的Cookie或自定义头信息可能需要调大这个值否则会报Header size exceeded的错误。2.3 切换与对比Tomcat vs. Undertow vs. JettySpringBoot可以轻松切换Web服务器。在pom.xml中排除默认的Tomcat引入你想要的即可。!-- 切换为 Undertow -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId exclusions exclusion groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-tomcat/artifactId /exclusion /exclusions /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-undertow/artifactId /dependency选型经验分享Tomcat中庸之王生态最完善兼容性最好调试工具多。对于绝大多数常规Web应用选择Tomcat不会出错。它的线程模型BIO/NIO成熟稳定。Undertow红帽出品性能黑马。它基于NIO采用非阻塞的XNIO框架内存占用小并发性能在高负载下往往优于Tomcat。特别适合微服务架构中的网关、轻量级服务。但要注意Undertow的配置项名称和逻辑与Tomcat有差异需要重新学习。Jetty轻量、灵活、易于嵌入。在异步处理、长连接如WebSocket方面有优势。很多开源项目如ActiveMQ使用Jetty作为内嵌服务器。提示除非有明确的性能瓶颈或特殊需求如需要极高的WebSocket并发否则不建议轻易更换默认的Tomcat。更换带来的性能提升可能远小于因不熟悉新服务器配置而引入的稳定性风险。3. 实现生产级优雅停机从理论到实践优雅停机Graceful Shutdown是指在收到停止指令如kill -15或SIGTERM后应用不会立即退出而是先拒绝新的流量同时等待一段时间让正在处理的请求完成然后再释放资源关闭进程。3.1 SpringBoot 2.3 的官方优雅停机方案SpringBoot从2.3版本开始内置了对优雅停机的支持这是目前最推荐、最标准的方式。第一步开启优雅停机功能在application.yml中配置server: shutdown: graceful # 启用优雅停机 spring: lifecycle: timeout-per-shutdown-phase: 30s # 设置停机等待的超时时间第二步理解其工作原理当你通过kill -15或spring-boot-starter-actuator的/actuator/shutdown端点默认关闭需手动开启触发停机时SpringBoot会按顺序执行以下流程关闭流量入口Web服务器停止接受新的请求Tomcat/Jetty/Undertow的连接器被关闭。此时健康检查如K8S的readinessProbe应开始失败将应用从负载均衡中摘除。发布ContextClosedEvent事件通知Spring容器即将关闭。等待活动请求完成这是核心阶段。容器会等待所有正在处理的请求包括异步请求完成但最长不会超过timeout-per-shutdown-phase设置的时间如30秒。关闭Spring容器销毁所有单例Bean执行PreDestroy方法等。强制终止如果超时如果在设定的超时时间后仍有请求未处理完SpringBoot会记录警告日志并强制关闭容器此时未完成的请求会被中断。第三步验证与测试启动你的应用。使用curl或Postman模拟一个长耗时请求例如一个sleep10秒的接口。在请求处理期间向应用发送SIGTERM信号在IDE中停止或使用kill -15 PID。观察控制台日志。你应该能看到类似“Graceful shutdown complete”的日志并且你的长耗时请求应该能正常完成并返回响应之后应用才会退出。再测试一个场景发送一个耗时超过timeout-per-shutdown-phase如35秒的请求然后立即发送停止信号。观察应用是否在等待30秒后强制退出并记录相关警告。3.2 自定义Bean的优雅关闭处理后台线程与连接池内置的优雅停机主要处理了Web请求层面。但你的应用很可能还有自己的后台任务、线程池、数据库连接池、Redis连接、MQ消费者等这些也需要妥善关闭。最佳实践实现SmartLifecycle或监听ContextClosedEvent对于由你管理的资源推荐实现SmartLifecycle接口它允许你定义关闭的相位phase实现有序关闭。Component public class MyBackgroundTaskManager implements SmartLifecycle { private final ExecutorService executorService Executors.newFixedThreadPool(5); private volatile boolean running false; Override public void start() { running true; // 启动你的后台任务 executorService.submit(this::doBackgroundWork); log.info(MyBackgroundTaskManager started.); } Override public void stop() { // 1. 停止接受新任务 running false; // 2. 优雅关闭线程池 executorService.shutdown(); // 停止接收新任务 try { // 等待现有任务完成最多等30秒 if (!executorService.awaitTermination(30, TimeUnit.SECONDS)) { executorService.shutdownNow(); // 强制取消正在执行的任务 log.warn(MyBackgroundTaskManager thread pool did not terminate gracefully.); } } catch (InterruptedException e) { executorService.shutdownNow(); Thread.currentThread().interrupt(); } log.info(MyBackgroundTaskManager stopped.); } Override public boolean isRunning() { return running; } // 通过getPhase控制关闭顺序数字越小优先级越高越早关闭 Override public int getPhase() { return Integer.MAX_VALUE - 1; // 在Web服务器关闭之后但在最核心的资源如DataSource关闭之前关闭 } private void doBackgroundWork() { while (running !Thread.currentThread().isInterrupted()) { // ... 执行任务 } } }对于第三方客户端如Redis、RabbitMQ 通常这些客户端的Spring Boot Starter如spring-boot-starter-data-redis,spring-boot-starter-amqp已经实现了SmartLifecycle或DisposableBean会在容器关闭时自动关闭连接。你只需要确保在配置中正确设置了连接参数。但务必查阅其文档确认其行为。3.3 与容器化部署Docker/K8s的协同在现代部署中应用运行在Docker容器中由Kubernetes管理。优雅停机需要与K8s的生命周期钩子配合。Kubernetes Pod的停止流程kubectl delete pod或滚动更新时K8s向Pod中的容器发送SIGTERM信号。terminationGracePeriodSecondsPod级别的设置默认30秒。这是容器在收到SIGTERM后被强制SIGKILL前的等待时间。你的SpringBoot应用收到SIGTERM开始执行上述优雅停机流程。如果在terminationGracePeriodSeconds内完成关闭则正常退出。如果超时K8s会发送SIGKILL强制杀死容器。关键配置# deployment.yaml apiVersion: apps/v1 kind: Deployment spec: template: spec: containers: - name: my-springboot-app image: my-app:latest lifecycle: preStop: # 在发送SIGTERM之前执行的操作可选 exec: command: [sh, -c, sleep 5] # 等待5秒让负载均衡器更新再开始优雅停机 # 重要确保terminationGracePeriodSeconds大于SpringBoot的timeout-per-shutdown-phase # 并且留出buffer时间给preStop钩子和网络延迟 terminationGracePeriodSeconds: 45经验之谈terminationGracePeriodSeconds例如45秒必须大于spring.lifecycle.timeout-per-shutdown-phase例如30秒加上preStop钩子的时间例如5秒并预留一些缓冲例如10秒。否则你的优雅停机流程可能还没走完容器就被强制杀死了。preStop钩子常用于从服务注册中心如Nacos、Eureka注销或通知网关下线确保在停止接收新流量后再开始处理存量请求。4. 常见陷阱、排查技巧与进阶思考即使配置了优雅停机在实际生产环境中依然会遇到各种问题。下面是一些典型的“坑”和排查思路。4.1 陷阱一数据库连接池未正确关闭导致连接泄漏现象应用关闭后数据库监控显示仍存在大量“睡眠”连接需要很久才超时释放。根因虽然Spring Boot会自动关闭DataSource但如果你的应用中有地方持有数据库连接而未在PreDestroy或SmartLifecycle.stop()中释放例如某些全局静态变量、未正确关闭的JdbcTemplate操作等或者连接池本身如HikariCP的关闭等待时间设置过长都可能出现问题。解决方案与验证显式配置连接池关闭超时以HikariCP为例spring: datasource: hikari: maximum-pool-size: 10 connection-timeout: 30000 # 优雅停机时等待连接池关闭的时间 initialization-fail-timeout: -1 # 默认值表示快速失败。在优雅停机场景下可以保持。 # 更关键的是确保Spring的优雅停机超时时间足够连接池完成关闭。在SmartLifecycle的stop()方法中确保所有数据库相关资源都被显式清理。验证在测试环境模拟一个持有数据库连接的长事务然后触发优雅停机。观察连接池监控和数据库连接视图确认连接是否在超时时间内被正确回收。4.2 陷阱二异步任务Async破坏优雅停机现象配置了优雅停机但应用关闭时正在执行的Async方法被中断数据不一致。根因Spring的Async默认使用一个简单的线程池执行器。当Spring容器关闭时它会尝试关闭这个线程池但默认的关闭行为可能是shutdownNow()这会尝试中断所有正在运行的线程。解决方案自定义异步线程池并配置优雅关闭行为Configuration EnableAsync public class AsyncConfig implements AsyncConfigurer { Override public Executor getAsyncExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(5); executor.setMaxPoolSize(10); executor.setQueueCapacity(25); executor.setThreadNamePrefix(MyAsync-); // 关键配置设置等待任务完成的策略 executor.setWaitForTasksToCompleteOnShutdown(true); // 优雅停机时等待任务完成 executor.setAwaitTerminationSeconds(30); // 等待任务完成的最大时间 executor.initialize(); return executor; } }在异步方法中处理中断在Async方法内部循环检查Thread.currentThread().isInterrupted()以便在收到中断信号时能够进行资源清理并安全退出。4.3 排查技巧如何确认优雅停机真的生效了日志分析确保你的日志级别包含了INFO。在关闭时SpringBoot会打印关键日志如“Initiating graceful shutdown”、“Waiting for active requests to complete”、“Graceful shutdown complete”。如果看到“Shutting down immediately due to timeout”说明有请求超时未完成。模拟长请求这是最直接的测试方法。编写一个/long-task接口里面sleep一段时间。在请求执行期间触发关闭观察请求是否能完成并收到响应。使用Actuator端点需引入spring-boot-starter-actuator并配置暴露management: endpoints: web: exposure: include: health,info,shutdown # 谨慎暴露shutdown通常仅用于测试 endpoint: shutdown: enabled: true通过POST访问/actuator/shutdown可以触发优雅停机方便测试。网络流量监控在应用关闭期间使用tcpdump或netstat命令观察应用端口如8080的连接状态。你应该会看到新的SYN包被拒绝流量入口已关闭而现有的ESTABLISHED连接会逐渐减少至零。4.4 进阶思考分布式场景下的优雅停机在微服务架构中一个服务的优雅停机不仅仅是自身的事情还涉及到上下游。服务注册与发现在收到停机信号后第一时间就应该从注册中心如Nacos、Eureka注销实例。这可以通过监听ContextClosedEvent并设置一个较高的相位SmartLifecycle中较低的getPhase()值来实现确保在停止接收流量前完成注销。许多服务注册中心的客户端如spring-cloud-starter-alibaba-nacos-discovery已经内置了此功能但需要确认其关闭顺序。配置中心如果使用了配置中心如Apollo、Nacos Config确保在关闭前配置监听器能正确释放资源避免内存泄漏。上游重试与熔断确保你的上游服务或网关如Spring Cloud Gateway配置了合理的重试和熔断策略。当下游服务开始优雅停机并拒绝新请求时上游的快速失败和重试其他健康实例的机制可以保证用户体验不受影响。消息队列消费者如果你的应用是消息消费者如RabbitMQ、Kafka需要在关闭前优雅地停止监听器、确认已处理的消息、并关闭连接。Spring Boot的RabbitListener和KafkaListener通常与容器生命周期绑定但需要检查autoStartup和shutdown相关配置。实现真正无感知的滚动升级或扩缩容优雅停机是基石。它不是一个简单的开关而是一个需要结合应用架构、基础设施K8s、中间件客户端进行通盘考虑的系统性工程。从配置好嵌入式Web Server的参数开始到实现每一个组件的优雅关闭再到与整个部署环境协同每一步都需要仔细设计和充分测试。 SpringBoot嵌入式Web Server配置与优雅停机实战指南
1. 项目概述为什么嵌入式Web Server和优雅停机如此重要如果你正在使用SpringBoot开发Web应用那么你几乎每天都在和嵌入式Web Server打交道只是你可能没有特别留意它。与传统的Java Web应用部署到独立的Tomcat、Jetty等应用服务器不同SpringBoot默认将Web服务器如Tomcat、Netty、Undertow内嵌到了应用本身。这意味着你的应用就是一个可执行的JAR包里面自带了一个“迷你版”的服务器。这种设计带来了极致的便捷性但也引入了一些新的配置和运维考量尤其是在应用的生命周期管理上比如“优雅停机”。简单来说嵌入式Web Server配置决定了你的应用如何对外提供服务包括端口、线程池、连接数、SSL加密等它直接关系到应用的性能、安全性和稳定性。而优雅停机则关乎应用在关闭时如何体面地“谢幕”——它需要确保正在处理的请求不被粗暴中断数据不会丢失连接能够被妥善关闭。想象一下一个电商应用在关闭时如果直接杀死进程可能会导致用户支付成功但订单未生成或者后台任务写到一半的数据损坏这种体验是灾难性的。因此深入理解并正确配置这两部分是每一个SpringBoot开发者从“能用”走向“好用”、“稳定”的必经之路。本文将从一个有多年踩坑经验的开发者视角带你彻底搞懂嵌入式Web Server的核心配置项并手把手教你实现生产级别的优雅停机方案避开那些文档里不会写的“坑”。2. 嵌入式Web Server的深度配置与调优实战SpringBoot支持多种嵌入式Web服务器默认是Tomcat你也可以轻松切换到Jetty或Undertow。选择哪个往往取决于具体的性能指标和场景需求但无论选哪个其配置哲学是相通的通过application.properties或application.yml文件进行外部化配置。下面我们以最常用的Tomcat为例拆解那些关键且易被忽略的配置项。2.1 基础连接与线程池配置性能的基石很多人配置服务器只改个端口这远远不够。线程池和连接器的配置是吞吐量和响应时间的决定性因素。server: port: 8080 tomcat: # 连接器Connector配置处理HTTP请求 max-connections: 10000 # 服务器接受的最大连接数Tomcat 8.5。超过此值的连接将被放入等待队列。 accept-count: 100 # 等待队列的长度。当所有可用线程都被占用且连接数达到max-connections后新连接进入此队列等待。 threads: max: 200 # 最大工作线程数。决定了并发处理请求的能力。 min-spare: 10 # 最小空闲工作线程数。Tomcat启动时会初始化的线程数用于快速响应请求。 # 连接超时控制 connection-timeout: 20000 # 连接超时时间毫秒。指从接受连接到请求行request line到达的时间。 keep-alive-timeout: 20000 # Keep-Alive连接在空闲多久后关闭毫秒。长连接复用减少TCP握手开销。 max-keep-alive-requests: 100 # 单个Keep-Alive连接上最多处理的请求数防止无限复用。配置逻辑与经验之谈max-connections、accept-count与threads.max的关系这是最容易出错的点。假设threads.max200max-connections10000accept-count100。那么并发模型是这样的最多有200个请求被线程同时处理当200个线程都忙时新来的连接会占用连接槽直到总连接数达到10000当连接数也达到10000后新连接才会进入长度为100的等待队列。如果队列也满了服务器将直接返回Connection refused错误。所以max-connections通常要远大于threads.max以应对突发流量和慢请求。threads.min-spare的设置在生产环境建议设置一个合理的值如10-50避免流量突增时临时创建线程的开销影响响应时间。connection-timeout这个不是Socket读取超时。如果客户端建立连接后迟迟不发送HTTP请求头超过这个时间连接会被关闭。对于公网服务设置一个合理的值如20-30秒可以防止恶意连接或网络问题导致的资源占用。Keep-Alive配置对于API服务器或内部微服务适当调高keep-alive-timeout如30秒和max-keep-alive-requests能显著提升性能。但对于面向公众的、连接来源复杂的服务不宜设置过长以防耗尽连接资源。2.2 高级调优应对大流量与慢请求当你的应用面临高并发或者存在文件上传、复杂计算等慢操作时以下配置至关重要。server: tomcat: # 针对慢请求或大请求的配置 max-swallow-size: 20MB # POST请求体最大大小字节。超过此值Tomcat将在读取请求体后中断连接。 max-http-form-post-size: 10MB # HTTP表单POST数据最大大小。 # 内部缓冲区配置 max-http-header-size: 8KB # 单个HTTP请求/响应头的最大大小。 # 静态资源缓存对于内嵌Tomcat服务静态文件有用 background-processor-delay: 10 # 静态资源缓存后台处理线程的延迟秒。max-swallow-size的坑这个参数名字有点怪它控制的是Tomcat“吞下”的请求体大小。如果客户端上传了一个超过这个限制的文件Tomcat会先完整读取整个请求体然后再返回400错误并关闭连接。这意味着一个1GB的大文件上传即使被拒绝也会占满你的网络I/O和内存。对于有上传功能的接口一定要根据业务需要合理设置并考虑在前置网关如Nginx或应用层进行更早的拦截。max-http-header-size如果你的请求头里夹带了大量的Cookie或自定义头信息可能需要调大这个值否则会报Header size exceeded的错误。2.3 切换与对比Tomcat vs. Undertow vs. JettySpringBoot可以轻松切换Web服务器。在pom.xml中排除默认的Tomcat引入你想要的即可。!-- 切换为 Undertow -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId exclusions exclusion groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-tomcat/artifactId /exclusion /exclusions /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-undertow/artifactId /dependency选型经验分享Tomcat中庸之王生态最完善兼容性最好调试工具多。对于绝大多数常规Web应用选择Tomcat不会出错。它的线程模型BIO/NIO成熟稳定。Undertow红帽出品性能黑马。它基于NIO采用非阻塞的XNIO框架内存占用小并发性能在高负载下往往优于Tomcat。特别适合微服务架构中的网关、轻量级服务。但要注意Undertow的配置项名称和逻辑与Tomcat有差异需要重新学习。Jetty轻量、灵活、易于嵌入。在异步处理、长连接如WebSocket方面有优势。很多开源项目如ActiveMQ使用Jetty作为内嵌服务器。提示除非有明确的性能瓶颈或特殊需求如需要极高的WebSocket并发否则不建议轻易更换默认的Tomcat。更换带来的性能提升可能远小于因不熟悉新服务器配置而引入的稳定性风险。3. 实现生产级优雅停机从理论到实践优雅停机Graceful Shutdown是指在收到停止指令如kill -15或SIGTERM后应用不会立即退出而是先拒绝新的流量同时等待一段时间让正在处理的请求完成然后再释放资源关闭进程。3.1 SpringBoot 2.3 的官方优雅停机方案SpringBoot从2.3版本开始内置了对优雅停机的支持这是目前最推荐、最标准的方式。第一步开启优雅停机功能在application.yml中配置server: shutdown: graceful # 启用优雅停机 spring: lifecycle: timeout-per-shutdown-phase: 30s # 设置停机等待的超时时间第二步理解其工作原理当你通过kill -15或spring-boot-starter-actuator的/actuator/shutdown端点默认关闭需手动开启触发停机时SpringBoot会按顺序执行以下流程关闭流量入口Web服务器停止接受新的请求Tomcat/Jetty/Undertow的连接器被关闭。此时健康检查如K8S的readinessProbe应开始失败将应用从负载均衡中摘除。发布ContextClosedEvent事件通知Spring容器即将关闭。等待活动请求完成这是核心阶段。容器会等待所有正在处理的请求包括异步请求完成但最长不会超过timeout-per-shutdown-phase设置的时间如30秒。关闭Spring容器销毁所有单例Bean执行PreDestroy方法等。强制终止如果超时如果在设定的超时时间后仍有请求未处理完SpringBoot会记录警告日志并强制关闭容器此时未完成的请求会被中断。第三步验证与测试启动你的应用。使用curl或Postman模拟一个长耗时请求例如一个sleep10秒的接口。在请求处理期间向应用发送SIGTERM信号在IDE中停止或使用kill -15 PID。观察控制台日志。你应该能看到类似“Graceful shutdown complete”的日志并且你的长耗时请求应该能正常完成并返回响应之后应用才会退出。再测试一个场景发送一个耗时超过timeout-per-shutdown-phase如35秒的请求然后立即发送停止信号。观察应用是否在等待30秒后强制退出并记录相关警告。3.2 自定义Bean的优雅关闭处理后台线程与连接池内置的优雅停机主要处理了Web请求层面。但你的应用很可能还有自己的后台任务、线程池、数据库连接池、Redis连接、MQ消费者等这些也需要妥善关闭。最佳实践实现SmartLifecycle或监听ContextClosedEvent对于由你管理的资源推荐实现SmartLifecycle接口它允许你定义关闭的相位phase实现有序关闭。Component public class MyBackgroundTaskManager implements SmartLifecycle { private final ExecutorService executorService Executors.newFixedThreadPool(5); private volatile boolean running false; Override public void start() { running true; // 启动你的后台任务 executorService.submit(this::doBackgroundWork); log.info(MyBackgroundTaskManager started.); } Override public void stop() { // 1. 停止接受新任务 running false; // 2. 优雅关闭线程池 executorService.shutdown(); // 停止接收新任务 try { // 等待现有任务完成最多等30秒 if (!executorService.awaitTermination(30, TimeUnit.SECONDS)) { executorService.shutdownNow(); // 强制取消正在执行的任务 log.warn(MyBackgroundTaskManager thread pool did not terminate gracefully.); } } catch (InterruptedException e) { executorService.shutdownNow(); Thread.currentThread().interrupt(); } log.info(MyBackgroundTaskManager stopped.); } Override public boolean isRunning() { return running; } // 通过getPhase控制关闭顺序数字越小优先级越高越早关闭 Override public int getPhase() { return Integer.MAX_VALUE - 1; // 在Web服务器关闭之后但在最核心的资源如DataSource关闭之前关闭 } private void doBackgroundWork() { while (running !Thread.currentThread().isInterrupted()) { // ... 执行任务 } } }对于第三方客户端如Redis、RabbitMQ 通常这些客户端的Spring Boot Starter如spring-boot-starter-data-redis,spring-boot-starter-amqp已经实现了SmartLifecycle或DisposableBean会在容器关闭时自动关闭连接。你只需要确保在配置中正确设置了连接参数。但务必查阅其文档确认其行为。3.3 与容器化部署Docker/K8s的协同在现代部署中应用运行在Docker容器中由Kubernetes管理。优雅停机需要与K8s的生命周期钩子配合。Kubernetes Pod的停止流程kubectl delete pod或滚动更新时K8s向Pod中的容器发送SIGTERM信号。terminationGracePeriodSecondsPod级别的设置默认30秒。这是容器在收到SIGTERM后被强制SIGKILL前的等待时间。你的SpringBoot应用收到SIGTERM开始执行上述优雅停机流程。如果在terminationGracePeriodSeconds内完成关闭则正常退出。如果超时K8s会发送SIGKILL强制杀死容器。关键配置# deployment.yaml apiVersion: apps/v1 kind: Deployment spec: template: spec: containers: - name: my-springboot-app image: my-app:latest lifecycle: preStop: # 在发送SIGTERM之前执行的操作可选 exec: command: [sh, -c, sleep 5] # 等待5秒让负载均衡器更新再开始优雅停机 # 重要确保terminationGracePeriodSeconds大于SpringBoot的timeout-per-shutdown-phase # 并且留出buffer时间给preStop钩子和网络延迟 terminationGracePeriodSeconds: 45经验之谈terminationGracePeriodSeconds例如45秒必须大于spring.lifecycle.timeout-per-shutdown-phase例如30秒加上preStop钩子的时间例如5秒并预留一些缓冲例如10秒。否则你的优雅停机流程可能还没走完容器就被强制杀死了。preStop钩子常用于从服务注册中心如Nacos、Eureka注销或通知网关下线确保在停止接收新流量后再开始处理存量请求。4. 常见陷阱、排查技巧与进阶思考即使配置了优雅停机在实际生产环境中依然会遇到各种问题。下面是一些典型的“坑”和排查思路。4.1 陷阱一数据库连接池未正确关闭导致连接泄漏现象应用关闭后数据库监控显示仍存在大量“睡眠”连接需要很久才超时释放。根因虽然Spring Boot会自动关闭DataSource但如果你的应用中有地方持有数据库连接而未在PreDestroy或SmartLifecycle.stop()中释放例如某些全局静态变量、未正确关闭的JdbcTemplate操作等或者连接池本身如HikariCP的关闭等待时间设置过长都可能出现问题。解决方案与验证显式配置连接池关闭超时以HikariCP为例spring: datasource: hikari: maximum-pool-size: 10 connection-timeout: 30000 # 优雅停机时等待连接池关闭的时间 initialization-fail-timeout: -1 # 默认值表示快速失败。在优雅停机场景下可以保持。 # 更关键的是确保Spring的优雅停机超时时间足够连接池完成关闭。在SmartLifecycle的stop()方法中确保所有数据库相关资源都被显式清理。验证在测试环境模拟一个持有数据库连接的长事务然后触发优雅停机。观察连接池监控和数据库连接视图确认连接是否在超时时间内被正确回收。4.2 陷阱二异步任务Async破坏优雅停机现象配置了优雅停机但应用关闭时正在执行的Async方法被中断数据不一致。根因Spring的Async默认使用一个简单的线程池执行器。当Spring容器关闭时它会尝试关闭这个线程池但默认的关闭行为可能是shutdownNow()这会尝试中断所有正在运行的线程。解决方案自定义异步线程池并配置优雅关闭行为Configuration EnableAsync public class AsyncConfig implements AsyncConfigurer { Override public Executor getAsyncExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(5); executor.setMaxPoolSize(10); executor.setQueueCapacity(25); executor.setThreadNamePrefix(MyAsync-); // 关键配置设置等待任务完成的策略 executor.setWaitForTasksToCompleteOnShutdown(true); // 优雅停机时等待任务完成 executor.setAwaitTerminationSeconds(30); // 等待任务完成的最大时间 executor.initialize(); return executor; } }在异步方法中处理中断在Async方法内部循环检查Thread.currentThread().isInterrupted()以便在收到中断信号时能够进行资源清理并安全退出。4.3 排查技巧如何确认优雅停机真的生效了日志分析确保你的日志级别包含了INFO。在关闭时SpringBoot会打印关键日志如“Initiating graceful shutdown”、“Waiting for active requests to complete”、“Graceful shutdown complete”。如果看到“Shutting down immediately due to timeout”说明有请求超时未完成。模拟长请求这是最直接的测试方法。编写一个/long-task接口里面sleep一段时间。在请求执行期间触发关闭观察请求是否能完成并收到响应。使用Actuator端点需引入spring-boot-starter-actuator并配置暴露management: endpoints: web: exposure: include: health,info,shutdown # 谨慎暴露shutdown通常仅用于测试 endpoint: shutdown: enabled: true通过POST访问/actuator/shutdown可以触发优雅停机方便测试。网络流量监控在应用关闭期间使用tcpdump或netstat命令观察应用端口如8080的连接状态。你应该会看到新的SYN包被拒绝流量入口已关闭而现有的ESTABLISHED连接会逐渐减少至零。4.4 进阶思考分布式场景下的优雅停机在微服务架构中一个服务的优雅停机不仅仅是自身的事情还涉及到上下游。服务注册与发现在收到停机信号后第一时间就应该从注册中心如Nacos、Eureka注销实例。这可以通过监听ContextClosedEvent并设置一个较高的相位SmartLifecycle中较低的getPhase()值来实现确保在停止接收流量前完成注销。许多服务注册中心的客户端如spring-cloud-starter-alibaba-nacos-discovery已经内置了此功能但需要确认其关闭顺序。配置中心如果使用了配置中心如Apollo、Nacos Config确保在关闭前配置监听器能正确释放资源避免内存泄漏。上游重试与熔断确保你的上游服务或网关如Spring Cloud Gateway配置了合理的重试和熔断策略。当下游服务开始优雅停机并拒绝新请求时上游的快速失败和重试其他健康实例的机制可以保证用户体验不受影响。消息队列消费者如果你的应用是消息消费者如RabbitMQ、Kafka需要在关闭前优雅地停止监听器、确认已处理的消息、并关闭连接。Spring Boot的RabbitListener和KafkaListener通常与容器生命周期绑定但需要检查autoStartup和shutdown相关配置。实现真正无感知的滚动升级或扩缩容优雅停机是基石。它不是一个简单的开关而是一个需要结合应用架构、基础设施K8s、中间件客户端进行通盘考虑的系统性工程。从配置好嵌入式Web Server的参数开始到实现每一个组件的优雅关闭再到与整个部署环境协同每一步都需要仔细设计和充分测试。