Java技术专题-了解虚拟机内部运行线程

前提概要
请求处理类型

       本章主要介绍一下相关JVM虚拟机内部的主要运作的线程,包含了一些VM Thread线程(包含GC处理的线程和系统接收外部请求的线程)以及用户定义级别的线程(线程池以及第三方功能的线程池),它们分工协作非常巧妙的构建出了JVM的系统生态,如果可以非常好的了解这些线程的功能以及标志名称,就可以在日后的工作中,非常方便的分析和研究Jstack的一些错误以及运行机制。

AttachListener(请求接收线程)

       AttachListener线程是负责接收到外部的命令,而对该命令进行执行的并且把结果返回给发送者。通常我们会用一些命令去要求JVM给我们一些反馈信息,如:java  -version、jmap、jstack等等。如果该线程在JVM启动的时候没有初始化,那么,则会在用户第一次执行JVM命令时,得到启动。

Signal Dispatcher(信号转发线程)

      前面我们提到第一个Attach Listener线程的职责是接收外部JVM命令,当命令接收成功后,会交给signal dispather线程去进行分发到各个不同的模块处理命令,并且返回处理结果。signal dispather线程也是在第一次接收外部JVM命令时,进行初始化工作。

总结

      可以看出以上的AttachListener线程和Signal Dispatcher线程是属于两者相互解耦的线程,有点类似单一职责且加入了命令模式的概念在里面,一个抓门负责接受(AttachListener)之后进行封装后转发给执行线程(Signal DIspatcher)统一进行执行和派遣工作。如同邮局收件和运件属于两个部门。

编译装载类型
CompilerThread0

       因为JVM涉及到编译器主要是JIT编译器和AOT编译器,本次主要讲解JIT编译器,对于JIT来讲有因为不同的运行模式拥有C1和C2编译器,但底层主要都是通过调用JITing,实时编译装卸class。通常,JVM会启动多个线程来处理这部分工作,线程名称后面的数字也会累加,例如:CompilerThread1、CompilerThread2等等

垃圾回收类型
ConcurrentMark-SweepGCThread

       并发标记清除垃圾回收器(就是通常所说的CMS GC)线程,该线程主要针对于老年代垃圾回收。启用该垃圾回收器,需要在JVM中加上:-XX:+UseConcMarkSweepGC

Finalizer线程

这个线程也是在main线程之后创建的,其优先级为10,主要用于在垃圾收集前,调用对象的finalize()方法;

关于Finalizer线程的几点:

1) 只有当开始一轮垃圾收集时,才会开始调用finalize()方法;因此并不是所有对象的finalize()方法都会被执行;

2) 该线程也是daemon线程,因此如果虚拟机中没有其他非daemon线程,不管该线程有没有执行完finalize()方法,JVM也会退出;

3) JVM在垃圾收集时会将失去引用的对象包装成Finalizer对象(Reference的实现),并放入ReferenceQueue(F-Queue),由Finalizer线程来处理;最后将该Finalizer对象的引用置为null,由垃圾收集器来回收;

4) JVM为什么要单独用一个线程来执行finalize()方法呢?如果JVM的垃圾收集线程自己来做,很有可能由于在finalize()方法中误操作导致GC线程停止或不可控,这对GC线程来说是一种灾难;

Gang worker#0

JVM用于做新生代垃圾回收(minor gc)的一个线程。#号后面是线程编号。

例如:Gang worker#1

GC Daemon

GC Daemon线程是JVM为RMI提供远程分布式GC使用的,GC Daemon线程里面会主动调用System.gc()方法,对服务器进行Full GC。

其初衷是当RMI服务器返回一个对象到其客户机(远程方法的调用方)时,其跟踪远程对象在客户机中的使用。当再没有更多的对客户机上远程对象的引用时,或者如果引用的“租借”过期并且没有更新,服务器将垃圾回收远程对象。不过,我们现在jvm启动参数都加上了-XX:+DisableExplicitGC配置,所以,这个线程只有打酱油的份了。

SurrogateLockerThread

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列队,这个列队的作用,后面会提到。

假设,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对象剔除掉。

系统级销毁
VMThread

