【死磕JVM】看完這篇我也會排查JVM記憶體過高了就是玩兒！

前言

CPU 是時分的，作業系統裡面有很多線程，每個線程的運作時間由CPU決定，CPU會分給每一個線程一個時間片，時間片是一個很短的時間長度，如果在時間片内，線程一直占有，就是100%，我們應該意識到，CPU運作速度很快（主頻非常高），除非是密集型耗費CPU的運算，其他類型的任務都會在小于時間片的時間内結束。

記憶體過高一般有兩種情況：記憶體溢出和記憶體洩露

記憶體溢出：程式配置設定的記憶體超過實體機的記憶體大小，導緻無法繼續配置設定記憶體，出現OOM報錯
記憶體洩露：不再使用的對象一直占據着記憶體不釋放，導緻這塊記憶體浪費掉，久而久之，記憶體洩露的對象堆積起來，也會導緻實體機的記憶體被耗盡，出現OOM報錯

具體操作

如何監控JVM，我們可以通過一個案例在了解一些實際當中的操作，大家可以看到下面的代碼，下面的代碼隻是模拟了當中的一個場景，一個風險控制的場景，一般銀行或者第三方公司在向一個人發放貸款的時候，會調用這個人的征信已經還款能力，給出響應的評級。

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 FullGCTest {

    //模拟銀行卡的類
    private static class CardInfo {
        //小農的銀行卡資訊記錄
        BigDecimal price = new BigDecimal(10000000.0);
        String name = "牧小農";
        int age = 18;
        Date birthdate = new Date();

        public void m() {}
    }

    //線程池 定時線程池
    //50個，然後設定 拒絕政策
    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(() -> {
                //調用M方法
                info.m();

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

    private static List<CardInfo> getAllCardInfo(){
        List<CardInfo> taskList = new ArrayList<>();
        //每次查詢100張卡出來
        for (int i = 0; i < 100; i++) {
            CardInfo ci = new CardInfo();
            taskList.add(ci);
        }

        return taskList;
    }
}

程式的設計其實比較簡單，就是我們用信用卡的案例來進行說明，比如CardInfo就是信用卡類，我們把這個人對應的信用卡的記錄都調用出來，之後做一些自己響應的業務處理方法來對它進行處理和計算，來看看我們這個模型是否符合modelFit，具體怎麼做呢，在應用程式中有一個類是CardInfo，有一個方法叫做getAllCardInfo，每次都是拿100個出來，拿100個之後用線程池做計算，線程池用的是

ScheduledThreadPoolExecutor (定時任務)

，new出來線程池之後，50個線程池，然後做對應的業務邏輯處理，會調用 modelFit()，使用100毫秒模拟業務的停頓。

首先我們需要使用javac 指令将Java檔案進行編譯

javac FullGCTest.java

進行編譯，然後列印GC日志，進行風險監控

列印GC日志：

java -Xms200M -Xmx200M -XX:+PrintGC FullGCTest

怎麼知道JVM記憶體過高？

在公司裡面，如果遇到了JVM記憶體過高的情況，那麼一般是運維團隊首先受到報警資訊，然後通知對應的開發人員去檢視，那麼開發人員應該如何檢視，或者怎麼樣去排查呢？

1、top 檢視程序

受到報警資訊後，拿top指令去查詢

[root@root ~]# top

檢視記憶體不斷增長，CPU占用率居高不下的。top後你會看到它的PID（31061）。它占比比較高。

2、top -Hp 檢視線程

找到CPU占用比較高的程序PID，這裡我們以 java 的程序為例

使用指令

top -Hp 31061

，這個時候它會把這個程序裡面所有的線程全部線程都羅列出來嗎，這些都是Java這個程序裡面内部的一些線程，如下圖所示：

我們會看到每個線程的占比都差不多，偶爾會有某一個線程比較高，在某些線程占得比較高的時候，這個小例子最終會是垃圾回收的線程占得比較高，因為垃圾回收不過來了，是以需要不停的來回回收，每次都回收一點點，實際這種例子裡面非常有可能是你業務邏輯線程，那一塊的業務邏輯線程占比非常高，這是時候就需要用到另外的指令——

jstack

3、jstack

當我們使用 top -Hp 知道了是哪個線程後，我們下一步就可以使用

jstack

指令，比如我們要檢視31083這個線程号，31061是我們的程序PID，我們要定位某一個線程cpu的占比會比其他cpu高很多，那麼我們就要定位這個線程裡面到底是什麼樣的問題的時候，就需要把這個線程号（31083）記下來。

因為 jstack 用到的線程号是16進制的，是以我們需要把31083的10進制轉換成16進制才可以

特點：

每個線程有自己的線程号碼，裡面有線程的狀态，可以觀察線程是否阻塞，如果長時間的wait和block說明這個線程是有問題的

4、轉換16進制

因為Java線程檔案中的線程ID是16進制，是以需要将線程ID從十進制轉換成十六進制

指令：

echo "obase=16;31083" | bc

5、jstack用法解析

[root@root ~]# jstack
Usage:
    jstack [-l] <pid>
        (to connect to running process)
    jstack -F [-m] [-l] <pid>
        (to connect to a hung process)
    jstack [-m] [-l] <executable> <core>
        (to connect to a core file)
    jstack [-m] [-l] [server_id@]<remote server IP or hostname>
        (to connect to a remote debug server)

Options:
    -F  to force a thread dump. Use when jstack <pid> does not respond (process is hung)
    -m  to print both java and native frames (mixed mode)
    -l  long listing. Prints additional information about locks
    -h or -help to print this help message

6、jstack檢視輸出

我們也可以用

jps或者java ps -ef| java

來檢視Java程序，這裡我們用jps來檢視

[root@root ~]# jps

[root@root ~]# jstack 31061

"pool-1-thread-3" #10 prio=5 os_prio=0 tid=0x00007f3568105800 nid=0x7961 waiting on condition [0x00007f35455cf000]
   java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x00000000f8a81148> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
        at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1088)
        at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
        at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)

