java命令行工具-jstack

综合整理。

介绍

通过thread dump的信息，可以定位到特定线程及其调用栈。配合top命令，可以找到系统中最耗CPU的线程代码段，这样能有针对性地进行优化。

jstack和thread dump有同样的结果，thread dump是用kill -3 pid命令得到的。

命令格式

$jstack [ option ] pid

$jstack [ option ] executable core

$jstack [ option ] [server-id@]remote-hostname-or-IP

参数说明

-F，在jstack -l pid无法响应时，强制打印堆栈。进程处于hung死状态可以用-F强制打出。

-l，长列表格式，打印关于锁的附加信息，如属于java.util.concurrent的ownable synchronizers列表。

-m，混合模式输出(包括java和本地c/c++片段)堆栈。

pid，进程号。

executable，产生core dump的java可执行程序。

core，打印出的core文件。

remote-hostname-or-ip，远程debug服务器的名称或IP。

server-id，唯一id，假如一台主机上有多个远程debug服务。

在thread dump中，线程的几种状态：

1、死锁(Deadlock)，重点关注。

2、等待资源(Waiting on condition)，重点关注。

3、等待获取监视器(Waiting on monitor entry)，重点关注。

4、阻塞(Blocked)，重点关注。

5、执行中(Runnable)，可不关注。

6、暂停(Suspended)，可不关注。

7、对象等待中(Object.wait()或TIMED_WAITING)，可不关注。

8、停止(Parked)，可不关注。

查看哪个线程占用最多资源。

ps mp pid -o THREAD,tid，查看这个进程下的所有线程占用情况。

发现线程324占用最多。

用jstack进行跟踪。

jstack pid重定向到临时文件

jstack 324 > a.dump

将刚刚发现占用cpu最多的线程id(324)换算成16进制，324 --> 144

查看jstack生成的文件：

然后可以看出是哪行代码导致的。

实例讲解

实例1：Waiting to lock 和 Blocked

"RMI TCP Connection(267865)-172.16.5.25" daemon prio=10 tid=0x00007fd508371000 nid=0x55ae waiting for monitor entry [0x00007fd4f8684000]

java.lang.Thread.State: BLOCKED (on object monitor)

at org.apache.log4j.Category.callAppenders(Category.java:201)

- waiting to lock <0x00000000acf4d0c0> (a org.apache.log4j.Logger)

at org.apache.log4j.Category.forcedLog(Category.java:388)

at org.apache.log4j.Category.log(Category.java:853)

at org.apache.commons.logging.impl.Log4JLogger.warn(Log4JLogger.java:234)

at com.tuan.core.common.lang.cache.remote.SpyMemcachedClient.get(SpyMemcachedClient.java:110)

说明：

1、线程状态是Blocked，阻塞状态。说明线程等待资源超时！

2、“waiting to lock <0x00000000acf4d0c0>”指，线程在等待给这个0x00000000acf4d0c0地址上锁(英文可描述为：trying to obtain 0x00000000acf4d0c0 lock)。

3、在dump日志里查找字符串0x00000000acf4d0c0，发现有大量线程都在等待给这个地址上锁。如果能在日志里找到谁获得了这个锁(如locked < 0x00000000acf4d0c0 >)，就可以顺藤摸瓜了。

4、“waiting for monitor entry”说明此线程通过 synchronized(obj) {……} 申请进入了临界区，从而进入了下图1中的“Entry Set”队列，但该 obj 对应的 monitor 被其他线程拥有，所以本线程在 Entry Set 队列中等待。

5、第一行里，"RMI TCP Connection(267865)-172.16.5.25"是 Thread Name 。tid指Java Thread id。nid指native线程的id。prio是线程优先级。[0x00007fd4f8684000]是线程栈起始地址。

实例2：Waiting on condition 和 TIMED_WAITING

"RMI TCP Connection(idle)" daemon prio=10 tid=0x00007fd50834e800 nid=0x56b2 waiting on condition [0x00007fd4f1a59000]

java.lang.Thread.State: TIMED_WAITING (parking)

at sun.misc.Unsafe.park(Native Method)

- parking to wait for <0x00000000acd84de8> (a java.util.concurrent.SynchronousQueue$TransferStack)

at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:198)

at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:424)

at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:323)

at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:874)

at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:945)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)

at java.lang.Thread.run(Thread.java:662)

说明：

1、“TIMED_WAITING (parking)”中的 timed_waiting 指等待状态，但这里指定了时间，到达指定的时间后自动退出等待状态；parking指线程处于挂起中。

