GC常用參數(shù)

• -Xmn -Xms -Xmx -Xss
  年輕代 最小堆 最大堆 棧空間
• -XX:+UseTLAB
  使用TLAB，默認(rèn)打開
• -XX:+PrintTLAB
  打印TLAB的使用情況
• -XX:TLABSize
  設(shè)置TLAB大小
• -XX:+DisableExplictGC
  System.gc()不管用 ，FGC
• -XX:+PrintGC
• -XX:+PrintGCDetails
• -XX:+PrintHeapAtGC
• -XX:+PrintGCTimeStamps
• -XX:+PrintGCApplicationConcurrentTime (低)
  打印應(yīng)用程序時(shí)間
• -XX:+PrintGCApplicationStoppedTime （低）
  打印暫停時(shí)長
• -XX:+PrintReferenceGC （重要性低）
  記錄回收了多少種不同引用類型的引用
• -verbose:class
  類加載詳細(xì)過程
• -XX:+PrintVMOptions
• -XX:+PrintFlagsFinal -XX:+PrintFlagsInitial
  必須會(huì)用
• -Xloggc:opt/log/gc.log
• -XX:MaxTenuringThreshold
  升代年齡，最大值15
• 鎖自旋次數(shù) -XX:PreBlockSpin 熱點(diǎn)代碼檢測參數(shù)-XX:CompileThreshold 逃逸分析 標(biāo)量替換 …
  這些不建議設(shè)置

JVM調(diào)優(yōu)第一步，了解JVM常用命令行參數(shù)

• JVM的命令行參數(shù)參考：https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html

• HotSpot參數(shù)分類

  標(biāo)準(zhǔn)： - 開頭，所有的HotSpot都支持

  非標(biāo)準(zhǔn)：-X 開頭，特定版本HotSpot支持特定命令

  不穩(wěn)定：-XX 開頭，下個(gè)版本可能取消

  java -version

  java -X

試驗(yàn)用程序：

import java.util.List; import java.util.LinkedList;public class HelloGC {public static void main(String[] args) {System.out.println("HelloGC!");List list = new LinkedList();for(;;) {byte[] b = new byte[1024*1024];list.add(b);}} }

查看默認(rèn)參數(shù)
查看GC詳細(xì)信息

一條GC信息的詳細(xì)信息如下：

關(guān)于上圖中的Times含義：在linux中的times代表：

Heap Dump的含義

eden space 5632K, 94% used [0x00000000ff980000,0x00000000ffeb3e28,0x00000000fff00000)后面的內(nèi)存地址指的是，起始地址，使用空間結(jié)束地址，整體空間結(jié)束地址

調(diào)優(yōu)實(shí)戰(zhàn)

調(diào)優(yōu)前的基礎(chǔ)概念：

吞吐量：用戶代碼時(shí)間 /（用戶代碼執(zhí)行時(shí)間 + 垃圾回收時(shí)間）

響應(yīng)時(shí)間：STW越短，響應(yīng)時(shí)間越好

所謂調(diào)優(yōu)，首先確定，追求啥？吞吐量優(yōu)先，還是響應(yīng)時(shí)間優(yōu)先？還是在滿足一定的響應(yīng)時(shí)間的情況下，要求達(dá)到多大的吞吐量…

問題：

科學(xué)計(jì)算，吞吐量。數(shù)據(jù)挖掘，thrput。吞吐量優(yōu)先的一般：（PS + PO）
響應(yīng)時(shí)間：網(wǎng)站 GUI API （1.8 G1）

什么是調(diào)優(yōu)？

根據(jù)需求進(jìn)行JVM規(guī)劃和預(yù)調(diào)優(yōu)

優(yōu)化運(yùn)行JVM運(yùn)行環(huán)境（慢，卡頓）

解決JVM運(yùn)行過程中出現(xiàn)的各種問題(不完全等同于解決OOM的問題，因?yàn)榍懊鎯身?xiàng)也很重要)

并發(fā)：

