Грациозное завершение работы
Тема дорожной карты · Spring Boot
Корректное завершение работы в Spring Boot — это возможность Spring Boot-приложения прекратить принимать новые запросы и завершить всю текущую работу до выхода из JVM-процесса, предотвращая повреждение данных и несогласованность состояния. Spring Boot включает корректное завершение одним свойством: server.shutdown=graceful в application.properties, после чего встроенный сервер Tomcat (или Undertow/Netty) перестаёт принимать новые соединения, позволяя активным потокам запросов завершиться в течение настраиваемого таймаута, задаваемого через spring.lifecycle.timeout-per-shutdown-phase (по умолчанию 30 секунд). В Kubernetes корректное завершение работы в Spring Boot сочетается с хуком жизненного цикла preStop и соответствующим terminationGracePeriodSeconds, чтобы дать поду достаточно времени на дренаж перед тем, как сигнал SIGTERM будет эскалирован до SIGKILL. Пробы /actuator/health/liveness и /actuator/health/readiness Spring Boot Actuator играют дополняющую роль: Kubernetes убирает под из ротации балансировщика нагрузки сразу после провала пробы готовности, до того как корректное завершение начнёт обработку сигнала завершения. Для приложений, использующих консьюмеров Spring Kafka или запланированные задачи @Async, может потребоваться дополнительная логика завершения, чтобы обработка сообщений в полёте и фоновые потоки также завершились корректно.
Как это работает
Грациозное завершение работы: Docker-образы через Spring Boot bootBuildImage (Cloud Native Buildpacks — layered, secure, маленькие образы) или hand-written Dockerfile. GraalVM native image (./gradlew nativeCompile) — static binary с sub-100ms startup + меньше памяти, отлично для serverless, дорого по build time + framework support. Graceful shutdown (server.shutdown=graceful) даёт in-flight запросам завершиться на SIGTERM. Production-ready config: тюньте JVM, выставьте heap, включите Actuator, log JSON, конфигурируйте connection pools (HikariCP дефолты обычно ок).
Когда применять
Buildpacks для большинства случаев — layered cache, security patches, без Dockerfile в поддержке. Native image — для serverless или fast-start workloads; верифицируйте что все зависимости поддерживают. Всегда graceful shutdown в K8s деплоях — abrupt termination дропает in-flight запросы. Memory limits + JVM tuning явно (не полагайтесь на auto-detect в контейнерах).
Типичные ошибки
Ловушки Грациозное завершение работы: деплой fat jar без health checks (K8s не может безопасно роутить трафик); 1GB+ Docker-образы со build artefacts (Buildpacks или multi-stage builds); нет graceful shutdown (rolling deploy дропает пользовательские запросы); JVM heap не выставлен, OOMKilled по K8s memory limit.