來源 | 編程技術宇宙
責編| Carol
封圖 | CSDN 下載自視覺中國
本文用知乎體的風格簡單介紹了JVM中幾個內置線程的工作，希望對大家學習JVM有一點幫助。
匿名用戶
JVM老鳥
228 人贊同了該回答
利益相關，匿了！
JVM公司裡面線程眾多，派系林立，尤其是執行引擎那波人，因為是核心部門，經常diss別的部門。
FinalizerThread
JVM核心員工，GC部門高級工程師。
428 人贊同了該回答
不請自來。
其實在JVM工作沒有你們想像的那麼辛苦，其他部門不清楚，就拿我所在的垃圾回收部（這名字不好聽，叫GC部門吧）來說說。
我的工作是負責執行對象的finalize方法，你們也知道，現在的程式設計師，很少實現類的這個方法了，所以我的工作大部分時間都可以摸魚。
評論里有人問我對象的finalize方法是如何被執行的，這裡統一回復一下。
JVM的ClassLoader部門在加載一個class的時候，會檢查它是否有實現finalize方法，具體細節我不太清楚，請@AppClassLoader同學來幫忙解答一下。
如果發現有finalize方法，以後創建這個類的所有對象都會附帶創建一個Finalizer對象。
這個Finalizer有兩個關鍵點：
-
繼承自Reference類，本身也是一個引用，引用的正是跟它一起創建的那個對象
-
裡面有一個名叫queue的成員，指向了一個隊列：
ReferenceQueue，正是Finalizer的一個靜態成員變量。
除此之外，Finalizer裡面還有一個靜態線程FinalizerThread，這個其實就是我了。我的工作就是不斷上面的隊列裡面取出Finalizer對象，然後執行它引用對象的finalize方法。
什麼？你問我Finalizer對象是什麼時候進入這個隊列里的？這我就不知道了，超出了我的工作範圍，可以請@ReferenceHandler幫忙解答一下。
以上。
AppClassLoader
JVM核心員工，類加載部門工程師。
522 人贊同了該回答
謝邀！
JVM公司整體來說還是挺不錯的，各方麵條件都還不錯。辦公大廈有兩層，一樓是native層，一堆native層的線程員工在下面辦公。我在二樓的Java層，這一層都是Java線程。
我在JVM類加載部門工作，我的Leader是ExtClassLoader，他的Leader是公司高管BootstrapClassLoader。
我們部門的工作就是把磁碟上的.class文件加載到內存中，變成一個個可以使用的類。工作嘛還算輕鬆。不過有一點讓我不爽的是部門的雙親委派制度。
每次遇到新的類需要加載，按照規定都必須請示領導來加載，領導又去請示他的領導來加載。但是高管BootstrapClassLoader只負責加載Java的核心類，我的領導也只負責加載一些擴展類，所以大部分時間請示完了結果他們都加載不了，還得讓我去加載。
一來二去的花了不少時間在流程上，瞎耽誤工夫。我多次反應這個問題，能不能不請示我直接加載算了，不過每次都被駁回，說是為了安全考慮，他們必須過目。唉，領導不肯放權也是難辦！
------------分割線------------
評論區戾氣太重！說我不懂安全也是醉了。
回答一下 @FinalizerThread同學的問題。
確實如他所說，我們ClassLoader會去檢查類有沒有實現finalize方法，檢查結果會保存在Klass結構中的AccessFlags里。
這是一個很重要的欄位，記錄了類的很多屬性：
有了這些信息，創建對象的時候就可以檢查標記來決定是否創建Finalizer對象了。
以上。
ReferenceHandler
JVM核心員工，GC部門高級工程師。
145 人贊同了該回答
感謝 @FinalizerThread同學邀請。
人在JVM，剛下晚班。
時間緊迫，簡單說幾句。
和這位同學一樣，我也是GC部門的員工，公司待遇確實不錯，這方面還是很有競爭力的。
至於我的工作嘛，跟垃圾回收密切相關！
你們也知道在Java中，除了基礎的強引用外，還有四種特殊的引用：
-
FinalReference
-
軟引用（SoftReference）
-
弱引用（WeakReference）
-
虛引用（PhantomReference）
前面FinalizerThread同學提到的Finalizer其實就是FinalReference的子類。
我的工作就是在垃圾回收時，把這些個特殊引用一個個加入到它們各自對應的隊列裡面去。
拿上面FinalizerThread同學提到的Finalizer對象來說，就是我來把它加到它所指向的隊列中，再由FinalizerThread同學去從這個隊列裡面取出來處理的。
VMThread
JVM核心員工，後勤部主管。
898 人贊同了該回答
這個問題我來簡單回答一下。
看了前面幾位的回答，真的是旱的旱死，澇的澇死。我一天天忙得氣都喘不過來，你們居然還有時間摸魚！
我算是JVM公司里每天到的最早的幾個了，跟隨Threads::create_vm就起來了。
和樓上兩位一樣的是我也有一個工作隊列，叫_vm_thread，其類型是VMOperationQueue。
和樓上兩位不一樣的是他們工作在二樓Java層，而我工作在一樓native層。
工作節奏這個東西真的是不同部門差得很遠，我所在的部門就我一個人，是一個單例線程，我要乾的就是不斷從工作隊列裡面取出操作來執行。
這個隊列裡面裝的都是一個個封裝成VM_Operation的東西，這是它們的基類，具體來說，有幾十種操作，列舉一部分，你們隨意感受一下：
#define VM_OPS_DO(template) \
template(None) \
template(ThreadStop) \
template(ThreadDump) \
template(PrintThreads) \
template(FindDeadlocks) \
template(ClearICs) \
template(ForceSafepoint) \
template(ForceAsyncSafepoint) \
template(Deoptimize) \
template(DeoptimizeFrame) \
template(DeoptimizeAll) \
template(ZombieAll) \
template(Verify) \
template(PrintJNI) \
template(HeapDumper) \
template(DeoptimizeTheWorld) \
template(CollectForMetadataAllocation) \
template(GC_HeapInspection) \
template(GenCollectFull) \
template(GenCollectFullConcurrent) \
template(GenCollectForAllocation) \
template(ParallelGCFailedAllocation) \
template(ParallelGCSystemGC) \
······
其他就不說了，就拿你們最熟悉的垃圾回收來說，沒有了我，JVM的堆區內存恐怕早就垃圾堆成山了。
時間關係，先寫到這裡。
---------------分割線---------------
一覺醒來居然有這麼多贊，謝謝大家！
再補充幾句。
VM_Operation中還設置了一個模式，用來表示執行這個操作是否需要進入安全點，（比如垃圾回收就需要），是否需要加鎖執行。
enum Mode {
_safepoint, // blocking, safepoint
_no_safepoint, // blocking, no safepoint
_concurrent, // non-blocking, no safepoint
_async_safepoint // non-blocking, safepoint
};
安全點的進入和退出都是我來發起的，執行的是SafepointSynchronize的begin函數和end函數。
以上。