• QPS
• TPS
  淘寶雙11并發(fā)歷年最高54萬，據(jù)說12306并發(fā)比淘寶更高，號(hào)稱上百萬

調(diào)優(yōu)，從規(guī)劃開始

• 調(diào)優(yōu)，從業(yè)務(wù)場景開始，沒有業(yè)務(wù)場景的調(diào)優(yōu)都是耍流氓

• 無監(jiān)控（壓力測試，能看到結(jié)果），不調(diào)優(yōu)（可以調(diào)整業(yè)務(wù)邏輯）

• 步驟：

• 熟悉業(yè)務(wù)場景（沒有最好的垃圾回收器，只有最合適的垃圾回收器）
• 響應(yīng)時(shí)間、停頓時(shí)間 [CMS G1 ZGC] （需要給用戶作響應(yīng)）
• 吞吐量 = 用戶時(shí)間 /( 用戶時(shí)間 + GC時(shí)間) [PS]
• 選擇回收器組合
• 計(jì)算內(nèi)存需求（沒有一定之規(guī)，是經(jīng)驗(yàn)值。 1.5G -> 16G，突然卡頓了，為啥？）
• 選定CPU（預(yù)算能買到的，當(dāng)然是越高越好，CPU多核，可以多線程運(yùn)行呀）
• 設(shè)定年代大小、升級(jí)年齡
• 設(shè)定日志參數(shù)，這是Java虛擬機(jī)的參數(shù)，也可以在Tomcat里面配置，貌似是在叫catalinaoptions里面指定java日志的參數(shù)。
• -Xloggc:/opt/xxx/logs/xxx-xxx-gc-%t.log -XX:+UseGCLogFileRotation-XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=20M -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCCause
  5個(gè)日志文件，循環(huán)產(chǎn)生。生產(chǎn)環(huán)境中的日志參數(shù)一般這么設(shè)置。
  %t是生成時(shí)間的意思。
  
• 或者每天產(chǎn)生一個(gè)日志文件
• 觀察日志情況

如何根據(jù)需求進(jìn)行JVM規(guī)劃和預(yù)調(diào)優(yōu)？

有人要問你，你應(yīng)該選用多大的內(nèi)存？什么樣的垃圾回收器組合？你怎么回答？

• 案例1：垂直電商，最高每日百萬訂單，處理訂單系統(tǒng)需要什么樣的服務(wù)器配置？

  這個(gè)問題比較業(yè)余，因?yàn)楹芏嗖煌姆?wù)器配置都能支撐(1.5G 16G 都有可能啊)

  我們做一個(gè)假設(shè)吧，1小時(shí)360000個(gè)訂單。集中時(shí)間段， 100個(gè)訂單/秒，（找一小時(shí)內(nèi)的高峰期，可能是1000訂單/秒）。我們就要找到這個(gè)最高峰的時(shí)間，保證你的架構(gòu)能夠承接的住。

  大多數(shù)情況下，是靠經(jīng)驗(yàn)值，然后做壓測。

  如果非要計(jì)算的話，你預(yù)估一下，一個(gè)訂單對象產(chǎn)生需要多少內(nèi)存？512K * 1000 = 500M內(nèi)

  專業(yè)一點(diǎn)的問法：要求響應(yīng)時(shí)間在多少時(shí)間的情況下，比如100ms，我們?nèi)ヌ粢粋€(gè)市面上性價(jià)比比較高的服務(wù)器，做壓測去測試，再不行加內(nèi)存，再不行，就上云服務(wù)器…
  這樣說就OK了

