cmsjvm

1、jvm 怎麼知道cms清理了多少垃圾

試試騰訊電腦管家，清理垃圾包括清理垃圾、清理痕跡、清理插件和系統加速四塊，垃圾和痕跡不必多說，掃描出的插件比較詳細，能查看插件詳情，插件文件的存儲路徑和注冊表位置信息都描述的很詳細。如果你無法確認某個插件是否有用，可以點擊投票按鍵看一下大家都是怎麼評價它的——某個大多數人去踩的插件，相信你也該知道怎麼去做了。

2、為什麼CMS GC時出現Concurrent Mode Failure

出現Concurrent ModeFailure現象時，解決辦法就是要讓年老代留有足夠的空間，以保證新對象空間的分配。另外在JVM BUG中有提到，JDK1.5_09版本之前，JVM參數-XX:是無效的，我這里應用環境的版本是JDK1.5_08，從gc日誌來看是可以生效的。
GC時還有一個常見的錯誤PromotionFailed，解決辦法類似，也是調整年輕代和年老代的比例，還有CMSGC的時機。

3、jvm cms 使用的是什麼演算法

通過讀屏障來看這個內存是不是發生移動，如果在移動稍微停一下，移動過去後再使用。
就是讀標記

4、如何設置jvm啟動參數

不管是YGC還是Full GC,GC過程中都會對導致程序運行中中斷,正確的選擇不同的GC策略,調整JVM、GC的參數，可以極大的減少由於GC工作，而導致的程序運行中斷方面的問題，進而適當的提高Java程序的工作效率。但是調整GC是以個極為復雜的過程，由於各個程序具備不同的特點，如：web和GUI程序就有很大區別（Web可以適當的停頓，但GUI停頓是客戶無法接受的），而且由於跑在各個機器上的配置不同（主要cup個數，內存不同），所以使用的GC種類也會不同(如何選擇見GC種類及如何選擇)。本文將注重介紹JVM、GC的一些重要參數的設置來提高系統的性能。
GC性能方面的考慮
對於GC的性能主要有2個方面的指標：吞吐量throughput（工作時間不算gc的時間占總的時間比）和暫停pause（gc發生時app對外顯示的無法響應）。
1. Total Heap
默認情況下，vm會增加/減少heap大小以維持free space在整個vm中占的比例，這個比例由MinHeapFreeRatio和MaxHeapFreeRatio指定。
一般而言，server端的app會有以下規則：
對vm分配盡可能多的memory；
將Xms和Xmx設為一樣的值。如果虛擬機啟動時設置使用的內存比較小，這個時候又需要初始化很多對象，虛擬機就必須重復地增加內存。
處理器核數增加，內存也跟著增大。
2. The Young Generation
另外一個對於app流暢性運行影響的因素是young generation的大小。young generation越大，minor collection越少；但是在固定heap size情況下，更大的young generation就意味著小的tenured generation，就意味著更多的major collection(major collection會引發minor collection)。
NewRatio反映的是young和tenured generation的大小比例。NewSize和MaxNewSize反映的是young generation大小的下限和上限，將這兩個值設為一樣就固定了young generation的大小（同Xms和Xmx設為一樣）。
如果希望，SurvivorRatio也可以優化survivor的大小，不過這對於性能的影響不是很大。SurvivorRatio是eden和survior大小比例。
一般而言，server端的app會有以下規則：
首先決定能分配給vm的最大的heap size，然後設定最佳的young generation的大小；
如果heap size固定後，增加young generation的大小意味著減小tenured generation大小。讓tenured generation在任何時候夠大，能夠容納所有live的data（留10%-20%的空餘）。
經驗&&規則
年輕代大小選擇
響應時間優先的應用:盡可能設大,直到接近系統的最低響應時間限制(根據實際情況選擇).在此種情況下,年輕代收集發生的頻率也是最小的.同時,減少到達年老代的對象.
吞吐量優先的應用:盡可能的設置大,可能到達Gbit的程度.因為對響應時間沒有要求,垃圾收集可以並行進行,一般適合8CPU以上的應用.
避免設置過小.當新生代設置過小時會導致:1.YGC次數更加頻繁 2.可能導致YGC對象直接進入舊生代,如果此時舊生代滿了,會觸發FGC.
年老代大小選擇
響應時間優先的應用:年老代使用並發收集器,所以其大小需要小心設置,一般要考慮並發會話率和會話持續時間等一些參數.如果堆設置小了,可以會造成內存碎 片,高回收頻率以及應用暫停而使用傳統的標記清除方式;如果堆大了,則需要較長的收集時間.最優化的方案,一般需要參考以下數據獲得:
並發垃圾收集信息、持久代並發收集次數、傳統GC信息、花在年輕代和年老代回收上的時間比例。
吞吐量優先的應用:一般吞吐量優先的應用都有一個很大的年輕代和一個較小的年老代.原因是,這樣可以盡可能回收掉大部分短期對象,減少中期的對象,而年老代盡存放長期存活對象.
較小堆引起的碎片問題
因為年老代的並發收集器使用標記,清除演算法,所以不會對堆進行壓縮.當收集器回收時,他會把相鄰的空間進行合並,這樣可以分配給較大的對象.但是,當堆空間較小時,運行一段時間以後,就會出現"碎片",如果並發收集器找不到足夠的空間,那麼並發收集器將會停止,然後使用傳統的標記,清除方式進行回收.如果出現"碎片",可能需要進行如下配置:
-XX:+UseCMSCompactAtFullCollection:使用並發收集器時,開啟對年老代的壓縮.
-XX:CMSFullGCsBeforeCompaction=0:上面配置開啟的情況下,這里設置多少次Full GC後,對年老代進行壓縮
用64位操作系統，Linux下64位的jdk比32位jdk要慢一些，但是吃得內存更多，吞吐量更大
XMX和XMS設置一樣大，MaxPermSize和MinPermSize設置一樣大，這樣可以減輕伸縮堆大小帶來的壓力
使用CMS的好處是用盡量少的新生代，經驗值是128M－256M， 然後老生代利用CMS並行收集， 這樣能保證系統低延遲的吞吐效率。 實際上cms的收集停頓時間非常的短，2G的內存， 大約20－80ms的應用程序停頓時間
系統停頓的時候可能是GC的問題也可能是程序的問題，多用jmap和jstack查看，或者killall -3 java，然後查看java控制台日誌，能看出很多問題。(相關工具的使用方法將在後面的blog中介紹)
仔細了解自己的應用，如果用了緩存，那麼年老代應該大一些，緩存的HashMap不應該無限制長，建議採用LRU演算法的Map做緩存，LRUMap的最大長度也要根據實際情況設定。
採用並發回收時，年輕代小一點，年老代要大，因為年老大用的是並發回收，即使時間長點也不會影響其他程序繼續運行，網站不會停頓
JVM參數的設置(特別是 –Xmx –Xms –Xmn -XX:SurvivorRatio -XX:MaxTenuringThreshold等參數的設置沒有一個固定的公式，需要根據PV old區實際數據 YGC次數等多方面來衡量。為了避免promotion faild可能會導致xmn設置偏小，也意味著YGC的次數會增多，處理並發訪問的能力下降等問題。每個參數的調整都需要經過詳細的性能測試，才能找到特定應用的最佳配置。
promotion failed:
垃圾回收時promotion failed是個很頭痛的問題，一般可能是兩種原因產生，第一個原因是救助空間不夠，救助空間里的對象還不應該被移動到年老代，但年輕代又有很多對象需要放入救助空間；第二個原因是年老代沒有足夠的空間接納來自年輕代的對象；這兩種情況都會轉向Full GC，網站停頓時間較長。
解決方方案一：
第一個原因我的最終解決辦法是去掉救助空間，設置-XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0即可，第二個原因我的解決辦法是設置為某個值（假設70），這樣年老代空間到70%時就開始執行CMS，年老代有足夠的空間接納來自年輕代的對象。
解決方案一的改進方案：
又有改進了，上面方法不太好，因為沒有用到救助空間，所以年老代容易滿，CMS執行會比較頻繁。我改善了一下，還是用救助空間，但是把救助空間加大，這樣也不會有promotion failed。具體操作上，32位Linux和64位Linux好像不一樣，64位系統似乎只要配置MaxTenuringThreshold參數，CMS還是有暫停。為了解決暫停問題和promotion failed問題，最後我設置-XX:SurvivorRatio=1 ，並把MaxTenuringThreshold去掉，這樣即沒有暫停又不會有promotoin failed，而且更重要的是，年老代和永久代上升非常慢（因為好多對象到不了年老代就被回收了），所以CMS執行頻率非常低，好幾個小時才執行一次，這樣，伺服器都不用重啟了。
-Xmx4000M -Xms4000M -Xmn600M -XX:PermSize=500M -XX:MaxPermSize=500M -Xss256K -XX:+DisableExplicitGC -XX:SurvivorRatio=1 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:+CMSClassUnloadingEnabled -XX:LargePageSizeInBytes=128M -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:=80 -XX:SoftRefLRUPolicyMSPerMB=0 -XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:log/gc.log

值與Xmn的關系公式
上面介紹了promontion faild產生的原因是EDEN空間不足的情況下將EDEN與From survivor中的存活對象存入To survivor區時,To survivor區的空間不足，再次晉升到old gen區，而old gen區內存也不夠的情況下產生了promontion faild從而導致full gc.那可以推斷出：eden+from survivor < old gen區剩餘內存時，不會出現promontion faild的情況，即：
(Xmx-Xmn)*(1-/100)>=(Xmn-Xmn/(SurvivorRatior+2)) 進而推斷出：
<=((Xmx-Xmn)-(Xmn-Xmn/(SurvivorRatior+2)))/(Xmx-Xmn)*100
例如：
當xmx=128 xmn=36 SurvivorRatior=1時 <=((128.0-36)-(36-36/(1+2)))/(128-36)*100 =73.913
當xmx=128 xmn=24 SurvivorRatior=1時 <=((128.0-24)-(24-24/(1+2)))/(128-24)*100=84.615…
當xmx=3000 xmn=600 SurvivorRatior=1時 <=((3000.0-600)-(600-600/(1+2)))/(3000-600)*100=83.33
低於70% 需要調整xmn或SurvivorRatior值。

5、如何設置JVM參數

設置eclipse jvm參數

打開Eclipse 或者 MyEclipse

打開 Windows -> Preferences -> Java -> Installed JREs 

選中你所使用的 JDK，然後點擊 Edit，會出現如下圖：

在 Default VM Arguments輸入框內輸入： -Xms512m -Xmx512m

解釋：

-Xms是設置java虛擬機的最小分配內存；-Xmx則是最大分配內存；512m為內存空間

一般-Xmx設置為你電腦物理內存的1/4，而把-Xms和 -Xmx設置為一樣，

其實你可以設置得更大一些，只要系統能分配足夠的內存就可以了，如果設置過大系統會提示你的。

6、JVM參數配置

不明白你想干什麼
通常JVM都不需要配置的
Eclipse是javaWeb開發工具
Tomcat是web應用伺服器,用來運行javaweb程序的
通常只有配置tomcat的內存大小,才會去配置JVM的內存等
具體要看樓主想配置什麼東西了
請採納哈...

7、JVM參數如何設置？(二)

ii、吞吐量優先的應用:盡可能的設置大,可能到達Gbit的程度.因為對響應時間沒有要求,垃圾收集可以並行進行,一般適合8CPU以上的應用.iii、避免設置過小.當新生代設置過小時會導致:1.YGC次數更加頻繁 2.可能導致YGC對象直接進入舊生代,如果此時舊生代滿了,會觸發FGC.2、年老代大小選擇i、響應時間優先的應用:年老代使用並發收集器,所以其大小需要小心設置,一般要考慮並發會話率和會話持續時間等一些參數.如果堆設置小了,可以會造成內存碎 片,高回收頻率以及應用暫停而使用傳統的標記清除方式;如果堆大了,則需要較長的收集時間.最優化的方案,一般需要參考以下數據獲得:並發垃圾收集信息、持久代並發收集次數、傳統GC信息、花在年輕代和年老代回收上的時間比例。ii、吞吐量優先的應用:一般吞吐量優先的應用都有一個很大的年輕代和一個較小的年老代.原因是,這樣可以盡可能回收掉大部分短期對象,減少中期的對象,而年老代盡存放長期存活對象.iii、較小堆引起的碎片問題因為年老代的並發收集器使用標記,清除演算法,所以不會對堆進行壓縮.當收集器回收時,他會把相鄰的空間進行合並,這樣可以分配給較大的對象.但是,當堆空間較小時,運行一段時間以後,就會出現"碎片",如果並發收集器找不到足夠的空間,那麼並發收集器將會停止,然後使用傳統的標記,清除方式進行回收.如果出現"碎片",可能需要進行如下配置:-XX:+UseCMSCompactAtFullCollection:使用並發收集器時,開啟對年老代的壓縮.-XX:CMSFullGCsBeforeCompaction=0:上面配置開啟的情況下,這里設置多少次Full GC後,對年老代進行壓縮iv、用64位操作系統，Linux下64位的jdk比32位jdk要慢一些，但是吃得內存更多，吞吐量更大v、XMX和XMS設置一樣大，MaxPermSize和MinPermSize設置一樣大，這樣可以減輕伸縮堆大小帶來的壓力vi、使用CMS的好處是用盡量少的新生代，經驗值是128M－256M， 然後老生代利用CMS並行收集， 這樣能保證系統低延遲的吞吐效率。 實際上cms的收集停頓時間非常的短，2G的內存， 大約20－80ms的應用程序停頓時間vii、系統停頓的時候可能是GC的問題也可能是程序的問題，多用jmap和jstack查看，或者killall -3 java，然後查看java控制台日誌，能看出很多問題。(相關工具的使用方法將在後面的blog中介紹)viii、仔細了解自己的應用，如果用了緩存，那麼年老代應該大一些，緩存的HashMap不應該無限制長，建議採用LRU演算法的Map做緩存，LRUMap的最大長度也要根據實際情況設定。ix、採用並發回收時，年輕代小一點，年老代要大，因為年老大用的是並發回收，即使時間長點也不會影響其他程序繼續運行，網站不會停頓x、JVM參數的設置(特別是 –Xmx –Xms –Xmn -XX:SurvivorRatio -XX:MaxTenuringThreshold等參數的設置沒有一個固定的公式，需要根據PV old區實際數據 YGC次數等多方面來衡量。為了避免promotion faild可能會導致xmn設置偏小，也意味著YGC的次數會增多，處理並發訪問的能力下降等問題。每個參數的調整都需要經過詳細的性能測試，才能找到特定應用的最佳配置。

8、JVM的垃圾演算法有哪幾種

一、垃圾收集器概述

如上圖所示，垃圾回收演算法一共有7個，3個屬於年輕代、三個屬於年老代，G1屬於橫跨年輕代和年老代的演算法。

JVM會從年輕代和年老代各選出一個演算法進行組合，連線表示哪些演算法可以組合使用

二、各個垃圾收集器說明

1、Serial(年輕代）

年輕代收集器，可以和Serial Old、CMS組合使用

採用復制演算法

使用單線程進行垃圾回收，回收時會導致Stop The World，用戶進程停止

client模式年輕代默認演算法

GC日誌關鍵字：DefNew(Default New Generation)

圖示（Serial+Serial Old)

2、ParNew(年輕代）

新生代收集器，可以和Serial Old、CMS組合使用

採用復制演算法

使用多線程進行垃圾回收，回收時會導致Stop The World，其它策略和Serial一樣

server模式年輕代默認演算法

使用-XX:ParallelGCthreads參數來限制垃圾回收的線程數

GC日誌關鍵字：ParNew(Parallel New Generation)

圖示（ParNew + Serail Old）

3、Paralle Scavenge(年輕代）

新生代收集器，可以和Serial Old、Parallel組合使用，不能和CMS組合使用

採用復制演算法

使用多線程進行垃圾回收，回收時會導致Stop The World

關注系統吞吐量

-XX:MaxGCPauseMillis：設置大於0的毫秒數，收集器盡可能在該時間內完成垃圾回收

-XX:GCTimeRatio：大於0小於100的整數，即垃圾回收時間占總時間的比率，設置越小則希望垃圾回收所佔時間越小，CPU能花更多的時間進行系統操作，提高吞吐量

-XX:UseAdaptiveSizePolicy：參數開關，啟動後系統動態自適應調節各參數，如-Xmn、-XX：SurvivorRatio等參數，這是和ParNew收集器重要的區別

GC日誌關鍵字：PSYoungGen

4、Serial Old(年老代）

年老代收集器，可以和所有的年輕代收集器組合使用(Serial收集器的年老代版本）

採用 」標記-整理「演算法，會對垃圾回收導致的內存碎片進行整理

使用單線程進行垃圾回收，回收時會導致Stop The World，用戶進程停止

GC日誌關鍵字：Tenured

圖示（Serial+Serial Old)

5、Parallel Old(年老代）

年老代收集器，只能和Parallel Scavenge組合使用(Parallel Scavenge收集器的年老代版本）

採用 」標記-整理「演算法，會對垃圾回收導致的內存碎片進行整理

關注吞吐量的系統可以將Parallel Scavenge+Parallel Old組合使用

GC日誌關鍵字：ParOldGen

圖示(Parallel Scavenge+Parallel Old)

6、CMS(Concurrent Mark Sweep年老代）

年老代收集器，可以和Serial、ParNew組合使用

採用 」標記-清除「演算法，可以通過設置參數在垃圾回收時進行內存碎片的整理
1、：默認開啟，FullGC時進行內存碎片整理，整理時用戶進程需停止，即發生Stop The World
2、CMSFullGCsBeforeCompaction：設置執行多少次不壓縮的Full GC後，執行一個帶壓縮的（默認為0，表示每次進入Full GC時都進行碎片整理）

CMS是並發演算法，表示垃圾回收和用戶進行同時進行，但是不是所有階段都同時進行，在初始標記、重新標記階段還是需要Stop the World。CMS垃圾回收分這四個階段
1、初始標記（CMS Initial mark）  Stop the World 僅僅標記一下GC Roots能直接關聯到的對象，速度快
2、並發標記（CMS concurrent mark） 進行GC Roots Tracing，時間長，不發生用戶進程停頓
3、重新標記（CMS remark）  Stop the World 修正並發標記期間因用戶程序繼續運行導致標記變動的那一部分對象的標記記錄，停頓時間較長，但遠比並發標記時間短
4、並發清除（CMS concurrent sweep） 清除的同時用戶進程會導致新的垃圾，時間長，不發生用戶進程停頓

適合於對響應時間要求高的系統

GC日誌關鍵字：CMS-initial-mark、CMS-concurrent-mark-start、CMS-concurrent-mark、CMS-concurrent-preclean-start、CMS-concurrent-preclean、CMS-concurrent-sweep、CMS-concurrent-reset等等

缺點
1、對CPU資源非常敏感
2、CMS收集器無法處理浮動垃圾，即清除時用戶進程同時產生的垃圾，只能等到下次GC時回收
3、因為是使用「標記-清除」演算法，所以會產生大量碎片

圖示

7、G1

G1收集器由於沒有使用過，所以從網上找了一些教程供大家了解

並行與並發

分代收集

空間整合

可預測的停頓

9、jvm cms stop the world進程什麼意思

JVM有個叫做「安全點」和「安全區域」的東西，在發生GC時，所有的線程都會執行到「安全點」停下來。

在需要GC的時候，JVM會設置一個標志，當線程執行到安全點的時候會輪詢檢測這個標志，如果發現需要GC，則線程會自己掛起，直到GC結束才恢復運行。

體系結構：

每個Java程序都離不開Java虛擬機，Java程序的運行依靠具體的Java虛擬機實例。在Java虛擬機規范中，分別用子系統、內存區、數據類型以及指令這幾個術語來描述的。這些組成部分一起展示出一個抽象化的虛擬機內部的抽象體系結構。

(9)cmsjvm擴展資料：

內存管理：

對於Java運行時涉及到的存儲區域主要包括程序計數器、Java虛擬機棧、本地方法棧、java堆、方法區以及直接內存等等。對於每個部分，都有其使用的條件。程序計數器主要是取下一條指令，在Java裡面主要是取下一條指令的位元組碼文件。

Java虛擬機棧主要是利用棧先進後出的特性存儲局部變數表，動態鏈接等，主要包括堆內存和棧內存，對於程序員內存分析而言是特別重要的。

本地方法棧與上邊的棧基本作用差不多，只不過這里是為Java方法而服務。Java堆是內存管理中最大的一塊，所有的線程共享這一塊內容，同時該部分也是垃圾收集器的主要區域。

10、jvm垃圾回收不了，java heap占滿，導致應用頻繁重啟

從【Heap Usage】看，老年代（concurrent mark-sweep generation）的內存使用了99%以上，相較而言，新生代還有較多剩餘；

JVM參數配置中的這一條，-XX:MaxTenuringThreshold=0，使新生代Eden區域的Java對象不經過Survivor區域，而直接晉升到老年代。這增加了老年代的垃圾回收負擔，而且老年代開啟了碎片整理，更加耗時；

請嘗試將-XX:MaxTenuringThreshold參數調大一些，讓對象晚一些進入老年代；

另外，請試一下增大Java堆內存的分配量，看是否能解決問題。

【以上只是個人猜測，不知能否幫上忙。從JVM的GC日誌中，也許能進一步發現問題。】