Java 內存查看與分析

首先使用 jps -l 查找當前所有的 Java 進程。

jstat 命令

jstat -gc pid 1000 或者 jstat -gc pid 1000 > out.txt：每隔1000號碼打印一次或導出 GC 的狀態。

S0C S0U：Survivor 0區的大小及使用情況
S1C S1U：Survivor 1區的大小及使用情況
EC EU：Eden 區的大小及使用情況
OC OU：Old 區的大小及使用情況
PC PU：Perm 區的大小及使用情況（Java 8 中取消）
MC MU：Metaspace 區的大小及使用情況（Java 8 中用戶替代 Perm 區）
YGC YGCT：Young Generation Minor GC 的數目及時間
FGC FGCT：Old Generation Full GC 的數目及時間
GCT：GC 總時間 = YGCT + FGCT

 S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT     GCT   
10752.0 10752.0  0.0    0.0   65536.0   3932.2   175104.0     0.0     4480.0 769.8  384.0   75.8       0    0.000   0      0.000    0.000
10752.0 10752.0  0.0    0.0   65536.0   3932.2   175104.0     0.0     4480.0 769.8  384.0   75.8       0    0.000   0      0.000    0.000
10752.0 10752.0  0.0    0.0   65536.0   3932.2   175104.0     0.0     4480.0 769.8  384.0   75.8       0    0.000   0      0.000    0.000
10752.0 10752.0  0.0    0.0   65536.0   3932.2   175104.0     0.0     4480.0 769.8  384.0   75.8       0    0.000   0      0.000    0.000
10752.0 10752.0  0.0    0.0   65536.0   3932.2   175104.0     0.0     4480.0 769.8  384.0   75.8       0    0.000   0      0.000    0.000
10752.0 10752.0  0.0    0.0   65536.0   3932.2   175104.0     0.0     4480.0 769.8  384.0   75.8       0    0.000   0      0.000    0.000

jmap -heap 命令

jmap -heap pid 或者 jmap -heap pid > out.txt：打印或導出堆內存使用情況。
例如：
可以查看：

Heap Configuration 堆的配置
Heap Usage 對的使用情況，包括 Eden 區, From 區，To 區，Old 區，Perm 區（Java 8 中取消）

Attaching to process ID 20128, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.92-b14

using thread-local object allocation.
Parallel GC with 4 thread(s)

Heap Configuration:
   MinHeapFreeRatio         = 0
   MaxHeapFreeRatio         = 100
   MaxHeapSize              = 4271898624 (4074.0MB)
   NewSize                  = 89128960 (85.0MB)
   MaxNewSize               = 1423966208 (1358.0MB)
   OldSize                  = 179306496 (171.0MB)
   NewRatio                 = 2
   SurvivorRatio            = 8
   MetaspaceSize            = 21807104 (20.796875MB)
   CompressedClassSpaceSize = 1073741824 (1024.0MB)
   MaxMetaspaceSize         = 17592186044415 MB
   G1HeapRegionSize         = 0 (0.0MB)

Heap Usage:
PS Young Generation
Eden Space:
   capacity = 67108864 (64.0MB)
   used     = 4026592 (3.840057373046875MB)
   free     = 63082272 (60.159942626953125MB)
   6.000089645385742% used
From Space:
   capacity = 11010048 (10.5MB)
   used     = 0 (0.0MB)
   free     = 11010048 (10.5MB)
   0.0% used
To Space:
   capacity = 11010048 (10.5MB)
   used     = 0 (0.0MB)
   free     = 11010048 (10.5MB)
   0.0% used
PS Old Generation
   capacity = 179306496 (171.0MB)
   used     = 0 (0.0MB)
   free     = 179306496 (171.0MB)
   0.0% used

873 interned Strings occupying 59320 bytes.

jmap -histo 命令

jmap -histo pid 或者 jmap -histo pid > out.txt：打印或導出堆內存中對象的數量及大小。
例如：
可以查看：

class name 類的名稱
instances 類對應的對象的數目
bytes 類對應的對象的大小

 num     #instances         #bytes  class name
