JVM系列八（GC turning 調優）

時間 2020-04-04

標籤 jvm 系列 turning 欄目 Java 简体版

原文原文鏈接

（說明：這一塊原本要總結，可是在github上有一份比較全，比較精華的總結，就貼過來了，整個系列缺了各類垃圾回收器和三色標記算法的一個詳細解釋，後期補上。原文地址：github.com/bjmashibing…）html

GC的基礎知識

1.什麼是垃圾

C語言申請內存：malloc freejava

C++： new deletelinux

c/C++ 手動回收內存nginx

Java: new ？git

自動內存回收，編程上簡單，系統不容易出錯，手動釋放內存，容易出兩種類型的問題：程序員

忘記回收

屢次回收

沒有任何引用指向的一個對象或者多個對象（循環引用）github

2.如何定位垃圾

引用計數（ReferenceCount）
根可達算法(RootSearching)

3.常見的垃圾回收算法

標記清除(mark sweep) - 位置不連續產生碎片效率偏低（兩遍掃描）
拷貝算法 (copying) - 沒有碎片，浪費空間
標記壓縮(mark compact) - 沒有碎片，效率偏低（兩遍掃描，指針須要調整）

4.JVM內存分代模型（用於分代垃圾回收算法）

部分垃圾回收器使用的模型面試

除Epsilon ZGC Shenandoah以外的GC都是使用邏輯分代模型redis

G1是邏輯分代，物理不分代算法

除此以外不只邏輯分代，並且物理分代
新生代 + 老年代 + 永久代（1.7）Perm Generation/ 元數據區(1.8) Metaspace
1. 永久代元數據 - Class
2. 永久代必須指定大小限制，元數據能夠設置，也能夠不設置，無上限（受限於物理內存）
3. 字符串常量 1.7 - 永久代，1.8 - 堆
4. MethodArea邏輯概念 - 永久代、元數據
新生代 = Eden + 2個suvivor區
1. YGC回收以後，大多數的對象會被回收，活着的進入s0
2. 再次YGC，活着的對象eden + s0 -> s1
3. 再次YGC，eden + s1 -> s0
4. 年齡足夠 -> 老年代（15 CMS 6）
5. s區裝不下 -> 老年代
老年代
1. 頑固分子
2. 老年代滿了FGC Full GC
GC Tuning (Generation)
1. 儘可能減小FGC
2. MinorGC = YGC
3. MajorGC = FGC
對象分配過程圖
動態年齡：（不重要） www.jianshu.com/p/989d3b06a…
分配擔保：（不重要） YGC期間 survivor區空間不夠了空間擔保直接進入老年代參考：cloud.tencent.com/developer/a…

5.常見的垃圾回收器

JDK誕生 Serial追隨提升效率，誕生了PS，爲了配合CMS，誕生了PN，CMS是1.4版本後期引入，CMS是里程碑式的GC，它開啓了併發回收的過程，可是CMS毛病較多，所以目前任何一個JDK版本默認是CMS 併發垃圾回收是由於沒法忍受STW
Serial 年輕代串行回收
PS 年輕代並行回收
ParNew 年輕代配合CMS的並行回收
SerialOld
ParallelOld
ConcurrentMarkSweep 老年代併發的，垃圾回收和應用程序同時運行，下降STW的時間(200ms) CMS問題比較多，因此如今沒有一個版本默認是CMS，只能手工指定 CMS既然是MarkSweep，就必定會有碎片化的問題，碎片到達必定程度，CMS的老年代分配對象分配不下的時候，使用SerialOld 進行老年代回收想象一下： PS + PO -> 加內存換垃圾回收器 -> PN + CMS + SerialOld（幾個小時 - 幾天的STW）幾十個G的內存，單線程回收 -> G1 + FGC 幾十個G -> 上T內存的服務器 ZGC 算法：三色標記 + Incremental Update
G1(10ms) 算法：三色標記 + SATB
ZGC (1ms) PK C++ 算法：ColoredPointers + LoadBarrier
Shenandoah 算法：ColoredPointers + WriteBarrier
Eplison
PS 和 PN區別的延伸閱讀： ▪docs.oracle.com/en/java/jav…
垃圾收集器跟內存大小的關係
1. Serial 幾十兆
2. PS 上百兆 - 幾個G
3. CMS - 20G
4. G1 - 上百G
5. ZGC - 4T - 16T（JDK13）

