探探Java之 JVM GC與調優

Java正道的光 發表於 2020-10-17

調優前的基礎概念

  1. 吞吐量:使用者程式碼時間 /(使用者程式碼執行時間 + 垃圾回收時間)
  2. 響應時間:STW越短,響應時間越好
  3. 所謂調優,首先確定,追求啥?吞吐量優先,還是響應時間優先?還是在滿足一定的響應時間的情況下,要求達到多大的吞吐量。如科學計算、資料探勘:吞吐量優先;網站、GU、 API 等追求響應時間。

什麼是調優

  1. 根據需求進行JVM規劃和預調優
  2. 優化JVM執行環境(慢、卡頓)
  3. 解決JVM執行過程中出現的各種問題(如OOM)
  • 根據需求進行JVM規劃和預調優

    調優一般來說,從業務場景開始,沒有業務場景的調優都是耍流氓;無監控 (壓力測試,能看到結果),不調優。

    步驟

    1. ​ 熟悉業務場景
    2. 選擇回收器組合,沒有最好的GC,只有最適合的GC。追求響應時間或停頓時間選擇CMS、G1、ZGC追求吞吐量 可選擇PS。
    3. 計算記憶體需求(經驗值 1.5G -16G)
    4. 選定CPU(越高越好)
    5. 設定年代大小,升級年代
    6. 設定日誌引數,日誌檔案全放一個?10T日誌怎麼查。可以設定滾動日誌如-Xloggc:/opt/xxx/logs/xxx-xxx-gc-%t.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=20M -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCCause, 或是每天產生一個日誌檔案。
    7. 觀察日誌情況

    提供一個簡單的案例分析

    案例1:垂直電商,最高每日百萬訂單,處理訂單系統需要什麼樣的伺服器配置?

    這個問題比較業餘,因為很多不同的伺服器配置都能支撐(1.5G -16G)。可以具體分析:一天中特定的高峰期1小時有360000訂單集, 1000個訂單/秒,可以根據經驗值估算需要的記憶體配置。如果非要要計算,可以這麼算:一個訂單產生需要多少記憶體?512K * 1000,需要500M記憶體。

    從另外專業的角度考慮:要求響應時間100ms,這種情況下可以通過壓測的方式找到符合的伺服器配置。

  • 優化JVM執行環境(慢、卡頓)

    1. 提供一個簡單的案例分析。

      有一個50萬PV的資料類網站(從磁碟提取文件到記憶體)原伺服器32位,1.5G的堆.使用者反饋網站比較緩慢,因此公司決定升級。新的伺服器為64位,16G的堆記憶體,結果使用者反饋卡頓十分嚴重,反而比以前效率更低了。

      1. 為什麼原網站慢?很多使用者瀏覽資料,很多資料load到記憶體,記憶體不足,頻繁GC,STW長,響應時間變慢。
      2. 為什麼會更卡頓?記憶體越大,FGC時間越長
      3. 如何解決?可以換垃圾回收器,如從PS 換為PN + CMS 或者是1.8以上的直接用G1。
    2. 系統CPU經常100%,如何調優?(面試高頻)

      CPU100%那麼一定有執行緒在佔用系統資源,

      1. 找出哪個程式cpu高(top)
      2. 該程式中的哪個執行緒cpu高(top -Hp)
      3. 匯出該執行緒的堆疊 (jstack)
      4. 查詢哪個方法(棧幀)消耗時間長 (jstack)
      5. 對比工作執行緒佔比高還是垃圾回收執行緒佔比高
    3. 系統記憶體飆高,如何調優(面試高頻)

      思路: 匯出堆記憶體(jmap); 使用工具如(jhat jvisualvm mat jprofiler)分析

  • 解決JVM執行過程中出現的各種問題

    提供一個測試案例來說明分析過程和常用的工具,程式碼如下:

    /**
     * 從資料庫中讀取信用資料,套用模型,並把結果進行記錄和傳輸
     */
    
    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;
        }
    }
    
    1. 啟動命令java -Xms20M -Xmx20M -XX:+UseParallelGC -XX:+HeapDumpOnOutOfMemoryError T15_FullGC_Problem01

    2. 一般是運維團隊首先受到報警資訊(CPU、Memory)

    3. top命令觀察到問題:記憶體不斷增長,CPU佔用率居高不下

    4. top -Hp 觀察程式中的執行緒,哪個執行緒CPU和記憶體佔比高

    5. jps定位具體java程式;jstack pid 定位執行緒狀況,重點關注:WAITING BLOCKED

      waiting on <0x0000000088ca3310> (a java.lang.Object)
      假如有一個程式中100個執行緒,很多執行緒都在waiting on ,一定要找到是哪個執行緒持有這把鎖。 怎麼找?搜尋jstack dump的資訊,找 ,看哪個執行緒持有這把鎖處於RUNNABLE狀態。

    6. jinfo pid 檢視JVM的情況,一般用處不大。

    7. 通過jstat -gc 動態觀察gc情況;或是閱讀GC日誌發現頻繁GC;或是通過arthas觀察gc情況。

    8. 線上定位,查詢有多少物件產生,注意大量的物件,使用jmap -histo pid |head -20

    9. jmap -dump:format=b,file=xxx pid可以線上堆轉儲,但是要慎重影響很大。

      線上系統記憶體特別大,jmap執行期間對程式產生很大影響,甚至卡頓(電商不適合)。

      如何解決? 啟動時候設定引數HeapDumpOnOutOfMemoryError,OOM的 時候會自動產生堆轉儲檔案;如果線上很多伺服器備份(高可用),停掉這臺伺服器對其它服務沒影響也可以線上堆轉儲;線上定位也可以用阿里的arthas。

    10. 使用MAT/jhat/jvisualvm 進行dump檔案分析。

      建議使用MAT/jvisualvm 裝入分析,介面友好且支援複雜查詢

    11. 最難的一點:定位到程式碼中的問題

      示例程式碼的問題是:執行緒池使用不當引起OOM;不停new CardInfo物件不停地起定時執行緒去處理,導致這些物件越來越多