"pool-1-thread-2" #9 prio=5 os_prio=0 tid=0x00007f3568103800 nid=0x7960 waiting on condition [0x00007f35456d0000]
   java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x00000000f8a81148> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
        at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1088)
        at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
        at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)

"pool-1-thread-1" #8 prio=5 os_prio=0 tid=0x00007f3568102000 nid=0x795f waiting on condition [0x00007f35457d1000]
   java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x00000000f8a81148> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
        at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1088)
        at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
        at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)

"Service Thread" #7 daemon prio=9 os_prio=0 tid=0x00007f35680b4000 nid=0x795d runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C1 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0x00007f35680b1000 nid=0x795c waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0x00007f35680af000 nid=0x795b waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0x00007f35680ad800 nid=0x795a runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" #3 daemon prio=8 os_prio=0 tid=0x00007f356807c800 nid=0x7959 in Object.wait() [0x00007f3558301000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00000000f8a86b38> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:144)
        - locked <0x00000000f8a86b38> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:165)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:216)

"Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x00007f3568077800 nid=0x7958 in Object.wait() [0x00007f3558402000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x00000000f8a86cf0> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:502)
        at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
        - locked <0x00000000f8a86cf0> (a java.lang.ref.Reference$Lock)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)

"main" #1 prio=5 os_prio=0 tid=0x00007f3568009800 nid=0x7956 waiting on condition [0x00007f356ed59000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
        at java.lang.Thread.sleep(Native Method)
        at FullGCTest.main(FullGCTest.java:35)

"VM Thread" os_prio=0 tid=0x00007f356806e000 nid=0x7957 runnable 

"VM Periodic Task Thread" os_prio=0 tid=0x00007f35680b7000 nid=0x795e waiting on condition 

JNI global references: 205

通過thread dump分析線程狀态