这个线程就比较牛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函数去执行该操作类型本身的业务逻辑。

VM操作类型被定义在vm_operations.hpp文件内:

ThreadStop、ThreadDump、PrintThreads、GenCollectFull、GenCollectFullConcurrent、CMS_Initial_Mark、CMS_Final_Remark。

DestroyJavaVM

JVM执行main()的线程在main执行完后调用JNI中的jni_DestroyJavaVM()方法唤起DestroyJavaVM线程。

(1)JVM在Jboss服务器启动之后,就会唤起DestroyJavaVM线程,处于等待状态,等待其它线程(java线程和native线程)退出时通知它卸载JVM的资源。

(2)线程退出时,都会判断自己当前是否是整个JVM中最后一个非daemon线程,如果是,则通知DestroyJavaVM线程卸载JVM。

(3)如果线程退出时判断自己不为最后一个非daemon线程,那么调用thread->exit(false),并在其中抛出thread_end事件,JVM不退出。

(4)如果线程退出时判断自己为最后一个非daemon线程,那么调用before_exit()方法,抛出两个事件:thread_end线程结束事件; 事件VM的death事件,然后调用thread->exit(true)方法,接下来把线程从activelist卸下,删除线程等等一系列工作执行完成后,则通知正在等待的DestroyJavaVM线程执行卸载JVM操作。

JDWP Event Helper ThreadJVM

JDWP是通讯交互协议,它定义了调试器和被调试程序之间传递信息的格式。它详细完整地定义了请求命令、回应数据和错误代码,保证了前端和后端的JVMTI和JDI的通信通畅。 该线程主要负责将JDI事件映射成JVMTI信号,以达到调试过程中操作JVM的目的。

JDWP TransportListener: dt_socket

该线程是一个Java Debugger的监听器线程,负责受理客户端的debug请求。通常我们习惯将它的监听端口设置为8787。

Low MemoryDetector

JVM这个线程是负责对可使用内存进行检测,如果发现可用内存低,分配新的内存空间。

process reaperJVM

该线程负责去执行一个OS命令行的操作。

Reference HandlerJVM

 JVM在创建main线程后就创建Reference Handler线程,其优先级最高,为10,它主要用于处理引用对象本身(软引用、弱引用、虚引用)的垃圾回收问题。

第三方线程
ContainerBackgroundProcessor

JBOSS它是一个守护线程,在JBOSS服务器在启动的时候就初始化了,主要工作是定期去检查有没有Session过期.过期则清除。

ConfigClientNotifierConfigServer

ConfigServer服务端有配置变更时,将最新的配置推送到ConfigServer客户端的数据列队中,ConfigClientNotifier线程定期检查该数据列队中是否有数据,如果有数据,则将数据分发到订阅该数据的组件去做业务逻辑。

比如

tair和hsf的数据都订阅了ConfigServer数据源,当ConfigClientNotifier线程发现数据有更新时,就触发做数据分发特定特定信号标识将数据分发到相应的订阅者。

ConfigClientWorker-DefaultConfigServer

主动向服务器端发送数据(主要是订阅和发布的数据)和接收服务器推送过来的数据(主要是订阅数据) 。

Dispatcher-Thread-3

Log4j具有异步打印日志的功能,需要异步打印日志的Appender都需要注册到AsyncAppender监听器器里面去,由AsyncAppender监听器进行监听,决定何时触发日志打印操作。

AsyncAppender监听器如果监听到它管辖范围内的Appender有打印日志的操作,则给这个Appender监听器生成一个相应的event,并将该event保存在一个Buffer区域内。 

Dispatcher-Thread-3线程负责判断这个event缓存区是否已经满了,如果已经满了,则将缓存区内的所有event分发到Appender执行器里面去,那些注册上来的Appender执行器收到自己的event后,则开始处理自己的日志打印工作,Dispatcher-Thread-3线程是一个守护线程。

IdleRemoverJBOSS

Jboss连接池有一个最小值,该线程每过一段时间都会被Jboss唤起,用于检查和销毁连接池中空闲和无效的连接,直到剩余的连接数小于等于它的最小值。

InsttoolCacheScheduler_QuartzSchedulerThread

