首先讓我們快速回顧一下我作為Java開發人員的職業生涯的早期。 我想消除正在進行的測試中的垃圾回收（GC）暫停。 瞧，當我發現無法完成時，我很生氣。 那時，我將問題拋在了“設計錯誤”上，并繼續前進。 對James Gosling或對該決定負責的人感到生氣。

幾天前，我遇到了一種使我想起過去的時代的情況。 幸運的是，過去的歲月在我體內積累了一些關于JVM內部的見解，我認為我會以博客文章的形式分享我的最新想法。

首先，你們中的某些人可能還記得我們在90年代后期使用的Java 1.1。 那時，您實際上就有可能關閉GC。 至少在Solaris（Sun提供的JVM版本）中，可以在您的JVM啟動參數中添加-noasyncgc選項。 在向后兼容JDK 1.4之前，仍然支持該選項，但是從JDK 1.2開始，它什么也沒做。 除了增加啟動腳本的復雜性。

該選項關閉了JVM控制的垃圾收集器。 您仍然可以通過從代碼中顯式調用System.gc()來收集未使用的對象。 聽起來像經驗豐富的工程師可以很好地利用靈活性。 那么–為什么要刪除此選項？

實際上，考慮以下因素后，此舉背后的動機就變得有意義了：

• 通過禁用GC，您實際上聲稱您知道應用程序在運行時需要多少內存。 但是，如果您錯了怎么辦？ 堆填滿后，禁用GC將導致應用程序終止。
• 調用System.gc()可能根本不執行垃圾回收。 在現代JVM中，僅是向JVM建議“我認為這是運行GC的好地方”。 并且–您的sysadmin可能通過指定-XX:+DisableExplicitGC啟動參數完全禁用了System.gc()調用。
• 如果System.gc()實際上是由JVM執行的，則將導致完整的垃圾回收。 對于大堆，這往往非常昂貴，并且會導致較長的暫停時間。
• 通過調用System.gc()仍然無法實現可預測的GC計時，尤其是在多線程應用程序中。

  現在，看一下以上幾點，并想象一個可以在沒有自動GC的JVM中運行的應用程序。 您可能不想將房子押在房子的行為上。 當我嘗試描繪調試會話以跟蹤該應用程序的任何性能問題時，我的后背上的頭發立即開始冒起。 所以也許先生。 戈斯林畢竟沒有犯過設計錯誤。

  但是，如果我停下來的停頓時間太長了，該怎么辦？ 我真的希望關閉GC嗎？ 實際上有一些可能性：

  • JVM分配了一部分內存，您可以在其中關閉GC。

  但是，我建議您僅在確定要做什么時才轉向這些解決方案。 在99.9％的情況下，垃圾收集器會比您更聰明。
  

  參考： 為什么我不能關閉垃圾收集器？ 由我們的JCG合作伙伴 Nikita Salnikov Tarnovski在Plumbr Blog博客上獲得。

翻譯自: https://www.javacodegeeks.com/2012/12/why-cant-i-turn-off-the-garbage-collector.html

總結

以上是生活随笔為你收集整理的为什么我不能关闭垃圾收集器？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。