javagcfullgc

㈠ 弱弱的問一句 jvm full gc到底是啥意思

JVM 內置的通用垃圾回收原則，堆內存劃分為 Eden、Survivor 和 Tenured/Old 空間。GC一共分三種：MinorGC,Major GC v和Full GC。Full GC是清理整個堆空間—包括年輕代和永久代。有時候系統會頻繁的FullGC，這時候需要去伺服器查一下原因。

當編輯並運行一個java程序時，需要同時涉及到這四種方面。使用文字編輯軟體（例如記事本、寫字板、UltraEdit等）或集成開發環境（Eclipse、MyEclipse等）在Java源文件中定義不同的類 ，通過調用類（這些類實現了Java API）中的方法來訪問資源系統，把源文件編譯生成一種二進制中間碼，存儲在class文件中，然後再通過運行與操作系統平台環境相對應的Java虛擬機來運行class文件，執行編譯產生的位元組碼，調用class文件中實現的方法來滿足程序的Java API調用。

(1)javagcfullgc擴展閱讀

觸發Full GC執行的情況有如下四種。舊生代空間不足

1.舊生代空間只有在新生代對象轉入及創建為大對象、大數組時才會出現不足的現象，當執行Full GC後空間仍然不足，則拋出如下錯誤：

java.lang.OutOfMemoryError: Java heap space

為避免以上兩種狀況引起的FullGC，調優時應盡量做到讓對象在Minor GC階段被回收、讓對象在新生代多存活一段時間及不要創建過大的對象及數組。

2. Permanet Generation空間滿

PermanetGeneration中存放的為一些class的信息等，當系統中要載入的類、反射的類和調用的方法較多時，Permanet Generation可能會被占滿，在未配置為採用CMS GC的情況下會執行Full GC。如果經過Full GC仍然回收不了，那麼JVM會拋出如下錯誤信息：

java.lang.OutOfMemoryError: PermGen space

為避免Perm Gen占滿造成Full GC現象，可採用的方法為增大Perm Gen空間或轉為使用CMS GC。

3. CMS GC時出現promotion failed和concurrent mode failure

對於採用CMS進行舊生代GC的程序而言，尤其要注意GC日誌中是否有promotion failed和concurrent mode failure兩種狀況，當這兩種狀況出現時可能會觸發Full GC。

promotionfailed是在進行Minor GC時，survivor space放不下、對象只能放入舊生代，而此時舊生代也放不下造成的；concurrent mode failure是在執行CMS GC的過程中同時有對象要放入舊生代，而此時舊生代空間不足造成的。

應對措施為：增大survivorspace、舊生代空間或調低觸發並發GC的比率，但在JDK 5.0+、6.0+的版本中有可能會由於JDK的bug29導致CMS在remark完畢後很久才觸發sweeping動作。對於這種狀況，可通過設置-XX:CMSMaxAbortablePrecleanTime=5（單位為ms）來避免。

4. 統計得到的Minor GC晉升到舊生代的平均大小大於舊生代的剩餘空間

這是一個較為復雜的觸發情況，Hotspot為了避免由於新生代對象晉升到舊生代導致舊生代空間不足的現象，在進行Minor GC時，做了一個判斷，如果之前統計所得到的Minor GC晉升到舊生代的平均大小大於舊生代的剩餘空間，那麼就直接觸發Full GC。

例如程序第一次觸發MinorGC後，有6MB的對象晉升到舊生代，那麼當下一次Minor GC發生時，首先檢查舊生代的剩餘空間是否大於6MB，如果小於6MB，則執行Full GC。

當新生代採用PSGC時，方式稍有不同，PS GC是在Minor GC後也會檢查，例如上面的例子中第一次Minor GC後，PS GC會檢查此時舊生代的剩餘空間是否大於6MB，如小於，則觸發對舊生代的回收。

除了以上4種狀況外，對於使用RMI來進行RPC或管理的Sun JDK應用而言，默認情況下會一小時執行一次Full GC。可通過在啟動時通過- java-Dsun.rmi.dgc.client.gcInterval=3600000來設置Full GC執行的間隔時間或通過-XX:+ DisableExplicitGC來禁止RMI調用System.gc。

參考資料來源：網路-JAVA

㈡ 請java 高手幫我看看這個問題，多次GC連續出現2個FULLGC 是什麼情況導致的

建議： (1)創建圖表：

㈢ java中，MinorGC、MajorGC、FullGC 什麼時候發生

minorGC：新生代滿了，就發生
FullGC：新生代滿了，老年代也滿了，還有新對象要產生，就發生
majorGC=FullGC

㈣ Java中full gc什麼意思

