海量連接服務端jvm參數調優雜記

原創 zhg_vincent 2019-05-15 09:53

原文鏈接 https://mp.weixin.qq.com/s/v_yjOv7EQaf4gKBnrDMUHw

應用：shark-美團點評移動端長連代理，每日接受移動端請求約150億

應用特點：

  1.  QPS比較高，新生代增長飛快

  2. 用戶的連接需要維持一段時間

  3. 單機需要維持海量連接，大概在幾十萬的級別

以上三個特點導致有大量小對象聚集在old區，高峯期old區域增長非常快，對象在一段時間內必然消亡

初始的線上gc的情況如下（備註：相關截圖來自點評的APM軟件CAT：https://github.com/dianping/cat）：

對應的jvm參數爲

 

-Xms10g -Xmx10g -Xss512k -XX:PermSize=384m -XX:MaxPermSize=384m -XX:NewSize=7g -XX:MaxNewSize=7g
-XX:SurvivorRatio=8 -XX:MaxDirectMemorySize=4g -XX:+UseParNewGC -XX:ParallelGCThreads=4
-XX:MaxTenuringThreshold=9 -XX:+UseConcMarkSweepGC -XX:+DisableExplicitGC 
-XX:+UseCMSInitiatingOccupancyOnly -XX:+ScavengeBeforeFullGC -XX:+UseCMSCompactAtFullCollection 
-XX:+CMSParallelRemarkEnabled -XX:CMSFullGCsBeforeCompaction=9 -XX:CMSInitiatingOccupancyFraction=70

可以看到新生代爲7G（其中Survivor爲7G*1/10=700M），老年代爲3G，對象最大的年齡居然只有9（-XX:MaxTenuringThreshold=9，導致new 區域進入到old區域的速度太快，old區域很快被撐滿，頻繁old gc），考慮到我這邊的對象在一段時間內（幾分鐘）肯定會消亡，於是先進行一次調優嘗試。

第一次調優

將年齡調到非常大，並且調大整個堆和young區，對應的jvm參數爲

-Xms14g -Xmx14g -Xss512k -XX:PermSize=384m -XX:MaxPermSize=384m -XX:NewSize=12g -XX:MaxNewSize=12g
-XX:SurvivorRatio=18 -XX:MaxDirectMemorySize=2g -XX:+UseParNewGC -XX:ParallelGCThreads=4
-XX:MaxTenuringThreshold=30 -XX:+UseConcMarkSweepGC -XX:+DisableExplicitGC-XX:+UseCMSInitiatingOccupancyOnly 
-XX:+ScavengeBeforeFullGC -XX:+UseCMSCompactAtFullCollection -XX:+CMSParallelRemarkEnabled 
-XX:CMSFullGCsBeforeCompaction=9 -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSClassUnloadingEnabled 
-XX:SoftRefLRUPolicyMSPerMB=0 -XX:-ReduceInitialCardMarks -XX:+CMSPermGenSweepingEnabled 
-XX:CMSInitiatingPermOccupancyFraction=70

結果old區域一直爲空，但是yong gc時間拉長許多，平均每次都要0.2s的時間，比之前的young gc多了整整三倍，這是無法接受的：

關於參數-XX:MaxTenuringThreshold：

在jdk1.7某個版本之前設置大於15表示是無窮大，即對象長命百歲，之後不管設置成多少，都是15，jdk1.8之後大於15直接報錯 見 http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2008-May/000309.html

第二次調優

將XX:MaxTenuringThreshold調整成15，由於之前cms 在old gc花的時間比較多，所以這裏嘗試serial old gc，對應的jvm參數爲：

-Xms14g -Xmx14g -Xss512k -XX:PermSize=384m -XX:MaxPermSize=384m -XX:NewSize=12g -XX:MaxNewSize=12g
 -XX:SurvivorRatio=18 -XX:MaxDirectMemorySize=2g -XX:+UseParNewGC -XX:ParallelGCThreads=4 
 -XX:MaxTenuringThreshold=15

