⑴ java的垃圾回收機制是什麼 請詳細解釋
Java的垃圾回收機制是Java虛擬機提供的能力，用於在空閑時間以不定時的方式動態回收無任何引用的對象占據的內存空間。
⑵ java的垃圾回收機制是什麼
1、回收的內容是new出來的對象所佔內存；
2、垃圾回收只與內存有關，清理內存外的資源依靠finalize()方法。垃圾回收機制在回收某個對象的內存前會調用該對象的finalize()方法。
3、強制系統垃圾回收的方式（通過程序通知系統進行垃圾回收，但系統還不一定進行垃圾回收）：
System.gc();
Runtime.getRuntime().gc();
5、對象在內存中的狀態有可達狀態、可恢復狀態、不可達狀態，當處於可恢復狀態時可能會進行垃圾回收。
⑶ 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）。
⑷ java中垃圾回收有哪幾種機制
強引用
在一般的Java程序中，見到最多的就是強引用（strong reference）。如Date date = new Date()，date就是一個對象的強引用。對象的強引用可以在程序中到處傳遞。很多情況下，會同時有多個引用指向同一個對象。強引用的存在限制了對象在內存中的存活時間。假如對象A中包含了一個對象B的強引用，那麼一般情況下，對象B的存活時間就不會短於對象A。如果對象A沒有顯式的把對象B的引用設為null的話，就只有當對象A被垃圾回收之後，對象B才不再有引用指向它，才可能獲得被垃圾回收的機會。
除了強引用之外，java.lang.ref包中提供了對一個對象的不同的引用方式。JVM的垃圾回收器對於不同類型的引用有不同的處理方式。
軟引用
軟引用（soft reference）在強度上弱於強引用，通過類SoftReference來表示。它的作用是告訴垃圾回收器，程序中的哪些對象是不那麼重要，當內存不足的時候是可以被暫時回收的。當JVM中的內存不足的時候，垃圾回收器會釋放那些只被軟引用所指向的對象。如果全部釋放完這些對象之後，內存還不足，才會拋出OutOfMemory錯誤。軟引用非常適合於創建緩存。當系統內存不足的時候，緩存中的內容是可以被釋放的。比如考慮一個圖像編輯器的程序。該程序會把圖像文件的全部內容都讀取到內存中，以方便進行處理。而用戶也可以同時打開多個文件。當同時打開的文件過多的時候，就可能造成內存不足。如果使用軟引用來指向圖像文件內容的話，垃圾回收器就可以在必要的時候回收掉這些內存。
publicclass ImageData {
private String path;
private SoftReference<byte[]> dataRef;
public ImageData(String path) {
this.path = path;
dataRef = new SoftReference<byte[]>(newbyte[0]);
}
privatebyte[] readImage() {
returnnewbyte[1024 * 1024]; //省略了讀取文件的操作 }
publicbyte[] getData() {
byte[] dataArray = dataRef.get();
if (dataArray == null || dataArray.length == 0) {
dataArray = readImage();
dataRef = new SoftReference<byte[]>(dataArray);
}
return dataArray;
}
}
在運行上面程序的時候，可以使用 -Xmx 參數來限制JVM可用的內存。由於軟引用所指向的對象可能被回收掉，在通過get方法來獲取軟引用所實際指向的對象的時候，總是要檢查該對象是否還存活。
弱引用
弱引用（weak reference）在強度上弱於軟引用，通過類WeakReference來表示。它的作用是引用一個對象，但是並不阻止該對象被回收。如果使用一個強引用的話，只要該引用存在，那麼被引用的對象是不能被回收的。弱引用則沒有這個問題。在垃圾回收器運行的時候，如果一個對象的所有引用都是弱引用的話，該對象會被回收。弱引用的作用在於解決強引用所帶來的對象之間在存活時間上的耦合關系。弱引用最常見的用處是在集合類中，尤其在哈希表中。哈希表的介面允許使用任何Java對象作為鍵來使用。當一個鍵值對被放入到哈希表中之後，哈希表對象本身就有了對這些鍵和值對象的引用。如果這種引用是強引用的話，那麼只要哈希表對象本身還存活，其中所包含的鍵和值對象是不會被回收的。如果某個存活時間很長的哈希表中包含的鍵值對很多，最終就有可能消耗掉JVM中全部的內存。
對於這種情況的解決辦法就是使用弱引用來引用這些對象，這樣哈希表中的鍵和值對象都能被垃圾回收。Java中提供了WeakHashMap來滿足這一常見需求。
幽靈引用
在介紹幽靈引用之前，要先介紹Java提供的對象終止化機制（finalization）。在Object類裡面有個finalize方法，其設計的初衷是在一個對象被真正回收之前，可以用來執行一些清理的工作。因為Java並沒有提供類似C++的析構函數一樣的機制，就通過 finalize方法來實現。但是問題在於垃圾回收器的運行時間是不固定的，所以這些清理工作的實際運行時間也是不能預知的。幽靈引用（phantom reference）可以解決這個問題。在創建幽靈引用PhantomReference的時候必須要指定一個引用隊列。當一個對象的finalize方法已經被調用了之後，這個對象的幽靈引用會被加入到隊列中。通過檢查該隊列裡面的內容就知道一個對象是不是已經准備要被回收了。
幽靈引用及其隊列的使用情況並不多見，主要用來實現比較精細的內存使用控制，這對於移動設備來說是很有意義的。程序可以在確定一個對象要被回收之後，再申請內存創建新的對象。通過這種方式可以使得程序所消耗的內存維持在一個相對較低的數量。
⑸ Java垃圾回收機制是什麼
垃圾是指：無用的對象或者引用
回收：清除其所佔內存
機制：自動發生或（gc()）
⑹ Java中垃圾回收有什麼目的什麼時候進行垃圾回收
垃圾回收器的作用是查找和回收（清理）無用的對象。以便讓JVM更有效的使用內存。
垃圾回收器的運行時間是不確定的，由JVM決定，在運行時是間歇執行的。雖然可以通過System.gc（）來強制回收垃圾，但是這個命令下達後無法保證JVM會立即響應執行，但經驗表明，下達命令後，會在短期內執行的請求。JVM通常會感到內存緊缺時候去執行垃圾回收操作。
垃圾回收過於頻繁會導致性能下降，過於稀疏會導致內存緊缺。這個JVM會將其控制到最好，不用程序員擔心。但有些程序在短期會吃掉大量內存，而這些恐怖的對象很快使用結束了，這時候也許有必要強制下達一條垃圾回命令，這是很有必要的，以便有更多可用的物理內存。
⑺ java中垃圾回收機制的原理
java中垃圾回收機制的原理
推薦一篇文章：
對高性能JAVA代碼之內存管理
更甚者你寫的代碼，GC根本就回收不了，直接系統掛掉。GC是一段程序，不是智能，他只回收他認為的垃圾，而不是回收你認為的垃圾。
GC垃圾回收：
Grabage Collection相信學過JAVA的人都知道這個是什麼意思。但是他是如何工作的呢？
首先，JVM在管理內存的時候對於變數的管理總是分新對象和老對象。新對象也就是開發者new出來的對象，但是由於生命周期短，那麼他佔用的內存並不是馬上釋放，而是被標記為老對象，這個時候該對象還是要存在一段時間。然後由JVM決定他是否是垃圾對象，並進行回收。
所以我們可以知道，垃圾內存並不是用完了馬上就被釋放，所以就會產生內存釋放不及時的現象，從而降低了內存的使用。而當程序浩大的時候。這種現象更為明顯，並且GC的工作也是需要消耗資源的。所以，也就會產生內存浪費。
JVM中的對象生命周期里談內存回收：
對象的生命周期一般分為7個階段：創建階段，應用階段，不可視階段，不可到達階段，可收集階段，終結階段，釋放階段。
創建階段：首先大家看一下，如下兩段代碼：
test1：
for（ int i=0; i《10000; i++）
Object obj=new Object（）;
test2：
Object obj=null;
for（ int i=0; i《10000; i++）
obj=new Object（）;
這兩段代碼都是相同的功能，但是顯然test2的性能要比test1性能要好，內存使用率要高，這是為什麼呢？原因很簡單，test1每次執行for循環都要創建一個Object的臨時對象，但是這些臨時對象由於JVM的GC不能馬上銷毀，所以他們還要存在很長時間，而test2則只是在內存中保存一份對象的引用，而不必創建大量新臨時變數，從而降低了內存的使用。
另外不要對同一個對象初始化多次。例如：
public class A{
private Hashtable table = new Hashtable（）;
public A（）{ table = new Hashtable（）;
// 這里應該去掉，因為table已經被初始化。
}
這樣就new了兩個Hashtable，但是卻只使用了一個。另外一個則沒有被引用。而被忽略掉。浪費了內存。並且由於進行了兩次new操作。也影響了代碼的執行速度。
應用階段：即該對象至少有一個引用在維護他。
不可視階段：即超出該變數的作用域。這里有一個很好的做法，因為JVM在GC的時候並不是馬上進行回收，而是要判斷對象是否被其他引用在維護。所以，這個時候如果我們在使用完一個對象以後對其obj=null或者obj.doSomething（）操作，將其標記為空，可以幫助JVM及時發現這個垃圾對象。
不可到達階段：就是在JVM中找不到對該對象的直接或者間接的引用。
可收集階段，終結階段，釋放階段：此為回收器發現該對象不可到達，finalize方法已經被執行，或者對象空間已被重用的時候。
JAVA的析構方法：
可能不會有人相信，JAVA有析構函數？ 是的，有。因為JAVA所有類都繼承至Object類，而finalize就是Object類的一個方法，這個方法在JAVA中就是類似於C++析構函數。一般來說可以通過重載finalize方法的形式才釋放類中對象。如：
public class A{
public Object a;
public A（）{ a = new Object ;}
protected void finalize（） throws java.lang.Throwable{
a = null; // 標記為空，釋放對象
super.finalize（）; // 遞歸調用超類中的finalize方法。
}
}
當然，什麼時候該方法被調用是由JVM來決定的。..。..。..。..。..。..。..。.
一般來說，我們需要創建一個destory的方法來顯式的調用該方法。然後在finalize也對該方法進行調用，實現雙保險的做法。
由於對象的創建是遞歸式的，也就是先調用超級類的構造，然後依次向下遞歸調用構造函數，所以應該避免在類的構造函數中初始化變數，這樣可以避免不必要的創建對象造成不必要的內存消耗。當然這里也就看出來介面的優勢。
數組的創建：
由於數組需要給定一個長度，所以在不確定數據數量的時候經常會創建過大，或過小的數組的現象。造成不必要的內存浪費，所以可以通過軟引用的方式來告訴JVM及時回收該內存。（軟引用，具體查資料）。
例如：
Object obj = new char［10000000000000000］;
SoftReference ref = new SoftReference（obj）;
共享靜態存儲空間：
我們都知道靜態變數在程序運行期間其內存是共享的，因此有時候為了節約內存工件，將一些變數聲明為靜態變數確實可以起到節約內存空間的作用。但是由於靜態變數生命周期很長，不易被系統回收，所以使用靜態變數要合理，不能盲目的使用。以免適得其反。
因此建議在下面情況下使用：
1，變數所包含的對象體積較大，佔用內存過多。
2，變數所包含對象生命周期較長。
3，變數所包含數據穩定。
4，該類的對象實例有對該變數所包含的對象的共享需求。（也就是說是否需要作為全局變數）。
對象重用與GC：
有的時候，如資料庫操作對象，一般情況下我們都需要在各個不同模塊間使用，所以這樣的對象需要進行重用以提高性能。也有效的避免了反復創建對象引起的性能下降。
一般來說對象池是一個不錯的注意。如下：
public abstarct class ObjectPool{
private Hashtable locked，unlocked;
private long expirationTime;
abstract Object create（）;
abstract void expire（ Object o）;
abstract void validate（ Object o）;
synchronized Object getObject（）{。..};
synchronized void freeObject（Object o）{。..};
這樣我們就完成了一個對象池，我們可以將通過對應的方法來存取刪除所需對象。來維護這快內存提高內存重用。
當然也可以通過調用System.gc（）強制系統進行垃圾回收操作。當然這樣的代價是需要消耗一些cpu資源。
不要提前創建對象：
盡量在需要的時候創建對象，重復的分配，構造對象可能會因為垃圾回收做額外的工作降低性能。
JVM內存參數調優：
強制內存回收對於系統自動的內存回收機制會產生負面影響，會加大系統自動回收的處理時間，所以應該盡量避免顯式使用System.gc（），
JVM的設置可以提高系統的性能。例如：
java -XX:NewSize=128m -XX:MaxNewSize=128m -XX:SurvivorRatio=8 -Xms512m -Xmx512m
具體可以查看java幫助文檔。我們主要介紹程序設計方面的性能提高。
JAVA程序設計中有關內存管理的其他經驗：
根據JVM內存管理的工作原理，可以通過一些技巧和方式讓JVM做GC處理時更加有效。，從而提高內存使用和縮短GC的執行時間。
1，盡早釋放無用對象的引用。即在不使用對象的引用後設置為空，可以加速GC的工作。（當然如果是返回值。..。.）
2，盡量少用finalize函數，此函數是JAVA給程序員提供的一個釋放對象或資源的機會，但是卻會加大GC工作量。
3，如果需要使用到圖片，可以使用soft應用類型，它可以盡可能將圖片讀入內存而不引起OutOfMemory.
4，注意集合數據類型的數據結構，往往數據結構越復雜，GC工作量更大，處理更復雜。
5，盡量避免在默認構造器（構造函數）中創建，初始化大量的對象。
6，盡量避免強制系統做垃圾回收。會增加系統做垃圾回收的最終時間降低性能。
7，盡量避免顯式申請數組，如果不得不申請數組的話，要盡量准確估算數組大小。
8，如果在做遠程方法調用。要盡量減少傳遞的對象大小。或者使用瞬間值避免不必要數據的傳遞。
9，盡量在合適的情況下使用對象池來提高系統性能減少內存開銷，當然，對象池不能過於龐大，會適得其反.
⑻ java垃圾回收常用的兩種方法是什麼
java垃圾回收由java虛擬機自己調用，程序員不用管
兩種方法是 System.gc()
Runtime.gc()
Java堆的管理—垃圾回收提到一下幾點，很不錯，或許可以作為寫程序時候的准則：
（1）不要試圖去假定垃圾收集發生的時間，這一切都是未知的。比如，方法中的一個臨時對象在方法調用完畢後就變成了無用對象，這個時候它的內存就可以被釋放。
（2）Java中提供了一些和垃圾收集打交道的類，而且提供了一種強行執行垃圾收集的方法--調用System.gc()，但這同樣是個不確定的方法。Java 中並不保證每次調用該方法就一定能夠啟動垃圾收集，它只不過會向JVM發出這樣一個申請，到底是否真正執行垃圾收集，一切都是個未知數。
（3）挑選適合自己的垃圾收集器。一般來說，如果系統沒有特殊和苛刻的性能要求，可以採用JVM的預設選項。否則可以考慮使用有針對性的垃圾收集器，比如增量收集器就比較適合實時性要求較高的系統之中。系統具有較高的配置，有比較多的閑置資源，可以考慮使用並行標記/清除收集器。
（4）關鍵的也是難把握的問題是內存泄漏。良好的編程習慣和嚴謹的編程態度永遠是最重要的，不要讓自己的一個小錯誤導致內存出現大漏洞。
（5）盡早釋放無用對象的引用。大多數程序員在使用臨時變數的時候，都是讓引用變數在退出活動域(scope)後，自動設置為null，暗示垃圾收集器來收集該對象，還必須注意該引用的對象是否被監聽，如果有，則要去掉監聽器，然後再賦空值。
就是說,對於頻繁申請內存和釋放內存的操作,還是自己控制一下比較好,但是System.gc()的方法不一定適用，最好使用finallize強制執行或者寫自己的finallize方法。
⑼ java垃圾回收是什麼
垃圾回收叫做GC：garbage collection，是java虛擬機JVM提供的一種內存回收方式。開發者在使用java開發的時候不需要像使用C/C++一樣去手動釋放內存，虛擬機會通過自動檢測的方式，去釋放內存。比如你用java new了一個對象，這個時候你得到了一個強引用，strong reference。當你不在需要這個對象的時候，你只需要把它設置成null。這個時候JVM並不會立刻回收掉這塊內存，在之後的某個時間點，當JVM檢測內存的時候發現這塊內存已經沒有任何強引用了，就會把它釋放掉。
⑽ java中的垃圾回收是什麼意思
垃圾回收就是gc（gabage collection）。
java比c++的優點就是多了垃圾回收機制，程序員不用去關心垃圾的回收，系統會自動調用去回收內存。
一般我們想回收的時候只需要調用system.gc方法就可以了。系統會自己去調用destroy方法和其他的回收方法釋放內存，節省內存空間。