Tomcat中Java垃圾收集調(diào)優(yōu)

1、.Tomcat 中 Java 垃圾收集調(diào)優(yōu)1 JVM 內(nèi)存 JAVA_OPTS參數(shù)說明設(shè)置服務(wù)器端的JVM參數(shù)一般在catalina.bat文件中 :JAVA_OPTS="-server-Xms2048m-Xmx2048m -Xss512k"JVM中對象的劃分及管理介紹JVM根據(jù)運(yùn)行于其中的對象的生存時間大致的分為3 種。并且將這3 種不同的對象分別存放在JVM從系統(tǒng)分配到的不同的內(nèi)存空間。這種對象存放空間的管理方式叫做Generation 管理方式。1). Young Generation（年輕代）：用于存放“早逝”對象（即瞬時對象）。例如：在創(chuàng)建對象時或者調(diào)用方法時使用

2、的臨時對象或局部變量。2). Tenured Generation(年老代 ) ：用于存放“駐留”對象（即較長時間被引用的對象）。往往體現(xiàn)為一個大型程序中的全局對象或長時間被使用的對象。3). Perm Generation(永久保存區(qū)域 ) ：用于存放“永久”對象。這些對象管理著運(yùn)行于JVM中的類和方法。-在命令行下用 java -XmxXXXXM -version命令來測試 java 可用最大內(nèi)存，測試可逐漸增大XXXX的值，如果執(zhí)行正常就表示指定的內(nèi)存大小可用，否則會打印錯誤信息。通常測試 windows 系統(tǒng) (32 位 )最大內(nèi)存為： 1500M, 但系統(tǒng)一般到1280M 就差不多了

3、-關(guān)于垃圾收集分類介紹在 JVM中有兩種垃圾方式:1).一種叫做Minor （次收集）。Minor 在 Young Generation （年輕代）的空間被對象全部占用后執(zhí)行，主要是對 Young Generation中的對象進(jìn)行垃圾收集。2).一種叫做Major （主收集）。 Major 是針對于整個Heap size(Xms 和 Xmx設(shè)置為 JVM使用的內(nèi)存，但不包括永久保存區(qū)域使用的內(nèi)存) 的垃圾收集。其中 Minor 方式的收集經(jīng)常發(fā)生，并且Minor 收集所占用的系統(tǒng)時間小。而Major 方式的垃圾收集則是一種“昂貴”的垃圾收集方式，因為在Major 要對整個Heap size 進(jìn)

4、行垃圾收集, 這會使得應(yīng)用停頓的時間變得較長。關(guān)于 TOMCAT內(nèi)存占用介紹Tomcat 運(yùn)行占用內(nèi)存= Xmx 占用的內(nèi)存+ Perm Generation(永久保存區(qū)域) 占用內(nèi)存 +所有 Java 應(yīng)用創(chuàng)建線程數(shù) x 1MJava 應(yīng)用每創(chuàng)建一個線程，在JVM的內(nèi)存里也會創(chuàng)建一個Thread 對象，但是同時也會在操作系統(tǒng)里創(chuàng)建一個真正的物理線程（參考JVM規(guī)范），操作系統(tǒng)會在TOMCAT余下的內(nèi)存里創(chuàng)建這個物理線程，而不是在JVM的 Xmx設(shè)置的內(nèi)存堆里創(chuàng)建。在jdk1.4里頭，默認(rèn)的棧大小是256KB，但是在jdk1.5里頭，默認(rèn)的棧大小為 1M每線程。因此，如果系統(tǒng)剩余內(nèi)存為400M

5、的可用內(nèi)存，則Java 應(yīng)用最多創(chuàng)建400 個可用線程。結(jié)論：要想創(chuàng)建更多的線程，必須減少分配給JVM的最大內(nèi)存。參數(shù)說明如下 ：1 / 5.-server:一定要作為第一個參數(shù)，在多個CPU時性能佳-Xms：初始 Heap 大小，使用的最小內(nèi)存,cpu 性能高時此值應(yīng)設(shè)的大一些-Xmx： java heap最大值，使用的最大內(nèi)存上面兩個值是分配JVM的最小和最大內(nèi)存，取決于硬件物理內(nèi)存的大小，建議均設(shè)為物理內(nèi)存的一半,最大不要超過可用物理內(nèi)存的80。-Xmn： young generation（年輕代）的heap 大小，一般設(shè)置為Xmx的 3、 4 分之一（此值對系統(tǒng)性能影響較大， Sun

