hi,all:
最近抽时间把JVM运行过程中产生的一些线程进行了整理,主要是围绕着我们系统jstack生成的文件为参照依据。 前段时间因为系统代码问题,造成性能到了天花板,于是就dump了一份stack出来进行分析。 看stack其实也需要一定的经验,毕竟它里面很多线程不可能都是有问题,所以,需要对他们有一定认识。 现在市面上很少有人对这一块做整理,所以,导致很多新人在拿到一个stack文件之后,也是一头雾水。 下面我把这次整理的一些个人认为比较重要的线程列出来,供大家参考。 如果发现有什么写得不对或者可以补充的地方,也请朋友们抱着乐于分享的态度灌灌水。
线程名称
|
所属
|
解释说明
|
Attach Listener
|
JVM
|
Attach Listener 线程是负责接收到外部的命令,而对该命令进行执行的并且吧结果返回给发送者。通常我们会用一些命令去要求jvm给我们一些反馈信息,如:java -version、jmap、jstack等等。 如果该线程在jvm启动的时候没有初始化,那么,则会在用户第一次执行jvm命令时,得到启动。
|
Signal Dispatcher
|
JVM
|
前面我们提到第一个Attach Listener线程的职责是接收外部jvm命令,当命令接收成功后,会交给signal dispather 线程去进行分发到各个不同的模块处理命令,并且返回处理结果。 signal dispather线程也是在第一次接收外部jvm命令时,进行初始化工作。
|
CompilerThread0
|
JVM
|
用来调用JITing,实时编译装卸class 。 通常,jvm会启动多个线程来处理这部分工作,线程名称后面的数字也会累加,例如:CompilerThread1
|
Concurrent Mark-Sweep GC Thread
|
JVM
|
并发标记清除垃圾回收器(就是通常所说的CMS GC)线程, 该线程主要针对于老年代垃圾回收。ps:启用该垃圾回收器,需要在jvm启动参数中加上: -XX:+UseConcMarkSweepGC
|
DestroyJavaVM
|
JVM
|
执行main()的线程在main执行完后调用JNI中的 jni_DestroyJavaVM() 方法唤起DestroyJavaVM 线程。 JVM在 Jboss 服务器启动之后,就会唤起DestroyJavaVM线程,处于等待状态,等待其它线程(java线程和native线程)退出时通知它卸载JVM。线程退出时,都会判断自己当前是否是整个JVM中最后一个非deamon线程,如果是,则通知DestroyJavaVM 线程卸载JVM。
ps:
扩展一下:
1.如果线程退出时判断自己不为最后一个非deamon线程,那么调用thread->exit(false) ,并在其中抛出thread_end事件,jvm不退出。
2.如果线程退出时判断自己为最后一个非deamon线程,那么调用before_exit() 方法,抛出两个事件: 事件1:thread_end 线程结束事件、事件2:VM的death事件。
然后调用thread->exit(true) 方法,接下来把线程从active list卸下,删除线程等等一系列工作执行完成后,则通知正在等待的DestroyJavaVM 线程执行卸载JVM操作。
|
ContainerBackgroundProcessor 线程
|
JBOSS
|
它是一个守护线程, 在jboss服务器在启动的时候就初始化了,主要工作是定期去检查有没有Session过期.过期则清除.
参考:http://liudeh-009.iteye.com/blog/1584876
|
Dispatcher-Thread-3 线程
|
Log4j
|
Log4j具有异步打印日志的功能,需要异步打印日志的Appender都需要注册到 AsyncAppender对象里面去,由AsyncAppender进行监听,决定何时触发日志打印操作。 AsyncAppender如果监听到它管辖范围内的Appender有打印日志的操作,则给这个Appender生成一个相应的event,并将该event保存在一个buffuer区域内。 Dispatcher-Thread-3线程负责判断这个event缓存区是否已经满了,如果已经满了,则将缓存区内的所有event分发到Appender容器里面去,那些注册上来的Appender收到自己的event后,则开始处理自己的日志打印工作。 Dispatcher-Thread-3线程是一个守护线程。
|
Finalizer线程
|
JVM
|
这个线程也是在main线程之后创建的,其优先级为10,主要用于在垃圾收集前,调用对象的finalize()方法;关于Finalizer线程的几点:
1) 只有当开始一轮垃圾收集时,才会开始调用finalize()方法;因此并不是所有对象的finalize()方法都会被执行;
2) 该线程也是daemon线程,因此如果虚拟机中没有其他非daemon线程,不管该线程有没有执行完finalize()方法,JVM也会退出;
3) JVM在垃圾收集时会将失去引用的对象包装成Finalizer对象(Reference的实现),并放入ReferenceQueue,由Finalizer线程来处理;最后将该Finalizer对象的引用置为null,由垃圾收集器来回收;
4) JVM为什么要单独用一个线程来执行finalize()方法呢?如果JVM的垃圾收集线程自己来做,很有可能由于在finalize()方法中误操作导致GC线程停止或不可控,这对GC线程来说是一种灾难;
|
Gang worker#0
|
JVM
|
JVM 用于做新生代垃圾回收(monir gc)的一个线程。#号后面是线程编号,例如:Gang worker#1
|
GC Daemon
|
JVM
|
GC Daemon 线程是JVM为RMI提供远程分布式GC使用的,GC Daemon线程里面会主动调用System.gc()方法,对服务器进行Full GC。 其初衷是当 RMI 服务器返回一个对象到其客户机(远程方法的调用方)时,其跟踪远程对象在客户机中的使用。当再没有更多的对客户机上远程对象的引用时,或者如果引用的“租借”过期并且没有更新,服务器将垃圾回收远程对象。
不过,我们现在jvm启动参数都加上了-XX:+DisableExplicitGC配置,所以,这个线程只有打酱油的份了。
|
IdleRemover
|
JBOSS
|
Jboss连接池有一个最小值, 该线程每过一段时间都会被Jboss唤起,用于检查和销毁连接池中空闲和无效的连接,直到剩余的连接数小于等于它的最小值。
|
Java2D Disposer
|
JVM
|
这个线程主要服务于awt的各个组件。 说起该线程的主要工作职责前,需要先介绍一下Disposer类是干嘛的。 Disposer提供一个addRecord方法。 如果你想在一个对象被销毁前再做一些善后工作,那么,你可以调用Disposer#addRecord方法,将这个对象和一个自定义的DisposerRecord接口实现类,一起传入进去,进行注册。
Disposer类会唤起“Java2D Disposer”线程,该线程会扫描已注册的这些对象是否要被回收了,如果是,则调用该对象对应的DisposerRecord实现类里面的dispose方法。
Disposer实际上不限于在awt应用场景,只是awt里面的很多组件需要访问很多操作系统资源,所以,这些组件在被回收时,需要先释放这些资源。
|
InsttoolCacheScheduler_QuartzSchedulerThread
|
Quartz
|
InsttoolCacheScheduler_QuartzSchedulerThread是Quartz的主线程,它主要负责实时的获取下一个时间点要触发的触发器,然后执行触发器相关联的作业 。
原理大致如下:
Spring和Quartz结合使用的场景下,Spring IOC容器初始化时会创建并初始化Quartz线程池(TreadPool),并启动它。刚启动时线程池中每个线程都处于等待状态,等待外界给他分配Runnable(持有作业对象的线程)。
继而接着初始化并启动Quartz的主线程(InsttoolCacheScheduler_QuartzSchedulerThread),该线程自启动后就会处于等待状态。等待外界给出工作信号之后,该主线程的run方法才实质上开始工作。run中会获取JobStore中下一次要触发的作业,拿到之后会一直等待到该作业的真正触发时间,然后将该作业包装成一个JobRunShell对象(该对象实现了Runnable接口,其实看是上面TreadPool中等待外界分配给他的Runnable),然后将刚创建的JobRunShell交给线程池,由线程池负责执行作业。
线程池收到Runnable后,从线程池一个线程启动Runnable,反射调用JobRunShell中的run方法,run方法执行完成之后, TreadPool将该线程回收至空闲线程中。
|
InsttoolCacheScheduler_Worker-2
|
Quartz
|
InsttoolCacheScheduler_Worker-2线程就是ThreadPool线程的一个简单实现,它主要负责分配线程资源去执行
InsttoolCacheScheduler_QuartzSchedulerThread线程交给它的调度任务(也就是JobRunShell)。
|
JBossLifeThread
|
Jboss
|
Jboss主线程启动成功,应用程序部署完毕之后将JBossLifeThread线程实例化并且start,JBossLifeThread线程启动成功之后就处于等待状态,以保持Jboss Java进程处于存活中。 所得比较通俗一点,就是Jboss启动流程执行完毕之后,为什么没有结束? 就是因为有这个线程hold主了它。 牛b吧~~
|
JBoss System Threads(1)-1
|
Jboss
|
该线程是一个socket服务,默认端口号为: 1099。 主要用于接收外部naming service(Jboss JNDI)请求。
|
JCA PoolFiller
|
Jboss
|
该线程主要为JBoss内部提供连接池的托管。 简单介绍一下工作原理 :
Jboss内部凡是有远程连接需求的类,都需要实现ManagedConnectionFactory接口,例如需要做JDBC连接的
XAManagedConnectionFactory对象,就实现了该接口。然后将XAManagedConnectionFactory对象,还有其它信息一起包装到InternalManagedConnectionPool对象里面,接着将InternalManagedConnectionPool交给PoolFiller对象里面的列队进行管理。 JCA PoolFiller线程会定期判断列队内是否有需要创建和管理的InternalManagedConnectionPool对象,如果有的话,则调用该对象的fillToMin方法, 触发它去创建相应的远程连接,并且将这个连接维护到它相应的连接池里面去。
|
JDWP Event Helper Thread
|
JVM
|
JDWP是通讯交互协议,它定义了调试器和被调试程序之间传递信息的格式。它详细完整地定义了请求命令、回应数据和错误代码,保证了前端和后端的JVMTI和JDI的通信通畅。 该线程主要负责将JDI事件映射成JVMTI信号,以达到调试过程中操作JVM的目的。
|
JDWP Transport Listener: dt_socket
|
JVM
|
该线程是一个Java Debugger的监听器线程,负责受理客户端的debug请求。 通常我们习惯将它的监听端口设置为8787。
|
Low Memory Detector
|
JVM
|
这个线程是负责对可使用内存进行检测,如果发现可用内存低,分配新的内存空间。
|
process reaper
|
JVM
|
该线程负责去执行一个 OS 命令行的操作。
|
Reference Handler
|
JVM
|
JVM在创建main线程后就创建Reference Handler线程,其优先级最高,为10,它主要用于处理引用对象本身(软引用、弱引用、虚引用)的垃圾回收问题 。
|
Surrogate Locker Thread (CMS)
|
JVM
|
这个线程主要用于配合CMS垃圾回收器使用,它是一个守护线程,其主要负责处理GC过程中,Java层的Reference(指软引用、弱引用等等)与jvm 内部层面的对象状态同步。 这里对它们的实现稍微做一下介绍:这里拿 WeakHashMap做例子,将一些关键点先列出来(我们后面会将这些关键点全部串起来):
1. 我们知道HashMap用Entry[]数组来存储数据的,WeakHashMap也不例外, 内部有一个Entry[]数组。
2. WeakHashMap的Entry比较特殊,它的继承体系结构为Entry->WeakReference->Reference 。
3. Reference 里面有一个全局锁对象:Lock,它也被称为pending_lock. 注意:它是静态对象。
4. Reference 里面有一个静态变量:pending。
5. Reference 里面有一个静态内部类:ReferenceHandler的线程,它在static块里面被初始化并且启动,启动完成后处于wait状态,它在一个Lock同步锁模块中等待。
6. 另外,WeakHashMap里面还实例化了一个ReferenceQueue列队,这个列队的作用,后面会提到。
7. 上面关键点就介绍完毕了,下面我们把他们串起来。
假设,WeakHashMap对象里面已经保存了很多对象的引用。 JVM 在进行CMS GC的时候,会创建一个ConcurrentMarkSweepThread(简称CMST)线程去进行GC,ConcurrentMarkSweepThread线程被创建的同时会创建一个SurrogateLockerThread(简称SLT)线程并且启动它,SLT启动之后,处于等待阶段。CMST开始GC时,会发一个消息给SLT让它去获取Java层Reference对象的全局锁:Lock。 直到CMS GC完毕之后,JVM 会将WeakHashMap中所有被回收的对象所属的WeakReference容器对象放入到Reference 的pending属性当中(每次GC完毕之后,pending属性基本上都不会为null了),然后通知SLT释放并且notify全局锁:Lock。此时激活了ReferenceHandler线程的run方法,使其脱离wait状态,开始工作了。ReferenceHandler这个线程会将pending中的所有WeakReference对象都移动到它们各自的列队当中,比如当前这个WeakReference属于某个WeakHashMap对象,那么它就会被放入相应的ReferenceQueue列队里面(该列队是链表结构)。 当我们下次从WeakHashMap对象里面get、put数据或者调用size方法的时候,WeakHashMap就会将ReferenceQueue列队中的WeakReference依依poll出来去和Entry[]数据做比较,如果发现相同的,则说明这个Entry所保存的对象已经被GC掉了,那么将Entry[]内的Entry对象剔除掉。
|
taskObjectTimerFactory
|
JVM
|
顾名思义,该线程就是用来执行任务的。 当我们把一个认为交给Timer对象,并且告诉它执行时间,周期时间后,Timer就会将该任务放入任务列队,并且通知taskObjectTimerFactory线程去处理任务,taskObjectTimerFactory线程会将状态为取消的任务从任务列队中移除,如果任务是非重复执行类型的,则在执行完该任务后,将它从任务列队中移除,如果该任务是需要重复执行的,则计算出它下一次执行的时间点。
|
VM Periodic Task Thread
|
JVM
|
该线程是JVM周期性任务调度的线程,它由WatcherThread创建,是一个单例对象。 该线程在JVM内使用得比较频繁,比如:定期的内存监控、JVM运行状况监控,还有我们经常需要去执行一些jstat 这类命令查看gc的情况,如下:
jstat -gcutil 23483 250 7 这个命令告诉jvm在控制台打印PID为:23483的gc情况,间隔250毫秒打印一次,一共打印7次。
|
VM Thread
|
JVM
|
这个线程就比较牛b了,是jvm里面的线程母体,根据hotspot源码(vmThread.hpp)里面的注释,它是一个单例的对象(最原始的线程)会产生或触发所有其他的线程,这个单个的VM线程是会被其他线程所使用来做一些VM操作(如,清扫垃圾等)。
在 VMThread 的结构体里有一个VMOperationQueue列队,所有的VM线程操作(vm_operation)都会被保存到这个列队当中,VMThread 本身就是一个线程,它的线程负责执行一个自轮询的loop函数(具体可以参考:VMThread.cpp里面的void VMThread::loop()) ,该loop函数从VMOperationQueue列队中按照优先级取出当前需要执行的操作对象(VM_Operation),并且调用VM_Operation->evaluate函数去执行该操作类型本身的业务逻辑。
ps:VM操作类型被定义在vm_operations.hpp文件内,列举几个:ThreadStop、ThreadDump、PrintThreads、GenCollectFull、GenCollectFullConcurrent、CMS_Initial_Mark、CMS_Final_Remark….. 有兴趣的同学,可以自己去查看源文件。
|
分享到:
相关推荐
Java线程Dump分析工具jstack是Java开发人员和运维人员常用的诊断工具,它能够帮助我们了解Java应用程序中线程的状态,以及线程的执行轨迹。本文将深入解析jstack的使用方法及其在不同场景下的应用。 jstack命令的...
`jstack`命令是Java开发中用于诊断线程堆栈信息的重要工具,它可以帮助开发者了解Java应用程序的线程状态,包括运行、等待、阻塞等,以及是否存在死锁等问题。当遇到性能问题或者线程卡住不前时,`jstack`能提供关键...
jstack是Java虚拟机自带的堆栈跟踪工具,它用于生成Java虚拟机当前时刻的线程快照。线程快照显示了Java虚拟机内每条线程正在执行的方法堆栈,这对于定位线程长时间停顿的原因非常有帮助。线程快照主要用来排查问题,...
通过`jstack`命令(Java堆栈跟踪工具),我们可以获取到应用的线程快照,即dump线程,从而分析是否存在死锁。`jstack`命令可以显示所有线程的状态,包括它们的堆栈跟踪,这对于定位死锁非常有帮助。 3. **使用...
1. **生成线程堆栈**:首先,你需要通过`jstack`命令对目标Java进程进行dump,命令格式通常为`jstack <pid>`,其中`pid`是Java进程的ID。这会生成一个包含所有线程信息的文本文件。 2. **上传线程日志**:将生成的...
其中,`jstack` 命令是一个 Java 命令行工具,用于生成 Thread Dump。 在 Unix 系统中,可以使用 `kill -3 <pid>` 命令来获取 Thread Dump,其中 `<pid>` 是 JVM 进程的进程 ID。在 Windows 系统中,可以按下 CTRL+...
本文将详细介绍`JStack`的使用方法及其在分析Java线程堆栈中的应用。 #### 二、JStack简介 `JStack`是Java Development Kit (JDK)的一部分,用于生成正在运行的Java应用程序的线程快照。这些快照提供了关于每个...
Java内存dump分析和Thread Dump(Java Core)是Java性能调优中的重要环节,它们能帮助开发者定位和解决系统中的各种问题,如内存泄漏、线程阻塞等。下面将详细介绍这两个概念及其分析工具。 首先,Java堆内存dump,...
需要本地安装JDK并配置JAVA环境变量。 之后使用java -jar jca469.jar即可打开工具。 直接将dump出来的堆栈信息,打开,便可分析。
JVM提供了一个强大的工具——`jstack`,用于生成线程堆栈转储,即Thread Dump,帮助开发者洞察线程的运行状态,识别性能瓶颈或死锁等问题。本文将详细探讨Thread Dump中的线程状态,以及如何分析和解决相关问题。 1...
【描述】:jstack命令用于生成Java应用程序的线程堆栈跟踪,它可以帮助开发者诊断Java应用中的线程问题。线程Dump日志提供了详细的线程状态和调用栈信息,这对于理解和解决线程阻塞、死锁等问题至关重要。如果堆栈...
线程 Dump 分析是 IT 系统性能优化中不可或缺的一部分,尤其在 Java 应用程序中,当系统出现响应慢或者卡死等异常情况时,通过获取和分析线程 Dump 文件,我们可以找出导致问题的线程,定位内存泄漏、死锁等问题。...
通过命令`jstack`(Java堆栈跟踪工具)可以方便地生成线程Dump文件。然而,对于大型系统来说,Dump文件中的信息量巨大,手工分析往往耗时且困难,难以快速定位问题所在。 这就是`TDA`发挥作用的地方。它具备以下...
Kubernetes 应用 Java 程序无法使用 jmap, jstack 的解决方案 背景: 在 Kubernetes 环境中,运行 Java 程序时,无法使用 jmap 和 jstack 命令进行性能分析和诊断。这种情况下,无法获取 Java 进程的 pid,导致无法...
3. **jstack命令**: jstack是JDK提供的命令行工具,用于打印Java应用程序的线程堆栈信息,这对于定位死锁和阻塞问题非常有用。 三、Java API提供的线程监控 1. **Thread类**: Java中的Thread类提供了获取当前线程、...
本文将详细探讨Java内存分析、dump分析、jmap和jstack工具的使用,以及如何利用这些工具进行堆栈分析。 首先,Java内存分析主要关注的是程序运行时的内存分配和管理。Java内存分为堆内存(Heap)、栈内存(Stack)...
Java线程 Dump(Thread Dump)是Java应用程序在特定时间点的线程状态快照,它包含每个线程的详细信息,如线程ID、线程名称、线程状态以及调用堆栈。当Java应用程序出现性能问题、死锁或者线程阻塞等情况时,Thread ...
- **组合使用jstack和tda**:在遇到Java应用性能问题或者线程异常时,先用`jstack`生成Thread Dump,然后使用tda进行解析和分析,这样可以提高问题定位的效率和准确性。 - **线程分析**:tda可以识别出可能的死锁...
通过`jstack <pid>`命令,我们可以获取到Java进程的详细线程信息,包括线程ID、线程状态和调用堆栈,这对于定位线程问题非常有帮助。 其次,`jconsole`是一个图形化的JVM监视工具,它可以提供内存使用情况、线程...