摘要:當一個實例被創(chuàng)建的時候,它最初被存放在堆內存空間的年輕代的區(qū)中。老年代或者永久代是堆內存的第二個邏輯部分。在垃圾回收過程中掃描屬于部分的堆內存。一旦實例從堆內存中刪除了,它們原來的位置將空出來給以后分配實例使用。
本文非原創(chuàng),翻譯自How Java Garbage Collection Works?
在Java中為對象分配和釋放內存空間都是由垃圾回收線程自動執(zhí)行完成的。和C語言不一樣的是Java程序員不需要手動寫垃圾回收相關的代碼。這是使得Java如此流行,同時也是Java能幫助程序員寫出更好的Java應用的優(yōu)點之一。
這是垃圾回收機制系列文章的第二篇。希望您已經讀過了第一部分Java垃圾回收簡介.
Java垃圾回收是一個自動運行的管理程序運行時使用的內存的進程。通過GC的自動執(zhí)行JVM將程序員從申請和釋放內存的繁重操作中解放出來。
Java垃圾回收GC初始化作為一個自動執(zhí)行的進程,程序員不需要在代碼中主動初始化GC。Java提供了System.gc()和Runtime.gc()這兩個hook來請求JVM調用GC進程。
盡管要求系統(tǒng)機制給程序員提供調用GC的機會,但是實際上這是由JVM負責決定的。JVM可以選擇拒絕啟動GC的請求,因此并不保證這些請求會真的調用垃圾回收。這是JVM基于內存堆空間的Eden區(qū)的使用情況做出的決定。JVM規(guī)范將這個選擇權利留給了各個JVM的具體實現(xiàn),因此實際上JVM是如何選擇的視不同JVM的實現(xiàn)而定(不過要記住的是,不能依賴于這兩個方法的調用,它們是不被保證執(zhí)行的)。
毫無疑問的是,我們知道垃圾回收進程是不能強制執(zhí)行的。不過我剛發(fā)現(xiàn)一個調用System.gc()確實有意義的場景。看下這篇文章你就會了解System.gc()調用是可用的這個特殊的場景。
Java 垃圾回收進程垃圾回收是一個回收不再使用的內存空間并將它變成能夠為將來的實例使用的過程。
Eden Space:當一個實例被創(chuàng)建的時候,它最初被存放在堆內存空間的年輕代的Eden區(qū)中。
注意:如果您不太理解這些術語,建議您先看下介紹內存模型、JVM架構及這些術語的詳細解釋的文章:garbage-collection-introduction-tutorial
Survivor Space(S0 和S1):作為minor回收周期的一部分,還活著的對象(還有引用指向它)被從eden區(qū)中移動到survivor空間S0。同樣的,垃圾回收器掃描S0并將活著的實例移動到S1。
無用的對象(沒有引用指向)被標記并回收。垃圾回收器(有四種可用的垃圾回收器,將在下一篇文章中介紹)決定這些被標記的實例是在掃描的過程中移出內存還是在另外獨立的遷移進程中執(zhí)行。
Old Generation:老年代或者永久代是堆內存的第二個邏輯部分。當垃圾回收器在做minor GC周期中,S1 survivor區(qū)中還活著的實例會被提升到老年代中。S1區(qū)中不再被引用的對象被標記并清除。
Major GC:在Java垃圾回收過程中實例生命周期的最后一個階段。Major GC在垃圾回收過程中掃描屬于Old Generation部分的堆內存。如果實例沒有被任何引用關聯(lián),它們將被標記、清除;如果它們還被引用關聯(lián)著,則將繼續(xù)存留在old generation。
垃圾回收過程中的對象銷毀–FinalizationMemory
Fragmentation:一旦實例從堆內存中刪除了,它們原來的位置將空出來給以后分配實例使用。顯然這些空閑空間很容易在內存空間中產生碎片。為了能夠更快地分配實例地址,需要對內存做去碎片化操作。根據(jù)不同垃圾回收器的策略,被回收的內存將在回收的過程同時或者在GC另外獨立的過程中壓縮整合。
就在移除一個對象并回收它的內存空間之前,Java垃圾回收器將會調用各個實例的finalize()方法,這樣實例對象就有機會可以釋放掉它占用的資源。盡管finalize()方法是保證在回收內存空間之前執(zhí)行的,但是對具體的執(zhí)行時間和執(zhí)行順序是沒有任何保證的。多個實例之間的finalize()執(zhí)行順序是不能提前預知的,甚至有可能它們是并行執(zhí)行的。程序不應該預先假設實例執(zhí)行finalize()的方法,也不應該使用finalize()方法來回收資源。
在finalize過程中拋出的任何異常都默認被忽略掉了,同時對象的銷毀過程被取消
JVM規(guī)范并沒有討論關于弱引用的垃圾回收,這是明確聲明的。具體的細節(jié)留給實現(xiàn)者決定。
垃圾回收是由守護進程執(zhí)行的
對象何時變成可被垃圾回收的?所有不能被活著的線程到達實例
不能被其他對象到達的循環(huán)引用對象 Java中有多種不同的引用類型。實例的可回收性取決于它的引用類型。
Reference | Garbage Collection |
---|---|
Strong Refrence | 不被垃圾回收 |
Soft Reference | 作為最后的選擇,有可能被回收 |
Weak Reference | 可以被垃圾回收 |
Phantom Reference | 可以被垃圾回收 |
在編譯過程中Java編譯器有個優(yōu)化機制,編譯器可以選擇將null賦值給一個實例,這樣就將這個實例標志為可被回收的。
class Animal { public static void main(String[] args) { Animal lion = new Animal(); System.out.println("Main is completed."); } protected void finalize() { System.out.println("Rest in Peace!"); } }
在上面這個類中,實例lion在除了初始化那一行在其他地方都沒有被使用到。因此作為一種優(yōu)化方法,Java編譯器可以在初始化那一行后面立即賦值lion = null。這樣finlizer可能會在Main方法的SOP之前打印結果。
Rest in Peace! Main is completed.
但結果的順序是不確定的,它取決于JVM的實現(xiàn)以及運行時的內存使用情況。從中我們能知道的一點是:編譯器在發(fā)現(xiàn)一個實例的之后的程序中不再被引用時可以選擇提前釋放實例內存。
這里有個實例何時變成可回收更好的例子。實例所有的屬性可以被存儲在寄存器中之后可以從寄存器中讀取這些屬性值,且未來在任何情況下都不會將值寫回到實例對象中。這樣盡管這個實例在未來還是被使用到了,但是實例對象依然可以被標記為可回收的。
何時能被垃圾回收可以簡單到僅僅認為在賦值為null的時候也可以復雜到如上面那一點所說的那樣。JVM的實現(xiàn)者會做一些取舍。其目標都是希望留下最少的痕跡,提高響應時間增大吞吐量。為了能夠達到這些目的,JVM實現(xiàn)者可以在垃圾回收中選擇更好的模式或算法來回收內存。
當finalize()被調用的時候,JVM釋放掉當前線程的所有同步塊。
Example Program for GC Scope
class GCScope { GCScope t; static int i = 1; public static void main(String args[]) { GCScope t1 = new GCScope(); GCScope t2 = new GCScope(); GCScope t3 = new GCScope(); //沒有任何一個對象是可以被GC的 t1.t = t2;//沒有任何一個對象是可以被GC的 t2.t = t3;//沒有任何一個對象是可以被GC的 t3.t = t1;//沒有任何一個對象是可以被GC的 t1 = null;//沒有任何一個對象是可以被GC的,t3.t還有對t1的引用 t2 = null;//沒有任何一個對象是可以被GC的,t3.t.t還有對t2的引用 t3 = null;//所有3個對象都可以被GC(沒有一個被引用了) //只有各個對象的變量t互相循環(huán)引用形成了一個孤立的引用環(huán),而沒有外部引用 } protected void finalize() { System.out.println("Garbage collected from boject" + i); i++; } }
Example Program for GC OutOfMemoryError
垃圾回收機制并不保證發(fā)生內存溢出時的安全,事實上內存溢出將會導致程序的崩潰,拋出OutOfMemoryError。
import java.util.LinkedList; import java.util.List; public class GC { public static void main(String[] args[]) { List l = new LinkedList(); //進入內部無限循環(huán)直接向鏈表中不斷添加元素 do { l.add(new String("Hello, World!"); } while (true); } }
Output
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space at java.util.LinkedList.linkLast(LinkedList.java:142) at java.util.LinkedList.add(LinkedList.java:338) at com.javapapers.java.GCScope.main(GCScope.java:12)
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉載請注明本文地址:http://m.specialneedsforspecialkids.com/yun/65042.html
摘要:垃圾回收監(jiān)控和分析工具是在安裝時免費提供的。監(jiān)控現(xiàn)在可以監(jiān)控垃圾回收過程了。至少我們可以知道程序中存在和對象內存分配和垃圾回收相關的問題。到此為止,關于垃圾回收的系列文章已經完結了。 本文非原創(chuàng),翻譯自Java Garbage Collection Monitoring and Analysis在Java中為對象分配和釋放內存空間都是由垃圾回收線程自動執(zhí)行完成的。和C語言不一樣的是Ja...
摘要:在架構中,堆內存和垃圾回收器這兩個部分和垃圾回收相關。堆內存在的內存模型中,最重要的是要了解堆內存的概念。在垃圾回收的過程中,這些對象將被從堆內存中清除,同時它們的空間也就被回收了。 本文非原創(chuàng),翻譯自Java Garbage Collection introduction在Java中為對象分配和釋放內存空間都是由垃圾回收線程自動執(zhí)行完成的。和C語言不一樣的是Java程序員不需要手動寫...
摘要:并發(fā)標記清除垃圾回收器,使用多個線程來掃描堆內存并標記可被清除的對象,然后清除標記的對象。垃圾回收器應用于大的堆內存空間。它將堆內存空間劃分為不同的區(qū)域,對各個區(qū)域并行地做回收工作。它會通過把重復的值移動到同一個數(shù)組來優(yōu)化堆內存占用。 本文非原創(chuàng),翻譯自Types of Java Garbage Collectors在Java中為對象分配和釋放內存空間都是由垃圾回收線程自動執(zhí)行完成的。...
摘要:執(zhí)行引擎作用執(zhí)行字節(jié)碼,或者執(zhí)行本地方法運行時數(shù)據(jù)區(qū)其實就是指在運行期間,其對內存空間的劃分和分配。 雖是讀書筆記,但是如轉載請注明出處https://uestc-dpz.github.io..拒絕伸手復制黨 JVM Java 虛擬機 Java 虛擬機(Java virtual machine,JVM)是運行 Java 程序必不可少的機制。JVM實現(xiàn)了Java語言最重要的特征:即平臺...
摘要:要加左右,因為位機器上的對象更大要加左右,因為位機器上的對象更大對于服務器程序的原則是保證越多內存越好將和設置成一樣大,關掉自動調整大小的機制。對于服務器程序的原則是決定你能夠給的最大內存,然后根據(jù)的大小來找到最好的設置。 Generations Young Generation 組成:eden + 2 survivor spaces Young generation的gc稱作min...
閱讀 989·2021-11-24 09:39
閱讀 2210·2021-11-16 11:54
閱讀 2092·2021-11-11 17:22
閱讀 2379·2021-09-30 09:55
閱讀 3607·2021-08-12 13:22
閱讀 1633·2019-08-30 15:44
閱讀 1179·2019-08-29 12:12
閱讀 3271·2019-08-27 10:58