服务滚动发布,如何确保进程退出期间,待处理和处理中的请求 服务正确处理请求,不出现业务异常呢? 我最近遇到Spring Event
的线上事故,原因就在于进程退出时,有应用线程从Spring GetBean
,然而Spring 不允许BeanFactory
销毁期间获取bean,导致请求处理失败、数据不一致的未知结果。详细原因参考:# Spring Event事件发布有坑!
为什么Spring 都销毁了,业务请求还要从Spring获取bean呢?这里面是否存在关闭顺序上的问题。要解决这个问题,先要了解JVM的退出方式有哪几种。
了解JVM优雅退出机制,能够保证服务在线上环境可以平稳发布。此外如果想了解如何 优雅退出一个线程参考# 深入理解线程的优雅退出机制
JVM退出方式
Java 虚拟机有三种退出方式,分别为正常退出、异常退出和强制关闭。简单介绍下三种方式各自包含哪些场景。
正常关闭
正常退出时,JVM会执行shutdown hook
钩子程序。钩子提供了java代码响应进程退出的机制,例如Spring等框架通过注册shutdownHook
钩子程序,监测到进程要退出的信号,然后关闭Spring上下文。
正常关闭的4种方式
解释下第一条,所有非守护线程退出,即main方法开始后创建的线程和main线程都退出后,进程就可以退出。非守护线程指应用自己创建的线程,守护线程包括JVM垃圾回收等jvm内部线程。值得一提的是:用户线程被创建后,如果调用Thread.setDaemon
也可修改为守护线程。
以下的代码演示了,主线程退出后,进程并未退出,直到第二个子线程退出后,所有非守护线程都退出,进程才退出。
Thread thread = new Thread(new Runnable() {
@Override
public void run() {
int cnt = 4;
for (int i = 0; i < cnt; i++) {
try {
Thread.sleep(10000);
} catch (InterruptedException e) {
System.out.println("被中断");
break;
}
System.out.println("子线程执行中");
}
System.out.println("子线程退出");
}
});
thread.start();
try {
Thread.sleep(20000);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("主线程提出");
执行结果
注意:千万不要使用Idea 执行junit 单元测试方法验证这个样例。因为idea 在执行junit方法完成后,会调用System.exit()
退出进程,从而不会等待子线程结束再退出进程。所以会造成一个假象 —— junit方法代表的主线程退出后,进程就退出。
当前应用服务动辄1000个线程,如果主动让1000个线程退出,然后走正常关闭的流程,还是比较困难的,所以一般情况下都是通过System.exit()或Kill pid方式退出进程。
强制退出
强制退出的方式,JVM无法执行shutdown hook
钩子程序,应用程序无法释放资源,无法等待剩余请求执行完毕,无法优雅退出。
Runtime.halt()
如果kill -9 一个进程,那么这个进程是感受不到任何“疼痛”的,和直接断掉电源差异不大。强制关闭进程,除了操作系统会回收进程的一系列资源例如文件和网络句柄等。应用进程内部不会感知到被关闭,更无法在关闭前执行一段代码。
除了人为kill-9进程,实际上操作系统在内存不足时,也会强制关闭一个内存占用最大的进程。例如我曾经遇到过一个诡异的线上问题。 java进程突然就没了,没有留下任何日志。
通过排查发现JVM的内存占用量每到达同一个值附近时,就会导致操作系统kill进程。最终定位原因是内存不足,docker实例一共8G的内存,Java占用了6G,其他进程和操作系统占用2G。 在服务刚发布时,由于jvm内存较少,虽然名义是8G,但是没有实际占用物理内存,但随着java进程内存逐渐增加(还未触发Full GC),触达物理系统内存上限,操作系统(linux kernel
)优先kill最大内存的进程。
一般情况下强制退出的原因就包括以上几点,出现进程突然消失的情况,重点从内存和进程Crash上着手。进程被强制关闭,就不要想着如何优雅关闭了,不可能做到的。
异常关闭
OOM是指一个线程新申请一块内存,JVM发现内存不足,于是触发Full GC,但是FullGC以后依然内存不足,于是该线程触发OOM异常。一般情况下线上进程如果出现OOM,需要及时关闭,否则可能不停触发OOM,导致更多的异常。
OOM只是在一个线程抛出异常,如果异常没有捕获,最多只会关闭这一个线程,不会殃及整个JVM。但是服务既然出现OOM,已经说明服务的内存模型存在问题,可能存在内存泄漏,这种情况下理应退出进程,避免更多的失败。
一般情况下,我们无法获知服务在哪行代码哪个线程出现OOM,自然无法有效catch异常,执行System.exit退出进程。好在JVM提供参数 配置,可以在OOM发生后执行某个策略
-XX:+HeapDumpOnOutOfMemoryError参数表示当JVM发生OOM时,自动生成DUMP文件。
-XX:HeapDumpPath= 目录,也可以指定文件名称,例如:−XX:HeapDumpPath={目录},也可以指定文件名称,例如:-
XX:HeapDumpPath=目录,也可以指定文件名称,例如:−XX:HeapDumpPath={目录}/java_heapdump.hprof-XX:OnOutOfMemoryError
在程序发生OOM异常时,执行指定命令,该参数接下来会详细介绍,也是JVM优雅退出的关键参数-XX:+ExitOnOutOfMemoryError 在程序发生OOM异常时,强制退出 -XX:+CrashOnOutOfMemoryError 在程序发生OOM异常时,强制退出,并生成Crash日志
可以在OnOutOfMemberError
配置脚本,通过脚本kill进程。可以使用以下参数配置,在OOM发生后,kill进程,如果进程在60s未退出,执行kill-9强制关闭。
-XX:OnOutOfMemoryError="kill -15 %p && sleep 60 && kill -9 %p &"
参考链接
相比于优雅关闭进程,如果你更关心OOM发生后堆栈的状态,则可以使用HeapDumpOnOutOfMemoryError
,OOM后打印heap dump
,然后强制退出进程。由于无法同时配置这两个参数,所以需要选择一个。更关心heapDump文件排查问题还是优雅退出,需要各位开发者根据业务实际场景决策。 可以参考这个博客分析为什么推荐使用 ExitOnOutOfMemoryError
服务优雅关闭只能在进程正常退出时和配置了OnOutOfMemoryError
的OOM场景可能触发优雅退出。这两种情况JVM都会执行shutdownHook
程序
ShutdownHook钩子程序
在jvm收到Kill 信号时,会开始执行注册的钩子程序。如何添加shutdown hook呢?
Runtime.getRuntime().addShutdownHook(new Thread(new Runnable() {
@Override
public void run() {
System.out.println("shutdown hook started");
}
}));
JDK在addShutdownHook
方法上提供了详细的注释,我翻译一下
当虚拟机开始关闭时,会以不确定的顺序启动所有的钩子程序,它们并发执行
当所有的钩子完成后,虚拟机才会关闭。在此期间守护线程和非守护线程都会继续运行。
如果通过调用System.exit()方法关机,一旦开始执行关闭程序,只能通过System.halt()方法强制终止虚拟机。
一旦开始执行关闭程序,不得再新建钩子或注销钩子,尝试以上两个操作会导致抛出IllegalStateException。
shutdown钩子在一个微妙时刻执行,应该进行防御编码,要写的线程安全,尽量避免死锁。
shutdown钩子应该尽快完成(虚拟机需要钩子程序全部执行完成,才能关闭)。
我曾经实验在钩子程序中调用System.exit
,这会阻塞中虚拟的关闭,使用Kill或者System.exit触发虚拟的关闭程序,钩子程序中再次调用System.exit
会导致虚拟机被阻塞,无法被关闭。所以严禁在钩子程序中调用 System.exit方法。
此外钩子程序会并发执行、无法保证顺序,这导致如果资源之间存在依赖,存在被依赖的资源可能先关闭,这将导致未知的结果。
所以应用程序最好使用一个钩子程序,恰好,我们的应用程序大多是Spring Boot应用,它已经接入了shutdown hook
,我们只需要实现Spring提供的关闭扩展点即可。无需自己再新增shutdown hook
,避免了和spring 并发关闭可能导致的不可知结果。
Spring提供的关闭扩展点
spring 关闭流程的源码
protected void doClose() {
if (this.active.get() && this.closed.compareAndSet(false, true)) {
// ...(省略)
publishEvent(new ContextClosedEvent(this));
this.lifecycleProcessor.onClose();
destroyBeans();
closeBeanFactory();
onClose();
this.active.set(false);
}
}
ContextClosedEvent
,可以使用EventListener注解 监听该事件,详情参考 :# Spring Event事件发布有坑!Lifecycle
类型Bean 的所有stop
方法。BeanFactory
,单例Bean中声明init-method
和destroy-method
的会被销毁。如果单例bean未声明两个方法,则不会被销毁。public interface Lifecycle {
void start();
void stop();
boolean isRunning();
Spring提供了三个位置感知进程关闭事件。首先发布容器关闭事件,此时BenaFactory
还未关闭,Bean资源都还未销毁。这是一个绝佳的关闭资源的地方。
当然有一个疑问:既然Spring会销毁需要销毁的bean,为什么还要在关闭事件中关闭资源呢?
这就要说到Spring销毁bean的顺序问题
Spring销毁bean的顺序
我找到Spring销毁的代码,如下图,最后被创建的单例Bean,最先被回收。
如果是XML方式定义bean,那么最后在xml定义的最后被创建,也就是最先被回收。所以xml中靠后的bean会先被回收。
那么如果是通过注解被加载进Spring呢?答案是未知。并不确定扫描包的时候,哪个类率先被扫到,加载进Spring。除非通过 DependOn
注解声明依赖顺序。
为什么Spring销毁bean的顺序如此重要,想象一个场景,Kafka消费者还在运行中,此时消费逻辑要发送一个Kafka消息,但是发送时生产者已经被销毁了,消息发送失败,应用数据处于不一致状态。 这不是推测,这个case 是我们在线上实际遇到的问题。
避免被依赖的bean先被回收,要严格控制Spring 单例Bean的依赖顺序?但是bean与bean之间依赖如此复杂,如果靠通过dependOn
注解声明的方式,肯定会有疏漏。有什么好的办法呢?
在关闭BeanFactory
之前,通过ContextCloseEvent
切断线上流量,服务请求的入口一般分为 http、Rpc、MQ。
关闭请求入口
关闭MQ入口
MQ无论是推拉模型,消费端一定提供了close
或者destroy
方法。通过在 ContextCloseEvent
消费逻辑中 关闭所有的消费者,切断所有的消费逻辑。但是要注意,因为BeanFacotry
阶段还要销毁bean,所以要保证close方法的幂等。可通过状态字段控制。
关闭RPC入口
Rpc的入口应用程序也可以主动关闭,Rpc提供方一般都会在服务发布后对外暴露端口,到注册中心注册。同样销毁时 从注册中心取消注册,即可保证不会再有rpc流量进来。
关闭Http入口
http入口实际上是通过SpringBoot 内嵌tomcat关闭的,Sprigboot中在 lifestyle的关闭流程中 会关闭Tomcat容器,这个流程发生在 beanFactory bean
被销毁之前。所以不存在入口未关闭,bean被销毁的情况。 详细请参考#### Spring Boot 优雅停机原理详解
此外默认情况下是立即关闭Tomcat,进行中的请求可能会失败,可以配置优雅关闭
server:
# 设置关闭方式为优雅关闭
shutdown: graceful
spring:
lifecycle:
# 优雅关闭超时时间, 默认30s
timeout-per-shutdown-phase: 30s
以上我们分别处理了http、rpc、mq的入口流量。但是假设线程池中依然存在进行中的请求怎么办,如果此时销毁bean和回收资源,则依然存在,调用被销毁的bean导致未知异常的可能性。所以需要主动关闭线程池。
可以在 ContextCloseEvent
中 关闭各种线程池,例如Rpc线程池、业务逻辑中创建的线程池。
线程池的优雅关闭
线程池关闭方法分为shutdown
和shutdownNow
。
- 拒绝新任务提交
- 待执行的任务不会取消
- 正在执行的任务也不会取消,将继续执行
- 拒绝新任务提交
- 取消待执行的任务
- 尝试取消执行中的任务()
无论哪个方法都会拒绝新任务提交。设想一下如果关闭线程池时,还有流量进来会怎样? 会被线程池拒绝,然后上游感知到大量的失败。
所以一定要先切断上游http/mq/rpc的流量,再关闭线程池,才能避免关闭期间请求被拒绝的情况发生。
取消待执行任务,会导致任务执行失败,所以不推荐使用shutdownNow
强行关闭,而是推荐使用shutdown
优雅关闭。
但是如果任务长时间无法结束,要一直等待吗? 不能。可以考虑使用awaitTermination
等待指定时间后。如果依然无法关闭,那么放弃等待。
后续的流程,Spring开始销毁bean,执行剩余的资源清理逻辑。等Spring执行完资源清理,shutdown hook
就执行完成。 此时虽然 线程池可能还没有关闭,但是Java进程也会关闭。
自此 从切流量、关闭线程池、等待线程池结束、销毁bean。整个过程保证了不存在新进的请求,等待处理进行中的请求,最终才会销毁 bean。这样Java进程才能算上功德圆满,优雅关闭!
总结
OnOutOfMemberError
="kill脚本"才会执行优雅关闭逻辑shutdown
钩子,小心并发和不要执行太久ContextCloseEvent
中 切断http/mq/rpc等入口流量。shutdown关闭线程池。