12一14幻女bbwxxxx在线播放

同性男男黄g片免费网站 CMS:聽我的,生產環境上要這樣建立JVM參數

发布日期:2022-05-19 04:24    点击次数:200

哪怕JDK16 GA已經發布很真切,然而,不错细倡导是,絕大多數的生產環境一经運行的是JDK8。此處必須來一句:JDK8 yyds。既然運行的是JDK8,那么生產環境的垃圾回收器基本上等于底下3種啦:

PS(JDK8默認) CMS G1 默認垃圾回收器

筆者此篇著作只聚焦于怎样建立一個比較合理的选拔CMS作為垃圾回收器的JVM參數。最初要說的是,JDK8要使用CMS,那么必須顯示声名,因為它选拔的默認垃圾回收器是ParallelGC。怎样驗證它默認选拔的垃圾回收器呢?极度簡單,運行如下代碼:

package 同性男男黄g片免费网站com.afei.test.main;  import java.util.ArrayList; import java.util.List;  /**  * @author 公眾號: 阿飛的博客  */ public class Main {      private static final int _1M = 1024*1024;      public static void main(String[] args) {          List<byte[]> byteList = new ArrayList<>();         for(int i=0; i<Integer.MAX_VALUE; i++){             byte[] test = new byte[_1M];             byteList.add(test);         }     }  } 

然后建立JVM參數:

-verbose:gc -XX:+PrintGCDetails 

運行幾秒鐘后,我們強行住手JVM進程,就會在戒指臺中看到如下日记從而佐證JDK8选拔的默認垃圾回收器等于ParallelGC:

[Full GC (Allocation Failure) [PSYoungGen: 342021K->342021K(348672K)] [ParOldGen: 1397423K->1397406K(1398272K)] 1739445K->1739427K(1746944K), [Metaspace: 3357K->3357K(1056768K)], 0.1902415 secs] [Times: user=0.26 sys=0.01, real=0.19 secs]  

或者不错通過如下信息得知默認垃圾回收器為ParallelGC:圖片

CMS用法

接下來筆者從多個方面介紹怎样建立一個較好的使用CMS垃圾回收器的JVM參數參數。

顯示声名CMS

顯示声名垃圾回收器為CMS+parNew极度簡單,只需要添加如下兩個JVM參數:

-XX:+UseConcMarkSweepGC -XX:+UseParNewGC 

這時候,再運行上头的代碼,就會得回如下信息。由下圖可知,這時候年輕代选拔的是ParNew,而老年代选拔的是CMS(concurrent mark-sweep):

顯示声名CMS仅仅使用CMS的第一步,接下來還有好多優化需要我們去做,還有好多JVM參數恭候我們去建立。

堆大小

接下來,最伏击的等于申来岁輕代和老年代的大小。由于选拔的CMS+ParNew。建議堆大小不要超過8G,最佳6G以內,因為CMS+ParNew組合情況下發生的FGC是选拔MSC算法且單線程回收,若是堆內存很大,FGC時STW時間會极度恐怖。筆者這里以4G舉例,這時候再添加幾個JVM參數,我們得回如下的建立。這里筆者設置的年輕代大要是1.5G,老年代大要是2.5G。這算是一個比較合理的比例搭配。若是你的JVM參數這樣搭配然而GC情況仍然不是很好,那么可能需要根據你的業務特色進行特別的調優:

-Xmx4g -Xms4g -Xmn1512m 

線程棧

JDK8默認的線程棧大小為1M,有點偏大。以筆者的經驗,絕大部分微服務項目是不错調整為512k,甚而256k的(筆者的項目等于256k,運行的棒棒噠):

-Xss256k 

Old回收閾值

既然建立的是CMS,那么如下兩個參數一定要加上。為什么要加上這兩個JVM參數呢?這是因為CMS回收條件极度復雜, 精品久久久无码人妻中文字幕若是欠亨過CMSInitiatingOccupancyFraction和UseCMSInitiatingOccupancyOnly松手只在老年代達到75%才回收的話(這個閾值不错根據具體情況適當調整),當線上际遇一些CMS GC時,是很難搞了了原因的:

-XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly 

CMS GC觸發條件相關著作推薦--【JVM 源碼解讀之 CMS GC 觸發條件】:https://mp.weixin.qq.com/s/Mu-Xz4CLgdxJhcMJ7aKAHg

元數據空間

若是是微服務架構,那么對于絕大部分應用來說,128M的元數據整个夠用。不過,JDK8的元數據空間并不是指定若干就驱动化多大的空間。而是按需擴展元數據空間。是以,我們不错設置256M。若是不設置這兩個參數的話,元數據空間默認驱动化唯有20M出頭,那么就會在應用啟動過程中,Metaspace擴容發生FGC:

-XX:MaxMetaspaceSize=256m -XX:MetaspaceSize=256M 

dump路徑