1.8默認的垃圾回收：PS + ParallelOld

常見垃圾回收器組合參數設定：(1.8)

-XX:+UseSerialGC = Serial New (DefNew) + Serial Old
- 小型程序。默認狀況下不會是這種選項，HotSpot會根據計算及配置和JDK版本自動選擇收集器
-XX:+UseParNewGC = ParNew + SerialOld
- 這個組合已經不多用（在某些版本中已經廢棄）
- stackoverflow.com/questions/3…
-XX:+UseConc(urrent)MarkSweepGC = ParNew + CMS + Serial Old
-XX:+UseParallelGC = Parallel Scavenge + Parallel Old (1.8默認) 【PS + SerialOld】
-XX:+UseParallelOldGC = Parallel Scavenge + Parallel Old
-XX:+UseG1GC = G1
Linux中沒找到默認GC的查看方法，而windows中會打印UseParallelGC
- java +XX:+PrintCommandLineFlags -version
- 經過GC的日誌來分辨
Linux下1.8版本默認的垃圾回收器究竟是什麼？
- 1.8.0_181 默認（看不出來）Copy MarkCompact
- 1.8.0_222 默認 PS + PO

JVM調優第一步，瞭解JVM經常使用命令行參數

JVM的命令行參數參考：docs.oracle.com/javase/8/do…
HotSpot參數分類

標準： - 開頭，全部的HotSpot都支持

非標準：-X 開頭，特定版本HotSpot支持特定命令

不穩定：-XX 開頭，下個版本可能取消

java -version
java -X
試驗用程序：
```
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);
    }
  }
}複製代碼
```
1. 區分概念：內存泄漏memory leak，內存溢出out of memory
2. java -XX:+PrintCommandLineFlags HelloGC
3. java -Xmn10M -Xms40M -Xmx60M -XX:+PrintCommandLineFlags -XX:+PrintGC HelloGC PrintGCDetails PrintGCTimeStamps PrintGCCauses
4. java -XX:+UseConcMarkSweepGC -XX:+PrintCommandLineFlags HelloGC
5. java -XX:+PrintFlagsInitial 默認參數值
6. java -XX:+PrintFlagsFinal 最終參數值
7. java -XX:+PrintFlagsFinal | grep xxx 找到對應的參數
8. java -XX:+PrintFlagsFinal -version |grep GC

PS GC日誌詳解

每種垃圾回收器的日誌格式是不一樣的！

PS日誌格式

heap dump部分：

eden space 5632K, 94% used [0x00000000ff980000,0x00000000ffeb3e28,0x00000000fff00000)
                            後面的內存地址指的是，起始地址，使用空間結束地址，總體空間結束地址複製代碼

total = eden + 1個survivor

調優前的基礎概念：

吞吐量：用戶代碼時間 /（用戶代碼執行時間 + 垃圾回收時間）
響應時間：STW越短，響應時間越好

所謂調優，首先肯定，追求啥？吞吐量優先，仍是響應時間優先？仍是在知足必定的響應時間的狀況下，要求達到多大的吞吐量...

問題：

科學計算，吞吐量。數據挖掘，thrput。吞吐量優先的通常：（PS + PO）

響應時間：網站 GUI API （1.8 G1）

什麼是調優？

根據需求進行JVM規劃和預調優
優化運行JVM運行環境（慢，卡頓）
解決JVM運行過程當中出現的各類問題(OOM)

調優，從規劃開始

調優，從業務場景開始，沒有業務場景的調優都是耍流氓
無監控（壓力測試，能看到結果），不調優
步驟：
1. 熟悉業務場景（沒有最好的垃圾回收器，只有最合適的垃圾回收器）
  1. 響應時間、停頓時間 [CMS G1 ZGC] （須要給用戶做響應）
  2. 吞吐量 = 用戶時間 /( 用戶時間 + GC時間) [PS]
