Springboot shutdown 耗时太长的分析使用btrace

2023-11-04 08:08
文章标签 java 分析 使用 springboot spring 耗时 shutdown 太长 btrace

本文主要是介绍Springboot shutdown 耗时太长的分析使用btrace，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

背景

从本文你可以学到如何分析jvm无法正常关闭的问题? 知道why and how.

没怎么用过springboot, 但是还是咬牙上了. 在这篇使用springboottest和h2来构建数据库测试的采坑记录中就发现我们的应用在测试用例跑完了无法自动关闭. 而且还总是等了2分钟就自动关闭了. 然后最开始以为是test case才有问题 结果发现是应用本身运行的时候正常关闭也有问题.
如下图:(测试已经完了,springboot开始shutdown 但是进程本身没有退出)
在这里插入图片描述

先google

发现都是说的如何gracefully shutdown的… 并没有立即shutdown的… 开始以为是springboot的问题, 写了个简单demo发现可以正常快速关闭…

初步诊断

一个简单办法是后台应用额外启动一个线程, 不断打印线程堆栈, 看看有哪些非daemon的线程,

        Thread th = new Thread(new Runnable() {@Overridepublic void run() {while(true) {try {Thread.sleep(1000 * 5);}catch (InterruptedException e) {e.printStackTrace();}Thread.getAllStackTraces().forEach((th, els) -> {System.out.println("-----------------");if (!th.isDaemon()) {System.out.println("non daemon:" + th);for (StackTraceElement e : els) {System.out.println("\t\t" + e);}} else {System.out.println("Daemon thread:" + th);}System.out.println("-----------------");});}}});th.setName("PrintThread");th.setDaemon(true);th.start();

我发现了这个:

Daemon thread:Thread[pool-8-thread-1,5,main]
-----------------
-----------------
non daemon:Thread[nioEventLoopGroup-2-4,10,main]sun.nio.ch.KQueueArrayWrapper.kevent0(Native Method)sun.nio.ch.KQueueArrayWrapper.poll(KQueueArrayWrapper.java:198)sun.nio.ch.KQueueSelectorImpl.doSelect(KQueueSelectorImpl.java:117)sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)io.netty.channel.nio.SelectedSelectionKeySetSelector.select(SelectedSelectionKeySetSelector.java:62)io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:753)io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:408)io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:897)io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)java.lang.Thread.run(Thread.java:748)
-----------------
-----------------
Daemon thread:Thread[Attach Listener,9,system]
-----------------
-----------------
Daemon thread:Thread[BTrace Command Queue Processor,5,main]
-----------------
-----------------
Daemon thread:Thread[RMI TCP Accept-0,5,system]
-----------------
-----------------
Daemon thread:Thread[Abandoned connection cleanup thread,5,main]
-----------------
-----------------
non daemon:Thread[pool-3-thread-1,5,main]sun.misc.Unsafe.park(Native Method)java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)java.lang.Thread.run(Thread.java:748)
-----------------
-----------------
Daemon thread:Thread[RMI TCP Connection(3)-127.0.0.1,5,RMI Runtime]
-----------------
-----------------
Daemon thread:Thread[PrintThread,5,main]
-----------------
-----------------
non daemon:Thread[pool-6-thread-1,5,main]sun.misc.Unsafe.park(Native Method)java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)java.lang.Thread.run(Thread.java:748)
-----------------
-----------------
Daemon thread:Thread[Monitor Ctrl-Break,5,main]
-----------------
-----------------
non daemon:Thread[nioEventLoopGroup-2-3,10,main]sun.nio.ch.KQueueArrayWrapper.kevent0(Native Method)sun.nio.ch.KQueueArrayWrapper.poll(KQueueArrayWrapper.java:198)sun.nio.ch.KQueueSelectorImpl.doSelect(KQueueSelectorImpl.java:117)sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)io.netty.channel.nio.SelectedSelectionKeySetSelector.select(SelectedSelectionKeySetSelector.java:62)io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:753)io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:408)io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:897)io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)java.lang.Thread.run(Thread.java:748)
-----------------
-----------------
non daemon:Thread[nioEventLoopGroup-2-5,10,main]sun.nio.ch.KQueueArrayWrapper.kevent0(Native Method)sun.nio.ch.KQueueArrayWrapper.poll(KQueueArrayWrapper.java:198)sun.nio.ch.KQueueSelectorImpl.doSelect(KQueueSelectorImpl.java:117)sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)io.netty.channel.nio.SelectedSelectionKeySetSelector.select(SelectedSelectionKeySetSelector.java:62)io.netty.channel.nio.NioEventLoop.select(NioEventLoop.java:753)io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:408)io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:897)io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)java.lang.Thread.run(Thread.java:748)
-----------------
-----------------
Daemon thread:Thread[COThread-kb,5,main]

