java垃圾收集器
A. java中垃圾回收器讓工作線程停頓下來是怎麼做的
1、jvm中，在執行垃圾收集演算法時，Java應用程序的其他所有除了垃圾收集收集器線程之外的線程都被掛起。此時，系統只能允許GC線程進行運行，其他線程則會全部暫停，等待GC線程執行完畢後才能再次運行。這些工作都是由虛擬機在後台自動發起和自動完成的，是在用戶不可見的情況下把用戶正常工作的線程全部停下來，這對於很多的應用程序，尤其是那些對於實時性要求很高的程序來說是難以接受的。 但不是說GC必須STW（Stop-The-World，全局暫停）, 你也可以選擇降低運行速度但是可以並發執行的收集演算法，這取決於你的業務。
B. java中是怎樣進行垃圾回收的
前面是我自己理解的後面是復制的
java中垃圾回收以前聽老師講好像是內存滿了他才去做一次整體垃圾回收,在回收垃圾的同時會調用finalize方法.你在構造一個類時可以構造一個類時覆蓋他的finalize方法以便於該類在被垃圾回收時執行一些代碼,比如釋放資源.
1.JVM的gc概述
gc即垃圾收集機制是指jvm用於釋放那些不再使用的對象所佔用的內存。java語言並不要求jvm有gc，也沒有規定gc如何工作。不過常用的jvm都有gc，而且大多數gc都使用類似的演算法管理內存和執行收集操作。
在充分理解了垃圾收集演算法和執行過程後，才能有效的優化它的性能。有些垃圾收集專用於特殊的應用程序。比如，實時應用程序主要是為了避免垃圾收集中斷，而大多數OLTP應用程序則注重整體效率。理解了應用程序的工作負荷和jvm支持的垃圾收集演算法，便可以進行優化配置垃圾收集器。
垃圾收集的目的在於清除不再使用的對象。gc通過確定對象是否被活動對象引用來確定是否收集該對象。gc首先要判斷該對象是否是時候可以收集。兩種常用的方法是引用計數和對象引用遍歷。
1.1.引用計數
引用計數存儲對特定對象的所有引用數，也就是說，當應用程序創建引用以及引用超出范圍時，jvm必須適當增減引用數。當某對象的引用數為0時，便可以進行垃圾收集。
1.2.對象引用遍歷
早期的jvm使用引用計數，現在大多數jvm採用對象引用遍歷。對象引用遍歷從一組對象開始，沿著整個對象圖上的每條鏈接，遞歸確定可到達（reachable）的對象。如果某對象不能從這些根對象的一個（至少一個）到達，則將它作為垃圾收集。在對象遍歷階段，gc必須記住哪些對象可以到達，以便刪除不可到達的對象，這稱為標記（marking）對象。
下一步，gc要刪除不可到達的對象。刪除時，有些gc只是簡單的掃描堆棧，刪除未標記的未標記的對象，並釋放它們的內存以生成新的對象，這叫做清除（sweeping）。這種方法的問題在於內存會分成好多小段，而它們不足以用於新的對象，但是組合起來卻很大。因此，許多gc可以重新組織內存中的對象，並進行壓縮（compact），形成可利用的空間。
為此，gc需要停止其他的活動活動。這種方法意味著所有與應用程序相關的工作停止，只有gc運行。結果，在響應期間增減了許多混雜請求。另外，更復雜的 gc不斷增加或同時運行以減少或者清除應用程序的中斷。有的gc使用單線程完成這項工作，有的則採用多線程以增加效率。
2.幾種垃圾回收機制
2.1.標記－清除收集器
這種收集器首先遍歷對象圖並標記可到達的對象，然後掃描堆棧以尋找未標記對象並釋放它們的內存。這種收集器一般使用單線程工作並停止其他操作。
2.2.標記－壓縮收集器
有時也叫標記－清除－壓縮收集器，與標記－清除收集器有相同的標記階段。在第二階段，則把標記對象復制到堆棧的新域中以便壓縮堆棧。這種收集器也停止其他操作。
2.3.復制收集器
這種收集器將堆棧分為兩個域，常稱為半空間。每次僅使用一半的空間，jvm生成的新對象則放在另一半空間中。gc運行時，它把可到達對象復制到另一半空間，從而壓縮了堆棧。這種方法適用於短生存期的對象，持續復制長生存期的對象則導致效率降低。
2.4.增量收集器
增量收集器把堆棧分為多個域，每次僅從一個域收集垃圾。這會造成較小的應用程序中斷。
2.5.分代收集器
這種收集器把堆棧分為兩個或多個域，用以存放不同壽命的對象。jvm生成的新對象一般放在其中的某個域中。過一段時間，繼續存在的對象將獲得使用期並轉入更長壽命的域中。分代收集器對不同的域使用不同的演算法以優化性能。
2.6.並發收集器
並發收集器與應用程序同時運行。這些收集器在某點上（比如壓縮時）一般都不得不停止其他操作以完成特定的任務，但是因為其他應用程序可進行其他的後台操作，所以中斷其他處理的實際時間大大降低。
2.7.並行收集器
並行收集器使用某種傳統的演算法並使用多線程並行的執行它們的工作。在多cpu機器上使用多線程技術可以顯著的提高java應用程序的可擴展性。
3.Sun HotSpot
1.4.1 JVM堆大小的調整
Sun HotSpot 1.4.1使用分代收集器，它把堆分為三個主要的域：新域、舊域以及永久域。Jvm生成的所有新對象放在新域中。一旦對象經歷了一定數量的垃圾收集循環後，便獲得使用期並進入舊域。在永久域中jvm則存儲class和method對象。就配置而言，永久域是一個獨立域並且不認為是堆的一部分。
下面介紹如何控制這些域的大小。可使用-Xms和-Xmx 控制整個堆的原始大小或最大值。
下面的命令是把初始大小設置為128M：
java –Xms128m
–Xmx256m為控制新域的大小，可使用-XX:NewRatio設置新域在堆中所佔的比例。
下面的命令把整個堆設置成128m，新域比率設置成3，即新域與舊域比例為1：3，新域為堆的1/4或32M：
java –Xms128m –Xmx128m
–XX:NewRatio =3可使用-XX:NewSize和-XX:MaxNewsize設置新域的初始值和最大值。
下面的命令把新域的初始值和最大值設置成64m:
java –Xms256m –Xmx256m –Xmn64m
永久域默認大小為4m。運行程序時，jvm會調整永久域的大小以滿足需要。每次調整時，jvm會對堆進行一次完全的垃圾收集。
使用-XX:MaxPerSize標志來增加永久域搭大小。在WebLogic Server應用程序載入較多類時，經常需要增加永久域的最大值。當jvm載入類時，永久域中的對象急劇增加，從而使jvm不斷調整永久域大小。為了避免調整，可使用-XX:PerSize標志設置初始值。
下面把永久域初始值設置成32m，最大值設置成64m。
java -Xms512m -Xmx512m -Xmn128m -XX:PermSize=32m -XX:MaxPermSize=64m
默認狀態下，HotSpot在新域中使用復制收集器。該域一般分為三個部分。第一部分為Eden，用於生成新的對象。另兩部分稱為救助空間，當Eden 充滿時，收集器停止應用程序，把所有可到達對象復制到當前的from救助空間，一旦當前的from救助空間充滿，收集器則把可到達對象復制到當前的to救助空間。From和to救助空間互換角色。維持活動的對象將在救助空間不斷復制，直到它們獲得使用期並轉入舊域。使用-XX:SurvivorRatio 可控制新域子空間的大小。
同NewRation一樣，SurvivorRation規定某救助域與Eden空間的比值。比如，以下命令把新域設置成64m，Eden佔32m，每個救助域各佔16m：
java -Xms256m -Xmx256m -Xmn64m -XX:SurvivorRation =2
如前所述，默認狀態下HotSpot對新域使用復制收集器，對舊域使用標記－清除－壓縮收集器。在新域中使用復制收集器有很多意義，因為應用程序生成的大部分對象是短壽命的。理想狀態下，所有過渡對象在移出Eden空間時將被收集。如果能夠這樣的話，並且移出Eden空間的對象是長壽命的，那麼理論上可以立即把它們移進舊域，避免在救助空間反復復制。但是，應用程序不能適合這種理想狀態，因為它們有一小部分中長壽命的對象。最好是保持這些中長壽命的對象並放在新域中，因為復制小部分的對象總比壓縮舊域廉價。為控制新域中對象的復制，可用-XX:TargetSurvivorRatio控制救助空間的比例（該值是設置救助空間的使用比例。如救助空間位1M，該值50表示可用500K）。該值是一個百分比，默認值是50。當較大的堆棧使用較低的 sruvivorratio時，應增加該值到80至90，以更好利用救助空間。用-XX:maxtenuring threshold可控制上限。
為放置所有的復制全部發生以及希望對象從eden擴展到舊域，可以把MaxTenuring Threshold設置成0。設置完成後，實際上就不再使用救助空間了，因此應把SurvivorRatio設成最大值以最大化Eden空間，設置如下：
java … -XX:MaxTenuringThreshold=0 –XX:SurvivorRatio＝50000 …
4.BEA JRockit JVM的使用
Bea WebLogic 8.1使用的新的JVM用於Intel平台。在Bea安裝完畢的目錄下可以看到有一個類似於jrockit81sp1_141_03的文件夾。這就是 Bea新JVM所在目錄。不同於HotSpot把Java位元組碼編譯成本地碼，它預先編譯成類。JRockit還提供了更細致的功能用以觀察JVM的運行狀態，主要是獨立的GUI控制台（只能適用於使用Jrockit才能使用jrockit81sp1_141_03自帶的console監控一些cpu及 memory參數）或者WebLogic Server控制台。
Bea JRockit JVM支持4種垃圾收集器：
4.1.1.分代復制收集器
它與默認的分代收集器工作策略類似。對象在新域中分配，即JRockit文檔中的nursery。這種收集器最適合單cpu機上小型堆操作。
4.1.2.單空間並發收集器
該收集器使用完整堆，並與背景線程共同工作。盡管這種收集器可以消除中斷，但是收集器需花費較長的時間尋找死對象，而且處理應用程序時收集器經常運行。如果處理器不能應付應用程序產生的垃圾，它會中斷應用程序並關閉收集。
分代並發收集器這種收集器在護理域使用排它復制收集器，在舊域中則使用並發收集器。由於它比單空間共同發生收集器中斷頻繁，因此它需要較少的內存，應用程序的運行效率也較高，注意，過小的護理域可以導致大量的臨時對象被擴展到舊域中。這會造成收集器超負荷運作，甚至採用排它性工作方式完成收集。
4.1.3.並行收集器
該收集器也停止其他進程的工作，但使用多線程以加速收集進程。盡管它比其他的收集器易於引起長時間的中斷，但一般能更好的利用內存，程序效率也較高。
默認狀態下，JRockit使用分代並發收集器。要改變收集器，可使用-Xgc:，對應四個收集器分別為 gen，singlecon，gencon以及parallel。可使用-Xms和-Xmx設置堆的初始大小和最大值。要設置護理域，則使用- Xns:java –jrockit –Xms512m –Xmx512m –Xgc:gencon –Xns128m…盡管JRockit支持-verbose:gc開關，但它輸出的信息會因收集器的不同而異。JRockit還支持memory、 load和codegen的輸出。
注意 ：如果 使用JRockit JVM的話還可以使用WLS自帶的console（C:\bea\jrockit81sp1_141_03\bin下）來監控一些數據，如cpu， memery等。要想能構監控必須在啟動服務時startWeblogic.cmd中加入－Xmanagement參數。
5.如何從JVM中獲取信息來進行調整
-verbose.gc開關可顯示gc的操作內容。打開它，可以顯示最忙和最空閑收集行為發生的時間、收集前後的內存大小、收集需要的時間等。打開- xx:+ printgcdetails開關，可以詳細了解gc中的變化。打開-XX: + PrintGCTimeStamps開關，可以了解這些垃圾收集發生的時間，自jvm啟動以後以秒計量。最後，通過-xx: + PrintHeapAtGC開關了解堆的更詳細的信息。為了了解新域的情況，可以通過-XX:=PrintTenuringDistribution開關了解獲得使用期的對象權。
6.Pdm系統JVM調整
6.1.伺服器：前提內存1G 單CPU
可通過如下參數進行調整：－server 啟用伺服器模式（如果CPU多，伺服器機建議使用此項）
－Xms,－Xmx一般設為同樣大小。 800m
－Xmn 是將NewSize與MaxNewSize設為一致。320m
－XX:PerSize 64m
－XX:NewSize 320m 此值設大可調大新對象區，減少Full GC次數
－XX:MaxNewSize 320m
－XX:NewRato NewSize設了可不設。
－XX: SurvivorRatio
－XX:userParNewGC 可用來設置並行收集
－XX:ParallelGCThreads 可用來增加並行度
－XXUseParallelGC 設置後可以使用並行清除收集器
－XX：UseAdaptiveSizePolicy 與上面一個聯合使用效果更好，利用它可以自動優化新域大小以及救助空間比值
6.2.客戶機：通過在JNLP文件中設置參數來調整客戶端JVM
JNLP中參數：initial-heap-size和max-heap-size
這可以在framework的RequestManager中生成JNLP文件時加入上述參數，但是這些值是要求根據客戶機的硬體狀態變化的（如客戶機的內存大小等）。建議這兩個參數值設為客戶機可用內存的60％（有待測試）。為了在動態生成JNLP時以上兩個參數值能夠隨客戶機不同而不同，可靠慮獲得客戶機系統信息並將這些嵌到首頁index.jsp中作為連接請求的參數。
在設置了上述參數後可以通過Visualgc 來觀察垃圾回收的一些參數狀態，再做相應的調整來改善性能。一般的標準是減少fullgc的次數，最好硬體支持使用並行垃圾回收（要求多CPU）。
C. java中的垃圾回收是什麼意思
垃圾回收就是gc（gabage collection）。
java比c++的優點就是多了垃圾回收機制，程序員不用去關心垃圾的回收，系統會自動調用去回收內存。
一般我們想回收的時候只需要調用system.gc方法就可以了。系統會自己去調用destroy方法和其他的回收方法釋放內存，節省內存空間。
D. java 垃圾回收是什麼
Java堆的管理—垃圾回收提到一下幾點，很不錯，或許可以作為寫程序時候的准則：
（1）不要試圖去假定垃圾收集發生的時間，這一切都是未知的。比如，方法中的一個臨時對象在方法調用完畢後就變成了無用對象，這個時候它的內存就可以被釋放。
（2）Java中提供了一些和垃圾收集打交道的類，而且提供了一種強行執行垃圾收集的方法--調用System.gc()，但這同樣是個不確定的方法。Java 中並不保證每次調用該方法就一定能夠啟動垃圾收集，它只不過會向JVM發出這樣一個申請，到底是否真正執行垃圾收集，一切都是個未知數。
（3）挑選適合自己的垃圾收集器。一般來說，如果系統沒有特殊和苛刻的性能要求，可以採用JVM的預設選項。否則可以考慮使用有針對性的垃圾收集器，比如增量收集器就比較適合實時性要求較高的系統之中。系統具有較高的配置，有比較多的閑置資源，可以考慮使用並行標記/清除收集器。
（4）關鍵的也是難把握的問題是內存泄漏。良好的編程習慣和嚴謹的編程態度永遠是最重要的，不要讓自己的一個小錯誤導致內存出現大漏洞。
（5）盡早釋放無用對象的引用。大多數程序員在使用臨時變數的時候，都是讓引用變數在退出活動域(scope)後，自動設置為null，暗示垃圾收集器來收集該對象，還必須注意該引用的對象是否被監聽，如果有，則要去掉監聽器，然後再賦空值。
就是說,對於頻繁申請內存和釋放內存的操作,還是自己控制一下比較好,但是System.gc()的方法不一定適用，最好使用finallize強制執行或者寫自己的finallize方法。
E. java語言中垃圾回收機制的優點，並考慮2種回收機制。求幫忙。
java語言中一個顯著的特點就是引入了垃圾回收機制，使C++程序員最頭痛的內存管理問題迎刃而解，他使得java程序員在編寫承學的哦時候不用再考慮內潤管理問題了，由於有了垃圾回收機制，java中的對象不再有「作用域」的概念，只是在對象引用的時候才有「作用域」，垃圾回收可以有效的防止內存泄漏，有效的使用可以使用的內存。
垃圾回收器通常作為一個單獨的低級別的線程運行，不可預知的情況下對內存堆中已經死亡的或者長時間沒有使用的對象進行清楚的哦回收，承諾過許願程序員不能實時的調用來幾回收器對某個對象或所有對象進行垃圾回收，回收機制有分帶復制來幾回收和標記垃圾回收，增量垃圾回收。
希望能幫到你，謝謝！
F. Java垃圾回收怎麼理解
Java的堆是一個運行時數據區，類的實例(對象)從中分配空間。Java虛擬機(JVM)的堆中儲存著正在運行的應用程序所建立的所有對象，這些對象通過new、newarray、anewarray和multianewarray等指令建立，但是它們不需要程序代碼來顯式地釋放。一般來說，堆的是由垃圾回收來負責的，盡管JVM規范並不要求特殊的垃圾回收技術，甚至根本就不需要垃圾回收，但是由於內存的有限性，JVM在實現的時候都有一個由垃圾回收所管理的堆。垃圾回收是一種動態存儲管理技術，它自動地釋放不再被程序引用的對象，按照特定的垃圾收集演算法來實現資源自動回收的功能。
垃圾收集的意義
在C++中，對象所佔的內存在程序結束運行之前一直被佔用，在明確釋放之前不能分配給其它對象；而在Java中，當沒有對象引用指向原先分配給某個對象的內存時，該內存便成為垃圾。JVM的一個系統級線程會自動釋放該內存塊。垃圾收集意味著程序不再需要的對象是"無用信息"，這些信息將被丟棄。當一個對象不再被引用的時候，內存回收它佔領的空間，以便空間被後來的新對象使用。事實上，除了釋放沒用的對象，垃圾收集也可以清除內存記錄碎片。由於創建對象和垃圾收集器釋放丟棄對象所佔的內存空間，內存會出現碎片。碎片是分配給對象的內存塊之間的空閑內存洞。碎片整理將所佔用的堆內存移到堆的一端，JVM將整理出的內存分配給新的對象。
垃圾收集能自動釋放內存空間，減輕編程的負擔。這使Java 虛擬機具有一些優點。首先，它能使編程效率提高。在沒有垃圾收集機制的時候，可能要花許多時間來解決一個難懂的存儲器問題。在用Java語言編程的時候，靠垃圾收集機制可大大縮短時間。其次是它保護程序的完整性， 垃圾收集是Java語言安全性策略的一個重要部份。
垃圾收集的一個潛在的缺點是它的開銷影響程序性能。Java虛擬機必須追蹤運行程序中有用的對象， 而且最終釋放沒用的對象。這一個過程需要花費處理器的時間。其次垃圾收集演算法的不完備性，早先採用的某些垃圾收集演算法就不能保證100%收集到所有的廢棄內存。當然隨著垃圾收集演算法的不斷改進以及軟硬體運行效率的不斷提升，這些問題都可以迎刃而解。
垃圾收集的演算法分析
Java語言規范沒有明確地說明JVM使用哪種垃圾回收演算法，但是任何一種垃圾收集演算法一般要做2件基本的事情：（1）發現無用信息對象；（2）回收被無用對象佔用的內存空間，使該空間可被程序再次使用。
大多數垃圾回收演算法使用了根集(root set)這個概念；所謂根集就量正在執行的Java程序可以訪問的引用變數的集合(包括局部變數、參數、類變數)，程序可以使用引用變數訪問對象的屬性和調用對象的方法。垃圾收集首選需要確定從根開始哪些是可達的和哪些是不可達的，從根集可達的對象都是活動對象，它們不能作為垃圾被回收，這也包括從根集間接可達的對象。而根集通過任意路徑不可達的對象符合垃圾收集的條件，應該被回收。下面介紹幾個常用的演算法。
1、 引用計數法(Reference Counting Collector)
引用計數法是唯一沒有使用根集的垃圾回收的法，該演算法使用引用計數器來區分存活對象和不再使用的對象。一般來說，堆中的每個對象對應一個引用計數器。當每一次創建一個對象並賦給一個變數時，引用計數器置為1。當對象被賦給任意變數時，引用計數器每次加1當對象出了作用域後(該對象丟棄不再使用)，引用計數器減1，一旦引用計數器為0，對象就滿足了垃圾收集的條件。
基於引用計數器的垃圾收集器運行較快，不會長時間中斷程序執行，適宜地必須 實時運行的程序。但引用計數器增加了程序執行的開銷，因為每次對象賦給新的變數，計數器加1，而每次現有對象出了作用域生，計數器減1。
2、tracing演算法(Tracing Collector)
tracing演算法是為了解決引用計數法的問題而提出，它使用了根集的概念。基於tracing演算法的垃圾收集器從根集開始掃描，識別出哪些對象可達，哪些對象不可達，並用某種方式標記可達對象，例如對每個可達對象設置一個或多個位。在掃描識別過程中，基於tracing演算法的垃圾收集也稱為標記和清除(mark-and-sweep)垃圾收集器.
3、compacting演算法(Compacting Collector)
為了解決堆碎片問題，基於tracing的垃圾回收吸收了Compacting演算法的思想，在清除的過程中，演算法將所有的對象移到堆的一端，堆的另一端就變成了一個相鄰的空閑內存區，收集器會對它移動的所有對象的所有引用進行更新，使得這些引用在新的位置能識別原來 的對象。在基於Compacting演算法的收集器的實現中，一般增加句柄和句柄表。
4、ing演算法(Coping Collector)
該演算法的提出是為了克服句柄的開銷和解決堆碎片的垃圾回收。它開始時把堆分成 一個對象 面和多個空閑面， 程序從對象面為對象分配空間，當對象滿了，基於coping演算法的垃圾 收集就從根集中掃描活動對象，並將每個 活動對象復制到空閑面(使得活動對象所佔的內存之間沒有空閑洞)，這樣空閑面變成了對象面，原來的對象面變成了空閑面，程序會在新的對象面中分配內存。
一種典型的基於coping演算法的垃圾回收是stop-and-演算法，它將堆分成對象面和空閑區域面，在對象面與空閑區域面的切換過程中，程序暫停執行。
5、generation演算法(Generational Collector)
stop-and-垃圾收集器的一個缺陷是收集器必須復制所有的活動對象，這增加了程序等待時間，這是coping演算法低效的原因。在程序設計中有這樣的規律：多數對象存在的時間比較短，少數的存在時間比較長。因此，generation演算法將堆分成兩個或多個，每個子堆作為對象的一代(generation)。由於多數對象存在的時間比較短，隨著程序丟棄不使用的對象，垃圾收集器將從最年輕的子堆中收集這些對象。在分代式的垃圾收集器運行後，上次運行存活下來的對象移到下一最高代的子堆中，由於老一代的子堆不會經常被回收，因而節省了時間。
6、adaptive演算法(Adaptive Collector)
在特定的情況下，一些垃圾收集演算法會優於其它演算法。基於Adaptive演算法的垃圾收集器就是監控當前堆的使用情況，並將選擇適當演算法的垃圾收集器。
透視Java垃圾回收
1、命令行參數透視垃圾收集器的運行
2、使用System.gc()可以不管JVM使用的是哪一種垃圾回收的演算法，都可以請求Java的垃圾回收。
在命令行中有一個參數-verbosegc可以查看Java使用的堆內存的情況，它的格式如下：
Java代碼 java -verbosegc classfile java -verbosegc classfile
可以看個例子：
Java代碼 class TestGC { public static void main(String[] args) </SPAN></li> { new TestGC(); </SPAN></li> System.gc(); System.runFinalization(); } } class TestGC { public static void main(String[] args) { new TestGC(); System.gc(); System.runFinalization(); } }
在這個例子中，一個新的對象被創建，由於它沒有使用，所以該對象迅速地變為可達，程序編譯後，執行命令： java -verbosegc TestGC 後結果為：
Java代碼 [Full GC 168K->97K(1984K)， 0.0253873 secs] [Full GC 168K->97K(1984K)， 0.0253873 secs]
機器的環境為，Windows 2000 + JDK1.3.1，箭頭前後的數據168K和97K分別表示垃圾收集GC前後所有存活對象使用的內存容量，說明有168K-97K=71K的對象容量被回收，括弧內的數據1984K為堆內存的總容量，收集所需要的時間是0.0253873秒（這個時間在每次執行的時候會有所不同）。
2、finalize方法透視垃圾收集器的運行
在JVM垃圾收集器收集一個對象之前 ，一般要求程序調用適當的方法釋放資源，但在沒有明確釋放資源的情況下，Java提供了預設機制來終止化該對象心釋放資源，這個方法就是finalize（）。它的原型為：
Java代碼 protected void finalize() throws Throwable protected void finalize() throws Throwable
在finalize()方法返回之後，對象消失，垃圾收集開始執行。原型中的throws Throwable表示它可以拋出任何類型的異常。
之所以要使用finalize()，是由於有時需要採取與Java的普通方法不同的一種方法，通過分配內存來做一些具有C風格的事情。這主要可以通過"固有方法"來進行，它是從Java里調用非Java方法的一種方式。C和C++是目前唯一獲得固有方法支持的語言。但由於它們能調用通過其他語言編寫的子程序，所以能夠有效地調用任何東西。在非Java代碼內部，也許能調用C的malloc()系列函數，用它分配存儲空間。而且除非調用了free()，否則存儲空間不會得到釋放，從而造成內存"漏洞"的出現。當然，free()是一個C和C++函數，所以我們需要在finalize()內部的一個固有方法中調用它。也就是說我們不能過多地使用finalize()，它並不是進行普通清除工作的理想場所。
在普通的清除工作中，為清除一個對象，那個對象的用戶必須在希望進行清除的地點調用一個清除方法。這與C++"破壞器"的概念稍有抵觸。在C++中，所有對象都會破壞（清除）。或者換句話說，所有對象都"應該"破壞。若將C++對象創建成一個本地對象，比如在堆棧中創建（在Java中是不可能的），那麼清除或破壞工作就會在"結束花括弧"所代表的、創建這個對象的作用域的末尾進行。若對象是用new創建的（類似於Java），那麼當程序員調用C++的delete命令時（Java沒有這個命令），就會調用相應的破壞器。若程序員忘記了，那麼永遠不會調用破壞器，我們最終得到的將是一個內存"漏洞"，另外還包括對象的其他部分永遠不會得到清除。
相反，Java不允許我們創建本地（局部）對象--無論如何都要使用new。但在Java中，沒有"delete"命令來釋放對象，因為垃圾收集器會幫助我們自動釋放存儲空間。所以如果站在比較簡化的立場，我們可以說正是由於存在垃圾收集機制，所以Java沒有破壞器。然而，隨著以後學習的深入，就會知道垃圾收集器的存在並不能完全消除對破壞器的需要，或者說不能消除對破壞器代表的那種機制的需要（而且絕對不能直接調用finalize()，所以應盡量避免用它）。若希望執行除釋放存儲空間之外的其他某種形式的清除工作，仍然必須調用Java中的一個方法。它等價於C++的破壞器，只是沒後者方便。
關於垃圾收集的幾點補充
經過上述的說明，可以發現垃圾回收有以下的幾個特點：
（1）垃圾收集發生的不可預知性：由於實現了不同的垃圾收集演算法和採用了不同的收集機制，所以它有可能是定時發生，有可能是當出現系統空閑CPU資源時發生，也有可能是和原始的垃圾收集一樣，等到內存消耗出現極限時發生，這與垃圾收集器的選擇和具體的設置都有關系。
（2）垃圾收集的精確性：主要包括2 個方面：（a）垃圾收集器能夠精確標記活著的對象；（b）垃圾收集器能夠精確地定位對象之間的引用關系。前者是完全地回收所有廢棄對象的前提，否則就可能造成內存泄漏。而後者則是實現歸並和復制等演算法的必要條件。所有不可達對象都能夠可靠地得到回收，所有對象都能夠重新分配，允許對象的復制和對象內存的縮並，這樣就有效地防止內存的支離破碎。
（3）現在有許多種不同的垃圾收集器，每種有其演算法且其表現各異，既有當垃圾收集開始時就停止應用程序的運行，又有當垃圾收集開始時也允許應用程序的線程運行，還有在同一時間垃圾收集多線程運行。
（4）垃圾收集的實現和具體的JVM 以及JVM的內存模型有非常緊密的關系。不同的JVM 可能採用不同的垃圾收集，而JVM 的內存模型決定著該JVM可以採用哪些類型垃圾收集。現在，HotSpot 系列JVM中的內存系統都採用先進的面向對象的框架設計，這使得該系列JVM都可以採用最先進的垃圾收集。
（5）隨著技術的發展，現代垃圾收集技術提供許多可選的垃圾收集器，而且在配置每種收集器的時候又可以設置不同的參數，這就使得根據不同的應用環境獲得最優的應用性能成為可能。
針對以上特點，我們在使用的時候要注意：
（1）不要試圖去假定垃圾收集發生的時間，這一切都是未知的。比如，方法中的一個臨時對象在方法調用完畢後就變成了無用對象，這個時候它的內存就可以被釋放。
（2）Java中提供了一些和垃圾收集打交道的類，而且提供了一種強行執行垃圾收集的方法--調用System.gc()，但這同樣是個不確定的方法。Java 中並不保證每次調用該方法就一定能夠啟動垃圾收集，它只不過會向JVM發出這樣一個申請，到底是否真正執行垃圾收集，一切都是個未知數。
（3）挑選適合自己的垃圾收集器。一般來說，如果系統沒有特殊和苛刻的性能要求，可以採用JVM的預設選項。否則可以考慮使用有針對性的垃圾收集器，比如增量收集器就比較適合實時性要求較高的系統之中。系統具有較高的配置，有比較多的閑置資源，可以考慮使用並行標記/清除收集器。
（4）關鍵的也是難把握的問題是內存泄漏。良好的編程習慣和嚴謹的編程態度永遠是最重要的，不要讓自己的一個小錯誤導致內存出現大漏洞。
（5）盡早釋放無用對象的引用。大多數程序員在使用臨時變數的時候，都是讓引用變數在退出活動域(scope)後，自動設置為null，暗示垃圾收集器來收集該對象，還必須注意該引用的對象是否被監聽，如果有，則要去掉監聽器，然後再賦空值。
結束語
一般來說，Java開發人員可以不重視JVM中堆內存的分配和垃圾處理收集，但是，充分理解Java的這一特性可以讓我們更有效地利用資源。同時要注意finalize()方法是Java的預設機制，有時為確保對象資源的明確釋放，可以編寫自己的finalize方法
G. java有哪些垃圾回收演算法
常用的垃圾回收演算法有：
(1).引用計數演算法：
給對象中添加一個引用計數器，每當有一個地方引用它時，計數器值就加1；當引用失效時，計數器值就減1；任何時刻計數器都為0的對象就是不再被使用的，垃圾收集器將回收該對象使用的內存。
引用計數演算法實現簡單，效率很高，微軟的COM技術、ActionScript、Python等都使用了引用計數演算法進行內存管理，但是引用計數演算法對於對象之間相互循環引用問題難以解決，因此java並沒有使用引用計數演算法。
(2).根搜索演算法：
通過一系列的名為「GC Root」的對象作為起點，從這些節點向下搜索，搜索所走過的路徑稱為引用鏈(Reference Chain)，當一個對象到GC Root沒有任何引用鏈相連時，則該對象不可達，該對象是不可使用的，垃圾收集器將回收其所佔的內存。
主流的商用程序語言C#、java和Lisp都使用根搜素演算法進行內存管理。
在java語言中，可作為GC Root的對象包括以下幾種對象：
a. java虛擬機棧(棧幀中的本地變數表)中的引用的對象。
b.方法區中的類靜態屬性引用的對象。
c.方法區中的常量引用的對象。
d.本地方法棧中JNI本地方法的引用對象。
java方法區在Sun HotSpot虛擬機中被稱為永久代，很多人認為該部分的內存是不用回收的，java虛擬機規范也沒有對該部分內存的垃圾收集做規定，但是方法區中的廢棄常量和無用的類還是需要回收以保證永久代不會發生內存溢出。
判斷廢棄常量的方法：如果常量池中的某個常量沒有被任何引用所引用，則該常量是廢棄常量。
判斷無用的類：
(1).該類的所有實例都已經被回收，即java堆中不存在該類的實例對象。
(2).載入該類的類載入器已經被回收。
(3).該類所對應的java.lang.Class對象沒有任何地方被引用，無法在任何地方通過反射機制訪問該類的方法。
Java中常用的垃圾收集演算法：
(1).標記-清除演算法：
最基礎的垃圾收集演算法，演算法分為「標記」和「清除」兩個階段：首先標記出所有需要回收的對象，在標記完成之後統一回收掉所有被標記的對象。
標記-清除演算法的缺點有兩個：首先，效率問題，標記和清除效率都不高。其次，標記清除之後會產生大量的不連續的內存碎片，空間碎片太多會導致當程序需要為較大對象分配內存時無法找到足夠的連續內存而不得不提前觸發另一次垃圾收集動作。
(2).復制演算法：
將可用內存按容量分成大小相等的兩塊，每次只使用其中一塊，當這塊內存使用完了，就將還存活的對象復制到另一塊內存上去，然後把使用過的內存空間一次清理掉。這樣使得每次都是對其中一塊內存進行回收，內存分配時不用考慮內存碎片等復雜情況，只需要移動堆頂指針，按順序分配內存即可，實現簡單，運行高效。
復制演算法的缺點顯而易見，可使用的內存降為原來一半。
(3).標記-整理演算法：
標記-整理演算法在標記-清除演算法基礎上做了改進，標記階段是相同的標記出所有需要回收的對象，在標記完成之後不是直接對可回收對象進行清理，而是讓所有存活的對象都向一端移動，在移動過程中清理掉可回收的對象，這個過程叫做整理。
標記-整理演算法相比標記-清除演算法的優點是內存被整理以後不會產生大量不連續內存碎片問題。
復制演算法在對象存活率高的情況下就要執行較多的復制操作，效率將會變低，而在對象存活率高的情況下使用標記-整理演算法效率會大大提高。
(4).分代收集演算法：
根據內存中對象的存活周期不同，將內存劃分為幾塊，java的虛擬機中一般把內存劃分為新生代和年老代，當新創建對象時一般在新生代中分配內存空間，當新生代垃圾收集器回收幾次之後仍然存活的對象會被移動到年老代內存中，當大對象在新生代中無法找到足夠的連續內存時也直接在年老代中創建。
H. java中final，finally和finalize的區別
1. final
在java中，final可以用來修飾類，方法和變數（成員變數或局部變數）。下面將對其詳細介紹。
1.1 修飾類
當用final修飾類的時，表明該類不能被其他類所繼承。當我們需要讓一個類永遠不被繼承，此時就可以用final修飾，但要注意：
final類中所有的成員方法都會隱式的定義為final方法。
1.2 修飾方法
使用final方法的原因主要有兩個：
(1) 把方法鎖定，以防止繼承類對其進行更改。
(2) 效率，在早期的java版本中，會將final方法轉為內嵌調用。但若方法過於龐大，可能在性能上不會有多大提升。因此在最近版本中，不需要final方法進行這些優化了。
final方法意味著「最後的、最終的」含義，即此方法不能被重寫。
注意：若父類中final方法的訪問許可權為private，將導致子類中不能直接繼承該方法，因此，此時可以在子類中定義相同方法名的函數，此時不會與重寫final的矛盾，而是在子類中重新地定義了新方法。
1.3 修飾變數
final成員變數表示常量，只能被賦值一次，賦值後其值不再改變。類似於C++中的const。
當final修飾一個基本數據類型時，表示該基本數據類型的值一旦在初始化後便不能發生變化；如果final修飾一個引用類型時，則在對其初始化之後便不能再讓其指向其他對象了，但該引用所指向的對象的內容是可以發生變化的。本質上是一回事，因為引用的值是一個地址，final要求值，即地址的值不發生變化。
final修飾一個成員變數（屬性），必須要顯示初始化。這里有兩種初始化方式，一種是在變數聲明的時候初始化；第二種方法是在聲明變數的時候不賦初值，但是要在這個變數所在的類的所有的構造函數中對這個變數賦初值。
當函數的參數類型聲明為final時，說明該參數是只讀型的。即你可以讀取使用該參數，但是無法改變該參數的值。
2. finally
finally作為異常處理的一部分，它只能用在try/catch語句中，並且附帶一個語句塊，表示這段語句最終一定會被執行（不管有沒有拋出異常），經常被用在需要釋放資源的情況下。（×）（這句話其實存在一定的問題）
很多人都認為finally語句塊一定會執行，但真的是這樣么？答案是否定的，例如下面這個例子：
只有與finally對應的try語句塊得到執行的情況下，finally語句塊才會執行。以上兩種情況在執行try語句塊之前已經返回或拋出異常，所以try對應的finally語句並沒有執行。
3. finalize
finalize()是在java.lang.Object里定義的，也就是說每一個對象都有這么個方法。這個方法在gc啟動，該對象被回收的時候被調用。其實gc可以回收大部分的對象（凡是new出來的對象，gc都能搞定，一般情況下我們又不會用new以外的方式去創建對象），所以一般是不需要程序員去實現finalize的。
特殊情況下，需要程序員實現finalize，當對象被回收的時候釋放一些資源，比如：一個socket鏈接，在對象初始化時創建，整個生命周期內有效，那麼就需要實現finalize，關閉這個鏈接。
使用finalize還需要注意一個事，調用super.finalize();
一個對象的finalize()方法只會被調用一次，而且finalize()被調用不意味著gc會立即回收該對象，所以有可能調用finalize()後，該對象又不需要被回收了，然後到了真正要被回收的時候，因為前面調用過一次，所以不會調用finalize()，產生問題。 所以，推薦不要使用finalize()方法，它跟析構函數不一樣。
I. java 中垃圾收集機制的原理是
JVM在程序運行期會有一個專門的垃圾回收線程,這個線程會判斷程序中的對象是否沒有任何引用或超出作用域,如果有這種情況,就會釋放這個對象,垃圾回收的線程只有在內存有空閑的時候才會執行,因為優先順序很低什麼的
J. Java垃圾回收：GC在什麼時候對什麼做了什麼
GC在什麼時候對什麼做了什麼？
要回答這個問題，先了解下GC的發展史、jvm運行時數據區的劃分、jvm內存分配策略、jvm垃圾收集演算法等知識。
先說下jvm運行時數據的劃分，粗暴的分可以分為堆區(Heap)和棧區(Stack)，但jvm的分法實際上比這復雜得多，大概分為下面幾塊：
1、程序計數器(Program Conuter Register)
程序計數器是一塊較小的內存空間，它是當前線程執行位元組碼的行號指示器，位元組碼解釋工作器就是通過改變這個計數器的值來選取下一條需要執行的指令。它是線程私有的內存，也是唯一一個沒有OOM異常的區域。
2、Java虛擬機棧區(Java Virtual Machine Stacks)
也就是通常所說的棧區，它描述的是Java方法執行的內存模型，每個方法被執行的時候都創建一個棧幀(Stack Frame)，用於存儲局部變數表、操作數棧、動態鏈接、方法出口等。每個方法被調用到完成，相當於一個棧幀在虛擬機棧中從入棧到出棧的過程。此區域也是線程私有的內存，可能拋出兩種異常：如果線程請求的棧深度大於虛擬機允許的深度將拋出StackOverflowError；如果虛擬機棧可以動態的擴展，擴展到無法動態的申請到足夠的內存時會拋出OOM異常。
3、本地方法棧(Native Method Stacks)
本地方法棧與虛擬機棧發揮的作用非常相似，區別就是虛擬機棧為虛擬機執行Java方法，本地方法棧則是為虛擬機使用到的Native方法服務。
4、堆區(Heap)
所有對象實例和數組都在堆區上分配，堆區是GC主要管理的區域。堆區還可以細分為新生代、老年代，新生代還分為一個Eden區和兩個Survivor區。此塊內存為所有線程共享區域，當堆中沒有足夠內存完成實例分配時會拋出OOM異常。
5、方法區(Method Area)
方法區也是所有線程共享區，用於存儲已被虛擬機載入的類信息、常量、靜態變數、即時編譯後的代碼等數據。GC在這個區域很少出現，這個區域內存回收的目標主要是對常量池的回收和類型的卸載，回收的內存比較少，所以也有稱這個區域為永久代(Permanent Generation)的。當方法區無法滿足內存分配時拋出OOM異常。
6、運行時常量池(Runtime Constant Pool)
運行時常量池是方法區的一部分，用於存放編譯期生成的各種字面量和符號引用。
垃圾收集(Garbage Collection)並不是Java獨有的，最早是出現在Lisp語言中，它做的事就是自動管理內存，也就是下面三個問題：
1、什麼時候回收
2、哪些內存需要回收
3、如何回收
1、什麼時候回收？
上面說到GC經常發生的區域是堆區，堆區還可以細分為新生代、老年代，新生代還分為一個Eden區和兩個Survivor區。
1.1 對象優先在Eden中分配，當Eden中沒有足夠空間時，虛擬機將發生一次Minor GC，因為Java大多數對象都是朝生夕滅，所以Minor GC非常頻繁，而且速度也很快；
1.2 Full GC，發生在老年代的GC，當老年代沒有足夠的空間時即發生Full GC，發生Full GC一般都會有一次Minor GC。大對象直接進入老年代，如很長的字元串數組，虛擬機提供一個-XX:PretenureSizeThreadhold參數，令大於這個參數值的對象直接在老年代中分配，避免在Eden區和兩個Survivor區發生大量的內存拷貝；
1.3 發生Minor GC時，虛擬機會檢測之前每次晉升到老年代的平均大小是否大於老年代的剩餘空間大小，如果大於，則進行一次Full GC，如果小於，則查看HandlePromotionFailure設置是否允許擔保失敗，如果允許，那隻會進行一次Minor GC，如果不允許，則改為進行一次Full GC。
2、哪些內存需要回收
jvm對不可用的對象進行回收，哪些對象是可用的，哪些是不可用的？Java並不是採用引用計數演算法來判定對象是否可用，而是採用根搜索演算法(GC Root Tracing)，當一個對象到GC Roots沒有任何引用相連接，用圖論的來說就是從GC Roots到這個對象不可達，則證明此對象是不可用的，說明此對象可以被GC。對於這些不可達對象，也不是一下子就被GC，而是至少要經歷兩次標記過程：如果對象在進行根搜索演算法後發現沒有與GC Roots相連接的引用鏈，那它將會第一次標記並且進行一次篩選，篩選條件是此對象有沒有必要執行finalize()方法，當對象沒有覆蓋finalize()方法或者finalize()方法已經被虛擬機調用執行過一次，這兩種情況都被視為沒有必要執行finalize()方法，對於沒有必要執行finalize()方法的將會被GC，對於有必要有必要執行的，對象在finalize()方法中可能會自救，也就是重新與引用鏈上的任何一個對象建立關聯即可。
3、如何回收
選擇不同的垃圾收集器，所使用的收集演算法也不同。
在新生代中，每次垃圾收集都發現有大批對象死去，只有少量存活，則使用復制演算法，新生代內存被分為一個較大的Eden區和兩個較小的Survivor區，每次只使用Eden區和一個Survivor區，當回收時將Eden區和Survivor還存活著的對象一次性的拷貝到另一個Survivor區上，最後清理掉Eden區和剛才使用過的Survivor區，Eden和Survivor的默認比例是8：1，可以使用-XX:SurvivorRatio來設置該比例。
而老年代中對象存活率高，沒有額外的空間對它進行分配擔保，必須使用「標記-清理」或「標記-整理」演算法。