2. 選擇回收器組合
3. 計算內存需求（經驗值 1.5G 16G）
4. 選定CPU（越高越好）
5. 設定年代大小、升級年齡
6. 設定日誌參數
  1. -Xloggc:/opt/xxx/logs/xxx-xxx-gc-%t.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=20M -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCCause
  2. 或者天天產生一個日誌文件
7. 觀察日誌狀況
案例1：垂直電商，最高每日百萬訂單，處理訂單系統須要什麼樣的服務器配置？

這個問題比較業餘，由於不少不一樣的服務器配置都能支撐(1.5G 16G)

1小時360000集中時間段， 100個訂單/秒，（找一小時內的高峯期，1000訂單/秒）

經驗值，

非要計算：一個訂單產生須要多少內存？512K * 1000 500M內存

專業一點兒問法：要求響應時間100ms

壓測！
案例2：12306遭遇春節大規模搶票應該如何支撐？

12306應該是中國併發量最大的秒殺網站：

號稱併發量100W最高

CDN -> LVS -> NGINX -> 業務系統 -> 每臺機器1W併發（10K問題） 100臺機器

普通電商訂單 -> 下單 ->訂單系統（IO）減庫存 ->等待用戶付款

12306的一種可能的模型：下單 -> 減庫存和訂單(redis kafka) 同時異步進行 ->等付款

減庫存最後還會把壓力壓到一臺服務器

能夠作分佈式本地庫存 + 單獨服務器作庫存均衡

大流量的處理方法：分而治之
怎麼獲得一個事務會消耗多少內存？
1. 弄臺機器，看能承受多少TPS？是否是達到目標？擴容或調優，讓它達到
2. 用壓測來肯定

優化環境

有一個50萬PV的資料類網站（從磁盤提取文檔到內存）原服務器32位，1.5G 的堆，用戶反饋網站比較緩慢，所以公司決定升級，新的服務器爲64位，16G 的堆內存，結果用戶反饋卡頓十分嚴重，反而比之前效率更低了
1. 爲何原網站慢? 不少用戶瀏覽數據，不少數據load到內存，內存不足，頻繁GC，STW長，響應時間變慢
2. 爲何會更卡頓？內存越大，FGC時間越長
3. 咋辦？ PS -> PN + CMS 或者 G1
系統CPU常常100%，如何調優？(面試高頻) CPU100%那麼必定有線程在佔用系統資源，
1. 找出哪一個進程cpu高（top）
2. 該進程中的哪一個線程cpu高（top -Hp）
3. 導出該線程的堆棧 (jstack)
4. 查找哪一個方法（棧幀）消耗時間 (jstack)
5. 工做線程佔比高 | 垃圾回收線程佔比高
系統內存飆高，如何查找問題？（面試高頻）
1. 導出堆內存 (jmap)
2. 分析 (jhat jvisualvm mat jprofiler ... )
如何監控JVM
1. jstat jvisualvm jprofiler arthas top...

解決JVM運行中的問題

一個案例理解經常使用工具

測試代碼：

package com.mashibing.jvm.gc;

import java.math.BigDecimal;
import java.util.ArrayList;
import java.util.Date;
import java.util.List;
import java.util.concurrent.ScheduledThreadPoolExecutor;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;

/**
 * 從數據庫中讀取信用數據，套用模型，並把結果進行記錄和傳輸
 */

public class T15_FullGC_Problem01 {

    private static class CardInfo {
        BigDecimal price = new BigDecimal(0.0);
        String name = "張三";
        int age = 5;
        Date birthdate = new Date();

        public void m() {}
    }

    private static ScheduledThreadPoolExecutor executor = new ScheduledThreadPoolExecutor(50,
            new ThreadPoolExecutor.DiscardOldestPolicy());

    public static void main(String[] args) throws Exception {
        executor.setMaximumPoolSize(50);

        for (;;){
            modelFit();
            Thread.sleep(100);
        }
    }

    private static void modelFit(){
        List<CardInfo> taskList = getAllCardInfo();
        taskList.forEach(info -> {
            // do something
            executor.scheduleWithFixedDelay(() -> {
                //do sth with info
                info.m();

            }, 2, 3, TimeUnit.SECONDS);
        });
    }

