ch/qos/logback/core/hook/ShutdownHook.java
一个正在运行 Java 应用如果突然将其停止,影响不止数据丢失,还会造成其他影响。比如:
想象一下,如果你现在刚好在 word 上写需求文档,电脑突然重启。等待开机完成,你可能会发现写了一个小时文档没有保存,就这么没了。。。
在Linux上通过kill -9 pid方式强制终止进程的副作用,这种方式虽然简单高效,但也会带来一些问题,特别是对于应用软件而言。这些问题包括但不限于:
在java程序中,很容易在进程结束时添加一个钩子,即ShutdownHook。通常在程序启动时加入以下代码即可
任何一个中间件系统,都需要有个“平滑部署,平滑下线”的功能。 如果基于Java开发,往往采用ShutDownHook去做这件事情。 比如我们在tomcat关闭时,注册ServletContextListener,在上下文销毁时,进行ShutDownHook调用。
我在公司内负责自研的dubbo注册中心相关工作,群里经常接到业务方反馈dubbo接口注销报错。经排查,确定是同一个接口调用了两次注销接口导致,由于我们的注册中心注销接口不能重复调用,调用第二次会因为实例已经注销而报实例找不到的错误。
这次Spring Boot 2.3对于这个常见场景做了配置化实现,下面就来一起看看如何使用吧!
上期文章分享了ShutdownHook的API和基本使用,但是少了一些实际工作中的案例,总感觉没啥大用一样。
reactor-netty-0.7.6.RELEASE-sources.jar!/reactor/ipc/netty/NettyConnector.java
当我们流量请求到此接口执行业务逻辑的时候,若服务端此时执行关机 (kill),spring boot 默认情况会直接关闭容器(tomcat 等),导致此业务逻辑执行失败。在一些业务场景下:会出现数据不一致的情况,事务逻辑不会回滚。
有一次发现代码中添加的 ShutdownHook没有生效,难道和 kill命令后面的数字有关?
目前Spring Boot已经发展到了2.3.4.RELEASE,伴随着2.3版本的到来,优雅停机机制也更加完善了。
kill命令可将指定的信号发送给相应的进程或工作。kill命令默认使用信号为15,用于结束进程或工作。如果进程或工作忽略此信号,则可以使用信号9,强制杀死进程或作业.
就上线来说,如果组件或者容器没有启动成功,就不应该对外暴露服务,对于下线来说,如果机器已经停机了,就应该保证服务已下线,如此可避免上游流量进入不健康的机器。
对于微服务来说,服务的优雅上下线是必要的。就上线来说,如果组件或者容器没有启动成功,就不应该对外暴露服务,对于下线来说,如果机器已经停机了,就应该保证服务已下线,如此可避免上游流量进入不健康的机器。
本文通过阅读Tomcat启动和关闭流程的源码,深入分析不同的Tomcat关闭方式背后的原理,让开发人员能够了解在使用不同的关闭方式时需要注意的点,避免因JVM进程异常退出导致的各种非预见性错误。
-jvm的不同shutdownHook执行是并行的也就造成了,spring容器的关闭和日志系统关闭时间先后的不确定
首先我们来看看BeanDefinition的存放位置。因为Bean对象的实例化肯定是BeanFactory基于对应的BeanDefinition的定义来实现的,所以在这个过程中BeanDefinition是非常重要的,前面的课程讲解已经完成了BeanDefinition的定义。同时根据前面refresh方法的讲解我们知道了BeanFactory的具体实现是 DefaultListableBeanFactory.所以BeanDefinition的相关信息是存储在 DefaultListableBeanFactory的相关属性中的。
时间追溯到2018年12月的某一天夜晚,那天我正准备上线一个需求完就回家,刚点下发布按钮,告警就响起,我擦,难道回不了家了?看着报错量只有一两个,断定只是偶发,稳住不要慌。
最近负责的项目已经到达10万 QPS的大关了,这么高的QPS,对系统的稳定性要求也更高了。之前QPS小的时候,系统更新部署很简单,现在不行了,一部署起来,上游应用方就找过来了,说你这应用咋回事,怎么突然抖动厉害了。。。
最近碰到一个问题,通过脚本执行kill -15后,程序并没有退出,进程一直都在,最后被退出脚本的通过kill -9,杀死。导致数据完整性被破坏,程序再重启后不可用。通过排查认后发现是在执行shutdownHook时死锁程序死锁。
我们编写的Web项目部署之后,经常会因为需要进行配置变更或功能迭代而重启服务,单纯的kill -9 pid的方式会强制关闭进程,这样就会导致服务端当前正在处理的请求失败,那有没有更优雅的方式来实现关机或重启呢?
对于任何一个线上应用,如何在服务更新部署过程中保证客户端无感知是开发者必须要解决的问题,即从应用停止到重启恢复服务这个阶段不能影响正常的业务请求。理想条件下,在没有请求的时候再进行更新是最安全可靠的,然而互联网应用必须要保证可用性,因此在技术层面上优化应用更新流程来保证服务在更新时无损是必要的。
Netty一个主要的目标就是促进“关注点分离”:使业务逻辑从网络基础设施应用程序中分离。不仅仅是Netty框架,其他框架的设计目的也大都是为了使业务程序和底层技术解耦,使程序员更加专注于业务逻辑实现,提高开发质量和效率。Netty为什么性能如此之高,主要是其内部的Reactor模型机制。
在 『ShutdownHook- Java 优雅停机解决方案』 一文中我们聊到了 Java 实现优雅停机原理。接下来我们就跟根据上面知识点,深入 Dubbo 内部,去了解一下 Dubbo 如何实现优雅停机。
Dubbo Spring Boot 工程致力于简化 Dubbo RPC 框架在Spring Boot应用场景的开发。同时也整合了 Spring Boot 特性:
前一篇服务框架技术栈粗略分析了服务框架需要的各个核心模块,首先提到的就是注册中心,注册中心实现了服务注册和发现的功能,在服务框架中也发挥着重要的作用。今天主要围绕注册中心实现的话题展开。
在实际项目中,Netty作为高性能的异步NIO通信框架,承担着各种协议的接入、解析和调度等任务,例如在RPC和分布式服务框架中,Netty常常被用作内部私有协议的基础通信框架。因此,在应用进程优雅退出时,Netty作为通信框架也需要进行优雅退出,以保证系统的稳定性和可靠性。
最近瞥了一眼项目的重启脚本,发现运维一直在使用 kill-9<pid> 的方式重启 springboot embedded tomcat,其实大家几乎一致认为: kill-9<pid> 的方式比较暴力,但究竟会带来什么问题却很少有人能分析出个头绪。这篇文章主要记录下自己的思考过程。 kill -9 和 kill -15 有什么区别? 在以前,我们发布 WEB 应用通常的步骤是将代码打成 war 包,然后丢到一个配置好了应用容器(如 Tomcat,Weblogic)的 Linux 机器上,这时候我们想要启动
1 介绍 微服务架构中的应用优雅停机主要是指应用实例有计划而平滑(即不产生需要处理的事故)的退出。应用服务器的停机主要分为两类:主动停机和被动停机,而其中主动停机和大部分的被动停机都是
otter/node/deployer/src/main/java/com/alibaba/otter/node/deployer/OtterLauncher.java
可以从linux进程关闭说起,其实,我们经常使用到杀进程的指令背后,就涉及到是否优雅下线的理念。
1.launchExecutor Master发送消息让Worker启动Executor
rocketmq-client-4.5.2-sources.jar!/org/apache/rocketmq/client/producer/DefaultMQProducer.java
本文是Netty文集中“Netty 源码解析”系列的文章。主要对Netty的重要流程以及类进行源码解析,以使得我们更好的去使用Netty。Netty是一个非常优秀的网络框架,对其源码解读的过程也是不断学习的过程。 Netty的优雅关闭操作 Netty是通过『eventLoopGroup.shutdownGracefully()』操作来实现它的优雅关闭的。 我们先来看下shutdownGracefully方法的doc说明: /** * Signals this executor tha
问题由来 今天运行工程时,发现停止tomcat时,java进程并不会退出,而是必须kill -9杀掉tomcat进程。 问题出现时将线程dump出来后,发现有一个非daemon的线程仍在运行。 "Hashed wheel timer #1" prio=6 tid=0x000000000ee73800 nid=0x750 waiting on condition [0x000000001383e000] java.lang.Thread.State: TIMED_WAITING (sleeping)
最近在学习和使用Web3j的过程中,发现一个非常奇怪的现象,当我使用了sendAsync()方法后,JVM进程一直无法退出。
今天学到了一个非常有趣的API:java.lang.Runtime#addShutdownHook,顾名思义,就是JVM shutdown的钩子,当JVM关闭时触发的。addShutdownHook 方法是 java.lang.Runtime 类提供的一个方法,用于注册在Java虚拟机即将关闭时执行的代码块(也称为“钩子”或“hook”)。这个代码块会在程序终止之前被执行,无论是正常终止还是由于异常终止。
最近在学习Java虚拟线程,打算深挖一下性能测试方面的潜力。不过在升级JDK的过程中遇到了一些意外情况。遇到了一个比较难缠的问题,报错信息如下:
一个 Tomcat 中有一个 Server,每个 Server 中至少有一个 Service。一个 Service 由至少一个 Connector 与一个 Container 组成。
领取专属 10元无门槛券
手把手带您无忧上云