6、官方推薦配置為整個堆的3/8 ）( 可使用 -XX:NewSize 和 -XX:MaxNewsize 設(shè)置年輕代的初始值和最大值)-Xincgc :啟動增量垃圾收集器，缺省是關(guān)閉的。增量垃圾收集器能減少偶然發(fā)生的長時間的垃圾回收造成的暫停時間。但增量垃圾收集器和應(yīng)用程序并發(fā)執(zhí)行，因此會占用部分CPU在應(yīng)用程序上的功能。-XX:CMSInitiatingOccupancyFraction=70發(fā)現(xiàn)引起promotion failed錯誤的原因是CMS來不及回收（CMS默認(rèn)在年老代占到90%左右才會執(zhí)行） ，年老代又沒有足夠的空間供GC把一些活的對象從年輕代移到年老代，所以執(zhí)行FullGC。CMS

7、InitiatingOccupancyFraction=70表示年老代占到約70%時就開始執(zhí)行 CMS，這樣就不會頻繁出現(xiàn)Full GC了。上兩個參數(shù)設(shè)置有很大技巧，基本上滿足:(Xmx-Xmn)*(100- CMSInitiatingOccupancyFraction)/100>=Xmn就不會出現(xiàn)promotion failed。如果在應(yīng)用中設(shè)置Xmx（最大內(nèi)存）是1500m，Xmn（年輕代）是340m，那么 Xmx-Xmn是 1160m，也就是年老代有 1160 兆，CMSInitiatingOccupancyFraction=70說明年老代到70%滿的時候開始執(zhí)行對年老代的并發(fā)垃圾

8、回收（ CMS），這時還剩 30%的空間是 1160*30%=348 兆，所以即使 Xmn（也就是年輕代共 340 兆）里所有對象都搬到年老代里， 348 兆的空間也足夠了，所以只要滿足上面的公式，就不會出現(xiàn)垃圾回收時的 promotion failed-XX:PermSize= xxxm:設(shè)定 xxx 兆內(nèi)存的永久保存區(qū)域-XX:MaxPermSize=xxxm: 設(shè)定 xxx 兆最大內(nèi)存的永久保存區(qū)域PermSize 和 MaxPermSize 指明虛擬機(jī)為java永久生成對象（Permanate generation）如， class對象、方法對象這些可反射（reflective）對象分

9、配內(nèi)存限制，這些內(nèi)存不包括在Heap（堆內(nèi)存） 區(qū)之中。上述參數(shù)如果不設(shè)定，永久保存區(qū)域默認(rèn)大?。?server選項下默認(rèn)MaxPermSize 為 64m，-client選項下默認(rèn) MaxPermSize 為 32m。運(yùn)行程序時， jvm 會調(diào)整永久保存區(qū)域的大小以滿足需要。每次調(diào)整時， jvm 會對堆進(jìn)行一次完全的垃圾收集。-XX:+UseConcMarkSweepGC ：選擇 CMS收集器（并發(fā)回收，縮短major 收集的時間）提示：此選項在Heap Size比較大而且Major 收集時間較長的情況下使用更合適?！?-XX:+UseParNewGC ：對年輕代采用多線程并行回收，這樣收得