    private static List<CardInfo> getAllCardInfo(){
        List<CardInfo> taskList = new ArrayList<>();

        for (int i = 0; i < 100; i++) {
            CardInfo ci = new CardInfo();
            taskList.add(ci);
        }

        return taskList;
    }
}
複製代碼

java -Xms200M -Xmx200M -XX:+PrintGC com.mashibing.jvm.gc.T15_FullGC_Problem01
通常是運維團隊首先受到報警信息（CPU Memory）
top命令觀察到問題：內存不斷增加 CPU佔用率居高不下
top -Hp 觀察進程中的線程，哪一個線程CPU和內存佔比高
jps定位具體java進程 jstack 定位線程情況，重點關注：WAITING BLOCKED eg. waiting on <0x0000000088ca3310> (a java.lang.Object) 假若有一個進程中100個線程，不少線程都在waiting on ，必定要找到是哪一個線程持有這把鎖怎麼找？搜索jstack dump的信息，找，看哪一個線程持有這把鎖RUNNABLE 做業：1：寫一個死鎖程序，用jstack觀察 2 ：寫一個程序，一個線程持有鎖不釋放，其餘線程等待
爲何阿里規範裏規定，線程的名稱（尤爲是線程池）都要寫有意義的名稱怎麼樣自定義線程池裏的線程名稱？（自定義ThreadFactory）
jinfo pid
jstat -gc 動態觀察gc狀況 / 閱讀GC日誌發現頻繁GC / arthas觀察 / jconsole/jvisualVM/ Jprofiler（最好用） jstat -gc 4655 500 : 每一個500個毫秒打印GC的狀況若是面試官問你是怎麼定位OOM問題的？若是你回答用圖形界面（錯誤） 1：已經上線的系統不用圖形界面用什麼？（cmdline arthas） 2：圖形界面到底用在什麼地方？測試！測試的時候進行監控！（壓測觀察）
jmap - histo 4655 | head -20，查找有多少對象產生
jmap -dump:format=b,file=xxx pid ：
線上系統，內存特別大，jmap執行期間會對進程產生很大影響，甚至卡頓（電商不適合） 1：設定了參數HeapDump，OOM的時候會自動產生堆轉儲文件 2：不少服務器備份（高可用），停掉這臺服務器對其餘服務器不影響 3：在線定位(通常小點兒公司用不到)
java -Xms20M -Xmx20M -XX:+UseParallelGC -XX:+HeapDumpOnOutOfMemoryError com.mashibing.jvm.gc.T15_FullGC_Problem01
使用MAT / jhat /jvisualvm 進行dump文件分析 www.cnblogs.com/baihuitests… jhat -J-mx512M xxx.dump http://192.168.17.11:7000 拉到最後：找到對應連接可使用OQL查找特定問題對象
找到代碼的問題

jconsole遠程鏈接

程序啓動加入參數：

java -Djava.rmi.server.hostname=192.168.17.11 -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=11111 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false XXX複製代碼

若是遭遇 Local host name unknown：XXX的錯誤，修改/etc/hosts文件，把XXX加入進去

192.168.17.11 basic localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6複製代碼

關閉linux防火牆（實戰中應該打開對應端口）

service iptables stop
chkconfig iptables off #永久關閉複製代碼

windows上打開 jconsole遠程鏈接 192.168.17.11:11111

jvisualvm遠程鏈接

www.cnblogs.com/liugh/p/762… （簡單作法）

jprofiler (收費)

arthas在線排查工具

爲何須要在線排查？在生產上咱們常常會碰到一些很差排查的問題，例如線程安全問題，用最簡單的threaddump或者heapdump很差查到問題緣由。爲了排查這些問題，有時咱們會臨時加一些日誌，好比在一些關鍵的函數裏打印出入參，而後從新打包發佈，若是打了日誌仍是沒找到問題，繼續加日誌，從新打包發佈。對於上線流程複雜並且審覈比較嚴的公司，從改代碼到上線須要層層的流轉，會大大影響問題排查的進度。
jvm觀察jvm信息
thread定位線程問題
dashboard 觀察系統狀況
heapdump + jhat分析
jad反編譯動態代理生成類的問題定位第三方的類（觀察代碼）版本問題（肯定本身最新提交的版本是否是被使用）
redefine 熱替換目前有些限制條件：只能改方法實現（方法已經運行完成），不能改方法名，不能改屬性 m() -> mm()
sc - search class
watch - watch method
沒有包含的功能：jmap