設定如下兩個參數(需要說明的是,HeapDumpPath參數指定的路徑需要提前創建好,JVM沒辦法在生成dump文献時創建該目錄),當JVM內存導致導致JVM進程退出時能自動在該目錄下生成dump文献:

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/log/jvmdump/ 

GC日记

這個必須有,否则線上環境GC問題都不好排查。而且loggc地点目錄(/data/log/gclog/)和dump路徑一樣,必須提前創建好,JVM無法自動創建該目錄:

-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/data/log/gclog/gc.log 

壓縮

我們都知晓,CMS GC是并發的垃圾回收器,它选拔的是標記铲除算法,亚洲大尺度无码专区尤物而不是壓縮算法。意味著隨著時間的推移,碎屑會越來越多,JVM終究會觸發內存整理這個動作。那么,什么時候整理內存碎屑呢?跟底下兩個參數有很大的關系。第一個參數是開啟這個才能,第二個參數示意在壓縮(compaction)內存之前需要發生若干次不壓縮內存的FGC。CMS GC不是FGC,在CMS GC搞不定的時候(比如:concurrent mode failure),會觸發整个STW但不壓縮內存的FGC(假设定名為NoCompactFGC),或者觸發整个STW而且壓縮內存的FGC(假设定名為CompactFGC)。是以,這個參數的敬爱敬爱等于,連續若干次NoCompactFGC后觸發CompactFGC。若是中間出現了CMS GC,那么又需要再行計數NoCompactFGC發生的次數:

-XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 

CMS回收條件推薦著作--[JVM 源碼解讀之 CMS 何時會進行 Full GC]:https://mp.weixin.qq.com/s/zn3-9e7ZZ7skLo1XDL0xww

筆者這里給出的建立事實上是默認值,即每次CMS GC搞不定的情況下觸發CompactFGC。這兩個參數很不好邻接,為此,筆者舉幾個例子,假设有3種GC花式:CMS GC,NoCompactFGC, CompactFGC(如下時yi du a):

if(should_compact){     // mark-sweep-compact     do_compaction_work(clear_all_soft_refs)  } else {        // mark-sweep     do_mark_sweep_work(clear_all_soft_refs,first_state,should_start_over); } 

NoCompactFGC等于不壓縮內存的FGC,选拔的是標記铲除(Mark-Sweep)算法,CompactFGC是會壓縮內存的FGC,选拔的是標記铲除壓縮算法(Mark Sweep Compact),然后假設我們建立了-XX:CMSFullGCsBeforeCompaction=3,那么:

1、CMS GC, NoCompactFGC, NoCompactFGC, NoCompactFGC, CompactFGC(這時候若是發生FGC就會壓縮內存) 2、CMS GC, NoCompactFGC, NoCompactFGC, CMS GC, NoCompactFGC(這時候若是發生FGC不會壓縮內存,因為在此之前并沒有連續3次NoCompactFGC) 3、CMS GC, CMS GC, CMS GC, NoCompactFGC(若是前边連續發生的是CMS GC,那么接下來觸發的FGC還不會壓縮內存) 

one more

终末,再推薦給众人一個搭配CMS時很好用的JVM參數,如下所示。官方對該參數的說明為:A System.gc() request invokes a concurrent collection and also unloads classes during such a concurrent gc cycle (effective only when UseConcMarkSweepGC)。這句話總結如下:1、唯有在使用CMS時才灵验。2、當調用System.gc()時會用CMS這個并行垃圾回收器去進行回收(比如大批使用DirectByteBuffer進行堆外內存操作,需要FGC來回收堆外內存的場景。就不错通過該參數讓本來需要FGC才能惩处的事情用CMS GC就不错惩处了)。3、除了能喚起并行垃圾回收器,還能卸載類。

-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses 

最終,得回我們建立的完好的JVM參數建立如下(此參數在过去筆者負責的一個微服務項目中運行了數年,單機并發1000+,CMS GC大要是8天傍边一次):

-Xms4g -Xmx4g -Xmn1512m -server -Xss256k -XX:MetaspaceSize=256M  -XX:MaxMetaspaceSize=256m -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/data/log/gclog/gc.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/log/jvmdump/ -XX:+UseConcMarkSweepGC -XX:+UseParNewGC  -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:+CMSClassUnloadingEnabled -XX:+TieredCompilation  -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses 

终末,筆者再介紹一個很好的校驗JVM參數的網址:https://opts.console.heapdump.cn/,這里我們不错用到它的“參數檢查”。不過需要說明的是:盡信書不如不讀書,此網址的校驗結果仅仅作為參考,是否整个适合你的生產環境,還得視情況而定,畢竟JVM調優可不是一件簡單的事情:

 本文轉載自微信公眾號「阿飛的博客」,不错通過以下二維碼關注。轉載本文請聯系阿飛的博客公眾號。

 



栏目分类



Powered by 12一14幻女bbwxxxx在线播放 @2013-2022 RSS地图 HTML地图