java 对象被回收的例子_Java对象的后事处理——垃圾回收（二）
1 先談Finalize()
finalize()能做的所有工作，使用try-finally或者其他方式都可以做得更好、更及時，所以筆者建議大家完全可以忘掉Java語言中有這個方法的存在。
——《深入理解JVM》
finalize()方法確實可以實現一次對象的自救，但是其不確定性和昂貴的運行代價都表明這個方法的使用需要十分的慎重。那么finalize()在什么時期起作用又是如何實現對象的自救的呢？首先我們要理解虛擬機在掃描到死亡對象的時候并不是直接回收的，而是進行一次標記并且篩選，篩選的條件就是其對象的finalize方法是否有必要執行。如果當前對象沒有重寫finalize方法或者已經調用過一次finalize方法，那么則視為沒有必要執行，此時便失去自救的機會，放入"即將回收"集合中。
否則的話，則將對象放入一個叫F-Queue的隊列中，稍后虛擬機將一個個的執行隊列中對象的finalize方法(就是在此處對象可以在finalize方法中將自身關聯到引用鏈，從而暫時逃脫被回收的命運)，需要注意的是虛擬機保證執行但不保證執行完finalize方法，原因是如果finalize方法執行時間過長或者陷入死循環，則可能讓系統奔潰。全部執行之后，虛擬機將對隊列的對象重新標記一次，如果還不在引用鏈中則GG，否則將其移出"即將回收"集合。下面例子參考《深入理解JVM》實現自救并且驗證只能自救一次的過程。
public classTestForGc {/**定義一個根節點的靜態變量*/
public staticTestForGc INSTANCE;/*** 重寫finalize方法，讓其被標記為有必要執行并且加入F-Q
*
*@throwsThrowable*/@Overrideprotected void finalize() throwsThrowable {super.finalize();
System.err.println("finalize method in TestForGc Class invoked!");//將自身關聯到根節點中，實現自救
INSTANCE = this;
}public static void main(String[] args) throwsInterruptedException {
INSTANCE= newTestForGc();
INSTANCE= null;
System.gc();//睡眠1S，保證F-Q中的方法執行完畢
TimeUnit.SECONDS.sleep(1);if(Objects.nonNull(INSTANCE)) {
System.out.println("i successfully save myself by finalize method!");
}else{
System.out.println("i am dead :(");
}/** 下面驗證finalize方法只能調用一次
* 幾乎完全一樣的代碼，卻是不同的結局*/INSTANCE= null;
System.gc();//睡眠1S
TimeUnit.SECONDS.sleep(1);if(Objects.nonNull(INSTANCE)) {
System.out.println("i successfully save myself by finalize method again!");
}else{
System.out.println("couldn't invoke finalize again, i am dead :(");
}
}
}
執行結果：
2 垃圾回收器
如果說回收算法是接口，那么垃圾回收器就是這些接口的實現類，共有7種回收器，接下來一一羅列。
2.1 Serial垃圾回收器
Serial是一種單線程垃圾回收器，在工作的時候的時候會暫停所有的用戶線程，也就是"stop-the-world"，雖然單線程代表了用戶線程的停頓，但是也意味著其不用進行線程的交互從而有更高的收集 效率。Serial采用復制算法，是Client端新生代的默認垃圾回收器。其工作圖類似于：
2.2 ParNew垃圾回收器。
ParNew是Serial回收器的多線程版本，是Server端新生代的默認回收器，除了并行多線程之外，其他包括實現都是一模一樣，當然也是采用復制算法。還有一點重要的是，新生代的收集器除了Serial之外，只有ParNew能跟年老代的CMS合作，其在低CPU的情況下效率比Serial低，但是在多個CPU的情況下要好的多。其工作圖：
2.3 Parallel Scavenge垃圾回收器
跟ParNew類似，作用于新生代，并行多線程并且也是采用復制算法。但是其關注的點卻不同，其著重的是一種叫做"吞吐量"的東西。所謂的"吞吐量"=運行用戶代碼的時間 / (運行用戶代碼的時間 + GC時間)，也就是說其更加注重用戶代碼運行時間而不是減少GC停頓時間。相對于其他收集器來說，可以更加高效的利用CPU，更加適合作為在后臺運算而不大需要交互的任務。Parallel收集器提供了兩個比較重要的參數。
-XX:MaxGCPauseMillis：表示收集器將盡可能的在這個參數設定的毫秒數內完成回收工作。但這并不代表其設置的越低越好，縮減回收時間是通過減少吞吐量換來的，如果設置得太低可能導致頻繁的GC。
-XX:GCTimeRatio：表示代碼運行時間和垃圾回收時間的比率，比如說設置為19，那么則垃圾回收時間占比為 1 / (1+19) = 5%，默認是99。
2.4 Serial Old垃圾回收器
Serial的年老代版本，同Serial基本相似，不同的是采用的是標記-整理算法實現，作為Client端默認的年老代收集器。如果在Server端的話，那么其主要作用有二：
1、跟新生代的Parallel Scavenge收集器配合。
2、做一個有價值的"備胎"：當CMS垃圾回收器因為預留空間問題放不下對象而發生Concurrent Mode Fail時，作為其備選方案執行垃圾回收。
2.5 Parallel Old垃圾回收器
Parallel Scavenge的年老代版本，多線程并行，同樣注重吞吐量，使用標記-整理算法。這個收集器可以跟新生代的Parallel Svavenge一起搭配使用，在注重吞吐量和CPU資源敏感的場合中是一對很好的組合。
2.6 CMS垃圾回收器
來了，它來了！CMS垃圾回收器被當做是具有劃時代意義的、真正實現并發的垃圾回收器，總而言之=》
,--^----------,--------,-----,-------^--,
| ||||||||| `--------' | O
`+---------------------------^----------|
`\_,-------, _______________________強__|
/ XXXXXX /`| /
/ XXXXXX / `\ /
/ XXXXXX /\______(
/ XXXXXX /
/ XXXXXX /
(________(
`------'
CMS是一款并發的垃圾回收器，但并不代表全程都不需要停頓，只是大部分時間是跟用戶線程一起執行的。其整個GC過程中總共有4個階段。
1、初始標記：簡單的標記所有的根節點，需要暫停所有的用戶線程，即"stop-the-world"，耗時較短。關于GCRooots的過程可以看下另一篇文章——垃圾回收(一)。
2、并發標記：跟用戶線程一起工作，尋找堆中的死亡對象，整個過程耗時最長。
3、重新標記：再次掃描，主要對象是并發標記過程中又新增的對象，也就是驗漏。多線程，需要STW，時間相對并發標記來說短。
4、并發清除：GC線程跟用戶線程一起執行，清除標記的死亡對象，"浮動垃圾"在此階段產生。
然而，優秀如CMS也會有不足之處，總共四個階段的標記及清除算法的實現必定為其帶來一些使用的麻煩。
缺點：
1、占用一定CPU資源：其有兩個階段需要并發跟用戶線程一起執行，也就是說要跟用戶線程搶占CPU的時間片，會占用一定的CPU資源，如果CPU資源不太優質的情況下，可能會造成不小的影響。
2、空間利用率不能達到最大：由于并發清除時用戶線程也在運行，那么在GC結束前必定會產生一些額外的垃圾，那么就必須給這些垃圾預留一定的空間，否則會導致內存不足從而報"Concurrent Mode Failure"，此時虛擬機便啟用后備方案——使用Serial Old來進行垃圾回收，進而浪費更多的時間。
3、內存碎片導致提前FullGC：CMS采用的是標記-清除算法，也就是說會產生內存碎片，那么可能出現大對象放不下的情況，進而不得不提前進行一次FullGC。為了解決這個問題，虛擬機提供了兩個參數-XX:+UseCMSCompactAtFullCollection和-XX:CMSFullGCsBeforeCompaction，分別表示CMS頂不住要進行FullGC的時候進行內存的整理(整理的過程中無法并發，停頓時間不得不變長) 和進行多少次不壓縮的FullGC之后來一次整理的GC(默認0次，表示每次都進行內存整理)。
2.7 G1垃圾回收器
G1是一個新秀垃圾回收器，被賦予了很大的使命——取代CMS。G1作為新時代的垃圾回收器，相對于其他垃圾回收器來說有許多優勢。
1、并行和并發：G1可以利用現在的硬件優勢，縮短GC時stop-the-world的停頓時間，并且GC的時候同時也能讓用戶線程執行。
2、分代收集：跟其他垃圾回收器不同，G1沒有物理上的年老代和新生代，其將內存分成了多個獨立的Region，每個Region都可能表示屬于新生代還是年老代，所以不需要一堆Region湊放在一起然后將這塊區域稱作新生代，它們之間并不需要連續，所以只有概念上的分代，也是這種分代方式使得G1可以獨立管理這個堆空間，不需要跟其他回收器合作。
3、空間整合：G1的算法從Region層面看屬于復制算法(從一個Region復制到另一個)，但是從整體看又是標記-整理法。然而不管是哪種，都表示G1不會產生內存碎片，不會因為空間不連續放不下大對象而出現FullGC的情況。
G1回收器將內存空間分成若干個Region，并且這些Region之前相互獨立。但是我們都知道這并不能真正的獨立，因為一個Region中的對象不一定只會被當前Region的其他對象引用，而可能被堆中的其他對象引用，那G1是如何實現避免全堆掃描的呢？這個問題在分代的其他回收器中也有，但是在這里突顯得更加明顯而已。再G1中，對象本身都會有一個Remembered Set，這個Set存放著當前對象被其他區域對象引用的信息，這樣子，在掃描引用的時候加上這個Set就可以避免全堆掃描了。
具體實現大致為：虛擬機在發現程序正在進行對Reference類型的寫操作時，會暫時中斷寫操作，然后檢查Reference引用的對象是否處于不同的區域(如果是分代，則只對年老代的對象進行檢查，檢查是否引用的對象在新生代)，如果是的話則將引用信息記錄在被引用的Remembered Set中，這樣在GC的時候加上Remembered Set的掃描就可以避免全堆掃描了。
跟CMS類型，G1也有四個階段(不算Remembered Set的掃描)，雖然相似但是還是有些區別的。
1、初始標記：標記可達的根節點，STW，單線程，時間短。
2、并發標記：跟用戶線程同時執行，并發執行時對象可能會產生引用變化，其會將這些變化記錄在Remembered Set Logs中，待下個階段整合。
3、最終標記：驗漏，將并發標記階段的引用變化記錄Remembered Set Logs整合到Remembered Set中。
4、篩選回收：對各個Region中的回收價值進行排序，然后執行回收計劃。暫停用戶線程，并行執行。
3 小結
本文首先介紹了“對象自救”的方法——finalize，并且用一個小例子演示了對象如何實現自救。接著介紹了7種不同的垃圾回收器，新生代中有單線程的Serial可以作為Client端新生代的默認回收器，有多線程版本的Serial——ParNew，還有著重點不同(吞吐量)的Parallel Scavenge；年老代方面有單線程的Serial Old、跨時代意義的并發回收器——CMS，雖然優秀但不可避免的有三個缺點、還有吞吐量年老代版本——Parallel Old收集器，最后還簡單介紹了G1收集器的幾個過程還有獨立的Region間是如何實現避免堆掃描的。
整體下來整篇行文還有些粗糙，日后會慢慢的圓潤，如果有關于這方面好的文章可以在下面評論區分享學習一下，下方為各個垃圾回收器的搭配圖。
It helps me a lot if you could share your opinion with us.
總結
以上是生活随笔為你收集整理的java 对象被回收的例子_Java对象的后事处理——垃圾回收（二）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 求一个女生爱情微信网名
- 下一篇： java实现fread_fread函数读