大多數情況下會基于thead dump 分析目前各個線程的運作情況，如是否存在死鎖，是否存在一個線程長時間持有鎖不釋放等等

在dump中，線程一般存在如下幾種狀态：

1、RUNNABLE，線程處于執行中

2、BLOCKED，線程被阻塞

3、WAITING，線程正在等待

locked &lt;0x000000076bf62208&gt;

說明線程對位址為

0x000000076bf62208

對象進行了加鎖；

waiting to lock &lt;0x000000076bf62208&gt;

說明線程在等待位址為

0x000000076bf62208

對象上的鎖；

waiting for monitor entry [0x000000001e21f000]

說明線程是通過synchronized關鍵字進入了螢幕的臨界區，并處于"Entry Set"隊列，等待monitor；

waiting on &lt;0x0000000088ca3310&gt; (a java.lang.Object)

等待鎖的釋放

假如有一個程序中有100個線程，很多線程都在waiting on 某一把鎖，然後線程不該阻塞的被阻塞了，該結束的沒結束掉，一定要找到哪個線程持有這把鎖，我們可以搜尋 jstack dump 的資訊，找到

&lt;0X...&gt;

的資訊，看哪個線程隻有了這把鎖，一般這個線程狀态是RUNNABLE，表示這個線程正在運作但是一直持有這把鎖不釋放，那麼就會導緻整個線程的死鎖

7、jstack分析死鎖

public class TestDeadLock {

    private static Object obj1 = new Object();
    private static Object obj2 = new Object();

    public static void main(String[] args) {
        new Thread(new Thread1()).start();
        new Thread(new Thread2()).start();
    }