10、快（縮短minor 收集的時間，如果設(shè)置 -XX:+UseConcMarkSweepGC，無須設(shè)置 -XX:+UseParNewGC，是默認(rèn)的）】-XX:MaxTenuringThreshold=5 CMS收集器中，新生代對象撐過過多少次minor gc 才進(jìn)入年老代的。默認(rèn)為0（或另一說法：一個對象如果在救助空間移動5 次還沒有被回收就放入年老代）。如果設(shè)置為0 就是去掉了新生代空間， 存活的臨時對象不經(jīng)過Survivor區(qū)直接進(jìn)入年老代， 不久就占滿年老代發(fā)生fullgc-XX:GCTimeRatio=19表示 java可以用 5%的時間來做垃圾回收，1/(1+19)=1 /20=5%-X

11、X:CMSFullGCsBeforeCompaction=N表示執(zhí)行 N 次 Full GC后執(zhí)行內(nèi)存壓縮，免得產(chǎn)生內(nèi)存碎片(案例都設(shè)置為：-XX:CMSFullGCsBeforeCompaction=0)-XX:+UseCMSCompactAtFullCollection：表示執(zhí)行Full GC后對內(nèi)存進(jìn)行整理壓縮，免得產(chǎn)生內(nèi)存碎片-Xnoclassgc ：禁用類垃圾回收，性能會高一點(diǎn)；-verbose:gc顯示垃圾收集信息（在虛擬機(jī)發(fā)生內(nèi)存回收時在輸出設(shè)備顯示信息）2 / 5.-Xloggc:gc.log指定垃圾收集日志文件-XX:+DisableExplicitGC禁止 System.g

12、c()：免得程序員誤調(diào)用gc 方法影響性能；-XX:+ExplicitGCInvokesConcurrent： System.gc()可以與應(yīng)用程序并發(fā)執(zhí)行。（ System.gc() 來收回不用的內(nèi)存， 是寫在程序里的。 System.gc() 只是“建議” JVM 回收內(nèi)存， 不是強(qiáng)制。禁止 System.gc() 要看實際開發(fā)的程序如何處理。 因此編程要養(yǎng)成習(xí)慣， 創(chuàng)建一個對象， 不再用時指向 null ，這樣 jvm 發(fā)現(xiàn)它不再使用時，會更早的把它放進(jìn)回收隊列，才能更早的進(jìn)行回收。例如：你要銷毀一個對象，可以代碼 :Stringa="ksadjflasdf"/dos

13、omething./a=null;這不是銷毀一個對象僅僅是把對一個對象的引用去掉了在 java 中一個對象可以被多個對象引用的只有一個對象不在被引用時才可以被垃圾收集）-XX:SoftRefLRUPolicyMSPerMB=N這個參數(shù)比較有用的，官方解釋是：Soft reference在虛擬機(jī)中比在客戶集中存活的更長一些。其清除頻率可以用命令行參數(shù)-XX:SoftRefLRUPolicyMSPerMB=<N> 來控制，這可以指定每兆堆空閑空間的soft reference保持存活（一旦它不強(qiáng)可達(dá)了）的毫秒數(shù)，這意味著每兆堆中的空閑空間中的soft reference會（在最后一個強(qiáng)

14、引用被回收之后）存活1 秒鐘。注意，這是一個近似的值，因為soft reference只會在垃圾回收時才會被清除，而垃圾回收并不總在發(fā)生。系統(tǒng)默認(rèn)為一秒，我覺得沒必要等1 秒，客戶集中不用就立刻清除，改為-XX:SoftRefLRUPolicyMSPerMB=0 ；-Xss 15120這使得 JBoss 每增加一個線程（thread)就會立即消耗15M內(nèi)存，而最佳值應(yīng)該是128K, 默認(rèn)值好像是 512k.+XX:AggressiveHeap會使得 Xms 沒有意義。這個參數(shù)讓jvm 忽略 Xmx參數(shù) , 瘋狂地吃完一個G物理內(nèi)存 , 再吃盡一個G的 swap。-Xss ：每個線程的Stack