GC算法的基礎概念

Card Table 因爲作YGC時，須要掃描整個OLD區，效率很是低，因此JVM設計了CardTable，若是一個OLD區CardTable中有對象指向Y區，就將它設爲Dirty，下次掃描時，只須要掃描Dirty Card 在結構上，Card Table用BitMap來實現

CMS

CMS的問題

Memory Fragmentation

-XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction 默認爲0 指的是通過多少次FGC才進行壓縮
Floating Garbage

Concurrent Mode Failure 產生：if the concurrent collector is unable to finish reclaiming the unreachable objects before the tenured generation fills up, or if an allocation cannot be satisfiedwith the available free space blocks in the tenured generation, then theapplication is paused and the collection is completed with all the applicationthreads stopped

解決方案：下降觸發CMS的閾值

PromotionFailed

解決方案相似，保持老年代有足夠的空間

–XX:CMSInitiatingOccupancyFraction 92% 能夠下降這個值，讓CMS保持老年代足夠的空間

CMS日誌分析

執行命令：java -Xms20M -Xmx20M -XX:+PrintGCDetails -XX:+UseConcMarkSweepGC com.mashibing.jvm.gc.T15_FullGC_Problem01

[GC (Allocation Failure) [ParNew: 6144K->640K(6144K), 0.0265885 secs] 6585K->2770K(19840K), 0.0268035 secs] [Times: user=0.02 sys=0.00, real=0.02 secs]

ParNew：年輕代收集器

6144->640：收集先後的對比

（6144）：整個年輕代容量

6585 -> 2770：整個堆的狀況

（19840）：整個堆大小

[GC (CMS Initial Mark) [1 CMS-initial-mark: 8511K(13696K)] 9866K(19840K), 0.0040321 secs] [Times: user=0.01 sys=0.00, real=0.00 secs] 
	//8511 (13696) : 老年代使用（最大）
	//9866 (19840) : 整個堆使用（最大）
[CMS-concurrent-mark-start]
[CMS-concurrent-mark: 0.018/0.018 secs] [Times: user=0.01 sys=0.00, real=0.02 secs] 
	//這裏的時間意義不大，由於是併發執行