發現效果確實比較明顯，new gc的時間縮小了兩倍左右，並且old gc的時間也從原來的15000ms 縮小到1500ms

第三次調優

仔細研究了一下第二種調優方式的組合，yong區域使用parNew 的方式，old區域使用serial old 的方式，如果在其他條件都相同的條件下使用parNew+cms的方式，old gc的時間會不會大幅度縮短？畢竟cms還是比較先進的收集器，於是分析了一下cms的幾個階段，有兩個階段是stop the world的，一個是初始化標記（intial mark），一個是重複標記（remark)，重複標記的原因是併發標記階段可能很多對象的狀態都產生了變化，所以這個時候需要再次暫停用戶所有的線程。

查看gc日誌，發現remark的時間比較長，日誌上下文如下

{Heap before GC invocations=23679 (full 18):

par new generation   total 6606080K, used 5902124K [0x0000000568000000, 0x0000000728000000, 0x0000000728000000)

eden space 5872128K,  99% used [0x0000000568000000, 0x00000006ce54f988, 0x00000006ce680000)

from space 733952K,   4% used [0x00000006fb340000, 0x00000006fd1bb758, 0x0000000728000000)

to   space 733952K,   0% used [0x00000006ce680000, 0x00000006ce680000, 0x00000006fb340000)

concurrent mark-sweep generation total 3145728K, used 2200878K [0x0000000728000000, 0x00000007e8000000, 0x00000007e8000000)

concurrent-mark-sweep perm gen total 393216K, used 37361K [0x00000007e8000000, 0x0000000800000000, 0x0000000800000000)

2016-08-27T17:26:00.058+0800: 261980.413: [GC2016-08-27T17:26:00.058+0800: 261980.413: [ParNew: 5902124K->27858K(6606080K), 0.0464930 secs] 8103002K->2230601K(9751808K), 0.0468010 secs] [Times: user=0.18 sys=0.00, real=0.05 secs]

Heap after GC invocations=23680 (full 18):

par new generation   total 6606080K, used 27858K [0x0000000568000000, 0x0000000728000000, 0x0000000728000000)

eden space 5872128K,   0% used [0x0000000568000000, 0x0000000568000000, 0x00000006ce680000)

from space 733952K,   3% used [0x00000006ce680000, 0x00000006d01b4910, 0x00000006fb340000)

to   space 733952K,   0% used [0x00000006fb340000, 0x00000006fb340000, 0x0000000728000000)

concurrent mark-sweep generation total 3145728K, used 2202742K [0x0000000728000000, 0x00000007e8000000, 0x00000007e8000000)

concurrent-mark-sweep perm gen total 393216K, used 37361K [0x00000007e8000000, 0x0000000800000000, 0x0000000800000000)

}

2016-08-27T17:26:00.107+0800: 261980.462: Application time: 0.0014750 seconds

2016-08-27T17:26:00.108+0800: 261980.463: [GC [1 CMS-initial-mark: 2202742K(3145728K)] 2235571K(9751808K), 0.0561400 secs] [Times: user=0.05 sys=0.00, real=0.05 secs]

2016-08-27T17:26:00.165+0800: 261980.520: [CMS-concurrent-mark-start]

2016-08-27T17:26:00.918+0800: 261981.273: [CMS-concurrent-mark: 0.753/0.754 secs] [Times: user=1.27 sys=0.12, real=0.76 secs]

2016-08-27T17:26:00.918+0800: 261981.273: [CMS-concurrent-preclean-start]

2016-08-27T17:26:00.949+0800: 261981.304: [CMS-concurrent-preclean: 0.028/0.031 secs] [Times: user=0.04 sys=0.01, real=0.03 secs]

2016-08-27T17:26:00.949+0800: 261981.304: [CMS-concurrent-abortable-preclean-start]

CMS: abort preclean due to time 2016-08-27T17:26:06.159+0800: 261986.514: [CMS-concurrent-abortable-preclean: 5.197/5.210 secs] [Times: user=8.31 sys=0.66, real=5.21 secs]