2、“waiting on condition”需要与堆栈中的“parking to wait for <0x00000000acd84de8> (a java.util.concurrent.SynchronousQueue$TransferStack)”结合来看。首先，本线程肯定是在等待某个条件的发生，来把自己唤醒。其次，SynchronousQueue 并不是一个队列，只是线程之间移交信息的机制，当我们把一个元素放入到 SynchronousQueue 中时必须有另一个线程正在等待接受移交的任务，因此这就是本线程在等待的条件。

实例3：in Obejct.wait() 和 TIMED_WAITING

"RMI RenewClean-[172.16.5.19:28475]" daemon prio=10 tid=0x0000000041428800 nid=0xb09 in Object.wait() [0x00007f34f4bd0000]

java.lang.Thread.State: TIMED_WAITING (on object monitor)

at java.lang.Object.wait(Native Method)

- waiting on <0x00000000aa672478> (a java.lang.ref.ReferenceQueue$Lock)

at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118)

- locked <0x00000000aa672478> (a java.lang.ref.ReferenceQueue$Lock)

at sun.rmi.transport.DGCClient$EndpointEntry$RenewCleanThread.run(DGCClient.java:516)

at java.lang.Thread.run(Thread.java:662)

说明：

1、“TIMED_WAITING (on object monitor)”，对于本例而言，是因为本线程调用了 java.lang.Object.wait(long timeout) 而进入等待状态。

2、“Wait Set”中等待的线程状态就是“ in Object.wait() ”。当线程获得了 Monitor，进入了临界区之后，如果发现线程继续运行的条件没有满足，它则调用对象(一般就是被 synchronized 的对象)的 wait() 方法，放弃了 Monitor，进入 “Wait Set”队列。只有当别的线程在该对象上调用了 notify() 或者 notifyAll() ，“ Wait Set”队列中线程才得到机会去竞争，但是只有一个线程获得对象的 Monitor，恢复到运行态。

3、RMI RenewClean是DGCClient的一部分。DGC指的是Distributed GC，即分布式垃圾回收。

4、请注意，是先 locked <0x00000000aa672478>，后waiting on <0x00000000aa672478>，之所以先锁再等同一个对象，请看下面它的代码实现：

static private class Lock { };

private Lock lock = new Lock();

