匿名用戶

JVM老鳥

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() 函數。

以上。