| Attach Listener |
JVM |
Attach Listener線程是負(fù)責(zé)接收到外部的命令，而對(duì)該命令進(jìn)行執(zhí)行的并且吧結(jié)果返回給發(fā)送者。通常我們會(huì)用一些命令去要求jvm給我們一些反饋信息咸这，如：java -version、jmap纪他、jstack等等戈抄。如果該線程在jvm啟動(dòng)的時(shí)候沒有初始化年柠，那么狡相，則會(huì)在用戶第一次執(zhí)行jvm命令時(shí)梯轻，得到啟動(dòng)。 |
| Signal Dispatcher |
JVM |
前面我們提到第一個(gè)Attach Listener線程的職責(zé)是接收外部jvm命令尽棕，當(dāng)命令接收成功后喳挑，會(huì)交給signal dispather線程去進(jìn)行分發(fā)到各個(gè)不同的模塊處理命令，并且返回處理結(jié)果滔悉。signal dispather線程也是在第一次接收外部jvm命令時(shí)伊诵，進(jìn)行初始化工作。 |
| CompilerThread0 |
JVM |
用來調(diào)用JITing回官，實(shí)時(shí)編譯裝卸class曹宴。通常，jvm會(huì)啟動(dòng)多個(gè)線程來處理這部分工作歉提，線程名稱后面的數(shù)字也會(huì)累加笛坦，例如：CompilerThread1 |
| ConcurrentMark-SweepGCThread |
JVM |
并發(fā)標(biāo)記清除垃圾回收器（就是通常所說的CMS GC）線程，該線程主要針對(duì)于老年代垃圾回收唯袄。ps：啟用該垃圾回收器弯屈，需要在jvm啟動(dòng)參數(shù)中加上：-XX:+UseConcMarkSweepGC |
| DestroyJavaVM |
JVM |
執(zhí)行main()的線程在main執(zhí)行完后調(diào)用JNI中的jni_DestroyJavaVM()方法喚起DestroyJavaVM線程蜗帜。 JVM在Jboss服務(wù)器啟動(dòng)之后恋拷，就會(huì)喚起DestroyJavaVM線程，處于等待狀態(tài)厅缺，等待其它線程（java線程和native線程）退出時(shí)通知它卸載JVM蔬顾。線程退出時(shí)，都會(huì)判斷自己當(dāng)前是否是整個(gè)JVM中最后一個(gè)非deamon線程湘捎，如果是诀豁，則通知DestroyJavaVM線程卸載JVM。ps：擴(kuò)展一下：1.如果線程退出時(shí)判斷自己不為最后一個(gè)非deamon線程窥妇，那么調(diào)用thread->exit(false)舷胜，并在其中拋出thread_end事件，jvm不退出活翩。2.如果線程退出時(shí)判斷自己為最后一個(gè)非deamon線程烹骨，那么調(diào)用before_exit()方法翻伺，拋出兩個(gè)事件： 事件1：thread_end線程結(jié)束事件、事件2：VM的death事件沮焕。然后調(diào)用thread->exit(true)方法吨岭，接下來把線程從active list卸下，刪除線程等等一系列工作執(zhí)行完成后峦树，則通知正在等待的DestroyJavaVM線程執(zhí)行卸載JVM操作辣辫。 |
| ContainerBackground Processor |
JBOSS |
它是一個(gè)守護(hù)線程,在jboss服務(wù)器在啟動(dòng)的時(shí)候就初始化了,主要工作是定期去檢查有沒有Session過期.過期則清除.參考：http://liudeh-009.iteye.com/blog/1584876
|
| ConfigClientNotifier |
ConfigServer |
ConfigServer服務(wù)端當(dāng)有配置變更時(shí)，就會(huì)將最新的配置推送到ConfigServer客戶端的一個(gè)數(shù)據(jù)列隊(duì)中魁巩，ConfigClientNotifier線程用于定期檢查該數(shù)據(jù)列隊(duì)中是否有數(shù)據(jù)急灭，如果有數(shù)據(jù)，則將數(shù)據(jù)分發(fā)到訂閱該數(shù)據(jù)的組件去做業(yè)務(wù)邏輯谷遂，比如：tair和hsf的數(shù)據(jù)都訂閱了ConfigServer數(shù)據(jù)源,當(dāng)ConfigClientNotifier線程發(fā)現(xiàn)數(shù)據(jù)有更新時(shí)化戳，就觸發(fā)做數(shù)據(jù)分發(fā)特定特定信號(hào)標(biāo)識(shí)將數(shù)據(jù)分發(fā)到相應(yīng)的訂閱者。 |
| ConfigClientWorker-Default |
ConfigServer |
包括主動(dòng)向服務(wù)器端發(fā)送數(shù)據(jù)（主要是訂閱和發(fā)布的數(shù)據(jù)）和接收服務(wù)器推送過來的數(shù)據(jù)（主要是訂閱數(shù)據(jù)的值） 埋凯。 |
| Dispatcher-Thread-3 |
Log4j |
Log4j具有異步打印日志的功能点楼，需要異步打印日志的Appender都需要注冊到AsyncAppender對(duì)象里面去，由AsyncAppender進(jìn)行監(jiān)聽白对，決定何時(shí)觸發(fā)日志打印操作掠廓。AsyncAppender如果監(jiān)聽到它管轄范圍內(nèi)的Appender有打印日志的操作，則給這個(gè)Appender生成一個(gè)相應(yīng)的event甩恼，并將該event保存在一個(gè)buffuer區(qū)域內(nèi)蟀瞧。 Dispatcher-Thread-3線程負(fù)責(zé)判斷這個(gè)event緩存區(qū)是否已經(jīng)滿了，如果已經(jīng)滿了条摸，則將緩存區(qū)內(nèi)的所有event分發(fā)到Appender容器里面去悦污，那些注冊上來的Appender收到自己的event后，則開始處理自己的日志打印工作钉蒲。Dispatcher-Thread-3線程是一個(gè)守護(hù)線程切端。 |
| Finalizer線程 |
JVM |
這個(gè)線程也是在main線程之后創(chuàng)建的，其優(yōu)先級(jí)為10顷啼，主要用于在垃圾收集前踏枣，調(diào)用對(duì)象的finalize()方法；關(guān)于Finalizer線程的幾點(diǎn)：1)只有當(dāng)開始一輪垃圾收集時(shí)钙蒙，才會(huì)開始調(diào)用finalize()方法茵瀑；因此并不是所有對(duì)象的finalize()方法都會(huì)被執(zhí)行；2)該線程也是daemon線程躬厌，因此如果虛擬機(jī)中沒有其他非daemon線程马昨，不管該線程有沒有執(zhí)行完finalize()方法，JVM也會(huì)退出；3) JVM在垃圾收集時(shí)會(huì)將失去引用的對(duì)象包裝成Finalizer對(duì)象（Reference的實(shí)現(xiàn)）鸿捧，并放入ReferenceQueue抢呆，由Finalizer線程來處理；最后將該Finalizer對(duì)象的引用置為null笛谦，由垃圾收集器來回收抱虐；4) JVM為什么要單獨(dú)用一個(gè)線程來執(zhí)行finalize()方法呢？如果JVM的垃圾收集線程自己來做饥脑，很有可能由于在finalize()方法中誤操作導(dǎo)致GC線程停止或不可控恳邀，這對(duì)GC線程來說是一種災(zāi)難； |
| Gang worker#0 |
JVM |
JVM用于做新生代垃圾回收（monir gc）的一個(gè)線程灶轰。#號(hào)后面是線程編號(hào)谣沸，例如：Gang worker#1 |
| GC Daemon |
JVM |
GC Daemon線程是JVM為RMI提供遠(yuǎn)程分布式GC使用的，GC Daemon線程里面會(huì)主動(dòng)調(diào)用System.gc()方法笋颤，對(duì)服務(wù)器進(jìn)行Full GC乳附。 其初衷是當(dāng)RMI服務(wù)器返回一個(gè)對(duì)象到其客戶機(jī)（遠(yuǎn)程方法的調(diào)用方）時(shí)，其跟蹤遠(yuǎn)程對(duì)象在客戶機(jī)中的使用伴澄。當(dāng)再?zèng)]有更多的對(duì)客戶機(jī)上遠(yuǎn)程對(duì)象的引用時(shí)赋除，或者如果引用的“租借”過期并且沒有更新，服務(wù)器將垃圾回收遠(yuǎn)程對(duì)象非凌。不過举农，我們現(xiàn)在jvm啟動(dòng)參數(shù)都加上了-XX:+DisableExplicitGC配置，所以敞嗡，這個(gè)線程只有打醬油的份了颁糟。 |
| IdleRemover |
JBOSS |
Jboss連接池有一個(gè)最小值，該線程每過一段時(shí)間都會(huì)被Jboss喚起喉悴，用于檢查和銷毀連接池中空閑和無效的連接棱貌，直到剩余的連接數(shù)小于等于它的最小值。 |
| Java2D Disposer |
JVM |
這個(gè)線程主要服務(wù)于awt的各個(gè)組件箕肃。說起該線程的主要工作職責(zé)前婚脱，需要先介紹一下Disposer類是干嘛的。Disposer提供一個(gè)addRecord方法突雪。如果你想在一個(gè)對(duì)象被銷毀前再做一些善后工作起惕，那么涡贱，你可以調(diào)用Disposer#addRecord方法咏删，將這個(gè)對(duì)象和一個(gè)自定義的DisposerRecord接口實(shí)現(xiàn)類，一起傳入進(jìn)去问词，進(jìn)行注冊督函。Disposer類會(huì)喚起“Java2D Disposer”線程，該線程會(huì)掃描已注冊的這些對(duì)象是否要被回收了，如果是辰狡，則調(diào)用該對(duì)象對(duì)應(yīng)的DisposerRecord實(shí)現(xiàn)類里面的dispose方法锋叨。Disposer實(shí)際上不限于在awt應(yīng)用場景，只是awt里面的很多組件需要訪問很多操作系統(tǒng)資源宛篇，所以娃磺，這些組件在被回收時(shí)，需要先釋放這些資源叫倍。 |
| FelixDispatchQueue |
Sofa |
該線程會(huì)在sofa啟動(dòng)時(shí)會(huì)喚起該線程,該線程用于分發(fā)OSGI事件到Declarative Services 中去發(fā)布偷卧，查找，綁定目標(biāo)服務(wù)吆倦。其實(shí)听诸，我們接口配置的service和reference就涉及到服務(wù)的發(fā)布、查找和綁定工作蚕泽。 Declarative Services 主要工作職責(zé)是方便地對(duì)服務(wù)之間的依賴關(guān)系和狀態(tài)進(jìn)行監(jiān)聽和管理晌梨。OSGI使用事件策略去調(diào)用Declarative Services中的服務(wù)。 |
| InsttoolCacheScheduler_QuartzSchedulerThread |
Quartz |
InsttoolCacheScheduler_QuartzSchedulerThread是Quartz的主線程须妻，它主要負(fù)責(zé)實(shí)時(shí)的獲取下一個(gè)時(shí)間點(diǎn)要觸發(fā)的觸發(fā)器仔蝌，然后執(zhí)行觸發(fā)器相關(guān)聯(lián)的作業(yè)。原理大致如下：Spring和Quartz結(jié)合使用的場景下荒吏，Spring IOC容器初始化時(shí)會(huì)創(chuàng)建并初始化Quartz線程池（TreadPool）掌逛，并啟動(dòng)它。剛啟動(dòng)時(shí)線程池中每個(gè)線程都處于等待狀態(tài)司倚，等待外界給他分配Runnable（持有作業(yè)對(duì)象的線程）豆混。繼而接著初始化并啟動(dòng)Quartz的主線程（InsttoolCacheScheduler_QuartzSchedulerThread），該線程自啟動(dòng)后就會(huì)處于等待狀態(tài)动知。等待外界給出工作信號(hào)之后皿伺，該主線程的run方法才實(shí)質(zhì)上開始工作。run中會(huì)獲取JobStore中下一次要觸發(fā)的作業(yè)盒粮，拿到之后會(huì)一直等待到該作業(yè)的真正觸發(fā)時(shí)間鸵鸥，然后將該作業(yè)包裝成一個(gè)JobRunShell對(duì)象（該對(duì)象實(shí)現(xiàn)了Runnable接口，其實(shí)看是上面TreadPool中等待外界分配給他的Runnable）丹皱，然后將剛創(chuàng)建的JobRunShell交給線程池妒穴，由線程池負(fù)責(zé)執(zhí)行作業(yè)。線程池收到Runnable后摊崭，從線程池一個(gè)線程啟動(dòng)Runnable讼油，反射調(diào)用JobRunShell中的run方法，run方法執(zhí)行完成之后呢簸，TreadPool將該線程回收至空閑線程中矮台。 |
| InsttoolCacheScheduler_Worker-2 |
Quartz |
InsttoolCacheScheduler_Worker-2線程就是ThreadPool線程的一個(gè)簡單實(shí)現(xiàn)乏屯，它主要負(fù)責(zé)分配線程資源去執(zhí)行InsttoolCacheScheduler_QuartzSchedulerThread線程交給它的調(diào)度任務(wù)（也就是JobRunShell）。 |
| java.util.concurrent.ThreadPoolExecutor$Worker |
JVM |
|
| JBossLifeThread |
Jboss |
Jboss主線程啟動(dòng)成功瘦赫，應(yīng)用程序部署完畢之后將JBossLifeThread線程實(shí)例化并且start辰晕，JBossLifeThread線程啟動(dòng)成功之后就處于等待狀態(tài)，以保持Jboss Java進(jìn)程處于存活中确虱。 所得比較通俗一點(diǎn)含友，就是Jboss啟動(dòng)流程執(zhí)行完畢之后，為什么沒有結(jié)束校辩？就是因?yàn)橛羞@個(gè)線程hold主了它唱较。牛b吧～～ |
| JBoss System Threads(1)-1 |
Jboss |
該線程是一個(gè)socket服務(wù)，默認(rèn)端口號(hào)為：1099召川。主要用于接收外部naming service（Jboss JNDI）請(qǐng)求南缓。 |
| JCA PoolFiller |
Jboss |
該線程主要為JBoss內(nèi)部提供連接池的托管。 簡單介紹一下工作原理 ：Jboss內(nèi)部凡是有遠(yuǎn)程連接需求的類荧呐，都需要實(shí)現(xiàn)ManagedConnectionFactory接口汉形，例如需要做JDBC連接的XAManagedConnectionFactory對(duì)象，就實(shí)現(xiàn)了該接口倍阐。然后將XAManagedConnectionFactory對(duì)象，還有其它信息一起包裝到InternalManagedConnectionPool對(duì)象里面峰搪，接著將InternalManagedConnectionPool交給PoolFiller對(duì)象里面的列隊(duì)進(jìn)行管理岔冀。 JCA PoolFiller線程會(huì)定期判斷列隊(duì)內(nèi)是否有需要?jiǎng)?chuàng)建和管理的InternalManagedConnectionPool對(duì)象概耻，如果有的話，則調(diào)用該對(duì)象的fillToMin方法鞠柄，觸發(fā)它去創(chuàng)建相應(yīng)的遠(yuǎn)程連接，并且將這個(gè)連接維護(hù)到它相應(yīng)的連接池里面去厌杜。 |
| JDWP Event Helper Thread |
JVM |
JDWP是通訊交互協(xié)議，它定義了調(diào)試器和被調(diào)試程序之間傳遞信息的格式夯尽。它詳細(xì)完整地定義了請(qǐng)求命令、回應(yīng)數(shù)據(jù)和錯(cuò)誤代碼匙握，保證了前端和后端的JVMTI和JDI的通信通暢。 該線程主要負(fù)責(zé)將JDI事件映射成JVMTI信號(hào)肺孤，以達(dá)到調(diào)試過程中操作JVM的目的罗晕。 |
| JDWP TransportListener: dt_socket |
JVM |
該線程是一個(gè)Java Debugger的監(jiān)聽器線程济欢，負(fù)責(zé)受理客戶端的debug請(qǐng)求赠堵。通常我們習(xí)慣將它的監(jiān)聽端口設(shè)置為8787。 |
| Low MemoryDetector |
JVM |
這個(gè)線程是負(fù)責(zé)對(duì)可使用內(nèi)存進(jìn)行檢測，如果發(fā)現(xiàn)可用內(nèi)存低艇挨，分配新的內(nèi)存空間耀里。 |
| process reaper |
JVM |
該線程負(fù)責(zé)去執(zhí)行一個(gè)OS命令行的操作。 |
| Reference Handler |
JVM |
JVM在創(chuàng)建main線程后就創(chuàng)建Reference Handler線程揍愁，其優(yōu)先級(jí)最高呐萨，為10，它主要用于處理引用對(duì)象本身（軟引用莽囤、弱引用谬擦、虛引用）的垃圾回收問題。 |
| SurrogateLockerThread(CMS) |
JVM |
這個(gè)線程主要用于配合CMS垃圾回收器使用朽缎，它是一個(gè)守護(hù)線程惨远，其主要負(fù)責(zé)處理GC過程中，Java層的Reference（指軟引用话肖、弱引用等等）與jvm內(nèi)部層面的對(duì)象狀態(tài)同步北秽。這里對(duì)它們的實(shí)現(xiàn)稍微做一下介紹：這里拿WeakHashMap做例子，將一些關(guān)鍵點(diǎn)先列出來（我們后面會(huì)將這些關(guān)鍵點(diǎn)全部串起來）1. 我們知道HashMap用Entry[]數(shù)組來存儲(chǔ)數(shù)據(jù)的最筒，WeakHashMap也不例外,內(nèi)部有一個(gè)Entry[]數(shù)組贺氓。2. WeakHashMap的Entry比較特殊，它的繼承體系結(jié)構(gòu)為Entry->WeakReference->Reference床蜘。3. Reference里面有一個(gè)全局鎖對(duì)象：Lock辙培，它也被稱為pending_lock. 注意：它是靜態(tài)對(duì)象。4. Reference 里面有一個(gè)靜態(tài)變量：pending邢锯。5. Reference 里面有一個(gè)靜態(tài)內(nèi)部類：ReferenceHandler的線程虏冻，它在static塊里面被初始化并且啟動(dòng)，啟動(dòng)完成后處于wait狀態(tài)弹囚，它在一個(gè)Lock同步鎖模塊中等待厨相。6. 另外，WeakHashMap里面還實(shí)例化了一個(gè)ReferenceQueue列隊(duì)鸥鹉，這個(gè)列隊(duì)的作用蛮穿，后面會(huì)提到。7. 上面關(guān)鍵點(diǎn)就介紹完畢了毁渗，下面我們把他們串起來。 假設(shè)灸异，WeakHashMap對(duì)象里面已經(jīng)保存了很多對(duì)象的引用羔飞。JVM在進(jìn)行CMS GC的時(shí)候檐春，會(huì)創(chuàng)建一個(gè)ConcurrentMarkSweepThread（簡稱CMST）線程去進(jìn)行GC，ConcurrentMarkSweepThread線程被創(chuàng)建的同時(shí)會(huì)創(chuàng)建一個(gè)SurrogateLockerThread（簡稱SLT）線程并且啟動(dòng)它卡儒，SLT啟動(dòng)之后俐巴，處于等待階段。CMST開始GC時(shí)擎鸠，會(huì)發(fā)一個(gè)消息給SLT讓它去獲取Java層Reference對(duì)象的全局鎖：Lock缘圈。直到CMS GC完畢之后，JVM會(huì)將WeakHashMap中所有被回收的對(duì)象所屬的WeakReference容器對(duì)象放入到Reference的pending屬性當(dāng)中（每次GC完畢之后赎线，pending屬性基本上都不會(huì)為null了）糊饱，然后通知SLT釋放并且notify全局鎖:Lock垂寥。此時(shí)激活了ReferenceHandler線程的run方法，使其脫離wait狀態(tài)另锋，開始工作了滞项。ReferenceHandler這個(gè)線程會(huì)將pending中的所有WeakReference對(duì)象都移動(dòng)到它們各自的列隊(duì)當(dāng)中，比如當(dāng)前這個(gè)WeakReference屬于某個(gè)WeakHashMap對(duì)象夭坪，那么它就會(huì)被放入相應(yīng)的ReferenceQueue列隊(duì)里面（該列隊(duì)是鏈表結(jié)構(gòu)）文判。當(dāng)我們下次從WeakHashMap對(duì)象里面get室梅、put數(shù)據(jù)或者調(diào)用size方法的時(shí)候亡鼠，WeakHashMap就會(huì)將ReferenceQueue列隊(duì)中的WeakReference依依poll出來去和Entry[]數(shù)據(jù)做比較，如果發(fā)現(xiàn)相同的仁热，則說明這個(gè)Entry所保存的對(duì)象已經(jīng)被GC掉了勾哩，那么將Entry[]內(nèi)的Entry對(duì)象剔除掉举哟。 |
| taskObjectTimerFactory |
JVM |
顧名思義妨猩，該線程就是用來執(zhí)行任務(wù)的诬乞。當(dāng)我們把一個(gè)任務(wù)交給Timer對(duì)象钠导，并且告訴它執(zhí)行時(shí)間牡属，周期時(shí)間后，Timer就會(huì)將該任務(wù)放入任務(wù)列隊(duì)悴势，并且通知taskObjectTimerFactory線程去處理任務(wù)措伐，taskObjectTimerFactory線程會(huì)將狀態(tài)為取消的任務(wù)從任務(wù)列隊(duì)中移除，如果任務(wù)是非重復(fù)執(zhí)行類型的捧存，則在執(zhí)行完該任務(wù)后昔穴，將它從任務(wù)列隊(duì)中移除，如果該任務(wù)是需要重復(fù)執(zhí)行的吗货，則計(jì)算出它下一次執(zhí)行的時(shí)間點(diǎn)宙搬。 |
| VM Periodic Task Thread |
JVM |
該線程是JVM周期性任務(wù)調(diào)度的線程勇垛，它由WatcherThread創(chuàng)建拓售，是一個(gè)單例對(duì)象。該線程在JVM內(nèi)使用得比較頻繁崭放，比如：定期的內(nèi)存監(jiān)控、JVM運(yùn)行狀況監(jiān)控建峭，還有我們經(jīng)常需要去執(zhí)行一些jstat這類命令查看gc的情況决摧，如下：jstat -gcutil 23483 250 7 這個(gè)命令告訴jvm在控制臺(tái)打印PID為：23483的gc情況，間隔250毫秒打印一次边锁，一共打印7次茅坛。 |
| VM Thread |
JVM |
這個(gè)線程就比較牛b了则拷，是jvm里面的線程母體煌茬，根據(jù)hotspot源碼（vmThread.hpp）里面的注釋，它是一個(gè)單例的對(duì)象（最原始的線程）會(huì)產(chǎn)生或觸發(fā)所有其他的線程坛善，這個(gè)單個(gè)的VM線程是會(huì)被其他線程所使用來做一些VM操作（如浑吟，清掃垃圾等）。在 VMThread的結(jié)構(gòu)體里有一個(gè)VMOperationQueue列隊(duì)省容，所有的VM線程操作(vm_operation)都會(huì)被保存到這個(gè)列隊(duì)當(dāng)中腥椒，VMThread本身就是一個(gè)線程候衍，它的線程負(fù)責(zé)執(zhí)行一個(gè)自輪詢的loop函數(shù)(具體可以參考：VMThread.cpp里面的void VMThread::loop())，該loop函數(shù)從VMOperationQueue列隊(duì)中按照優(yōu)先級(jí)取出當(dāng)前需要執(zhí)行的操作對(duì)象(VM_Operation)蛉鹿，并且調(diào)用VM_Operation->evaluate函數(shù)去執(zhí)行該操作類型本身的業(yè)務(wù)邏輯。ps：VM操作類型被定義在vm_operations.hpp文件內(nèi)领追，列舉幾個(gè)：ThreadStop响逢、ThreadDump、PrintThreads些膨、GenCollectFull订雾、GenCollectFullConcurrent职抡、CMS_Initial_Mark误甚、CMS_Final_Remark…..有興趣的同學(xué)窑邦，可以自己去查看源文件。 |
