Java垃圾回收線程的優先級

Question

我在採訪中被問過以下問題： 「垃圾回收線程的默認優先級是什麼？」 我知道我們不能強制GC或改變它的優先級，儘管我從來沒有聽說過它的默認優先級。有人知道嗎？

Answer 1

面試官可能找到的答案是GC處於低優先級的後臺進程。原因在於運行GC代價昂貴，但它不是（通常）關鍵流程，所以只能在系統有時間完成而不是中斷關鍵任務時完成。 （在實時系統中存在類似的想法 - 在後臺任務中執行不重要的進程，並在前臺執行所有關鍵進程 - 所有這些都將具有比後臺任務更高的優先級。）

這樣說，if你閱讀Sun關於垃圾收集的文獻，只是將GC作爲一個低優先級的線程並不是相當於的權利。實際上，GC可能不只是一個單一的線程。相反，當內存不足時，GC會運行（儘管確定內存何時低仍然可能在後臺線程中完成 - 也許有人可以澄清這一點）。

這裏有一些很好的鏈接，閱讀GC：

• http://www.javacoffeebreak.com/articles/thinkinginjava/abitaboutgarbagecollection.html
• Is it possible to change the priority of garbage Collector thread?

Answer 2

它是低優先級的線程（不知道確切的優先級）。這裏的要點是避免GC在可能的情況下減慢普通線程。我會說它低於正常優先級:)

Answer 3

也許這個問題是針對JVM的實際實現。正如你可以在在線參考中看到的那樣，有多種方式來實現垃圾回收器，並且它可能會隨着版本的不同而改變。這就是爲什麼每個人都告訴你不要依賴GC的行爲。它可能在另一個JVM上運行不同。

Answer 4

至少在Java RTS中，垃圾收集線程的優先級可以根據需要進行調整。優先級調整（以及一般的線程調度）對於多個CPU而言也與僅有一個CPU相當不同。

目前，我將假定一個多CPU配置，因爲這是（目前爲止）最常見的了。我也只談論默認調度程序 - 其他調度程序可以完全不同的方式做事。你的線程基本上分爲兩類：重要的和非重要的優先級（你也可以有「非堆實時」線程，比其中任何一個高，但由於他們不/不能使用堆，他們與GC沒什麼關係）。垃圾收集線程通常以低於其中任何一個的優先級運行，但可以將提升爲比非關鍵線程更高的優先級（如果需要）。雖然GC線程優先級總是低於關鍵實時線程的優先級。

我之所以對「關鍵」和「非關鍵」優先級之間的劃分有點模糊，原因在於：可以調整。您可以選擇線程的哪些優先級可以被GC搶佔，哪些不能。其意圖是關鍵線程難以獲得實時響應，非關鍵線程可獲得軟實時響應。由您決定/配置哪些線程屬於哪個類別。

Answer 5

我會說這個問題的正確答案是「如果你認爲你需要擔心垃圾收集器的線程優先級，那麼你可能做錯了什麼。

請記住，線程優先級並不一定與進程獲得多少CPU時間直接相關。它因系統而異，但在Windows上，線程優先級主要用於確定正在等待運行的線程調度到可用CPU的ORDER，以便高優先級線程可搶佔低優先級線程，假設兩個線程實際上都在競爭CPU。沒有真正的規則「給較低CPU優先級的CPU」。 （在Linux上，在線程優先級（好值）和分配的CPU時間之間存在一點點直接關係。）

在Windows中使用線程優先級，對於後臺線程像一個垃圾回收器，更合適的解決方案可能（也許是自相矛盾）將其設置爲高優先級，然後通過其他方式控制CPU使用的比例（實質上是故意適當調整時間比例或等待適當的信號） 。具體來說，高優先級適合於後臺線程，大多數情況下不需要做任何事情，但是當需要做某事時，需要儘快完成。

我實際上並沒有看到特定的垃圾收集算法使用哪些線程優先級（如果有的話）。但我的觀點是，這種情況有點複雜，並且根據線程優先級的垃圾收集器的行爲來做出任何假設似乎很奇怪。

那些對線程優先級更感興趣的人可能會喜歡看看我採用的一些measurements of the effect of thread priorities--不出所料，幾年前，現在這個材料可以做更新。

更新：巧合，talk by Cliff Click昨天發佈在YouTube上。在大約35分鐘的時間裏，他提到了這一點，即某些JIT和GC線程需要高度優先，以免它們餓死。