轉發的~但能解決你的問題

除直接調用System.gc外，觸發Full GC執行的情況有如下四種。
1. 舊生代空間不足
舊生代空間只有在新生代對象轉入及創建為大對象、大數組時才會出現不足的現象，當執行Full GC後空間仍然不足，則拋出如下錯誤：
java.lang.OutOfMemoryError: Java heap space
為避免以上兩種狀況引起的FullGC，調優時應盡量做到讓對象在Minor GC階段被回收、讓對象在新生代多存活一段時間及不要創建過大的對象及數組。
2. Permanet Generation空間滿
PermanetGeneration中存放的為一些class的信息等，當系統中要載入的類、反射的類和調用的方法較多時，Permanet Generation可能會被占滿，在未配置為採用CMS GC的情況下會執行Full GC。如果經過Full GC仍然回收不了，那麼JVM會拋出如下錯誤信息：
java.lang.OutOfMemoryError: PermGen space
為避免Perm Gen占滿造成Full GC現象，可採用的方法為增大Perm Gen空間或轉為使用CMS GC。
3. CMS GC時出現promotion failed和concurrent mode failure
對於採用CMS進行舊生代GC的程序而言，尤其要注意GC日誌中是否有promotion failed和concurrent mode failure兩種狀況，當這兩種狀況出現時可能會觸發Full GC。
promotionfailed是在進行Minor GC時，survivor space放不下、對象只能放入舊生代，而此時舊生代也放不下造成的；concurrent mode failure是在執行CMS GC的過程中同時有對象要放入舊生代，而此時舊生代空間不足造成的。
應對措施為：增大survivorspace、舊生代空間或調低觸發並發GC的比率，但在JDK 5.0+、6.0+的版本中有可能會由於JDK的bug29導致CMS在remark完畢後很久才觸發sweeping動作。對於這種狀況，可通過設置-XX:CMSMaxAbortablePrecleanTime=5（單位為ms）來避免。
4. 統計得到的Minor GC晉升到舊生代的平均大小大於舊生代的剩餘空間
這是一個較為復雜的觸發情況，Hotspot為了避免由於新生代對象晉升到舊生代導致舊生代空間不足的現象，在進行Minor GC時，做了一個判斷，如果之前統計所得到的Minor GC晉升到舊生代的平均大小大於舊生代的剩餘空間，那麼就直接觸發Full GC。
例如程序第一次觸發MinorGC後，有6MB的對象晉升到舊生代，那麼當下一次Minor GC發生時，首先檢查舊生代的剩餘空間是否大於6MB，如果小於6MB，則執行Full GC。
當新生代採用PSGC時，方式稍有不同，PS GC是在Minor GC後也會檢查，例如上面的例子中第一次Minor GC後，PS GC會檢查此時舊生代的剩餘空間是否大於6MB，如小於，則觸發對舊生代的回收。
除了以上4種狀況外，對於使用RMI來進行RPC或管理的Sun JDK應用而言，默認情況下會一小時執行一次Full GC。可通過在啟動時通過- java-Dsun.rmi.dgc.client.gcInterval=3600000來設置Full GC執行的間隔時間或通過-XX:+ DisableExplicitGC來禁止RMI調用System.gc。

㈤ JVM堆內存很富足時，為什麼經常連續發生兩次full GC

前面我自理解面復制java垃圾收前聽師講像內存滿才做整體垃圾收,收垃圾同調用finalize.構造類構造類覆蓋finalize便於該類垃圾收執行些代碼,比釋放資源.1.JVMgc概述 gc即垃圾收集機制指jvm用於釋放些再使用象所佔用內存java語言並要求jvmgc沒規定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則存儲classmethod象配置言永久域獨立域並且認堆部 面介紹何控制些域使用-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值設置64mjava -Xms512m -Xmx512m -Xmn128m -XX:PermSize=32m -XX:MaxPermSize=64m 默認狀態HotSpot新域使用復制收集器該域般三部第部Eden用於新象另兩部稱救助空間Eden 充滿收集器停止應用程序所達象復制前from救助空間旦前from救助空間充滿收集器則達象復制前to救助空間Fromto救助空間互換角色維持象救助空間斷復制直獲使用期並轉入舊域使用-XX:SurvivorRatio 控制新域空間 同NewRationSurvivorRation規定某救助域與Eden空間比值比命令新域設置64mEden佔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所目錄同於HotSpotJava位元組碼編譯本碼預先編譯類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:應四收集器別 gensinglecongencon及parallel使用-Xms-Xmx設置堆初始值要設置護理域則使用- Xns:java –jrockit –Xms512m –Xmx512m –Xgc:gencon –Xns128m…盡管JRockit支持-verbose:gc關輸信息收集器同異JRockit支持memory、 loadcodegen輸 注意 ： 使用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-sizemax-heap-size frameworkRequestManagerJNLP文件加入述參數些值要求根據客戶機硬體狀態變化（客戶機內存等）建議兩參數值設客戶機用內存60％（待測試）態JNLP兩參數值能夠隨客戶機同同靠慮獲客戶機系統信息並些嵌首頁index.jsp作連接請求參數 設置述參數通Visualgc 觀察垃圾收些參數狀態再做相應調整改善性能般標准減少fullgc數硬體支持使用並行垃圾收（要求CPU）