有很多netty的线程没有关闭. 那么问题来了 : 如何知道是谁创建的这些线程呢? 在一个复杂项目中

大杀器 BTrace

我的另外一篇博客: 记录一次TCP连接异常问题-使用btrace
完整的代码参考github的md: btrace_usage.md 里面的0.1 Add an example of how to run 部分.
以前也有用过btrace, 发现btrace从 com.sun开源出来了… 给oracle点赞… 所以才有了更新后的文档.

回归正题

在这里插入图片描述可以看到是我们引用的一个外部组件初始化的netty. 想办法加入springboot shutdownhook中就可以了. ps结果还发现了项目中其他多个地方非daemon线程. 统一修改后就可以了. 比如用guava的ThreadFactoryBuilder修饰一下就可以了

Executors.newSingleThreadScheduledExecutor(new ThreadFactoryBuilder().setDaemon(true).setNameFormat("cleanup-expirecode").build()).scheduleAtFixedRate(()

思考问题

  1. 前面我有说到, 在自己的应用启动了一个额外的进程来打印堆栈, 实际上这个可以通过btrace实现.就留给大家思考啦.
  2. springboot的DelayedShutdownHook 解决完自身的非daemon后发现还剩一个这个:
non daemon:Thread[DelayedShutdownHook-for-java.util.concurrent.ThreadPoolExecutor@2c47a053[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0],5,main]sun.misc.Unsafe.park(Native Method)java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)java.util.concurrent.ThreadPoolExecutor.awaitTermination(ThreadPoolExecutor.java:1475)com.google.common.util.concurrent.MoreExecutors$Application$1.run(MoreExecutors.java:203)java.lang.Thread.run(Thread.java:748)

如何通过btrace找到这个线程池是谁创建的呢? (ps: 跟前面监控线程创建类似类似)
结果发现是guava的线程池封装:

我们的代码:// private final ExecutorService _executor = Executors.newSingleThreadExecutor();private final ExecutorService _executor = MoreExecutors.getExitingExecutorService((ThreadPoolExecutor)Executors.newFixedThreadPool(1));

guava的代码:
com.google.common.util.concurrent.MoreExecutors.Application#getExitingExecutorService(java.util.concurrent.ThreadPoolExecutor)final ExecutorService getExitingExecutorService(ThreadPoolExecutor executor) {return getExitingExecutorService(executor, 120, TimeUnit.SECONDS);}

是的没错, 就是2分钟!!! 问题到此解决了.

这篇关于Springboot shutdown 耗时太长的分析使用btrace的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/344408。

相关文章

JVM 的类初始化机制

JVM 的类初始化机制

前言 当你在 Java 程序中new对象时，有没有考虑过 JVM 是如何把静态的字节码（byte code）转化为运行时对象的呢，这个问题看似简单，但清楚的同学相信也不会太多，这篇文章首先介绍 JVM 类初始化的机制，然后给出几个易出错的实例来分析，帮助大家更好理解这个知识点。 JVM 将字节码转化为运行时对象分为三个阶段，分别是：loading 、Linking、initialization
阅读更多...
Spring Security 基于表达式的权限控制

