Java多線程：死結，java多線程
周末看到一個用jstack查看死結的例子。昨天晚上總結了一下jstack(查看線程)、jmap(查看記憶體)和jstat(效能分析)命令。供大家參考
1．Jstack
1.1 jstack能得到運行java程式的java stack和native stack的資訊。可以輕鬆得知當前線程的運行情況。如所示
註：這個和thread dump是同樣的結果。但是thread dump是用kill -3 pid命令，還是伺服器上面少用kill為妙
1.2 命名行格式
jstack [ option ] pid
jstack [ option ] executable core
jstack [ option ] [server-id@]remote-hostname-or-IP
最常用的還是jstack pid
1.3 在thread dump中，要留意下面幾種狀態
死結，Deadlock（重點關注）
等待資源，Waiting on condition（重點關注）
• 等待擷取監視器，Waiting on monitor entry（重點關注）
阻塞，Blocked（重點關注）
• 執行中，Runnable
• 暫停，Suspended
• 對象等待中，Object.wait() 或 TIMED_WAITING
• 停止，Parked
下面有詳細的例子講這種分析，大家參考原著
http://www.cnblogs.com/zhengyun_ustc/archive/2013/01/06/dumpanalysis.html
線程名稱 所屬 解釋說明 Attach Listener JVM Attach Listener 線程是負責接收到外部的命令，而對該命令進行執行的並且吧結果返回給寄件者。通常我們會用一些命令去要求jvm給我們一些反饋資訊，如：java -version、jmap、jstack等等。 如果該線程在jvm啟動的時候沒有初始化，那麼，則會在使用者第一次執行jvm命令時，得到啟動。
Signal DispatcherJVM前面我們提到第一個Attach Listener線程的職責是接收外部jvm命令，當命令接收成功後，會交給signal dispather 線程去進行分發到各個不同的模組處理命令，並且返回處理結果。 signal dispather線程也是在第一次接收外部jvm命令時，進行初始化工作。
CompilerThread0JVM用來調用JITing，Just-In-Time 編譯裝卸class 。 通常，jvm會啟動多個線程來處理這部分工作，線程名稱後面的數字也會累加，例如：CompilerThread1
Concurrent Mark-Sweep GC ThreadJVM並發標記清除記憶體回收行程（就是通常所說的CMS GC）線程， 該線程主要針對於老年代記憶體回收。ps：啟用該記憶體回收行程，需要在jvm啟動參數中加上： -XX:+UseConcMarkSweepGC
DestroyJavaVMJVM執行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_
QuartzSchedulerThreadQuartz 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）。
JBossLifeThreadJboss Jboss主線程啟動成功，應用程式部署完畢之後將JBossLifeThread線程執行個體化並且start，JBossLifeThread線程啟動成功之後就處於等待狀態，以保持Jboss Java進程處於存活中。 所得比較通俗一點，就是Jboss啟動流程執行完畢之後，為什麼沒有結束？ 就是因為有這個線程hold主了它。 牛b吧～～
JBoss System Threads(1)-1 Jboss 該線程是一個socket服務，預設連接埠號碼為： 1099。 主要用於接收外部naming service（Jboss JNDI）請求。
JCA PoolFillerJboss 該線程主要為JBoss內部提供串連池的託管。 簡單介紹一下工作原理 ：
Jboss內部凡是有遠端連線需求的類，都需要實現ManagedConnectionFactory介面，例如需要做JDBC串連的
XAManagedConnectionFactory對象，就實現了該介面。然後將XAManagedConnectionFactory對象，還有其它資訊一起封裝到InternalManagedConnectionPool對象裡面，接著將InternalManagedConnectionPool交給PoolFiller對象裡面的列隊進行管理。 JCA PoolFiller線程會定期判斷列隊內是否有需要建立和管理的InternalManagedConnectionPool對象，如果有的話，則調用該對象的fillToMin方法， 觸發它去建立相應的遠端連線，並且將這個串連維護到它相應的串連池裡面去。
JDWP Event Helper ThreadJVM
JDWP是通訊互動協議，它定義了調試器和被偵錯工具之間傳遞資訊的格式。它詳細完整地定義了請求命令、回應資料和錯誤碼，保證了前端和後端的JVMTI和JDI的通訊通暢。 該線程主要負責將JDI事件映射成JVMTI訊號，以達到調試過程中操作JVM的目的。
JDWP Transport Listener: dt_socketJVM該線程是一個Java Debugger的監聽器線程，負責受理用戶端的debug請求。 通常我們習慣將它的監聽連接埠設定為8787。
Low Memory DetectorJVM這個線程是負責對可使用記憶體進行檢測，如果發現可用記憶體低，分配新的記憶體空間。
process reaperJVM 該線程負責去執行一個 OS 命令列的操作。
Reference HandlerJVM JVM在建立main線程後就建立Reference Handler線程，其優先順序最高，為10，它主要用於處理引用對象本身（軟引用、弱引用、虛引用）的記憶體回收問