15、 大小顯示日志參數(shù)-verbose:gc 在虛擬機(jī)發(fā)生內(nèi)存回收時在輸出設(shè)備顯示信息，格式如下：Full GC 268K->168K(1984K), 0.0187390 secs該參數(shù)用來監(jiān)視虛擬機(jī)內(nèi)存回收的情況。-XX:+PrintGCDetails-XX:+PrintGCTimeStamps(GC發(fā)生的時間 )-XX:+PrintGCApplicationStoppedTime(GC消耗了多少時間)-XX:+PrintGCApplicationConcurrentTime(GC之間運(yùn)行了多少時間)-XX:+PrintTenuringDistribution參數(shù)觀察各個Age 的對象總大

16、小2 GC 日志打印GC 調(diào)優(yōu)是個很實驗很伽利略的活兒，GC日志是先決的數(shù)據(jù)參考和最終驗證：-XX:+PrintGCDetails-XX:+PrintGCTimeStamps(GC發(fā)生的時間 ) -XX:+PrintGCApplicationStoppedTime(GC消耗了多少時間) -XX:+PrintGCApplicationConcurrentTime(GC之間運(yùn)行了多少時間)3 收集器選擇3 / 5.CMS收集器（并發(fā)回收） ：暫停時間優(yōu)先配置參數(shù)： -XX:+UseConcMarkSweepGC已默認(rèn)無需配置的參數(shù)：-XX:+UseParNewGC(Parallel收集新生代 )-

17、XX:+CMSPermGenSweepingEnabled(CMS收集持久代 ) -XX:UseCMSCompactAtFullCollection(full gc時壓縮年老代 )初始效果： 1g 堆內(nèi)存的新生代約60m，minor gc約 5-20 毫秒， full gc約 130 毫秒。Parallel收集器（并行回收） ：吞吐量優(yōu)先配置參數(shù)：-XX:+UseParallelGC-XX:+UseParallelOldGC(Parallel收集年老代，從JDK6.0 開始支持 )已默認(rèn)無需配置的參數(shù)：-XX:+UseAdaptiveSizePolicy(動態(tài)調(diào)整新生代大小)初始效果： 1g

18、堆內(nèi)存的新生代約90-110m( 動態(tài)調(diào)整 ) ， minor gc約 5-20 毫秒， full gc有無UseParallelOldGC參數(shù)分別為1.3/1.1秒，差別不大。另外 -XX:MaxGCPauseMillis=100設(shè)置 minor gc 的期望最大時間，JVM會以此來調(diào)整新生代的大小，但在此測試環(huán)境中對象死的太快，此參數(shù)作用不大。4 調(diào)優(yōu)實戰(zhàn)Parallel收集高達(dá)1 秒的暫停時間基本不可忍受，所以選擇CMS收集器。在被壓測的Mule 2.0應(yīng)用里，每秒都有大約400M的海量短命對象產(chǎn)生：因為默認(rèn)60M的新生代太小了，頻繁發(fā)生minor gc ，大約 0.2 秒就進(jìn)行一次。因

19、為 CMS收集器中 MaxTenuringThreshold(新生代對象撐過過多少次minor gc才進(jìn)入年老代的設(shè)置) 默認(rèn) 0，存活的臨時對象不經(jīng)過Survivor區(qū)直接進(jìn)入年老代，不久就占滿年老代發(fā)生full gc。對這兩個參數(shù)的調(diào)優(yōu)，既要改善上面兩種情況，又要避免新生代過大，復(fù)制次數(shù)過多造成minor gc的暫停時間過長。使用 -Xmn 調(diào)到 1/3總內(nèi)存。觀察后設(shè)置-Xmn500M，新生代實際約460m。( 用 -XX:NewRatio設(shè)置無效，只能用 -Xmn) 。添加 -XX:+PrintTenuringDistribution參數(shù)觀察各個Age 的對象總大小，觀察后設(shè)置-XX:MaxTenuringThreshold=5。優(yōu)化后，大約1.1 秒才發(fā)生一次minor gc ，且速度依然保持在15-20ms 之間。同時年老代的增長速度大大減緩，很久才發(fā)生一次full gc，參數(shù)定稿：-server -Xms1536m -Xmx1536m -Xmn512m-XX:+UseConcMarkSweepGC-XX:MaxTenuringThreshold=5 -XX:+E