您好,登錄后才能下訂單哦!
本篇內容介紹了“Java內存分配與回收策略”的有關知識,在實際案例的操作過程中,不少人都會遇到這樣的困境,接下來就讓小編帶領大家學習一下如何處理這些情況吧!希望大家仔細閱讀,能夠學有所成!
Minor GC:發生在新生代上,因為新生代對象存活時間很短,因此 Minor GC 會頻繁執行, 執行的速度一般也會比較快。
Full GC:又稱Major GC,發生在老年代上,老年代對象其存活時間長, 因此 Full GC 很少執行,執行速度會比 Minor GC 慢很多。
大多數情況下,對象在新生代 Eden 區分配,當 Eden 區空間不夠時,發起 Minor GC。
大對象是指需要連續內存空間的對象,最典型的大對象是那種很長的字符串以及數組。
經常出現大對象會提前觸發垃圾收集以獲取足夠的連續空間分配給大對象。
-XX:PretenureSizeThreshold,大于此值的對象直接在老年代分配,避免在 Eden 區和 Survivor 區之間的大量內存復制。
為對象定義年齡計數器,對象在 Eden 出生并經過 Minor GC 依然存活, 將移動到 Survivor 中,年齡就增加 1 歲,增加到一定年齡則移動到老年代中。
-XX:MaxTenuringThreshold 用來定義年齡的閾值。
虛擬機并不是永遠地要求對象的年齡必須達到 MaxTenuringThreshold 才能晉升老年代, 如果在 Survivor 中相同年齡所有對象大小的總和大于 Survivor 空間的一半, 則年齡大于或等于該年齡的對象可以直接進入老年代,無需等到 MaxTenuringThreshold 中要求的年齡。
在發生 Minor GC 之前,虛擬機先檢查老年代最大可用的連續空間是否大于新生代所有對象總空間,如果條件成立的話,那么 Minor GC 可以確認是安全的。
如果不成立的話虛擬機會查看 HandlePromotionFailure 設置值是否允許擔保失敗,如果允許那么就會繼續檢查老年代最大可用的連續空間是否大于歷次晉升到老年代對象的平均大小,如果大于,將嘗試著進行一次 Minor GC;如果小于,或者 HandlePromotionFailure 設置不允許冒險,那么就要進行一次 Full GC。
對于 Minor GC,其觸發條件非常簡單,當 Eden 空間滿時,就將觸發一次 Minor GC。 而 Full GC 則相對復雜,有以下條件:
相應腦圖
只是建議虛擬機執行 Full GC,但是虛擬機不一定真正去執行。不建議使用這種方式,而是讓虛擬機管理內存。
老年代空間不足的常見場景為前文所講的大對象直接進入老年代、長期存活的對象進入老年代等。
為了避免以上原因引起的 Full GC,應當盡量不要創建過大的對象以及數組。 除此之外,可以通過 -Xmn 虛擬機參數調大新生代的大小,讓對象盡量在新生代被回收掉,不進入老年代。 還可以通過 -XX:MaxTenuringThreshold 調大對象進入老年代的年齡,讓對象在新生代多存活一段時間。
使用復制算法的 Minor GC 需要老年代的內存空間作擔保,如果擔保失敗會執行一次 Full GC。 具體內容請參考上面的第五小節。
在 JDK 1.7 及以前,HotSpot 虛擬機中的方法區是用永久代實現的, 永久代中存放的為一些 Class 的信息、常量、靜態變量等數據。
當系統中要加載的類、反射的類和調用的方法較多時,永久代可能會被占滿, 在未配置為采用 CMS GC 的情況下也會執行 Full GC。 如果經過 Full GC 仍然回收不了,那么虛擬機會拋出 java.lang.OutOfMemoryError。
為避免以上原因引起的 Full GC,可采用的方法為增大永久代空間或轉為使用 CMS GC。
執行 CMS GC 的過程中同時有對象要放入老年代,而此時老年代空間不足 (可能是 GC 過程中浮動垃圾過多導致暫時性的空間不足), 便會報 Concurrent Mode Failure 錯誤,并觸發 Full GC。
“Java內存分配與回收策略”的內容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站,小編將為大家輸出更多高質量的實用文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。