[CMS-concurrent-preclean-start]
[CMS-concurrent-preclean: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
	//標記Card爲Dirty，也稱爲Card Marking
[GC (CMS Final Remark) [YG occupancy: 1597 K (6144 K)][Rescan (parallel) , 0.0008396 secs][weak refs processing, 0.0000138 secs][class unloading, 0.0005404 secs][scrub symbol table, 0.0006169 secs][scrub string table, 0.0004903 secs][1 CMS-remark: 8511K(13696K)] 10108K(19840K), 0.0039567 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
	//STW階段，YG occupancy:年輕代佔用及容量
	//[Rescan (parallel)：STW下的存活對象標記
	//weak refs processing: 弱引用處理
	//class unloading: 卸載用不到的class
	//scrub symbol(string) table: 
		//cleaning up symbol and string tables which hold class-level metadata and 
		//internalized string respectively
	//CMS-remark: 8511K(13696K): 階段事後的老年代佔用及容量
	//10108K(19840K): 階段事後的堆佔用及容量

[CMS-concurrent-sweep-start]
[CMS-concurrent-sweep: 0.005/0.005 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 
	//標記已經完成，進行併發清理
[CMS-concurrent-reset-start]
[CMS-concurrent-reset: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
	//重置內部結構，爲下次GC作準備複製代碼

G1

▪www.oracle.com/technical-r…

G1日誌詳解

[GC pause (G1 Evacuation Pause) (young) (initial-mark), 0.0015790 secs]
//young -> 年輕代 Evacuation-> 複製存活對象 
//initial-mark 混合回收的階段，這裏是YGC混合老年代回收
   [Parallel Time: 1.5 ms, GC Workers: 1] //一個GC線程
      [GC Worker Start (ms):  92635.7]
      [Ext Root Scanning (ms):  1.1]
      [Update RS (ms):  0.0]
         [Processed Buffers:  1]
      [Scan RS (ms):  0.0]
      [Code Root Scanning (ms):  0.0]
      [Object Copy (ms):  0.1]
      [Termination (ms):  0.0]
         [Termination Attempts:  1]
      [GC Worker Other (ms):  0.0]
      [GC Worker Total (ms):  1.2]
      [GC Worker End (ms):  92636.9]
   [Code Root Fixup: 0.0 ms]
   [Code Root Purge: 0.0 ms]
   [Clear CT: 0.0 ms]
   [Other: 0.1 ms]
      [Choose CSet: 0.0 ms]
      [Ref Proc: 0.0 ms]
      [Ref Enq: 0.0 ms]
      [Redirty Cards: 0.0 ms]
      [Humongous Register: 0.0 ms]
      [Humongous Reclaim: 0.0 ms]
      [Free CSet: 0.0 ms]
   [Eden: 0.0B(1024.0K)->0.0B(1024.0K) Survivors: 0.0B->0.0B Heap: 18.8M(20.0M)->18.8M(20.0M)]
 [Times: user=0.00 sys=0.00, real=0.00 secs] 
//如下是混合回收其餘階段
[GC concurrent-root-region-scan-start]
[GC concurrent-root-region-scan-end, 0.0000078 secs]
[GC concurrent-mark-start]
//沒法evacuation，進行FGC
[Full GC (Allocation Failure)  18M->18M(20M), 0.0719656 secs]
   [Eden: 0.0B(1024.0K)->0.0B(1024.0K) Survivors: 0.0B->0.0B Heap: 18.8M(20.0M)->18.8M(20.0M)], [Metaspace: 38
76K->3876K(1056768K)] [Times: user=0.07 sys=0.00, real=0.07 secs]
複製代碼

案例彙總

OOM產生的緣由多種多樣，有些程序未必產生OOM，不斷FGC(CPU飆高，但內存回收特別少) （上面案例）

硬件升級系統反而卡頓的問題（見上）
線程池不當運用產生OOM問題（見上）不斷的往List里加對象（實在太LOW）
smile jira問題實際系統不斷重啓解決問題加內存 + 更換垃圾回收器 G1 真正問題在哪兒？不知道
tomcat http-header-size過大問題（Hector）

lambda表達式致使方法區溢出問題(MethodArea / Perm Metaspace) LambdaGC.java -XX:MaxMetaspaceSize=9M -XX:+PrintGCDetails

"C:\Program Files\Java\jdk1.8.0_181\bin\java.exe" -XX:MaxMetaspaceSize=9M -XX:+PrintGCDetails "-javaagent:C:\Program Files\JetBrains\IntelliJ IDEA Community Edition 2019.1\lib\idea_rt.jar=49316:C:\Program Files\JetBrains\IntelliJ IDEA Community Edition 2019.1\bin" -Dfile.encoding=UTF-8 -classpath "C:\Program Files\Java\jdk1.8.0_181\jre\lib\charsets.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\deploy.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\ext\access-bridge-64.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\ext\cldrdata.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\ext\dnsns.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\ext\jaccess.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\ext\jfxrt.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\ext\localedata.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\ext\nashorn.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\ext\sunec.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\ext\sunjce_provider.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\ext\sunmscapi.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\ext\sunpkcs11.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\ext\zipfs.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\javaws.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\jce.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\jfr.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\jfxswt.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\jsse.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\management-agent.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\plugin.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\resources.jar;C:\Program Files\Java\jdk1.8.0_181\jre\lib\rt.jar;C:\work\ijprojects\JVM\out\production\JVM;C:\work\ijprojects\ObjectSize\out\artifacts\ObjectSize_jar\ObjectSize.jar" com.mashibing.jvm.gc.LambdaGC
[GC (Metadata GC Threshold) [PSYoungGen: 11341K->1880K(38400K)] 11341K->1888K(125952K), 0.0022190 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[Full GC (Metadata GC Threshold) [PSYoungGen: 1880K->0K(38400K)] [ParOldGen: 8K->1777K(35328K)] 1888K->1777K(73728K), [Metaspace: 8164K->8164K(1056768K)], 0.0100681 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] 
[GC (Last ditch collection) [PSYoungGen: 0K->0K(38400K)] 1777K->1777K(73728K), 0.0005698 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[Full GC (Last ditch collection) [PSYoungGen: 0K->0K(38400K)] [ParOldGen: 1777K->1629K(67584K)] 1777K->1629K(105984K), [Metaspace: 8164K->8156K(1056768K)], 0.0124299 secs] [Times: user=0.06 sys=0.00, real=0.01 secs] 
java.lang.reflect.InvocationTargetException
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:388)
	at sun.instrument.InstrumentationImpl.loadClassAndCallAgentmain(InstrumentationImpl.java:411)
Caused by: java.lang.OutOfMemoryError: Compressed class space
	at sun.misc.Unsafe.defineClass(Native Method)
	at sun.reflect.ClassDefiner.defineClass(ClassDefiner.java:63)
	at sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:399)
	at sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:394)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.reflect.MethodAccessorGenerator.generate(MethodAccessorGenerator.java:393)
	at sun.reflect.MethodAccessorGenerator.generateSerializationConstructor(MethodAccessorGenerator.java:112)
	at sun.reflect.ReflectionFactory.generateConstructor(ReflectionFactory.java:398)
	at sun.reflect.ReflectionFactory.newConstructorForSerialization(ReflectionFactory.java:360)
	at java.io.ObjectStreamClass.getSerializableConstructor(ObjectStreamClass.java:1574)
	at java.io.ObjectStreamClass.access$1500(ObjectStreamClass.java:79)
	at java.io.ObjectStreamClass$3.run(ObjectStreamClass.java:519)
	at java.io.ObjectStreamClass$3.run(ObjectStreamClass.java:494)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.io.ObjectStreamClass.<init>(ObjectStreamClass.java:494)
	at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:391)
	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1134)
	at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
	at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
	at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
	at javax.management.remote.rmi.RMIConnectorServer.encodeJRMPStub(RMIConnectorServer.java:727)
	at javax.management.remote.rmi.RMIConnectorServer.encodeStub(RMIConnectorServer.java:719)
	at javax.management.remote.rmi.RMIConnectorServer.encodeStubInAddress(RMIConnectorServer.java:690)
	at javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:439)
	at sun.management.jmxremote.ConnectorBootstrap.startLocalConnectorServer(ConnectorBootstrap.java:550)
	at sun.management.Agent.startLocalManagementAgent(Agent.java:137)
