1.概述

转载:http://cxytiandi.com/blog/detail/15386

转载自:徐靖峰 Kirito的技术分享

最近瞥了一眼项目的重启脚本,发现运维一直在使用 kill -9 的方式重启 springboot embedded tomcat,其实大家几乎一致认为: kill -9 的方式比较暴力,但究竟会带来什么问题却很少有人能分析出个头绪。这篇文章主要记录下自己的思考过程。

kill -9 和 kill -15 有什么区别?

在以前,我们发布 WEB 应用通常的步骤是将代码打成 war 包,然后丢到一个配置好了应用容器(如 Tomcat,Weblogic)的 Linux 机器上,这时候我们想要启动/关闭应用,方式很简单,运行其中的启动/关闭脚本即可。而 springboot 提供了另一种方式,将整个应用连同内置的 tomcat 服务器一起打包,这无疑给发布应用带来了很大的便捷性,与之而来也产生了一个问题:如何关闭 springboot 应用呢?一个显而易见的做法便是,根据应用名找到进程 id,杀死进程 id 即可达到关闭应用的效果。

上述的场景描述引出了我的疑问:怎么优雅地杀死一个 springboot 应用进程呢?这里仅仅以最常用的 Linux 操作系统为例,在 Linux 中 kill 指令负责杀死进程,其后可以紧跟一个数字,代表信号编号(Signal),执行 kill -l 指令,可以一览所有的信号编号。

xu@ntzyz-qcloud ~ % kill -l
HUP INT QUIT ILL TRAP ABRT BUS FPE KILL USR1 SEGV USR2 PIPE ALRM TERM STKFLT CHLD CONT STOP TSTP TTIN TTOU URG XCPU XFSZ VTALRM PROF WINCH POLL PWR SYS

本文主要介绍下第 9 个信号编码 KILL,以及第 15 个信号编号 TERM 。

先简单理解下这两者的区别:

  1. kill -9 pid 可以理解为操作系统从内核级别强行杀死某个进程
  2. kill -15 pid 则可以理解为发送一个通知,告知应用主动关闭。

这么对比还是有点抽象,那我们就从应用的表现来看看,这两个命令杀死应用到底有啥区别。

代码准备

由于笔者 springboot 接触较多,所以以一个简易的 springboot 应用为例展开讨论,添加如下代码。

1 增加一个实现了 DisposableBean 接口的类

@Component
public class TestDisposableBean implements DisposableBean{@Overridepublic void destroy() throws Exception {System.out.println("测试 Bean 已销毁 ...");}
}

2 增加 JVM 关闭时的钩子

@SpringBootApplication
@RestController
public class TestShutdownApplication implements DisposableBean {public static void main(String[] args) {SpringApplication.run(TestShutdownApplication.class, args);Runtime.getRuntime().addShutdownHook(new Thread(new Runnable() {@Overridepublic void run() {System.out.println("执行 ShutdownHook ...");}}));}
}

测试步骤

执行 java -jar test-shutdown-1.0.jar 将应用运行起来
测试 kill -9 pid,kill -15 pid,ctrl + c 后输出日志内容
测试结果

kill -15 pid & ctrl + c,效果一样,输出结果如下

2018-01-14 16:55:32.424  INFO 8762 --- [       Thread-3] ationConfigEmbeddedWebApplicationContext : Closing org.springframework.boot.context.embedded.AnnotationConfigEmbeddedWebApplicationContext@2cdf8d8a: startup date [Sun Jan 14 16:55:24 UTC 2018]; root of context hierarchy
2018-01-14 16:55:32.432  INFO 8762 --- [       Thread-3] o.s.j.e.a.AnnotationMBeanExporter        : Unregistering JMX-exposed beans on shutdown
执行 ShutdownHook ...
测试 Bean 已销毁 ...
java -jar test-shutdown-1.0.jar  7.46s user 0.30s system 80% cpu 9.674 total

