JVM調優分享

面試精選集，快快前往領取吧！ offer.liangsonghua.me/。關注微信公衆號：松花皮蛋的黑板報，獲取更多精彩！

一. 默認配置

配置及說明：

-Djava.library.path=/usr/local/lib-server -Xms6144m-Xmx6144m-XX:MaxPermSize=256m-Dsun.net.client.defaultConnectTimeout=60000-Dsun.net.client.defaultReadTimeout=60000-Dnetworkaddress.cache.ttl=300-Dsun.net.inetaddr.ttl=300

-Djava.library.path

指定非java類包的位置（如：dll，so）。

-server

若是tomcat是運行在生產環境中的，這個參數必須加上,-server參數可使tomcat以server模式運行,這個模式下將擁有：更大、更高的併發處理能力，更快更強捷的JVM垃圾回收機制，能夠有更大的負載與吞吐量。

-Xms<size>和-Xmx<size>

前者表示JVM初始化堆的大小，後者表示JVM堆的最大值。通常把Xms與Xmx兩個值設成同樣是最優的作法，不然會致使jvm有較爲頻繁的GC，影響系統性能。

-XX:MaxPermSize=256m

初始化JVM非堆（持久代、永久代、方法區）最大值。

-Dsun.net.client.defaultConnectTimeout=60000

鏈接創建超時設置。

-Dsun.net.client.defaultReadTimeout=60000

內容獲取超時設置。

-Dnetworkaddress.cache.ttl=300

jvm dns緩存超時的相關設置。

-Dsun.net.inetaddr.ttl=300

jvm dns緩存超時的相關設置。

二. 調整GC策略

背景：

線上頻繁發生報警（堆內存佔用超過80%），建立dump文件並分析發現，大量數據爲char[]、String等類型，主要爲業務模塊產生的臨時數據，以mybatis查詢緩存字符串爲主，無大對象，過段時間full gc會自行回收（但回收量有時較大，有時較少）。考慮調整GC策略。

配置及說明：

-XX:+UseParNewGC-XX:+UseConcMarkSweepGC-XX:+CMSParallelRemarkEnabled

-XX:+UseParNewGC

設置年輕代爲並行收集。可與CMS收集同時使用。JDK5.0以上，JVM會根據系統配置自行設置，因此無需再設置此值。

-XX:+UseConcMarkSweepGC

設置年老代爲CMS併發收集。CMS流程：初始標記(CMS-initial-mark) -> 併發標記(CMS-concurrent-mark) -> 從新標記(CMS-remark) -> 併發清除(CMS-concurrent-sweep) ->併發重設狀態等待下次CMS的觸發(CMS-concurrent-reset)。

-XX:+CMSParallelRemarkEnabled

CMS開啓並行remark。

-XX:+CMSScavengeBeforeRemark

強制remark以前開始一次minor gc，減小remark的暫停時間。

-Xss

設置每一個線程的堆棧大小。JDK5.0之後每一個線程堆 棧大小爲1M，之前每一個線程堆棧大小爲256K。根據應用的線程所需內存大小進行調整。在相同物理內存下，減少這個值能生成更多的線程。可是操做系統對一 個進程內的線程數仍是有限制的，不能無限生成，經驗值在3000~5000左右。線程棧的大小是個雙刃劍，若是設置太小，可能會出現棧溢出，特別是在該線程內有遞歸、大的循環時出現溢出的可能性更大，若是該值設置過大，就有影響到建立棧的數量，若是是多線程的應用，就會出現內存溢出的錯誤。線出現過棧溢出。

三. 保底配置

背景：

線上頻繁發生報警（堆內存佔用超過80%），調大堆內存到6144m、調整GC策略後依然存在問題，分析dump文件發現主要數據爲char[]、String等類型的臨時數據，暫增長保底策略，堆內存達到70%後強制CMS GC。

配置及說明：

-XX:CMSInitiatingOccupancyFraction=70-XX:+UseCMSInitiatingOccupancyOnly

–XX:CMSInitiatingOccupancyFraction=70

堆內存使用達到70％後強制開始CMS收集。