Spring Security 基于表达式的权限控制

前言 spring security 3.0已经可以使用spring el表达式来控制授权，允许在表达式中使用复杂的布尔逻辑来控制访问的权限。 常见的表达式 Spring Security可用表达式对象的基类是SecurityExpressionRoot。 表达式描述hasRole([role])用户拥有制定的角色时返回true （Spring security默认会带有ROLE_前缀）,去
阅读更多...
浅析Spring Security认证过程

浅析Spring Security认证过程

类图 为了方便理解Spring Security认证流程，特意画了如下的类图，包含相关的核心认证类 概述 核心验证器 AuthenticationManager 该对象提供了认证方法的入口，接收一个Authentiaton对象作为参数; public interface AuthenticationManager {Authentication authenticate(Authenti
阅读更多...
Spring Security--Architecture Overview

Spring Security--Architecture Overview

1 核心组件 这一节主要介绍一些在Spring Security中常见且核心的Java类，它们之间的依赖，构建起了整个框架。想要理解整个架构，最起码得对这些类眼熟。 1.1 SecurityContextHolder SecurityContextHolder用于存储安全上下文（security context）的信息。当前操作的用户是谁，该用户是否已经被认证，他拥有哪些角色权限…这些都被保
阅读更多...
Spring Security基于数据库验证流程详解

Spring Security基于数据库验证流程详解

Spring Security 校验流程图 相关解释说明（认真看哦） AbstractAuthenticationProcessingFilter 抽象类 /*** 调用 #requiresAuthentication(HttpServletRequest, HttpServletResponse) 决定是否需要进行验证操作。* 如果需要验证，则会调用 #attemptAuthentica
阅读更多...
Spring Security 从入门到进阶系列教程

Spring Security 从入门到进阶系列教程

Spring Security 入门系列 《保护 Web 应用的安全》 《Spring-Security-入门（一）：登录与退出》 《Spring-Security-入门（二）：基于数据库验证》 《Spring-Security-入门（三）：密码加密》 《Spring-Security-入门（四）：自定义-Filter》 《Spring-Security-入门（五）：在 Sprin
阅读更多...
Java架构师知识体认识

Java架构师知识体认识

源码分析 常用设计模式 Proxy代理模式Factory工厂模式Singleton单例模式Delegate委派模式Strategy策略模式Prototype原型模式Template模板模式 Spring5 beans 接口实例化代理Bean操作 Context Ioc容器设计原理及高级特性Aop设计原理Factorybean与Beanfactory Transaction 声明式事物
阅读更多...
中文分词jieba库的使用与实景应用（一）

中文分词jieba库的使用与实景应用（一）

知识星球：https://articles.zsxq.com/id_fxvgc803qmr2.html 目录 一.定义： 精确模式（默认模式）： 全模式： 搜索引擎模式： paddle 模式（基于深度学习的分词模式）： 二 自定义词典 三.文本解析   调整词出现的频率 四. 关键词提取 A. 基于TF-IDF算法的关键词提取 B. 基于TextRank算法的关键词提取
阅读更多...
使用SecondaryNameNode恢复NameNode的数据

使用SecondaryNameNode恢复NameNode的数据

1）需求： NameNode进程挂了并且存储的数据也丢失了，如何恢复NameNode 此种方式恢复的数据可能存在小部分数据的丢失。 2）故障模拟 （1）kill -9 NameNode进程 [lytfly@hadoop102 current]$ kill -9 19886 （2）删除NameNode存储的数据（/opt/module/hadoop-3.1.4/data/tmp/dfs/na
阅读更多...
Hadoop数据压缩使用介绍

Hadoop数据压缩使用介绍

一、压缩原则 （1）运算密集型的Job，少用压缩 （2）IO密集型的Job，多用压缩 二、压缩算法比较 三、压缩位置选择 四、压缩参数配置 1）为了支持多种压缩/解压缩算法，Hadoop引入了编码/解码器 2）要在Hadoop中启用压缩，可以配置如下参数
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2