kill -9 pid,没有输出任何应用日志

可以发现,kill -9 pid 是给应用杀了个措手不及,没有留给应用任何反应的机会。而反观 kill -15 pid,则比较优雅,先是由AnnotationConfigEmbeddedWebApplicationContext (一个 ApplicationContext 的实现类)收到了通知,紧接着执行了测试代码中的 Shutdown Hook,最后执行了 DisposableBean#destory() 方法。孰优孰劣,立判高下。

一般我们会在应用关闭时处理一下“善后”的逻辑,比如

  1. 关闭 socket 链接
  2. 清理临时文件
  3. 发送消息通知给订阅方,告知自己下线
  4. 将自己将要被销毁的消息通知给子进程
  5. 各种资源的释放
  6. 等等

kill -9 pid 则是直接模拟了一次系统宕机,系统断电,这对于应用来说太不友好了,不要用收割机来修剪花盆里的花。取而代之,便是使用 kill -15 pid 来代替。如果在某次实际操作中发现:kill -15 pid 无法关闭应用,则可以考虑使用内核级别的 kill -9 pid ,但请事后务必排查出是什么原因导致 kill -15 pid 无法关闭。

springboot 如何处理 -15 TERM Signal

上面解释过了,使用 kill -15 pid 的方式可以比较优雅的关闭 springboot 应用,我们可能有以下的疑惑: springboot/spring 是如何响应这一关闭行为的呢?是先关闭了 tomcat,紧接着退出 JVM,还是相反的次序?它们又是如何互相关联的?

尝试从日志开始着手分析,AnnotationConfigEmbeddedWebApplicationContext 打印出了 Closing 的行为,直接去源码中一探究竟,最终在其父类 AbstractApplicationContext 中找到了关键的代码:

@Override
public void registerShutdownHook() {if (this.shutdownHook == null) {this.shutdownHook = new Thread() {@Overridepublic void run() {synchronized (startupShutdownMonitor) {doClose();}}};Runtime.getRuntime().addShutdownHook(this.shutdownHook);}
}
@Override
public void close() {synchronized (this.startupShutdownMonitor) {doClose();if (this.shutdownHook != null) {Runtime.getRuntime().removeShutdownHook(this.shutdownHook);}}
}
protected void doClose() {if (this.active.get() && this.closed.compareAndSet(false, true)) {LiveBeansView.unregisterApplicationContext(this);// 发布应用内的关闭事件publishEvent(new ContextClosedEvent(this));// Stop all Lifecycle beans, to avoid delays during individual destruction.if (this.lifecycleProcessor != null) {this.lifecycleProcessor.onClose();}// spring 的 BeanFactory 可能会缓存单例的 BeandestroyBeans();// 关闭应用上下文&BeanFactorycloseBeanFactory();// 执行子类的关闭逻辑onClose();this.active.set(false);}
}

为了方便排版以及便于理解,我去除了源码中的部分异常处理代码,并添加了相关的注释。在容器初始化时,ApplicationContext 便已经注册了一个 Shutdown Hook,这个钩子调用了 Close() 方法,于是当我们执行 kill -15 pid 时,JVM 接收到关闭指令,触发了这个 Shutdown Hook,进而由 Close() 方法去处理一些善后手段。具体的善后手段有哪些,则完全依赖于 ApplicationContext 的 doClose() 逻辑,包括了注释中提及的销毁缓存单例对象,发布 close 事件,关闭应用上下文等等,特别的,当 ApplicationContext 的实现类是 AnnotationConfigEmbeddedWebApplicationContext 时,还会处理一些 tomcat/jetty 一类内置应用服务器关闭的逻辑。

窥见了 springboot 内部的这些细节,更加应该了解到优雅关闭应用的必要性。JAVA 和 C 都提供了对 Signal 的封装,我们也可以手动捕获操作系统的这些 Signal,在此不做过多介绍,有兴趣的朋友可以自己尝试捕获下。

还有其他优雅关闭应用的方式吗?
spring-boot-starter-actuator 模块提供了一个 restful 接口,用于优雅停机。

添加依赖

<dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

添加配置

#启用shutdown
endpoints.shutdown.enabled=true
#禁用密码验证
endpoints.shutdown.sensitive=false

生产中请注意该端口需要设置权限,如配合 spring-security 使用。

执行 curl -X POST host:port/shutdown 指令,关闭成功便可以获得如下的返回:

{"message":"Shutting down, bye..."}

虽然 springboot 提供了这样的方式,但按我目前的了解,没见到有人用这种方式停机,kill -15 pid 的方式达到的效果与此相同,将其列于此处只是为了方案的完整性。

如何销毁作为成员变量的线程池?

尽管 JVM 关闭时会帮我们回收一定的资源,但一些服务如果大量使用异步回调,定时任务,处理不当很有可能会导致业务出现问题,在这其中,线程池如何关闭是一个比较典型的问题。

@Service
public class SomeService {ExecutorService executorService = Executors.newFixedThreadPool(10);public void concurrentExecute() {executorService.execute(new Runnable() {@Overridepublic void run() {System.out.println("executed...");}});}
}

我们需要想办法在应用关闭时(JVM 关闭,容器停止运行),关闭线程池。

初始方案:什么都不做。在一般情况下,这不会有什么大问题,因为 JVM 关闭,会释放之,但显然没有做到本文一直在强调的两个字,没错—-优雅。

方法一的弊端在于线程池中提交的任务以及阻塞队列中未执行的任务变得极其不可控,接收到停机指令后是立刻退出?还是等待任务执行完成?抑或是等待一定时间任务还没执行完成则关闭?

方案改进:

发现初始方案的劣势后,我立刻想到了使用 DisposableBean 接口,像这样:

@Service
public class SomeService implements DisposableBean{ExecutorService executorService = Executors.newFixedThreadPool(10);public void concurrentExecute() {executorService.execute(new Runnable() {@Overridepublic void run() {System.out.println("executed...");}});}@Overridepublic void destroy() throws Exception {executorService.shutdownNow();//executorService.shutdown();}
}

ThreadPoolExecutor 在 shutdown 之后会变成 SHUTDOWN 状态,无法接受新的任务,随后等待正在执行的任务执行完成。意味着,shutdown 只是发出一个命令,至于有没有关闭还是得看线程自己。

ThreadPoolExecutor 对于 shutdownNow 的处理则不太一样,方法执行之后变成 STOP 状态,并对执行中的线程调用 Thread.interrupt() 方法(但如果线程未处理中断,则不会有任何事发生),所以并不代表“立刻关闭”。

查看 shutdown 和 shutdownNow 的 java doc,会发现如下的提示:

shutdown() :Initiates an orderly shutdown in which previously submitted tasks are executed, but no new tasks will be accepted.Invocation has no additional effect if already shut down.This method does not wait for previously submitted tasks to complete execution.Use {@link #awaitTermination awaitTermination} to do that.
shutdownNow():Attempts to stop all actively executing tasks, halts the processing of waiting tasks, and returns a list of the tasks that were awaiting execution. These tasks are drained (removed) from the task queue upon return from this method.This method does not wait for actively executing tasks to terminate. Use {@link #awaitTermination awaitTermination} to do that.There are no guarantees beyond best-effort attempts to stop processing actively executing tasks. This implementation cancels tasks via {@link Thread#interrupt}, so any task that fails to respond to interrupts may never terminate.

两者都提示我们需要额外执行 awaitTermination 方法,仅仅执行 shutdown/shutdownNow 是不够的。

最终方案:参考 spring 中线程池的回收策略,我们得到了最终的解决方案。

public abstract class ExecutorConfigurationSupport extends CustomizableThreadFactoryimplements DisposableBean{@Overridepublic void destroy() {shutdown();}/*** Perform a shutdown on the underlying ExecutorService.* @see java.util.concurrent.ExecutorService#shutdown()* @see java.util.concurrent.ExecutorService#shutdownNow()* @see #awaitTerminationIfNecessary()*/public void shutdown() {if (this.waitForTasksToCompleteOnShutdown) {this.executor.shutdown();}else {this.executor.shutdownNow();}awaitTerminationIfNecessary();}/*** Wait for the executor to terminate, according to the value of the* {@link #setAwaitTerminationSeconds "awaitTerminationSeconds"} property.*/private void awaitTerminationIfNecessary() {if (this.awaitTerminationSeconds > 0) {try {this.executor.awaitTermination(this.awaitTerminationSeconds, TimeUnit.SECONDS));}catch (InterruptedException ex) {Thread.currentThread().interrupt();}}}
}

保留了注释,去除了一些日志代码,一个优雅关闭线程池的方案呈现在我们的眼前。

  1. 通过 waitForTasksToCompleteOnShutdown 标志来控制是想立刻终止所有任务,还是等待任务执行完成后退出。

  2. executor.awaitTermination(this.awaitTerminationSeconds, TimeUnit.SECONDS)); 控制等待的时间,防止任务无限期的运行(前面已经强调过了,即使是 shutdownNow 也不能保证线程一定停止运行)。

更多需要我们的思考的优雅停机策略

在我们分析 RPC 原理的系列文章里面曾经提到,服务治理框架一般会考虑到优雅停机的问题。通常的做法是事先隔断流量,接着关闭应用

常见的做法是将服务节点从注册中心摘除,订阅者接收通知,移除节点,从而优雅停机;

涉及到数据库操作,则可以使用事务的 ACID 特性来保证即使 crash 停机也能保证不出现异常数据,正常下线则更不用说了;

又比如消息队列可以依靠 ACK 机制+消息持久化,或者是事务消息保障;定时任务较多的服务,处理下线则特别需要注意优雅停机的问题,因为这是一个长时间运行的服务,比其他情况更容易受停机问题的影响,可以使用幂等和标志位的方式来设计定时任务…

事务和 ACK 这类特性的支持,即使是宕机,停电,kill -9 pid 等情况,也可以使服务尽量可靠;而同样需要我们思考的还有 kill -15 pid,正常下线等情况下的停机策略。最后再补充下整理这个问题时,自己对 jvm shutdown hook 的一些理解。

shutdown hook 会保证 JVM 一直运行,知道 hook 终止 (terminated)。这也启示我们,如果接收到 kill -15 pid 命令时,执行阻塞操作,可以做到等待任务执行完成之后再关闭 JVM。同时,也解释了一些应用执行 kill -15 pid 无法退出的问题,没错,中断被阻塞了。

其他好文章:https://blog.csdn.net/u18256007842/article/details/85330504

【Java】优雅停机时的一点思考相关推荐

  1. 研究优雅停机时的一点思考

    作者:徐靖峰 来源:Kirito的技术分享 开头先废话几句,有段时间没有更新博客了,除了公司项目比较忙之外,还有个原因就是开始思考如何更好地写作. 远的来说,我从大一便开始在 CSDN 上写博客,回头 ...

  2. java 优雅停机_spring boot2.0实现优雅停机的方法

    前期踩的坑 (spring boot 1.x) 1. 添加mavne依赖 org.springframework.boot spring-boot-starter-actuator 2. 启用shut ...

  3. 研究 Dubbo 网卡地址注册时的一点思考

    1 如何选择合适的网卡地址 可能相当一部分人还不知道我这篇文章到底要讲什么,我说个场景,大家应该就明晰了.在分布式服务调用过程中,以 Dubbo 为例,服务提供者往往需要将自身的 IP 地址上报给注册 ...

  4. 锁失效_关于bigtable中chubby锁失效时的一点思考

    最近跟国内几家热门公司做分布式存储的大佬们聊了聊,过程十分愉快,但同时也有点小虐.说到底,自己在这个领域并没有很久的经验,很多东西仍停留在知其然而不知其所以然的地步.魔鬼藏在细节之处. 不过这也正好是 ...

  5. java中final class的一点思考

    2019独角兽企业重金招聘Python工程师标准>>> final class什么意思不再多少,但有什么用处了 书上说final class的执行要快一些,因为编译器知道不会继承,所 ...

  6. Java应用的优雅停机

    一. 优雅停机的概念 优雅停机一直是一个非常严谨的话题,但由于其仅仅存在于重启.下线这样的部署阶段,导致很多人忽视了它的重要性,但没有它,你永远不能得到一个完整的应用生命周期,永远会对系统的健壮性持怀 ...

  7. 一文聊透 Dubbo 优雅停机

    点击蓝色"程序猿DD"关注我 回复"资源"获取独家整理的学习资料! 作者 | kiritomoe 来源 | 公众号「Kirito的技术分享」 1 前言 一年之前 ...

  8. 处于停机等非正常状态_一文聊透 Dubbo 优雅停机

    1 前言 一年之前,我曾经写过一篇<研究优雅停机时的一点思考>,主要介绍了 kill -9,kill -15 两个 Linux 指令的含义,并且针对性的聊到了 Spring Boot 应用 ...

  9. 不懂优雅停机,搞挂了线上服务该咋办?

    作者丨陈树义 来源丨公众号:陈树义(ID:gh_b6f5025d4a8d) 公司项目是用 consul 进行注册的,在发布微服务的时候,总是会导致调用方出现一定几率的调用失败.一开始百思不得其解,后来 ...

最新文章

  1. Unity3D 多平台 预编译 宏定义
  2. BZOJ 1101: [POI2007]Zap( 莫比乌斯反演 )
  3. unity3D常见问题
  4. crf的实现 keras_你的 CRF 层的学习率可能不够大
  5. Kalman Filter --卡尔曼滤波
  6. gcc可以编译python程序吗_GCC编译C语言程序完整演示
  7. PresentViewController切换界面
  8. 有序表的最小和(element)
  9. ML之FE:利用【数据分析+数据处理】算法对国内某平台上海2020年6月份房价数据集【12+1】进行特征工程处理(史上最完整,建议收藏)——附录
  10. HCIE-Datacom V1.0 考试大纲
  11. 如何去管理Java项目
  12. BT搜索引擎TorrentSpy被迫永久关闭
  13. 24 个必须掌握的数据库⾯试题
  14. python3中 operator模块用法介绍
  15. AMD意外泄漏下一代APU信息
  16. Python基于YOLOv5的交通标志识别系统[源码&技术文档&部署视频&数据集]
  17. Android实战技巧之四十 Android5 1 1源代码编译与烧写
  18. 机器视觉基础知识/经典系统/常用领域以及机器视觉常用的图像处理库
  19. uni-app 引入线上的阿里 iconfont图标库
  20. 强化学习:Introduction

热门文章

  1. 富士康有麻烦了,iPhone产能已被削减
  2. 《你好,李焕英》总票房逆袭《哪吒》 成中国影史亚军
  3. 未成年人互联网普及率达99% 腾讯等倡议加强青少年网络素养教育
  4. 给还是不给?又一个国家要求苹果必须为iPhone 12提供充电器
  5. 诺基亚赢得运营商Orange比利时5G合同,华为回应...
  6. 高通宣布与华为达成新专利授权协议,华为砸下18亿美元
  7. 特斯拉上市十年回报率高达12倍,马斯克做对了什么?
  8. 降级无门!苹果关闭iOS 13.2.2验证通道
  9. 麒麟990 5G获外媒好评:华为Mate30系列有望引领5G时代新体验
  10. SpaceX公布四月份宇宙飞船爆炸原因:由阀门泄露引发