    private static class Thread1 implements Runnable {
        @Override
        public void run() {
            synchronized (obj1) {
                System.out.println("Thread1 拿到了 obj1 的鎖！");
                try {// 停頓2秒的意義在于，讓Thread2線程拿到obj2的鎖
                    Thread.sleep(2000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                synchronized (obj2) {
                    System.out.println("Thread1 拿到了 obj2 的鎖！");
                }
            }
        }
    }

    private static class Thread2 implements Runnable {
        @Override
        public void run() {
            synchronized (obj2) {
                System.out.println("Thread2 拿到了 obj2 的鎖！");
                try {
                    // 停頓2秒的意義在于，讓Thread1線程拿到obj1的鎖
                    Thread.sleep(2000);
                } catch (Exception e) {
                    e.printStackTrace();
                }
                synchronized (obj1) {
                    System.out.println("Thread2 拿到了obj1的鎖！");
                }
            }
        }
    }

}

通過指令檢視分析日志

[root@root fuccGC]# jps
485 Bootstrap
9877 Jps
10629 QuorumPeerMain
9846 TestDeadLock
[root@root fuccGC]# jstack 9846

記憶體監控工具的使用

我們可以使用jvm自帶的指令去進行監控GC的資訊：

jinfo pid：這個指令就是把這個程序的一些詳細資訊列出來

[root@root ~]# jinfo 9846

這個隻是有幫助，但是幫助不是特别大，大家隻要記住有這個指令就行，不做深入了解

jstat -gc pid 1000：這個就是每一秒鐘将GC的日志列印出來，動态觀察GC情況/閱讀GC日志發現頻繁GC等等，但是這個資訊看起來不是很直覺，能夠分析出來的東西也不多，是以一般使用的也不是很多

我們用的最多的還是通過工具去檢視，比如 jconsole/jvisualvm

1、 jconsole

這兩個是JDK自帶的一個工具，也是一個圖形界面的工具，隻要你裝了JDK就有這兩個工具，可以從本機去跟蹤遠端伺服器上的一個程序，作為Linux伺服器，很少有人會裝圖形界面，如下圖所示：

在我們程式啟動的時候要加入參數：

java -Djava.rmi.server.hostname=101.XX.XXX.XX -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=8080 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.rmi.port=8080 FullGCTest

基本情況如下，我們就可以監控到我們遠端伺服器上面的記憶體資訊

2、 jvisualvm

輕按兩下 jvisualvm

選擇遠端-點選檔案按鈕

選擇添加JMX連接配接

輸入我們的位址和賬号密碼就可以登入了

這樣就可以檢視我們遠端服務的記憶體資訊了

在這裡我們就知道怎麼定位問題了，哪一個類占用了多少記憶體，就會顯示出來，點選抽樣器，記憶體，之後就會對遠端的那台機器的JAVA程序記憶體，在圖形化界面中顯示，有多少個類，占用了多少個位元組，這樣我們就可以具體定位到是哪個類有問題了

面試中如何回答定位記憶體溢出(OOM)

如果面試官我們如何定位OOM的問題，但是我們不能回答用圖形界面，因為作為一個服務來講，在不斷的運作，當我們開一個JMX服務的時候，會形象服務本來的運作效率，那我們已經上線的系統不用圖形化用什麼？還有一個叫Jprofiler是最好用的圖形界面，但是這個是收費的，是以一般用不到，

如果不用圖形界面那我們用什麼，我們可以用 cmdline、arthas這兩個

圖形界面用在什麼地方呢？用在測試上，測試的時候進行監控~

如果已經上線的項目，我們不用圖形界面可以用什麼呢？我們可以用Jmap

jmap

[root@root ~]# jmap -histo 19086 | head -20

它就會把我們的記憶體資訊列印出來，雖然沒有圖形化界面友善，但是裡面的資訊也足夠我們去觀察和定位問題了

設定了參數HeapDump，OOM的時候會自動産生堆轉儲檔案( java -Xms20M -Xmx20M -XX:+UseParallelGC -XX:+HeapDumpOnOutOfMemoryError FullGCTest )
<font color='red'>很多伺服器備份（高可用），停掉這台伺服器對其他伺服器不影響</font>
下期講解，哈哈哈

【死磕JVM】看完這篇我也會排查JVM記憶體過高了就是玩兒！

前言

具體操作

怎麼知道JVM記憶體過高？

1、top 檢視程序

2、top -Hp 檢視線程

3、jstack

4、轉換16進制

5、jstack用法解析

6、jstack檢視輸出

7、jstack分析死鎖

記憶體監控工具的使用

1、 jconsole

2、 jvisualvm

面試中如何回答定位記憶體溢出(OOM)

jmap

繼續閱讀

話說ReferenceQueue

java｜ this關鍵字

Ubuntu下安裝配置JDK

java 字元串池_什麼是Java字元串池？

使用JVisualVM遠端監控Tomcat

記一次排查線上頻繁FullGC 過程

記一次壓測環境OOM問題排查與解決

秒懂JVM的三大參數類型，就靠這十個小實驗了初級—中級—進階三個級别的大廠面試真題阿裡雲——Java 實習生/初級美團——Java 中級螞蟻金服——Java 進階基礎篇JVM 篇MySQL 篇Redis 篇

JVM垃圾回收（GC）原理

JVM 記憶體模型和垃圾回收（二）：串行垃圾回收器

JDK1.8中JVM記憶體分析

面試曆程（3）

Java學習曆程（7）——Static與this關鍵字Static與this關鍵字

老生常談的java垃圾回收機制

JVM記憶體管理、直接記憶體和垃圾回收

并發專題-Volatile關鍵字實作原理

【死磕JVM】看完這篇我也會排查JVM記憶體過高了 就是玩兒！

前言

具體操作

怎麼知道JVM記憶體過高？

1、top 檢視程序

2、top -Hp 檢視線程

3、jstack

4、轉換16進制

5、jstack用法解析

6、jstack檢視輸出

7、jstack分析死鎖

記憶體監控工具的使用

1、 jconsole

2、 jvisualvm

面試中如何回答定位記憶體溢出(OOM)

jmap

繼續閱讀

【死磕JVM】看完這篇我也會排查JVM記憶體過高了就是玩兒！