• 案例2：12306遭遇春節(jié)大規(guī)模搶票應(yīng)該如何支撐？（這個(gè)是架構(gòu)上的一個(gè)設(shè)計(jì)，和調(diào)優(yōu)關(guān)系不大）

  12306應(yīng)該是中國并發(fā)量最大的秒殺網(wǎng)站：號(hào)稱并發(fā)量最高100W

  架構(gòu)模型：CDN -> LVS -> NGINX -> 業(yè)務(wù)系統(tǒng) -> 100臺(tái)機(jī)器，每臺(tái)機(jī)器1W并發(fā)（單機(jī)10K問題），目前這個(gè)問題已解決，主要是用redis
  .

  業(yè)務(wù)流程：普通電商訂單 -> 下單 ->訂單系統(tǒng)（IO）減庫存 ->生成訂單，等待用戶付款

  12306的一種可能的模型，是異步來進(jìn)行的： 下單 -> 減庫存 和 訂單(redis kafka) 同時(shí)異步進(jìn)行 ->等付款，付完款，持久化到Hbase, MySQL等等
  .
  減庫存最后還會(huì)把壓力壓到一臺(tái)服務(wù)器，怎么辦？

  可以做分布式本地庫存 + 單獨(dú)服務(wù)器做庫存均衡

  大流量的處理方法：分而治之，每臺(tái)機(jī)器只減自己機(jī)器上有的庫存
  流量傾斜的問題怎么解決？比如有的機(jī)器上已經(jīng)沒庫存了，有的機(jī)器上還剩很多？
  這時(shí)候你還需要一臺(tái)單獨(dú)的服務(wù)器，去做所有服務(wù)器的平衡，如果某臺(tái)服務(wù)器沒庫存了，從別的機(jī)器上挪一些過去。

• 怎么得到一個(gè)事務(wù)會(huì)消耗多少內(nèi)存？
  1、弄臺(tái)機(jī)器，看能承受多少TPS？是不是達(dá)到目標(biāo)？擴(kuò)容或調(diào)優(yōu)，讓它達(dá)到
  2、用壓測來確定

優(yōu)化環(huán)境

（這個(gè)可以稍微改一下寫進(jìn)簡歷中）
有一個(gè)50萬PV的文檔資料類網(wǎng)站（從磁盤提取文檔到內(nèi)存）原服務(wù)器32位，1.5G
的堆，用戶反饋網(wǎng)站比較緩慢。因此公司決定升級(jí)，新的服務(wù)器為64位，16G的堆內(nèi)存，結(jié)果用戶反饋卡頓十分嚴(yán)重，反而比以前效率更低了！

為什么原網(wǎng)站慢?
因?yàn)楹芏嘤脩魹g覽數(shù)據(jù)，很多用戶瀏覽導(dǎo)致很多數(shù)據(jù)Load到內(nèi)存，產(chǎn)生了很多文檔對應(yīng)的Java包裝對象（而不是文檔對象，文檔本身可以走Nginx）。內(nèi)存不足，頻繁GC，STW長，響應(yīng)時(shí)間變慢

為什么會(huì)更卡頓？
內(nèi)存越大，FGC時(shí)間越長

咋辦？
PS 換成 PN + CMS，或者 G1
或者業(yè)務(wù)上的調(diào)整，文檔不走JVM

系統(tǒng)CPU經(jīng)常100%，如何調(diào)優(yōu)？(面試高頻)
這樣回答：推理過程是：CPU100%，那么一定有線程在占用系統(tǒng)資源，所以

找出哪個(gè)進(jìn)程cpu高（top命令）

該進(jìn)程中的哪個(gè)線程cpu高（top -Hp）

如果是java程序，導(dǎo)出該線程的堆棧 (jstack)

查找哪個(gè)方法（棧幀）消耗時(shí)間，哪個(gè)方法調(diào)用的哪個(gè)方法 (jstack)，然后去看這個(gè)方法的代碼

工作線程占比高 | 垃圾回收線程占比高

系統(tǒng)內(nèi)存飆高，如何查找問題？（面試高頻）

導(dǎo)出堆內(nèi)存 (jmap)

分析 (jhat jvisualvm mat jprofiler … )

如何監(jiān)控JVM

jstat jvisualvm jprofiler arthas top…

總結(jié)

以上是生活随笔為你收集整理的JVM从入门到精通（七）：GC常用参数，Method Area，JVM调优案例分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。