-XX:+UseCMSInitiatingOccupancyOnly

只是用設定的回收閾值(上面指定的70%),若是不指定,JVM僅在第一次使用設定值,後續則自動調整。

四. 記錄GC日誌

背景：增長gc日誌方便後續的JVM優化分析和問題排查。

配置及說明：

-XX:+PrintGCDetails-XX:+PrintGCDateStamps-Xloggc:/export/Logs/gc.log-XX:+UseGCLogFileRotation-XX:NumberOfGCLogFiles=10-XX:GCLogFileSize=1m

-XX:+PrintGCDetails

輸出GC的詳細日誌。

-XX:+PrintGCDateStamps

輸出GC的時間戳（以日期的形式）。

-Xloggc:/export/Logs/gc.log

gc日誌文件的輸出路徑。

-XX:+UseGCLogFileRotation

打開或關閉GC日誌滾動記錄功能，要求必須設置 -Xloggc參數。

-XX:NumberOfGCLogFiles=3

設置滾動日誌文件的個數，必須大於1。

-XX:GCLogFileSize=512k

設置滾動日誌文件的大小，必須大於8k。

-XX:+PrintHeapAtGC

在進行GC的先後打印出堆的信息，該日誌輸出量較大，能夠不開啓。

五. 進一步優化

背景：

增長70%強制CMS GC配置後再也不觸發報警，但依然會在某特殊場景頻繁full gc。經過gc分析，懷疑在這種特殊場景下：內存分配過快致使不少數據在年輕代待的時間過短就進入老年代，導致老年代中不斷堆積稍後就無效的對象，最終觸發full gc。考慮增大年輕代內存、eden與survivor分配策略。

系統分析：

主要的內存消耗是業務產生的臨時性數據，這些數據業務結束後即無效，增大年輕代有助於讓這些臨時性數據減小進入老年代進而觸發full gc的機率，可是也不能一味增長年輕代，年輕代過大會影響minor gc過慢，系統吞吐量下降。

配置及說明：

-XX:NewRatio=3-XX:SurvivorRatio=4

-XX:NewRatio=3

設置老年代與新生代的比例。指定老年代OC：新生代YC爲 3：1。老年代佔堆大小的 3/4，新生代佔 1/4。

-XX:SurvivorRatio=4

年輕代中Eden區與Survivor區的大小比值。設置爲4，則表示S0C：S1C：EC=1：1：4。該配置默認爲8。增大Survivor區能夠容納更多的存活對象。這樣就會防止由於Survivor區過小致使很對存活對象尚未達到MaxTenuringThreshold閾值就直接進入老年代，潛在增大old gc的觸發頻率。

-XX:ParallelGCThreads=8

設置並行垃圾收集的線程數量。8表示每次並行垃圾收集將有8個線程執行。若是不明確設置該標誌，虛擬機將使用基於可用 (虛擬) 處理器數量計算的默認值。決定因素是由 Java Runtime。availableProcessors() 方法的返回值 N，若是 N<=8，並行垃圾收集器數=N；若是 N>8，JVM會調整算法，每超出5/8個CPU啓動一個新的線程，並行垃圾收集器數= 8 + ((N – 8) * 5/8) = 3+5*N/8。如16覈對應13線程，32覈對應23線程。當 JVM 獨佔地使用系統和處理器時使用默認設置更有意義。可是，若是有多個 JVM(或其餘耗 CPU 的系統) 在同一臺機器上運行，咱們應該使用 – XX:ParallelGCThreads 來減小垃圾收集線程數到一個適當的值。例如，若是 4 個以服務器方式運行的 JVM 同時跑在在一個具備 16 核處理器的機器上,設置 – XX:ParallelGCThreads=4 是明智的，它能使不一樣 JVM 的垃圾收集器不會相互干擾。

文章來源：www.liangsonghua.me

關注微信公衆號：松花皮蛋的黑板報，獲取更多精彩！

公衆號介紹：分享在京東工做的技術感悟，還有JAVA技術和業內最佳實踐，大部分都是務實的、能看懂的、可復現的