Quartz的主线程,它主要负责实时的获取下一个时间点要触发的触发器,然后执行触发器相关联的作业。原理大致如下:Spring和Quartz结合使用的场景下,Spring IOC容器初始化时会创建并初始化Quartz线程池(ThreadPool),并启动它。刚启动时线程池中每个线程都处于等待状态,等待外界给他分配Runnable。

继而接着初始化并启动Quartz的主线程(InsttoolCacheScheduler_QuartzSchedulerThread),该线程自启动后就会处于等待状态。等待外界给出工作信号之后,该主线程的run方法才实质上开始工作。

run中会获取JobStore中下一次要触发的作业,拿到之后会一直等待到该作业的真正触发时间,然后将该作业包装成一个JobRunShell对象(该对象实现了Runnable接口,其实看是上面ThreadPool中等待外界分配给他的Runnable),然后将刚创建的JobRunShell交给线程池,由线程池负责执行作业。线程池收到Runnable后,从线程池一个线程启动Runnable,反射调用JobRunShell中的run方法,run方法执行完成之后,TreadPool将该线程回收至空闲线程中。

InsttoolCacheScheduler_Worker-2

InsttoolCacheScheduler_Worker-2线程就是ThreadPool线程的一个简单实现,它主要负责分配线程资源去执行InsttoolCacheScheduler_QuartzSchedulerThread线程交给它的调度任务(也就是JobRunShell)。

JBossLifeThreadJboss

Jboss主线程启动成功,应用程序部署完毕之后将JBossLifeThread线程实例化并且start,JBossLifeThread线程启动成功之后就处于等待状态,以保持Jboss Java进程处于存活中。 所得比较通俗一点,就是Jboss启动流程执行完毕之后,为什么没有结束?就是因为有这个线程hold主了它。牛b吧~~

JBoss System Threads(1)-1Jboss 该线程是一个socket服务,默认端口号为:1099。主要用于接收外部naming service(Jboss  JNDI)请求。

JCA PoolFiller

该线程主要为JBoss内部提供连接池的托管。 简单介绍一下工作原理:Jboss内部凡是有远程连接需求的类,都需要实现ManagedConnectionFactory接口,例如需要做JDBC连接的XAManagedConnectionFactory对象,就实现了该接口。然后将XAManagedConnectionFactory对象,还有其它信息一起包装到InternalManagedConnectionPool对象里面,接着将InternalManagedConnectionPool交给PoolFiller对象里面的列队进行管理。  

JCA PoolFiller线程会定期判断列队内是否有需要创建和管理的InternalManagedConnectionPool对象,如果有的话,则调用该对象的fillToMin方法,触发它去创建相应的远程连接,并且将这个连接维护到它相应的连接池里面去。

taskObjectTimerFactoryJVM

顾名思义,该线程就是用来执行任务的。当我们把一个任务交给Timer对象,并且告诉它执行时间,周期时间后,Timer就会将该任务放入任务列队,并且通知taskObjectTimerFactory线程去处理任务,taskObjectTimerFactory线程会将状态为取消的任务从任务列队中移除,如果任务是非重复执行类型的,则在执行完该任务后,将它从任务列队中移除,如果该任务是需要重复执行的,则计算出它下一次执行的时间点。

VM Periodic Task ThreadJVM

该线程是JVM周期性任务调度的线程,它由WatcherThread创建,是一个单例对象。该线程在JVM内使用得比较频繁,比如:定期的内存监控、JVM运行状况监控,还有我们经常需要去执行一些jstat这类命令查看gc的情况,

如下

jstat -gcutil 23483 250 7  这个命令告诉jvm在控制台打印PID为:23483的gc情况,间隔250毫秒打印一次,一共打印7次。

案例

S0C、S1C、S0U、S1U:Survivor 0/1区容量(Capacity)和使用量(Used)

EC、EU:Eden区容量和使用量

OC、OU:年老代容量和使用量

PC、PU:永久代容量和使用量

YGC、YGT:年轻代GC次数和GC耗时

FGC、FGCT:Full GC次数和Full GC耗时

GCT:GC总耗时

本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
THE END
分享
二维码
< <上一篇
下一篇>>