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总耗时