複製代碼

直接內存溢出問題（少見）《深刻理解Java虛擬機》P59，使用Unsafe分配直接內存，或者使用NIO的問題
棧溢出問題 -Xss設定過小

比較一下這兩段程序的異同，分析哪個是更優的寫法：

Object o = null;
for(int i=0; i<100; i++) {
    o = new Object();
    //業務處理
}複製代碼

for(int i=0; i<100; i++) {
    Object o = new Object();
}複製代碼

重寫finalize引起頻繁GC 小米雲，HBase同步系統，系統經過nginx訪問超時報警，最後排查，C++程序員重寫finalize引起頻繁GC問題爲何C++程序員會重寫finalize？（new delete） finalize耗時比較長（200ms）
若是有一個系統，內存一直消耗不超過10%，可是觀察GC日誌，發現FGC老是頻繁產生，會是什麼引發的？ System.gc() (這個比較Low)
Distuptor有個能夠設置鏈的長度，若是過大，而後對象大，消費完不主動釋放，會溢出 (來自死物風情)
用jvm都會溢出，mycat用崩過，1.6.5某個臨時版本解析sql子查詢算法有問題，9個exists的聯合sql就致使生成幾百萬的對象（來自死物風情）
new 大量線程，會產生 native thread OOM，（low）應該用線程池，解決方案：減小堆空間（太TMlow了）,預留更多內存產生native thread JVM內存佔物理內存比例 50% - 80%