----------------------------------------------
   1:           522        3248552  [I
   2:          3282         416008  [C
   3:           217          78016  [B
   4:           581          66208  java.lang.Class
   5:          2292          55008  java.lang.String
   6:           618          32144  [Ljava.lang.Object;
   7:           152          10944  java.lang.reflect.Field
   8:           262           6288  java.lang.StringBuilder
   9:           178           5696  java.io.File
  10:           173           5536  java.util.HashMap$Node
  11:            61           5368  java.lang.reflect.Method
  12:            82           5248  java.net.URL
  13:           110           4400  java.lang.ref.SoftReference
  14:            26           4256  [Ljava.util.HashMap$Node;
  15:           259           4144  java.lang.Integer
  16:           101           4040  java.util.TreeMap$Entry

以上轉載自簡書
作者：專職跑龍套
鏈接：https://www.jianshu.com/p/4462f81e0789

主要分析工具和命令有如下幾種：

1：gc日誌輸出

在jvm啓動參數中加入 -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimestamps -XX:+PrintGCApplicationStopedTime，jvm將會按照這些參數順序輸出gc概要信息，詳細信息，gc時間信息，gc造成的應用暫停時間。如果在剛纔的參數後面加入參數 -Xloggc:文件路徑，gc信息將會輸出到指定的文件中。其他參數還有

-verbose:gc和-XX:+PrintTenuringDistribution等。

2：jconsole

jconsole是jdk自帶的一個內存分析工具，它提供了圖形界面。可以查看到被監控的jvm的內存信息，線程信息，類加載信息，MBean信息。

jconsole位於jdk目錄下的bin目錄，在windows下是jconsole.exe，在unix和linux下是jconsole.sh，jconsole可以監控本地應用，也可以監控遠程應用。要監控本地應用，執行jconsole pid，pid就是運行的java進程id，如果不帶上pid參數，則執行jconsole命令後，會看到一個對話框彈出，上面列出了本地的java進程，可以選擇一個進行監控。如果要遠程監控，則要在遠程服務器的jvm參數里加入一些東西，因爲jconsole的遠程監控基於jmx的，關於jconsole詳細用法，請見專門介紹jconsle的文章，我也會在博客裏專門詳細介紹jconsole。

3:jviusalvm

在JDK6 update 7之後，jdk推出了另外一個工具：jvisualvm,java可視化虛擬機，它不但提供了jconsole類似的功能，還提供了jvm內存和cpu實時診斷，還有手動dump出jvm內存情況，手動執行gc。

和jconsole一樣，運行jviusalvm，在jdk的bin目錄下執行jviusalvm，windows下是jviusalvm.exe,linux和unix下是jviusalvm.sh。

4：jmap

jmap是jdk自帶的jvm內存分析的工具，位於jdk的bin目錄。jdk1.6中jmap命令用法：

Usage:

jmap -histo <pid>

（to connect to running process and print histogram of java object heap

jmap -dump:<dump-options> <pid>

（to connect to running process and dump java heap）

dump-options:

format=b binary default

file=<file> dump heap to <file>

Example: jmap -dump:format=b,file=heap.bin <pid>

jmap -histo <pid>在屏幕上顯示出指定pid的jvm內存狀況。以我本機爲例，執行該命令，屏幕顯示：

num #instances #bytes class name

----------------------------------------------

1: 24206 2791864 <constMethodKlass>

2: 22371 2145216 [C

3: 24206 1940648 <methodKlass>

4: 1951 1364496 <constantPoolKlass>

5: 26543 1282560 <symbolKlass>

6: 6377 1081744 [B

7: 1793 909688 <constantPoolCacheKlass>

8: 1471 614624 <instanceKlassKlass>

9: 14581 548336 [Ljava.lang.Object;

10: 3863 513640 [I

11: 20677 496248 java.lang.String

12: 3621 312776 [Ljava.util.HashMap$Entry;

13: 3335 266800 java.lang.reflect.Method

14: 8256 264192 java.io.ObjectStreamClass$WeakClassKey

15: 7066 226112 java.util.TreeMap$Entry

16: 2355 173304 [S

17: 1687 161952 java.lang.Class

18: 2769 150112 [[I

19: 3563 142520 java.util.HashMap

20: 5562 133488 java.util.HashMap$Entry

Total 239019 17140408

爲了方便查看，我刪掉了一些行。從上面的信息很容易看出，#instance指的是對象數量，#bytes指的是這些對象佔用的內存大小，class name指的是對象類型。

再看jmap的dump選項，這個選項是將jvm的堆中內存信息輸出到一個文件中，在我本機執行

jmap -dump:file=c:dump.txt 340

注意340是我本機的java進程pid，dump出來的文件比較大有10幾M，而且我只是開了tomcat，跑了一個很簡單的應用，且沒有任何訪問，可以想象，大型繁忙的服務器上，dump出來的文件該有多大。需要知道的是，dump出來的文件信息是很原始的，絕不適合人直接觀看，而jmap -histo顯示的內容又太簡單，例如只顯示某些類型的對象佔用多大內存，以及這些對象的數量，但是沒有更詳細的信息，例如這些對象分別是由誰創建的。那這麼說，dump出來的文件有什麼用呢？當然有用，因爲有專門分析jvm的內存dump文件的工具。

5：jhat

上面說了，有很多工具都能分析jvm的內存dump文件，jhat就是sun jdk6及以上版本自帶的工具，位於jdk的bin目錄，執行 jhat -J -Xmx512m [file] ，file就是dump文件路徑。jhat內置一個簡單的web服務器，此命令執行後，jhat在命令行裏顯示分析結果的訪問地址，可以用-port選項指定端口，具體用法可以執行jhat -heap查看幫助信息。訪問指定地址後，就能看到頁面上顯示的信息，比jmap -histo命令顯示的豐富得多，更爲詳細。

6：eclipse內存分析器

上面說了jhat，它能分析jvm的dump文件，但是全部是文字顯示，eclipse memory analyzer，是一個eclipse提供用於分析jvm 堆dump的插件，它的分析速度比jhat快，分析結果是圖形界面顯示，比jhat的可讀性更高。其實jvisualvm也可以分析dump文件，也是有圖形界面顯示的。

7：jstat

如果說jmap傾向於分析jvm內存中對象信息的話，那麼jsta就是傾向於分析jvm內存的gc情況。都是jvm內存分析工具，但顯然，它們是從不同維度來分析的。jsat常用的參數有很多，如 -gc,-gcutil,-gccause，這些選項具體作用可查看jsat幫助信息，我經常用-gcutil，這個參數的作用不斷的顯示當前指定的jvm內存的垃圾收集的信息。

我在本機執行 jstat -gcutil 340 10000，這個命令是每個10秒鐘輸出一次jvm的gc信息，10000指的是間隔時間爲10000毫秒。屏幕上顯示如下信息（我只取了第一行，因爲是按的一定頻率顯示，所以實際執行的時候，會有很多行）：

S0 S1 E O P YGC YGCT FGC FGCT GCT

54.62 0.00 42.87 43.52 86.24 1792 5.093 33 7.670 12.763

額……怎麼說呢，要看懂這些信息代表什麼意思，還必須對jvm的gc機制有一定的瞭解才行啊。其實如果對sun的 hot spot jvm的gc比較瞭解的人，應該很容易看懂這些信息，但是不清楚gc機制的人，有點莫名其妙，所以在這裏我還是先講講sun的jvm的gc機制吧。說到gc，其實不僅僅只是java的概念，其實在java之前，就有很多語言有gc的概念了，gc嘛就是垃圾收集的意思，更多的是一種算法性的東西，而跟具體語言沒太大關係，所以關於gc的歷史，gc的主流算法我就不講了，那扯得太遠了，扯得太遠了就是扯淡。sun現在的jvm，內存的管理模型是分代模型，所以gc當然是分代收集了。分代是什麼意思呢？就是將對象按照生命週期分成三個層次，分別是：新生代，舊生代，持久代。對象剛開始分配的時候，大部分都在新生代，當新生代gc提交被觸發後了，執行一次新生代範圍內的gc，這叫minor gc，如果執行了幾次minor gc後，還有對象存活，將這些對象轉入舊生代，因爲這些對象已經經過了組織的重重考驗了哇。舊生代的gc頻率會更低一些，如果舊生代執行了gc，那就是full gc，因爲不是局部gc，而是全內存範圍的gc，這會造成應用停頓，因爲全內存收集，必須封鎖內存，不許有新的對象分配到內存，持久代就是一些jvm期間，基本不會消失的對象，例如class的定義，jvm方法區信息，例如靜態塊。需要主要的是，新生代裏又分了三個空間：eden，susvivor0，susvivor1，按字面上來理解，就是伊甸園區，倖存1區，倖存2區。新對象分配在eden區中，eden區滿時，採用標記-複製算法，即檢查出eden區存活的對象，並將這些對象複製到是s0或s1中，然後清空eden區。jvm的gc說開來，不只是這麼簡單，例如還有串行收集，並行收集，併發收集，還有着名的火車算法，不過那說得太遠了，現在對這個有大致瞭解就好。說到這裏，再來看一下上面輸出的信息：

S0 S1 E O P YGC YGCT FGC FGCT GCT

54.62 0.00 42.87 43.52 86.24 1792 5.093 33 7.670 12.763

S0:新生代的susvivor0區，空間使用率爲5462%

S1:新生代的susvivor1區，空間使用率爲0.00%（因爲還沒有執行第二次minor收集）

E:eden區，空間使用率42.87%

O:舊生代，空間使用率43.52%

P:持久帶，空間使用率86.24%

YGC:minor gc執行次數1792次

YGCT:minor gc耗費的時間5.093毫秒

FGC:full gc執行次數33

FGCT:full gc耗費的時間7.670毫秒

GCT:gc耗費的總時間12.763毫秒

當然也可以配合linux自帶的命令進行排查：

1. ps命令

ps -aux | sort -k4nr | head -N

*命令詳解：
1. head：-N可以指定顯示的行數，默認顯示10行。
2. ps：參數a指代all——所有的進程，u指代userid——執行該進程的用戶id，x指代顯示所有程序，不以終端機來區分。ps -aux的輸出格式如下：

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0  19352  1308 ?        Ss   Jul29   0:00 /sbin/init
root         2  0.0  0.0      0     0 ?        S    Jul29   0:00 [kthreadd]
root         3  0.0  0.0      0     0 ?        S    Jul29   0:11 [migration/0]

3. sort -k4nr中（k代表從根據哪一個關鍵詞排序，後面的數字4表示按照第四列排序；n指代numberic sort，根據其數值排序；r指代reverse，這裏是指反向比較結果，輸出時默認從小到大，反向後從大到小。）。本例中，可以看到%MEM在第4個位置，根據%MEM的數值進行由大到小的排序。-k3表示按照cpu佔用率排序。

2. top工具

命令行輸入top回車，然後按下大寫M按照memory排序，按下大寫P按照CPU排序。

怎樣選擇工具

上面列舉的一些工具，各有利弊，其實如果在開發環境，使用什麼樣的工具是無所謂的，只要能得到結果就好。但是在生產環境裏，卻不能亂選擇，因爲這些工具本身就會耗費大量的系統資源，如果在一個生產服務器壓力很大的時候，貿然執行這些工具，可能會造成很意外的情況。最好不要在服務器本機監控，遠程監控會比較好一些，但是如果要遠程監控，服務器端的啓動腳本要加入一些jvm參數，例如用jconsloe遠程監控tomcat或jboss等，都需要設置jvm的jmx參數，如果僅僅只是分析服務器的內存分配和gc信息，強烈推薦，先用jmap導出服務器端的jvm的堆dump文件，然後再用jhat，或者jvisualvm，或者eclipse內存分析器來分析內存狀況。

以下摘自簡書

作者：佔小狼
鏈接：https://www.jianshu.com/p/6690f7e92f27
來源：簡書

記得前段時間，同事說他們測試環境的服務器cpu使用率一直處於100%，本地又沒有什麼接口調用，爲什麼會這樣？cpu使用率居高不下，自然是有某些線程一直佔用着cpu資源，那又如何查看佔用cpu較高的線程？

當然一個正常的程序員不會寫出上述代碼，這裏只是爲了讓一個線程佔用較高的cpu資源。

top命令

在linux環境下，可以通過top命令查看各個進程的cpu使用情況，默認按cpu使用率排序

1、上圖中可以看出pid爲23344的java進程佔用了較多的cpu資源；
2、通過top -Hp 23344可以查看該進程下各個線程的cpu使用情況；

上圖中可以看出pid爲25077的線程佔了較多的cpu資源，利用jstack命令可以繼續查看該線程當前的堆棧狀態。

jstack命令

通過top命令定位到cpu佔用率較高的線程之後，繼續使用jstack pid命令查看當前java進程的堆棧狀態

jstack命令生成的thread dump信息包含了JVM中所有存活的線程，爲了分析指定線程，必須找出對應線程的調用棧，應該如何找？

在top命令中，已經獲取到了佔用cpu資源較高的線程pid，將該pid轉成16進制的值，在thread dump中每個線程都有一個nid，找到對應的nid即可；隔段時間再執行一次stack命令獲取thread dump，區分兩份dump是否有差別，在nid=0x246c的線程調用棧中，發現該線程一直在執行JstackCase類第33行的calculate方法，得到這個信息，就可以檢查對應的代碼是否有問題。

通過thread dump分析線程狀態

除了上述的分析，大多數情況下會基於thead dump分析當前各個線程的運行情況，如是否存在死鎖、是否存在一個線程長時間持有鎖不放等等。

在dump中，線程一般存在如下幾種狀態：
1、RUNNABLE，線程處於執行中
2、BLOCKED，線程被阻塞
3、WAITING，線程正在等待

實例1：多線程競爭synchronized鎖

很明顯：線程1獲取到鎖，處於RUNNABLE狀態，線程2處於BLOCK狀態
1、locked <0x000000076bf62208>說明線程1對地址爲0x000000076bf62208對象進行了加鎖；
2、waiting to lock <0x000000076bf62208> 說明線程2在等待地址爲0x000000076bf62208對象上的鎖；
3、waiting for monitor entry [0x000000001e21f000]說明線程1是通過synchronized關鍵字進入了監視器的臨界區，並處於"Entry Set"隊列，等待monitor，具體實現可以參考深入分析synchronized的JVM實現；

實例2：通過wait掛起線程

static class Task implements Runnable {
    @Override
    public void run() {
        synchronized (lock) {
            try {
                lock.wait();
                //TimeUnit.SECONDS.sleep(100000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }
}

dump結果

線程1和2都處於WAITING狀態
1、線程1和2都是先locked <0x000000076bf62500>，再waiting on <0x000000076bf62500>，之所以先鎖再等同一個對象，是因爲wait方法需要先通過synchronized獲得該地址對象的monitor；
2、waiting on <0x000000076bf62500>說明線程執行了wait方法之後，釋放了monitor，進入到"Wait Set"隊列，等待其它線程執行地址爲0x000000076bf62500對象的notify方法，並喚醒自己，具體實現可以參考深入分析Object.wait/notify實現機制；

wudiazu

發佈了5 篇原創文章 · 獲贊 18 · 訪問量 9萬+

私信關注

java內存、垃圾回收查看與分析

Java 內存查看與分析

jstat 命令

jmap -heap 命令

jmap -histo 命令

1. ps命令

2. top工具

top命令

jstack命令

通過thread dump分析線程狀態

實例1：多線程競爭synchronized鎖

實例2：通過wait掛起線程

dump結果

[轉帖]使用NMT和pmap解決JVM資源泄漏問題原創

Python實現大麥網搶票的四大關鍵技術點解析

Python 安裝庫指令大全

salesforce零基礎學習（一百三十八）零碎知識點小總結（十）

一款開源的.NET程序集反編譯、編輯和調試神器

關於接口協議，你必須要知道這些！

基於 Milvus + LlamaIndex 實現高級 RAG

【2024-05-21】以茶會友

linux命令之vi

機器學習中的範數規則化之（二）核範數與規則項參數選擇

談談Java內存管理

Spring事件機制詳解

pandas數據清洗，排序，索引設置，數據選取

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結