JVM内部的线程

原文地址：http://club.alibabatech.org/article_detail.htm?articleId=4 有个人整理。

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

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

• RMI TCP Accept/RMI TCP Connection
  调试时出现的线程。

• CompilerThread0
  用来调用JITing，实时编译装卸class。通常，jvm会启动多个线程来处理这部分工作，线程名称后面的数字也会累加，例如：CompilerThread1

• Finalizer线程
  这个线程也是在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线程来说是一种灾难

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

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

• Gang worker#0
  JVM用于做新生代垃圾回收（minor gc）的一个线程。

• Concurrent Mark-Sweep GC Thread
  并发标记清除垃圾回收器(就是通常所说的CMS GC)线程， 该线程主要针对于年老代垃圾回收。

• Surrogate Locker Thread (CMS)
  这个线程主要用于配合CMS垃圾回收器使用，它是一个守护线程，其主要负责处理GC过程中，Java层的Reference(指软引用、弱引用等等)与jvm 内部层面的对象状态同步。

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

• DestroyJavaVM
  执行main()的线程在main执行完后调用JNI中的 jni_DestroyJavaVM() 方法唤起DestroyJavaVM 线程。每一个用户线程退出时，都会判断自己是否时最后一个用户线程，是的话就通知DestroyJavaVM线程彻底关闭虚拟机。

• VM Periodic Task Thread
  该线程是JVM周期性任务调度的线程，它由WatcherThread创建，是一个单例对象。
  该线程在JVM内使用得比较频繁，比如：定期的内存监控、JVM运行状况监控。