GC經常使用參數

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

Parallel經常使用參數

-XX:SurvivorRatio
-XX:PreTenureSizeThreshold 大對象到底多大
-XX:MaxTenuringThreshold
-XX:+ParallelGCThreads 並行收集器的線程數，一樣適用於CMS，通常設爲和CPU核數相同
-XX:+UseAdaptiveSizePolicy 自動選擇各區大小比例

CMS經常使用參數

-XX:+UseConcMarkSweepGC
-XX:ParallelCMSThreads CMS線程數量
-XX:CMSInitiatingOccupancyFraction 使用多少比例的老年代後開始CMS收集，默認是68%(近似值)，若是頻繁發生SerialOld卡頓，應該調小，（頻繁CMS回收）
-XX:+UseCMSCompactAtFullCollection 在FGC時進行壓縮
-XX:CMSFullGCsBeforeCompaction 多少次FGC以後進行壓縮
-XX:+CMSClassUnloadingEnabled
-XX:CMSInitiatingPermOccupancyFraction 達到什麼比例時進行Perm回收
GCTimeRatio 設置GC時間佔用程序運行時間的百分比
-XX:MaxGCPauseMillis 停頓時間，是一個建議時間，GC會嘗試用各類手段達到這個時間，好比減少年輕代

G1經常使用參數

-XX:+UseG1GC
-XX:MaxGCPauseMillis 建議值，G1會嘗試調整Young區的塊數來達到這個值
-XX:GCPauseIntervalMillis ？GC的間隔時間
-XX:+G1HeapRegionSize 分區大小，建議逐漸增大該值，1 2 4 8 16 32。隨着size增長，垃圾的存活時間更長，GC間隔更長，但每次GC的時間也會更長 ZGC作了改進（動態區塊大小）
G1NewSizePercent 新生代最小比例，默認爲5%
G1MaxNewSizePercent 新生代最大比例，默認爲60%
GCTimeRatio GC時間建議比例，G1會根據這個值調整堆空間
ConcGCThreads 線程數量
InitiatingHeapOccupancyPercent 啓動G1的堆空間佔用比例

思考：

-XX:MaxTenuringThreshold控制的是什麼？ A: 對象升入老年代的年齡 B: 老年代觸發FGC時的內存垃圾比例
生產環境中，傾向於將最大堆內存和最小堆內存設置爲：（爲何？） A: 相同 B：不一樣
JDK1.8默認的垃圾回收器是： A: ParNew + CMS B: G1 C: PS + ParallelOld D: 以上都不是
什麼是響應時間優先？
什麼是吞吐量優先？
ParNew和PS的區別是什麼？
ParNew和ParallelOld的區別是什麼？（年代不一樣，算法不一樣）
長時間計算的場景應該選擇：A：停頓時間 B: 吞吐量
大規模電商網站應該選擇：A：停頓時間 B: 吞吐量
HotSpot的垃圾收集器最經常使用有哪些？
常見的HotSpot垃圾收集器組合有哪些？
JDK1.7 1.8 1.9的默認垃圾回收器是什麼？如何查看？
所謂調優，究竟是在調什麼？
若是採用PS + ParrallelOld組合，怎麼作才能讓系統基本不產生FGC
若是採用ParNew + CMS組合，怎樣作纔可以讓系統基本不產生FGC
1.加大JVM內存
2.加大Young的比例
3.提升Y-O的年齡
4.提升S區比例
5.避免代碼內存泄漏
G1是否分代？G1垃圾回收器會產生FGC嗎？
若是G1產生FGC，你應該作什麼？
1. 擴內存
2. 提升CPU性能（回收的快，業務邏輯產生對象的速度固定，垃圾回收越快，內存空間越大）
3. 下降MixedGC觸發的閾值，讓MixedGC提前發生（默認是45%）
問：生產環境中可以隨隨便便的dump嗎？小堆影響不大，大堆會有服務暫停或卡頓（加live能夠緩解），dump前會有FGC
問：常見的OOM問題有哪些？棧堆 MethodArea 直接內存