㈥ 為什麼會發生full gc

前面是我自己理解的後面是復制的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 fullgc什麼意思

GC是垃圾回收站。
FULL GC分析和問題定位
a. GC log收集和分析
(1)在JVM啟動參數增加："-verbose:gc -Xloggc:<file_name> -XX:+PrintGCDetails -XX:+PrintGCDateStamps"
PrintGCTimeStamp只能獲得相對時間，建議使用PrintGCDateStamps獲得full gc 發生的絕對時間
(2)如果採用CMS GC,仔細分析jstat FGC輸出和GC 日誌會發現， CMS的每個並發GC周期則有兩個stop-the-world階段——initial mark與final re-mark，使得CMS的每個並發GC周期總共會更新full GC計數器兩次，initial mark與final re-mark各一次

b. Dump JVM 內存快照
/opt/taobao/java/bin/jmap -mp:format=b,file=mp.bin pid
這里有一個問題是什麼時候進行mp?
一種方法是前面提到的用jstat工具觀察，當OLD區到達比較高的比例如60%，一般會很快觸發一次FULL GC,可以進行一次DUMP,在FULL GC發生以後再DUMP一次，這樣比較就可以發現到底是哪些對象導致不停的FULL GC
另外一種方法是通過配置JVM參數
-XX:+HeapDumpBeforeFullGC -XX:+HeapDumpAfterFullGC分別用於指定在full GC之前與之後生成heap mp

c. 利用MAT((Memory Analyzer Tool)工具分析mp文件
關於MAT具體使用方法網上有很多介紹，這里不做詳細展開，這里需要注意的是：
(1) MAT預設只分析reachable的對象，unreachable的對象（將被收集掉的對象）被忽略，而分析FULL GC頻繁原因時unreachable object也應該同時被重點關注。如果要顯示unreachable的對象細節必須用mat 1.1以上版本並且打開選項「keep unreachable object」
(2) 通常mp文件會好幾個G，無法在windows上直接進行分析，我們可以先把mp文件在linux上進行分析，再把分析好的文件拷貝到windows上，在windows上用MAT打開分析文件。

㈧ java 怎樣規避full gc

據我觀察JAVA程序，一般在命令行模式下運行JAVA任務，JDK可以承受的內存上限大概是機器物理內存的1/4。
比如我的伺服器是16G的內存，那麼JAVA程序可以佔用的最大內存是4G左右，超出就報溢出。

所以在一般程序運行中，JAVA內存逐漸從
100MB 200MB, 300...1G...2G...... 膨脹到4G，在這個過程中，我的循環都設置了System.gc()，偶爾有佔用內存減少的時候，但是基本下降都很有限，然後過一會兒又繼續上升。直到上升到4G的時候，如果此時系統沒有明確的數據持續寫進內存，只是大量進行新建變數，賦值，然後生命周期結束待回收的過程，系統會大量進行GC的操作，保證JAVA內存不超過4G，但我似乎感覺一旦在內存在4G上下游動的時候，JAVA程序的性能就開始走低。

所以我的理解是，GC直到不得不執行的時候才會被執行，而且效果並不好。。。。
PS，如果是8G內存的伺服器，GC頻繁執行是在JAVA佔用內存到達2G的時候。
同不知道如何進行高效的內存回收。本來沒有任何寫入內存操作的程序，但是程序處理問題一大了，佔有內存就很多。

㈨ 為什麼java進程頻繁出現fullgc

為什麼java進程頻繁出現fullgc
因為有java虛擬機啊，比如說優先順序什麼的，都可以交給虛擬機處理。

㈩ Java中full gc什麼意思

gc是垃圾回收的意思（gabage
collection），內存處理器是編程人員容易出現問題的地方，忘記或者錯誤的內存回收導致程序或者系統的不穩定甚至崩潰，java的gc功能可以自動監測對象是否超過作用域從而達到自動回收內存的目的，java語言沒有提供釋放已分配內存的俄顯示操作方法。
希望能幫到你，謝謝！