首先看一下一個java程序的jmap輸出：

程式碼如下:

[[email protected] ~]$ jmap -heap 837

Attaching to process ID 837, please wait...

Debugger attached successfully.

Server compiler detected.

JVM version is 20.10-b01

using thread-local object allocation.

Parallel GC with 2 thread(s)

Heap Configuration:

MinHeapFreeRatio = 40

MaxHeapFreeRatio = 70

MaxHeapSize = 4294967296 (4096.0MB)

NewSize = 1310720 (1.25MB)

MaxNewSize = 17592186044415 MB

OldSize = 5439488 (5.1875MB)

NewRatio = 2

SurvivorRatio = 8

PermSize = 21757952 (20.75MB)

MaxPermSize = 85983232 (82.0MB)

Heap Usage:

PS Young Generation

Eden Space:

capacity = 41025536 (39.125MB)

used = 18413552 (17.560531616210938MB)

free = 22611984 (21.564468383789062MB)

44.883147900858624% used

From Space:

capacity = 4325376 (4.125MB)

used = 3702784 (3.53125MB)

free = 622592 (0.59375MB)

85.60606060606061% used

To Space:

capacity = 4521984 (4.3125MB)

used = 0 (0.0MB)

free = 4521984 (4.3125MB)

0.0% used

PS Old Generation

capacity = 539820032 (514.8125MB)

used = 108786168 (103.74657440185547MB)

free = 431033864 (411.06592559814453MB)

20.152302906758376% used

PS Perm Generation

capacity = 85983232 (82.0MB)

used = 60770232 (57.95500946044922MB)

free = 25213000 (24.04499053955078MB)

70.67684080542588% used

然後再用ps看看：

程式碼如下:

[[email protected] ~]$ ps -p 837 -o vsz,rss

VSZ RSS

7794992 3047320

關於這裡的幾個generation網上資料一大把就不細說了，這裡算一下求和可以得知前者總共給Java環境分配了644M的記憶體，而ps輸出的VSZ和RSS分別是7.4G和2.9G，這到底是怎麼回事呢?

前面jmap輸出的內容裡，MaxHeapSize 是在命令列上配的，-Xmx4096m，這個java程式可以用到的最大堆記憶體。

VSZ是指已分配的線性空間大小，這個大小通常並不等於程式實際用到的記憶體大小，產生這個的可能性很多，比如記憶體對映，共享的動態庫，或者向系統申請了更多的堆，都會擴充套件線性空間大小，要檢視一個程序有哪些記憶體對映，可以使用 pmap 命令來檢視：

程式碼如下:

[[email protected] ~]$ pmap -x 837

837: java

Address Kbytes RSS Dirty Mode Mapping

0000000040000000 36 4 0 r-x-- java

0000000040108000 8 8 8 rwx-- java

00000000418c9000 13676 13676 13676 rwx-- [ anon ]

00000006fae00000 83968 83968 83968 rwx-- [ anon ]

0000000700000000 527168 451636 451636 rwx-- [ anon ]

00000007202d0000 127040 0 0 ----- [ anon ]

...

...

00007f55ee124000 4 4 0 r-xs- az.png

00007fff017ff000 4 4 0 r-x-- [ anon ]

ffffffffff600000 4 0 0 r-x-- [ anon ]

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

total kB 7796020 3037264 3023928

這裡可以看到很多anon，這些表示這塊記憶體是由mmap分配的。

RSZ是Resident Set Size，常駐記憶體大小，即程序實際佔用的實體記憶體大小， 在現在這個例子當中，RSZ和實際堆記憶體佔用差了2.3G，這2.3G的記憶體組成分別為：

JVM本身需要的記憶體，包括其載入的第三方庫以及這些庫分配的記憶體

NIO的DirectBuffer是分配的native memory

記憶體對映檔案，包括JVM載入的一些JAR和第三方庫，以及程式內部用到的。上面 pmap 輸出的內容裡，有一些靜態檔案所佔用的大小不在Java的heap裡，因此作為一個Web伺服器，趕緊把靜態檔案從這個Web伺服器中人移開吧，放到nginx或者CDN裡去吧。

JIT， JVM會將Class編譯成native程式碼，這些記憶體也不會少，如果使用了Spring的AOP，CGLIB會生成更多的類，JIT的記憶體開銷也會隨之變大，而且Class本身JVM的GC會將其放到Perm Generation裡去，很難被回收掉，面對這種情況，應該讓JVM使用ConcurrentMarkSweep GC，並啟用這個GC的相關引數允許將不使用的class從Perm Generation中移除， 引數配置： -XX:+UseConcMarkSweepGC -X:+CMSPermGenSweepingEnabled -X:+CMSClassUnloadingEnabled，如果不需要移除而Perm Generation空間不夠，可以加大一點： -X:PermSize=256M -X:MaxPermSize=512M

JNI，一些JNI介面呼叫的native庫也會分配一些記憶體，如果遇到JNI庫的記憶體洩露，可以使用valgrind等記憶體洩露工具來檢測

執行緒棧，每個執行緒都會有自己的棧空間，如果執行緒一多，這個的開銷就很明顯了

jmap/jstack 取樣，頻繁的取樣也會增加記憶體佔用，如果你有伺服器健康監控，記得這個頻率別太高，否則健康監控變成致病監控了。

關於JVM的幾個GC堆和GC的情況，可以用jstat來監控，例如監控程序837每隔1000毫秒重新整理一次，輸出20次：

程式碼如下:

[[email protected] ~]$ jstat -gcutil 837 1000 20

S0 S1 E O P YGC YGCT FGC FGCT GCT

0.00 80.43 24.62 87.44 98.29 7101 119.652 40 19.719 139.371

0.00 80.43 33.14 87.44 98.29 7101 119.652 40 19.719 139.371

幾個欄位分別含義如下：

S0

年輕代中第一個survivor(倖存區)已使用的佔當前容量百分比

S1

年輕代中第二個survivor(倖存區)已使用的佔當前容量百分比

E

年輕代中Eden(伊甸園)已使用的佔當前容量百分比

O

old代已使用的佔當前容量百分比

P

perm代已使用的佔當前容量百分比

YGC

從應用程式啟動到取樣時年輕代中gc次數

YGCT

從應用程式啟動到取樣時年輕代中gc所用時間(s)

FGC

從應用程式啟動到取樣時old代(全gc)gc次數

FGCT

從應用程式啟動到取樣時old代(全gc)gc所用時間(s)

GCT

從應用程式啟動到取樣時gc用的總時間(s)

結論

因此如果正常情況下jmap輸出的記憶體佔用遠小於 RSZ，可以不用太擔心，除非發生一些嚴重錯誤，比如PermGen空間滿了導致OutOfMemoryError發生，或者RSZ太高導致引起系統公憤被OOM Killer給幹掉，就得注意了，該加記憶體加記憶體，沒錢買記憶體加交換空間，或者按上面列的組成部分逐一排除。

這幾個記憶體指標之間的關係是：VSZ >> RSZ >> Java程式實際使用的堆大小