public Reference<? extends T> remove(long timeout) {

synchronized (lock) {

Reference<? extends T> r = reallyPoll();

if (r != null) return r;

for (;;) {

lock.wait(timeout);

r = reallyPoll();

...

}

即，线程的执行中，先用synchronized获得了这个对象的 Monitor(对应于 locked <0x00000000aa672478> )；当执行到lock.wait(timeout);，线程就放弃了Monitor的所有权，进入“Wait Set”队列(对应于waiting on <0x00000000aa672478>)。

5、从堆栈信息看，是正在清理remote references to remote objects，引用的租约到了，分布式垃圾回收在逐一清理。

线程状态分析

Waiting on condition

该状态出现在线程等待某个条件的发生。具体是什么原因，可以结合stacktrace来分析。最常见的情况是线程在等待网络的读写，比如当网络数据没有准备好读时，线程处于这种等待状态，而一旦有数据准备好读之后，线程会重新激活，读取并处理数据。在 Java引入 NIO之前，对于每个网络连接，都有一个对应的线程来处理网络的读写操作，即使没有可读写的数据，线程仍然阻塞在读写操作上，这样有可能造成资源浪费，而且给操作系统的线程调度也带来压力。在 NIO里采用了新的机制，编写的服务器程序的性能和可扩展性都得到提高。

如果发现有大量的线程都在处在Wait on condition，从线程stack看，正等待网络读写，这可能是一个网络瓶颈的征兆。因为网络阻塞导致线程无法执行。一种情况是网络非常忙，几乎消耗了所有的带宽，仍然有大量数据等待网络读写；另一种情况也可能是网络空闲，但由于路由等问题，导致包无法正常的到达。所以要结合系统的一些性能观察工具来综合分析，比如netstat统计单位时间的发送包的数目，如果很明显超过了所在网络带宽的限制;观察cpu的利用率，如果系统态的CPU时间，相对于用户态的 CPU时间比例较高；如果程序运行在Solaris 10平台上，可以用 dtrace工具看系统调用的情况，如果观察到read/write的系统调用的次数或者运行时间遥遥领先；这些都指向由于网络带宽所限导致的网络瓶颈。

另外一种出现Waiting on condition的常见情况是该线程在 sleep，等待 sleep的时间到了时候，将被唤醒。

Waiting for monitor entry和in Object.wait()

在多线程的程序中，实现线程之间的同步，要了解Monitor。Monitor是Java中用以实现线程之间的互斥与协作的主要手段，它可以看成是对象或者Class的锁。每一个对象都有，也仅有一个monitor。下图描述了线程和Monitor之间关系，以及线程的状态转换。

每个Monitor在某个时刻，只能被一个线程拥有，该线程就是“Active Thread”，而其它线程都是“Waiting Thread”，分别在两个队列 “ Entry Set”和“Wait Set”里面等候。在“Entry Set”中等待的线程状态是“Waiting for monitorentry”，而在“Wait Set”中等待的线程状态是“in Object.wait()”。

先看“Entry Set”里面的线程。被synchronized保护起来的代码段为临界区。当一个线程申请进入临界区时，它就进入了“Entry Set”队列。对应的code就像：

synchronized(obj){

...

}

这时有两种可能性：

a.该monitor不被其它线程拥有，Entry Set里面也没有其它等待线程。本线程即成为相应类或者对象的Monitor的Owner，执行临界区的代码。此时线程将处于Runnable状态；

b.该monitor被其它线程拥有，本线程在Entry Set队列中等待。此时dump的信息显示“waiting for monitor entry”。

"Thread-0" prio=10 tid=0x08222eb0 nid=0x9 waiting for monitor entry [0xf927b000..0xf927bdb8]

at testthread.WaitThread.run(WaitThread.java:39)

- waiting to lock <0xef63bf08> (a java.lang.Object)

- locked <0xef63beb8> (a java.util.ArrayList)

at java.lang.Thread.run(Thread.java:595)

临界区的设置，是为了保证其内部的代码执行的原子性和完整性。但是因为临界区在任何时间只允许线程串行通过，这和我们多线程的程序的初衷是相反的。如果在多线程的程序中，大量使用 synchronized，或者不适当的使用了它，会造成大量线程在临界区的入口等待，造成系统的性能大幅下降。如果在线程 DUMP中发现了这个情况，应该审查源码，改进程序。

再来看现在线程为什么会进入“Wait Set”。当线程获得了Monitor，进入了临界区之后，如果发现线程继续运行的条件没有满足，它则调用对象(一般就是被 synchronized 的对象)的 wait() 方法，放弃了 Monitor，进入 “Wait Set”队列。只有当别的线程在该对象上调用了notify()或者notifyAll()，“Wait Set”队列中线程才得到机会去竞争，但是只有一个线程获得对象的Monitor，恢复到运行态。在“Wait Set”中的线程， DUMP中表现为： in Object.wait()，类似于：

"Thread-1" prio=10 tid=0x08223250 nid=0xa in Object.wait() [0xef47a000..0xef47aa38]

at java.lang.Object.wait(Native Method)

- waiting on <0xef63beb8> (a java.util.ArrayList)

at java.lang.Object.wait(Object.java:474)

at testthread.MyWaitThread.run(MyWaitThread.java:40)

- locked <0xef63beb8> (a java.util.ArrayList)

at java.lang.Thread.run(Thread.java:595)

仔细观察上面的DUMP信息，会发现它有以下两行：

locked <0xef63beb8> (ajava.util.ArrayList)

waiting on <0xef63beb8> (ajava.util.ArrayList)

这里需要解释一下，为什么先lock了这个对象，然后又waiting on同一个对象呢？看看这个线程对应的代码：

synchronized(obj) {

...

obj.wait();

...

}

线程的执行中，先用synchronized获得了这个对象的Monitor(对应于locked <0xef63beb8>)。当执行到obj.wait(),线程即放弃了Monitor的所有权，进入“wait set”队列(对应于waiting on<0xef63beb8>)。

在程序中，往往会出现多个类似的线程，它们都有相似的dump也可能是正常的。比如，在程序中有多个服务线程，设计成从一个队列里面读取请求数据。这个队列就是lock以及waiting on的对象。当队列为空的时候，这些线程都会在这个队列上等待，直到队列有了数据，这些线程被notify，当然只有一个线程获得了lock，继续执行，而其它线程继续等待。

上面提到如果synchronized和monitor机制运用不当，可能会造成多线程程序的性能问题。在JDK5.0中，引入了Lock机制，从而使开发者能更灵活的开发高性能的并发多线程程序，可以替代以往JDK中的synchronized和Monitor的机制。但要注意的是，因为Lock类只是一个普通类，JVM无从得知Lock对象的占用情况，所以在线程DUMP中，也不会包含关于Lock的信息，关于死锁等问题，就不如用synchronized的编程方式容易识别。

案例分析

死锁

在下面这个示例中，是个较为典型的死锁情况：

"Thread-1" prio=5 tid=0x00acc490 nid=0xe50 waiting for monitor entry [0x02d3f000..0x02d3fd68]

at deadlockthreads.TestThread.run(TestThread.java:31)

- waiting to lock <0x22c19f18> (a java.lang.Object)

- locked <0x22c19f20> (a java.lang.Object)

"Thread-0" prio=5 tid=0x00accdb0 nid=0xdec waiting for monitor entry [0x02cff000..0x02cff9e8]

at deadlockthreads.TestThread.run(TestThread.java:31)

- waiting to lock <0x22c19f20> (a java.lang.Object)

- locked <0x22c19f18> (a java.lang.Object)

在JAVA5中加强了对死锁的检测。线程Dump中可以直接报告出Java级别的死锁，如下所示：

Found one Java-level deadlock:

=============================

"Thread-1":

waiting to lock monitor 0x0003f334 (object 0x22c19f18, a java.lang.Object),

which is held by "Thread-0"

"Thread-0":

waiting to lock monitor 0x0003f314 (object 0x22c19f20, a java.lang.Object),

which is held by "Thread-1"

热锁

热锁，也往往是导致系统性能瓶颈的主要因素。其表现特征为，由于多个线程对临界区，或者锁的竞争，可能出现：

* 频繁的线程的上下文切换：从操作系统对线程的调度来看，当线程在等待资源而阻塞的时候，操作系统会将之切换出来，放到等待的队列，当线程获得资源之后，调度算法会将这个线程切换进去，放到执行队列中。

* 大量的系统调用：因为线程的上下文切换，以及热锁的竞争，或者临界区的频繁的进出，都可能导致大量的系统调用。

* 大部分CPU开销用在“系统态”：线程上下文切换，和系统调用，都会导致 CPU在 “系统态 ”运行，换而言之，虽然系统很忙碌，但是 CPU用在 “用户态 ”的比例较小，应用程序得不到充分的 CPU资源。

* 随着CPU数目的增多，系统的性能反而下降。因为 CPU数目多，同时运行的线程就越多，可能就会造成更频繁的线程上下文切换和系统态的 CPU开销，从而导致更糟糕的性能。

上面的描述，都是一个scalability(可扩展性)很差的系统的表现。从整体的性能指标看，由于线程热锁的存在，程序的响应时间会变长，吞吐量会降低。

那么，怎么去了解“热锁”出现在什么地方呢？一个重要的方法还是结合操作系统的各种工具观察系统资源使用状况，以及收集 Java线程的 DUMP信息，看线程都阻塞在什么方法上，了解原因，才能找到对应的解决方法。

综合运用

第一步，找出Java进程ID，jps即可。

第二步，找出该进程内最耗费CPU的线程，可以使用ps -Lfp pid或者ps mp pid -o THREAD,tid,time或者top -Hp pid，这里用第三个，输出如下：

TIME列就是各个Java线程耗费的CPU时间，CPU时间最长的是线程ID为21742的线程，用

printf "%x\n" 21742

得到21742的十六进制值为54ee，下面会用到。

第三步，用jstack输出进程21711的堆栈信息，然后根据线程ID的十六进制值grep，如下：

jstack 21711 | grep 54ee

"PollIntervalRetrySchedulerThread" prio=10 tid=0x00007f950043e000 nid=0x54ee in Object.wait() [0x00007f94c6eda000]

可以看到CPU消耗在PollIntervalRetrySchedulerThread这个类的Object.wait()，定位到代码：

// Idle wait

getLog().info("Thread [" + getName() + "] is idle waiting...");

schedulerThreadState = PollTaskSchedulerThreadState.IdleWaiting;

long now = System.currentTimeMillis();

long waitTime = now + getIdleWaitTime();

long timeUntilContinue = waitTime - now;

synchronized(sigLock) {

try {

if(!halted.get()) {

sigLock.wait(timeUntilContinue);

}

catch (InterruptedException ignore) {

}

它是轮询任务的空闲等待代码，上面的sigLock.wait(timeUntilContinue)就对应了前面的Object.wait()。

参考

JVM运行中的一些线程，以jstack生成的文件为依据。

线程名称	所属	解释说明
Attach Listener	JVM	Attach Listener线程是负责接收到外部的命令，而对该命令进行执行的，并且把结果返回给发送者。我们会用一些命令去要求jvm提供一些反馈信息，如：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)线程，该线程主要针对于老年代垃圾回收。
DestroyJavaVM	JVM	执行main()的线程在main执行完后调用JNI中的jni_DestroyJavaVM()唤起DestroyJavaVM线程。JVM在Jboss服务器启动之后，就会唤起DestroyJavaVM线程，处于等待状态，等待其它线程(java线程和native线程)退出时通知它卸载JVM。线程退出时，都会判断自己当前是否是整个JVM中最后一个非deamon线程，如果是，则通知DestroyJavaVM线程卸载JVM。扩展一下： 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操作。
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配置，所以，这个线程只有打酱油的份了。
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)。
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…。