2016-08-27T17:26:06.160+0800: 261986.515: Application time: 5.9951640 seconds

2016-08-27T17:26:06.161+0800: 261986.516: [GC[YG occupancy: 4756927 K (6606080 K)]

2016-08-27T17:26:06.161+0800: 261986.516: [Rescan (parallel) , 18.1621480 secs]
2016-08-27T17:26:24.323+0800: 262004.678: [weak refs processing, 0.0000750 secs

2016-08-27T17:26:24.323+0800: 262004.678: [class unloading, 0.0069760 secs

2016-08-27T17:26:24.330+0800: 262004.685: [scrub symbol table, 0.0040020 secs

2016-08-27T17:26:24.334+0800: 262004.689: [scrub string table, 0.0009240 secs] [1 CMS-remark: 2202742K(3145728K)] 6959670K(9751808K), 18.1769610 secs] [Times: user=71.37 sys=0.06, real=18.18 secs]

2016-08-27T17:26:24.338+08002016-08-27T17:26:24.338+0800: : 262004.693: Application time: 0.0002080 seconds

262004.693: [CMS-concurrent-sweep-start]

2016-08-27T17:26:24.347+0800: 262004.702: Application time: 0.0079820 seconds

2016-08-27T17:26:24.868+0800: 262005.223: Application time: 0.5186580 seconds

{Heap before GC invocations=23680 (full 19):

par new generation   total 6606080K, used 5899299K [0x0000000568000000, 0x0000000728000000, 0x0000000728000000)

eden space 5872128K,  99% used [0x0000000568000000, 0x00000006ce5d44b8, 0x00000006ce680000)

from space 733952K,   3% used [0x00000006ce680000, 0x00000006d01b4910, 0x00000006fb340000)

to   space 733952K,   0% used [0x00000006fb340000, 0x00000006fb340000, 0x0000000728000000)

concurrent mark-sweep generation total 3145728K, used 1891716K [0x0000000728000000, 0x00000007e8000000, 0x00000007e8000000)

concurrent-mark-sweep perm gen total 393216K, used 37361K [0x00000007e8000000, 0x0000000800000000, 0x0000000800000000)

2016-08-27T17:26:24.870+0800: 262005.225: [GC2016-08-27T17:26:24.870+0800: 262005.225: [ParNew: 5899299K->56108K(6606080K), 0.0580910 secs] 7791015K->1949708K(9751808K), 0.0584000 secs] [Times: user=0.22 sys=0.01, real=0.05 secs]

Heap after GC invocations=23681 (full 19):

par new generation   total 6606080K, used 56108K [0x0000000568000000, 0x0000000728000000, 0x0000000728000000)

eden space 5872128K,   0% used [0x0000000568000000, 0x0000000568000000, 0x00000006ce680000)

from space 733952K,   7% used [0x00000006fb340000, 0x00000006fea0b1f8, 0x0000000728000000)

to   space 733952K,   0% used [0x00000006ce680000, 0x00000006ce680000, 0x00000006fb340000)

concurrent mark-sweep generation total 3145728K, used 1893599K [0x0000000728000000, 0x00000007e8000000, 0x00000007e8000000)

concurrent-mark-sweep perm gen total 393216K, used 37361K [0x00000007e8000000, 0x0000000800000000, 0x0000000800000000)

}

重新標記居然用了18s(對應這一段GC日誌：[1 CMS-remark: 2202742K(3145728K)] 6959670K(9751808K), 18.1769610 secs]，另外，由於是多核心CPU的服務器，所以Times的real要遠小於user的值，這個remark階段是多線程並行的)！重新標記的時候，old區域的大小是固定的(這裏設置成old區域的70%)，按理說每次remark的時間應該都差不多才對，但是查了很多cms old gc日誌，發現高峯期和低峯期remark的時間相差太大，兩者的區別也只有eden區域，因爲我這裏eden的設置是比較大的，高峯期的時候，一次cms old從初始化標記開始，到remark之間，即併發標記階段，用戶程序會和gc線程是併發執行的。另外，由於我們程序的TPS比較高，我們再看一下GC日誌，整個併發階段的時間跨度爲從2016-08-27T17:26:00.165+0800到2016-08-27T17:26:24.330+0800，總計24秒左右，那麼，這個過程中肯定會新產生大量的新的對象。

如果remark之前能把eden區域的對象都清理一遍，那remark時，需要掃描的對象將會少很多很多對吧？cms正好有這麼個參數-XX:+CMSScavengeBeforeRemark，這玩意的意思是在remark之前，來一次yong gc，恰好滿足我們的要求，加了這個參數之後，對應的jvm參數爲：

-Xms14g -Xmx14g -Xss512k -XX:PermSize=384m -XX:MaxPermSize=384m -XX:NewSize=12g -XX:MaxNewSize=12g
-XX:SurvivorRatio=18 -XX:MaxDirectMemorySize=2g -XX:+UseParNewGC -XX:ParallelGCThreads=4 
-XX:MaxTenuringThreshold=15  -XX:+CMSScavengeBeforeRemark -XX:+UseConcMarkSweepGC -XX:+DisableExplicitGC
-XX:+UseCMSInitiatingOccupancyOnly -XX:+ScavengeBeforeFullGC -XX:+UseCMSCompactAtFullCollection
-XX:+CMSParallelRemarkEnabled -XX:CMSFullGCsBeforeCompaction=9 -XX:CMSInitiatingOccupancyFraction=70

效果如下：

發現old gc的時間縮小到原來cms的1/100，竊喜。接下來分析gc日誌，來驗證我的猜想

{Heap before GC invocations=4644 (full 6):

 par new generation   total 11953792K, used 11384636K [0x0000000468000000, 0x0000000768000000, 0x0000000768000000)

  eden space 11324672K,  99% used [0x0000000468000000, 0x000000071b30eb48, 0x000000071b340000)

  from space 629120K,   9% used [0x000000071b340000, 0x000000071ee004e0, 0x00000007419a0000)

  to   space 629120K,   0% used [0x00000007419a0000, 0x00000007419a0000, 0x0000000768000000)

 concurrent mark-sweep generation total 2097152K, used 1464467K [0x0000000768000000, 0x00000007e8000000, 0x00000007e8000000)

 concurrent-mark-sweep perm gen total 393216K, used 37291K [0x00000007e8000000, 0x0000000800000000, 0x0000000800000000)

2016-08-28T10:46:09.846+0800: 68434.688: [GC2016-08-28T10:46:09.846+0800: 68434.688: [ParNew: 11384636K->61763K(11953792K), 0.0716150 secs] 12849103K->1528727K(14050944K), 0.0719060 secs] [Times: user=0.28 sys=0.00, real=0.07 secs]

Heap after GC invocations=4645 (full 6):

 par new generation   total 11953792K, used 61763K [0x0000000468000000, 0x0000000768000000, 0x0000000768000000)

  eden space 11324672K,   0% used [0x0000000468000000, 0x0000000468000000, 0x000000071b340000)

  from space 629120K,   9% used [0x00000007419a0000, 0x00000007455f0dd8, 0x0000000768000000)

  to   space 629120K,   0% used [0x000000071b340000, 0x000000071b340000, 0x00000007419a0000)

 concurrent mark-sweep generation total 2097152K, used 1466964K [0x0000000768000000, 0x00000007e8000000, 0x00000007e8000000)

 concurrent-mark-sweep perm gen total 393216K, used 37291K [0x00000007e8000000, 0x0000000800000000, 0x0000000800000000)

}

2016-08-28T10:46:19.590+0800: 68444.431: Application time: 9.6715460 seconds

{Heap before GC invocations=4645 (full 6):

 par new generation   total 11953792K, used 11384705K [0x0000000468000000, 0x0000000768000000, 0x0000000768000000)

  eden space 11324672K,  99% used [0x0000000468000000, 0x000000071b18f768, 0x000000071b340000)

  from space 629120K,   9% used [0x00000007419a0000, 0x00000007455f0dd8, 0x0000000768000000)

  to   space 629120K,   0% used [0x000000071b340000, 0x000000071b340000, 0x00000007419a0000)

 concurrent mark-sweep generation total 2097152K, used 1466964K [0x0000000768000000, 0x00000007e8000000, 0x00000007e8000000)

 concurrent-mark-sweep perm gen total 393216K, used 37291K [0x00000007e8000000, 0x0000000800000000, 0x0000000800000000)

2016-08-28T10:46:19.591+0800: 68444.433: [GC2016-08-28T10:46:19.591+0800: 68444.433: [ParNew: 11384705K->69180K(11953792K), 0.0728020 secs] 12851669K->1538700K(14050944K), 0.0730170 secs] [Times: user=0.27 sys=0.01, real=0.07 secs]

Heap after GC invocations=4646 (full 6):

 par new generation   total 11953792K, used 69180K [0x0000000468000000, 0x0000000768000000, 0x0000000768000000)

  eden space 11324672K,   0% used [0x0000000468000000, 0x0000000468000000, 0x000000071b340000)

  from space 629120K,  10% used [0x000000071b340000, 0x000000071f6cf378, 0x00000007419a0000)

  to   space 629120K,   0% used [0x00000007419a0000, 0x00000007419a0000, 0x0000000768000000)

 concurrent mark-sweep generation total 2097152K, used 1469519K [0x0000000768000000, 0x00000007e8000000, 0x00000007e8000000)

 concurrent-mark-sweep perm gen total 393216K, used 37291K [0x00000007e8000000, 0x0000000800000000, 0x0000000800000000)

}

2016-08-28T10:46:19.666+0800: 68444.508: Application time: 0.0019110 seconds

2016-08-28T10:46:19.667+0800: 68444.509: [GC [1 CMS-initial-mark: 1469519K(2097152K)] 1545525K(14050944K), 0.0869600 secs] [Times: user=0.09 sys=0.00, real=0.08 secs]

2016-08-28T10:46:19.755+0800: 68444.597: [CMS-concurrent-mark-start]

2016-08-28T10:46:20.418+0800: 68445.260: [CMS-concurrent-mark: 0.663/0.663 secs] [Times: user=1.47 sys=0.24, real=0.66 secs]

2016-08-28T10:46:20.418+0800: 68445.260: [CMS-concurrent-preclean-start]

2016-08-28T10:46:20.438+0800: 68445.280: [CMS-concurrent-preclean: 0.018/0.020 secs] [Times: user=0.04 sys=0.01, real=0.02 secs]

2016-08-28T10:46:20.438+0800: 68445.280: [CMS-concurrent-abortable-preclean-start]

2016-08-28T10:46:24.542+0800: 68449.384: [CMS-concurrent-abortable-preclean: 4.090/4.104 secs] [Times: user=8.60 sys=1.40, real=4.10 secs]

2016-08-28T10:46:24.543+0800: 68449.385: Application time: 4.7880220 seconds


// 這裏在remark之前進行一次young gc

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝yong gc開始＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

2016-08-28T10:46:24.544+0800: 68449.386: [GC[YG occupancy: 5803756 K (11953792 K)]{Heap before GC invocations=4646 (full 7):

 par new generation   total 11953792K, used 5803756K [0x0000000468000000, 0x0000000768000000, 0x0000000768000000)

  eden space 11324672K,  50% used [0x0000000468000000, 0x00000005c602bd88, 0x000000071b340000)

  from space 629120K,  10% used [0x000000071b340000, 0x000000071f6cf378, 0x00000007419a0000)

  to   space 629120K,   0% used [0x00000007419a0000, 0x00000007419a0000, 0x0000000768000000)

 concurrent mark-sweep generation total 2097152K, used 1469519K [0x0000000768000000, 0x00000007e8000000, 0x00000007e8000000)

 concurrent-mark-sweep perm gen total 393216K, used 37291K [0x00000007e8000000, 0x0000000800000000, 0x0000000800000000)

2016-08-28T10:46:24.544+0800: 68449.386: [GC2016-08-28T10:46:24.544+0800: 68449.386: [ParNew: 5803756K->70533K(11953792K), 0.0668770 secs] 7273276K->1542365K(14050944K), 0.0669610 secs] [Times: user=0.25 sys=0.01, real=0.07 secs]

Heap after GC invocations=4647 (full 7):

 par new generation   total 11953792K, used 70533K [0x0000000468000000, 0x0000000768000000, 0x0000000768000000)

  eden space 11324672K,   0% used [0x0000000468000000, 0x0000000468000000, 0x000000071b340000)

 from space 629120K,  11% used [0x00000007419a0000, 0x0000000745e81738, 0x0000000768000000)

  to   space 629120K,   0% used [0x000000071b340000, 0x000000071b340000, 0x00000007419a0000)

 concurrent mark-sweep generation total 2097152K, used 1471831K [0x0000000768000000, 0x00000007e8000000, 0x00000007e8000000)

 concurrent-mark-sweep perm gen total 393216K, used 37291K [0x00000007e8000000, 0x0000000800000000, 0x0000000800000000)

}

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝yong gc結束,開始remark＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝


2016-08-28T10:46:24.611+0800: 68449.453: [Rescan (parallel) , 0.0392690 secs]

2016-08-28T10:46:24.650+0800: 68449.492: [weak refs processing, 0.0001190 secs

2016-08-28T10:46:24.650+0800: 68449.492: [class unloading, 0.0072200 secs]

2016-08-28T10:46:24.658+0800: 68449.500: [scrub symbol table, 0.0083430 secs]
2016-08-28T10:46:24.666+0800: 68449.508: [scrub string table, 0.0011760 secs] [1 CMS-remark: 1471831K(2097152K)] 1542365K(14050944K), 0.1264420 secs] [Times: user=0.42 sys=0.01, real=0.13 secs]

2016-08-28T10:46:24.671+0800: 68449.513: [CMS-concurrent-sweep-start]

2016-08-28T10:46:24.672+0800: 68449.514: Application time: 0.0018070 seconds

2016-08-28T10:46:26.388+0800: 68451.230: [CMS-concurrent-sweep: 1.714/1.717 secs] [Times: user=3.70 sys=0.58, real=1.72 secs]

2016-08-28T10:46:26.388+0800: 68451.230: [CMS-concurrent-reset-start]

2016-08-28T10:46:26.396+0800: 68451.238: [CMS-concurrent-reset: 0.007/0.007 secs] [Times: user=0.02 sys=0.00, real=0.01 secs]

2016-08-28T10:46:34.434+0800: 68459.276: Application time: 9.7600810 seconds

可以看到，在remark之前，來一次yong gc，eden區域從5803756k降到70533k，給這個清理效果點個贊。這些空間如果不消除，那麼cms將會在這些空間上進行非常耗時的標記，最後再看看remark的時間（[1 CMS-remark: 1471831K(2097152K)] 1542365K(14050944K), 0.1264420 secs]），降到0.1264420s，和原來相比，整整一百倍的提高。

總結：

最後，對於長連接，push一類的海量服務端應用，16G內存8核心，推薦的JVM參數如下（僅供參考）：

jdk1.7

-Xms13g -Xmx13g -Xss512k -XX:PermSize=384m -XX:MaxPermSize=384m -XX:NewSize=12g -XX:MaxNewSize=12g
-XX:SurvivorRatio=18 -XX:MaxDirectMemorySize=2g -XX:+UseParNewGC -XX:ParallelGCThreads=4 
-XX:MaxTenuringThreshold=15 -XX:+CMSParallelRemarkEnabled -XX:+CMSScavengeBeforeRemark
-XX:+UseConcMarkSweepGC -XX:+DisableExplicitGC -XX:+UseCMSInitiatingOccupancyOnly 
-XX:CMSInitiatingOccupancyFraction=70 -XX:+ScavengeBeforeFullGC -XX:+UseCMSCompactAtFullCollection 
-XX:CMSFullGCsBeforeCompaction=9 -XX:+CMSClassUnloadingEnabled  -XX:CMSInitiatingPermOccupancyFraction=70 
-XX:+ExplicitGCInvokesConcurrent -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCApplicationConcurrentTime 
-XX:+PrintHeapAtGC -Xloggc:/data/applogs/heap_trace.txt -XX:-HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/data/applogs/HeapDumpOnOutOfMemoryError

jdk1.8

-Xms13g -Xmx13g -Xss512k -XX:MetaspaceSize=384m -XX:MaxMetaspaceSize=384m -XX:NewSize=11g -XX:MaxNewSize=11g
-XX:SurvivorRatio=18 -XX:MaxDirectMemorySize=2g -XX:+UseParNewGC -XX:ParallelGCThreads=4
-XX:MaxTenuringThreshold=15 -XX:+UseConcMarkSweepGC -XX:+DisableExplicitGC -XX:+UseCMSInitiatingOccupancyOnly
-XX:+ScavengeBeforeFullGC -XX:+CMSScavengeBeforeRemark -XX:+CMSParallelRemarkEnabled 
-XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSClassUnloadingEnabled -XX:SoftRefLRUPolicyMSPerMB=0
-XX:-ReduceInitialCardMarks -XX:+CMSClassUnloadingEnabled -XX:+ExplicitGCInvokesConcurrent -XX:+PrintGCDetails
-XX:+PrintGCDateStamps -XX:+PrintGCApplicationConcurrentTime -XX:+PrintHeapAtGC -Xloggc:/data/applogs/heap_trace.txt 
-XX:-HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/applogs/HeapDumpOnOutOfMemoryError

這樣可以保證大多數對象在young區域就能被銷燬，即使一些對象到了old區，也會被在remark之前yong gc清理掉，從而儘可能降低cms gc的remark這個需要完全STW的階段的時間消耗。

發表評論
所有評論
還沒有人評論，想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章

JVM類加載機制入門

java 運行類的入口是mian方法,主類在運行的時候加載其他的類,加載的時候,會優先加載父類.靜態方法優先於構造方法先執行. jar包或war包裏的類不是一次性全部加載的，是使用到時才加載。 package com.bonc.j

踏雪江南 2020-07-08 12:23:41

類加載和類實例化

Java程序中對類的使用方式分爲兩類 ：主動使用和被動使用 主動使用： 創建類的實例 訪問某個類或接口的靜態變量，或者對該靜態變量賦值 調用類的靜態方法 反射 初始化一個類的子類 java虛擬機啓動時被標明爲啓動類的類 從JDK

吃酒忘情殇 2020-07-08 12:36:21

JVM之自定義類加載器入門

在上一篇博客中寫到雙親委派機制.傳送門 瞭解完雙親委派機制那麼對JVM類加載器原理有一定的瞭解,那麼書寫定義類加載加載器就不會太難了.主要是重寫ClassLoader中findClass方法 這個方法主要是根據包名查找class文

踏雪江南 2020-07-08 12:23:41

jvm雙親委派機制之打破雙親委派機制

在上一篇博客中介紹了一下如何書寫自定義加載器.傳送門 這一篇要介紹的就是自定義類加載器來打破雙親委派機制. 思路就是加載類的時候不走parent屬性來找,直接從指定的classpath中找 package com.bonc.jvm

踏雪江南 2020-07-08 12:23:41

jvm雙親委派機制

JVM整體流程如上圖所示.java類的加載是有加載器來進行的.JVM中有以下幾種類加載器: 1.引導類加載器BootstrapClassLoader :負責加載支撐JVM運行的位於JRE的lib目錄核心類庫,比如rt.jar,c

踏雪江南 2020-07-08 12:23:41

深入淺出 Java 虛擬機（五）G1 垃圾回收器

本文章爲《深入淺出 Java 虛擬機》系列課程學習筆記，侵刪。學習地址爲 深入淺出 Java 虛擬機 1 CMS 垃圾回收器存在的問題 以下場景很極端，但卻經常發生。 在發生 Minor GC 時，由於 Survivor 區已

Geffin 2020-07-08 10:04:53

深入淺出 Java 虛擬機（六）大流量高併發下的調優

本文章爲《深入淺出 Java 虛擬機》系列課程學習筆記，侵刪。學習地址爲 深入淺出 Java 虛擬機 1 引言 垃圾回收器一般使用默認參數，就可以比較好的運行。但如果用錯了某些參數，那麼後果可能會比較嚴重。 如果你的應用程序目

Geffin 2020-07-08 10:04:52

JVM內存N個問題的最全解析

推薦閱讀：爲了阿里巴巴的P7offer，我籌備了半年，四面之後終於成功拿下                   面試阿里（P8）竟被MySQL難倒，奮發圖強二次面試斬獲阿里offer                   爲面阿里P8，我肝

mrchaochao 2020-07-08 10:00:46

面試，JVM總掛？阿里架構大牛：爭氣點，“路”都給你指出來了

Java後端，三年經驗，剛面完一波大廠，明顯感覺要求跟往年不同，尤其是在JVM方面。 往年面試，圍繞JVM的一般都以理論問題居多，譬如： 畫圖解釋一下，一個對象在JVM中是如何分配，如何流轉的？ 什麼情況下JVM內存中的一個對象會被垃圾回

mrchaochao 2020-07-08 10:00:46

問題解決：遇到tomcat的假死問題，如何排查問題

文章目錄問題場景問題環境問題原因排查過程查看tomcat的gc情況排查內存泄露問題HashMap死鎖CLOSE_WAIT過多情況總結參考鏈接參考圖JVM結構TCP的三次握手和四次揮手隨緣求贊 問題場景 線上，有時候會遇到一種這樣的

ldx2 2020-07-08 09:08:50

GC算法原理

JVM 垃圾回收原理   對於JVM的垃圾收集（GC），這是一個作爲Java開發者必須瞭解的內容，那麼，我們需要去了解哪些內容呢，其實，GC主要是解決下面的三個問題： 哪些內存需要回收？ 什麼時候回收？ 如何回收？

简烦 2020-07-08 07:25:51

【Java基礎】 JVM、JRE、JDK三者關係

Java版本 （ Java主要有三個版本） JavaSE：（簡稱J2SE）Java標準版，是所有Java的技術核心和基礎，也是學習Java語言的基礎，此版本主要用於開發桌面應用（C/S）程序。 JavaEE：（簡稱J2EE）Jav

赤澳魚蛋 2020-07-08 07:08:47

Spring嵌套事務失效的問題

直接上代碼 @Transactional public void methodA() { try { methodB(); } catch (Exception e) { e.printStackTrace();

cap423654 2020-07-08 06:59:29

Redis分佈式鎖注意點

死鎖 爲了防止死鎖，必須設置過期時間 例如：線程A拿到鎖，還沒有解鎖，程序突然掛掉，鎖一直存在，其他線程一直拿不到鎖。所以要設置過期時間 加鎖跟解鎖必須是同一個線程，保證原子性 例如：線程A拿到鎖，業務還沒有處理完成，鎖已經超時被

cap423654 2020-07-08 06:59:29

Redis緩存設計原則

  緩存熱數據 緩存讀寫順序：讀，先緩存，後數據庫；寫，先數據庫，後緩存 所有緩存數據都應該設置過期時間 緩存的過期時間應該避免集中過期，造成緩存擊穿 緩存key具備可讀性，應避免不同業務出現同名的key，簡單縮寫可節省內存空間 避免緩存

cap423654 2020-07-08 06:59:29