javajmap
❶ 如何查看java虛擬機堆內存的參數值
請確保java_home/bin配置到path環境變數下,因為這些工具都在jdk的bin目錄下
jps(JVM Process Status Tool):JVM機進程狀況工具
用來查看基於HotSpot JVM裡面所有進程的具體狀態, 包括進程ID,進程啟動的路徑等等。與unix上的ps類似,用來顯示本地有許可權的java進程,可以查看本地運行著幾個java程序,並顯示他們的進程號。使用jps時,不需要傳遞進程號做為參數。
Jps也可以顯示遠程系統上的JAVA進程,這需要遠程服務上開啟了jstat服務,以及RMI注及服務,不過常用都是對本對的JAVA進程的查看。
命令格式:jps [ options ] [ hostid ]
常用參數說明:
-m 輸出傳遞給main方法的參數,如果是內嵌的JVM則輸出為null。
-l 輸出應用程序主類的完整包名,或者是應用程序JAR文件的完整路徑。
-v 輸出傳給JVM的參數。
例如:
C:\Users\Administrator>jps -lmv
1796 -Dosgi.requiredJavaVersion=1.5 -Xms40m -Xmx512m -XX:MaxPermSize=256m
7340 sun.tools.jps.Jps -lmv -Denv.class.path=.;D:\DevTools\VM\jdk1.6.0_31\\lib\dt.jar;D:\DevTools\VM\jdk1.6.0_31\\lib\tools.jar; -Dapplication.home=D:\DevTools\VM\jdk1.6.0_31 -Xms8m
其中pid為1796的是我的eclipse進程,pid為7340的是jps命令本身的進程
jinfo(Configuration Info for Java):JVM配置信息工具
可以輸出並修改運行時的java 進程的opts。用處比較簡單,用於輸出JAVA系統參數及命令行參數
命令格式:jinfo [ options ] [ pid ]
常用參數說明:
-flag 輸出,修改,JVM命令行參數
例如:
C:\Users\Administrator>jinfo 1796
將會列印出很多jvm運行時參數信息,由於比較長這里不再列印出來,可以自己試試,內容一目瞭然
Jstack(Stack Trace for Java):JVM堆棧跟蹤工具
jstack用於列印出給定的java進程ID或core file或遠程調試服務的Java堆棧信息,如果是在64位機器上,需要指定選項"-J-d64「
命令格式:jstack [ option ] pid
常用參數說明:
-F 當』jstack [-l] pid』沒有相應的時候強制列印棧信息
-l 長列表. 列印關於鎖的附加信息,例如屬於java.util.concurrent的ownable synchronizers列表.
-m 列印java和native c/c++框架的所有棧信息.
-h | -help列印幫助信息
例如:
C:\Users\Administrator>jstack 1796
2013-05-22 11:42:38
Full thread mp Java HotSpot(TM) Client VM (20.6-b01 mixed mode):
"Worker-30" prio=6 tid=0x06514c00 nid=0x1018 in Object.wait() [0x056af000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at org.eclipse.core.internal.jobs.WorkerPool.sleep(WorkerPool.java:188)
- locked <0x1ad84a90> (a org.eclipse.core.internal.jobs.WorkerPool)
at org.eclipse.core.internal.jobs.WorkerPool.startJob(WorkerPool.java:220)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:50)
......
......
......
......
jstat(JVM statistics Monitoriing Tool):JVM統計信息監視工具
對Java應用程序的資源和性能進行實時的命令行的監控,包括了對Heap size和垃圾回收狀況的監控
命令格式:jstat [ option pid [interval [ s | ms ] [count] ] ]
常用參數說明:
-gcutil 輸出已使用空間占總空間的百分比
-gccapacity 輸出堆中各個區域使用到的最大和最小空間
例如:每隔1秒監控jvm內存一次,共監控5次
C:\Users\Administrator>jstat -gccapacity 1796 1s 5
NGCMN NGCMX NGC S0C S1C EC OGCMN OGCMX OGC OC PGCMN PGCMX PGC PC YGC FGC
13632.0 174720.0 40896.0 4032.0 4032.0 32832.0 27328.0 349568.0 81684.0 81684.0 12288.0 262144.0 80640.0 80640.0 42 96
13632.0 174720.0 40896.0 4032.0 4032.0 32832.0 27328.0 349568.0 81684.0 81684.0 12288.0 262144.0 80640.0 80640.0 42 96
13632.0 174720.0 40896.0 4032.0 4032.0 32832.0 27328.0 349568.0 81684.0 81684.0 12288.0 262144.0 80640.0 80640.0 42 96
13632.0 174720.0 40896.0 4032.0 4032.0 32832.0 27328.0 349568.0 81684.0 81684.0 12288.0 262144.0 80640.0 80640.0 42 96
13632.0 174720.0 40896.0 4032.0 4032.0 32832.0 27328.0 349568.0 81684.0 81684.0 12288.0 262144.0 80640.0 80640.0 42 97
C:\Users\Administrator>jstat -gcutil 1796 1s 5
S0 S1 E O P YGC YGCT FGC FGCT GCT
0.00 0.00 0.52 53.35 99.77 42 0.513 99 38.119 38.632
0.00 0.00 0.52 53.35 99.77 42 0.513 99 38.119 38.632
0.00 0.00 0.52 53.35 99.77 42 0.513 99 38.119 38.632
0.00 0.00 0.52 53.35 99.77 42 0.513 99 38.119 38.632
0.00 0.00 0.52 53.35 99.77 42 0.513 99 38.119 38.632
一些術語的中文解釋:
S0C:年輕代中第一個survivor(倖存區)的容量 (位元組)
S1C:年輕代中第二個survivor(倖存區)的容量 (位元組)
S0U:年輕代中第一個survivor(倖存區)目前已使用空間 (位元組)
S1U:年輕代中第二個survivor(倖存區)目前已使用空間 (位元組)
EC:年輕代中Eden(伊甸園)的容量 (位元組)
EU:年輕代中Eden(伊甸園)目前已使用空間 (位元組)
OC:Old代的容量 (位元組)
OU:Old代目前已使用空間 (位元組)
PC:Perm(持久代)的容量 (位元組)
PU:Perm(持久代)目前已使用空間 (位元組)
YGC:從應用程序啟動到采樣時年輕代中gc次數
YGCT:從應用程序啟動到采樣時年輕代中gc所用時間(s)
FGC:從應用程序啟動到采樣時old代(全gc)gc次數
FGCT:從應用程序啟動到采樣時old代(全gc)gc所用時間(s)
GCT:從應用程序啟動到采樣時gc用的總時間(s)
NGCMN:年輕代(young)中初始化(最小)的大小 (位元組)
NGCMX:年輕代(young)的最大容量 (位元組)
NGC:年輕代(young)中當前的容量 (位元組)
OGCMN:old代中初始化(最小)的大小 (位元組)
OGCMX:old代的最大容量 (位元組)
OGC:old代當前新生成的容量 (位元組)
PGCMN:perm代中初始化(最小)的大小 (位元組)
PGCMX:perm代的最大容量 (位元組)
PGC:perm代當前新生成的容量 (位元組)
S0:年輕代中第一個survivor(倖存區)已使用的占當前容量百分比
S1:年輕代中第二個survivor(倖存區)已使用的占當前容量百分比
E:年輕代中Eden(伊甸園)已使用的占當前容量百分比
O:old代已使用的占當前容量百分比
P:perm代已使用的占當前容量百分比
S0CMX:年輕代中第一個survivor(倖存區)的最大容量 (位元組)
S1CMX :年輕代中第二個survivor(倖存區)的最大容量 (位元組)
ECMX:年輕代中Eden(伊甸園)的最大容量 (位元組)
DSS:當前需要survivor(倖存區)的容量 (位元組)(Eden區已滿)
TT: 持有次數限制
MTT : 最大持有次數限制
jmap( Memory Map for Java):JVM內存映像工具
列印出某個java進程(使用pid)內存內的所有『對象』的情況(如:產生那些對象,及其數量)
命令格式:jmap [ option ] pid
常用參數說明:
-mp:[live,]format=b,file=<filename> 使用二進制形式輸出jvm的heap內容到文件中, live子選項是可選的,假如指定live選項,那麼只輸出活的對象到文件.
-histo[:live] 列印每個class的實例數目,內存佔用,類全名信息. VM的內部類名字開頭會加上前綴」*」. 如果live子參數加上後,只統計活的對象數量.
-F 強迫.在pid沒有相應的時候使用-mp或者-histo參數. 在這個模式下,live子參數無效.
例如:以二進制形式輸入當前堆內存映像到文件data.hprof中
jmap -mp:live,format=b,file=data.hprof 1796
生成的文件可以使用jhat工具進行分析,在OOM(內存溢出)時,分析大對象,非常有用
通過使用如下參數啟動JVM,也可以獲取到mp文件:
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=./java_pid<pid>.hprof
在jvm發生內存溢出時生成內存映像文件
jhat(JVM Heap Analysis Tool):JVM堆轉儲快照分析工具
用於對JAVA heap進行離線分析的工具,他可以對不同虛擬機中導出的heap信息文件進行分析,如linux上導出的文件可以拿到WINDOWS上進行分析,可以查找諸如內存方面的問題。
命令格式:jhat mpfile(jmap生成的文件)
例如:分析jmap導出的內存映像
jhat data.hprof
執行成功後,訪問http://localhost:7000即可查看內存信息,
MAT(Memory Analyzer Tool):一個基於Eclipse的內存分析工具
官網: http://www.eclipse.org/mat/
update:http://download.eclipse.org/mat/1.2/update-site/
這是eclipse的一個插件,安裝後可以打開xxx.hprof文件,進行分析,比jhat更方便使用,有些時候由於線上xxx.hprof文件過大,直接使用jhat進行初步分析了,可以的話拷貝到本地分析效果更佳。
圖形化監控工具:
在JDK安裝目錄bin下面有兩個可視化監控工具
1. JConsole(Java Monitoring and Management Console) 基於JMX的可視化管理工具。
2. VisualVM(All-in-one Java Troubleshooting Tool)隨JDK發布的最強大的運行監視和故障處理程序。
推薦使用VisualVM,他有很多插件,可以更方便的監控運行時JVM
❷ JDK命令介紹
命令jps用於列出java進程,直接運行jps不加任何參數,可以列出Java程序的進程ID以及Main函數等名稱。
參數-q指定jps只輸出進程ID,而不輸出類的短名稱
參數-m用於輸出傳遞給Java進程(主函數)的參數
參數 -l用於輸出主函數的完整路徑
參數 -v可以顯示傳遞給JVM的參數
jstat是一個可以用於觀察Java應用程序運行時信息的工具。它的功能非常強大,可以通過它,查看堆信息的詳細使用情況。主要用於監控虛擬機的各種運行狀態信息,如類的裝載、內存、垃圾回收、JIT編譯器等,在沒有GUI的伺服器上,這款工具是首選的一款監控工具。
基本使用語法為:
選項option可以由以下值構成:
-class:顯示ClassLoader的相關信息。
-compiler:顯示JIT編譯的相關信息。
-gc:顯示與GC相關的堆信息。
-gccapacity:顯示各個代的容量及使用情況。
-gccause:顯示垃圾收集相關信息(同-gcutil),同時顯示最後一次或當前正在發生的垃圾收集的誘發原因。
-gcnew:顯示新生代信息。
-gcnewcapacity:顯示新生代大小與使用情況。
-gcold:顯示老年代與永久代的信息。
-gcoldcapacity:顯示老年代的大小。
-gcmetacapacity:顯示元空間的大小。(在java8之前是使用-gcpermcapacity顯示永久代的大小)
-gcutil:顯示垃圾收集信息。
-printcompilation:輸出JIT編譯的方法信息。
以上選項可以輸入 jstat -options 查看。
-t 參數可以在輸出信息前加一個 Timestamp 列,顯示程序的運行時間。
-h 參數可以在周期性數據輸出時,輸出多少行數據後,跟著輸出一個表頭信息。
vmid 參數就是Java進程id。
interval 參數用於指定輸出統計數據的周期,單位為毫秒。
count 用於指定一共輸出多少次數據。
jinfo 可以用來查看正在運行的Java運行程序的擴展參數,甚至支持在運行時修改部分參數。可以用來查看正在運行的 java 應用程序的擴展參數,包括Java System屬性和JVM命令行參數;也可以動態的修改正在運行的 JVM 一些參數。當系統崩潰時,jinfo可以從core文件裡面知道崩潰的Java應用程序的配置信息。
jmap 可以生成Java應用程序的堆快照和對象的統計信息。基本語法為:
option 選項如下:
-mp 生成java堆轉儲快照。格式為: -mp:[live,]format=b,file=,其中live子參數說明是否只mp出存活的對象
-finalizerinfo 顯示在F-Queue中等待Finalizer線程執行finalize方法的對象。只在Linux/Solaris平台下有效
-heap 顯示java堆詳細信息,如使用哪種收集器、參數配置、分代情況等,在Linux/Solaris平台下有效
-histo 顯示堆中對象統計信息,包含類、實例對象、合集容量
-permstat 以ClassLoader為統計口徑顯示永久代內存狀態。只在Linux/Solaris平台下有效
-F 當虛擬機進程對-mp選項沒有相應時。可使用這個選項強制生成mp快照。只在Linux/Solaris平台下有效
使用 jhat 工具可以用於分析Java應用程序的堆快照內容。jhat 在分析完成後,使用HTTP伺服器展示其分析結果。在瀏覽器中訪問 http://localhost:7000/
jstack 可用於導出Java應用程序的線程堆棧。語法為:
-l選項用於列印鎖的附加信息。
jstack 工具會在控制台輸出程序中所有的鎖信息,可以使用重定向將輸出保存到文件。
通過 jstack 工具不僅可以得到線程堆棧,它還能自動進行死鎖檢查,輸出找到的死鎖信息。
之前所述的工具中,只涉及到監控本機的Java應用程序。而在這些工具中,一些監控工具也支持對遠程計算機的監控(如:jps、jstat)。為了啟用遠程監控,則需要配合使用jstatd工具。
命令jstatd是一個RMI服務端程序,它的作用相當於代理伺服器,建立本地計算機與遠程監控工具的通信。jstatd伺服器將本機的Java應用程序信息傳遞到遠程計算機。
JConsole(Java Monitoring and ManagementConsole)工具時JDK自帶的圖形化性能監控工具。通過JConsole工具,可以查看Java應用程序的運行概況,監控堆信息、永久區使用情況、類載入情況等。
❸ java內存查看與分析
業界有很多強大的java profile的工具,比如Jporfiler,yourkit,這些收費的東西我就不想說了,想說的是,其實java自己就提供了很多內存監控的小工具,下面列舉的工具只是一小部分,仔細研究下扒陵jdk的工具,還是蠻有意思的呢:)
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實時診斷,還有手動mp出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 -mp:mp-options pid
(to connect to running process and mp java heap)
mp-options:
format=b binary default
file=file mp heap to file
Example: jmap -mp: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的mp選項,這個選項是將jvm的堆中內存信息輸出到一個文件中,在我本機執行
jmap -mp:file=c:mp.txt 340
注意340是我本機的java進程pid,mp出來的文件比較大有10幾M,而且我只是開了tomcat,跑了一個很簡單的應用,且沒有任何訪問,可以想像,大型繁忙的伺服器上,mp出來的文件該有多大。需要知道的是,mp出來的文件信息是很原始的,絕不適合人直接觀看,而jmap -histo顯示的內容又太簡單,例如只顯示某些類型的對象佔用多大內存,以及這些對象的數量,但是沒有更詳細的信息,例如這些對象分別是由誰創建的。那這么說,mp出來的文件有什麼用呢?當然有用,因為有專門分析jvm的內存mp文件的工具。
5:jhat
上面說了,有很多工具都能分析jvm的內存mp文件,jhat就是sun jdk6及以上版本自帶的工具,位於jdk的bin目錄,執行 jhat -J -Xmx512m [file] ,file就是mp文件路徑。jhat內置一個簡單的web伺服器,此命令執行後,jhat在命令行里顯示分析結果的訪問地址,可以用-port選項指定埠,具體用法可以執行jhat -heap查看幫助信息。訪問指定地址後,就能看到頁面上顯示的信息,比jmap -histo命令顯示的豐富得多,更為詳細。
6:eclipse內存分析器
上面說了jhat,它能分析jvm的mp文件,但是全部是文字顯示,eclipse memory analyzer,是一個eclipse提供用於分析jvm 堆mp的插件,它的分析速度比jhat快,分析結果是圖形界面顯示,比jhat的可讀性更高。其實jvisualvm也可以分析mp文件,也是有圖形界面顯示的。
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毫秒
怎樣選擇工具
上面列舉的一些工具,各有利弊,其實如果在開發環境,使用什麼樣的工具是無所謂的,只要能得到結果就好。但是在生產環境里,卻不能亂選擇,因為這些工具本身就會耗費大量的系統資源,如果在一個生產伺服器壓力很大的時候,貿然執行這些工具,可能會造成很意外的情況。最好不要在伺服器本機監控,遠程監控會比較好一些,但是如果要遠程監控,伺服器端的啟動腳本要加入一些jvm參數,例如用jconsloe遠程監控tomcat或jboss等,都需要設置jvm的jmx參數,如果僅僅只是分析伺服器的內存分配和gc信息,強烈推薦,先用jmap導出伺服器端的jvm的堆mp文件,然後再用jhat,或者jvisualvm,或者eclipse內存分析器來分析內存狀況。
❹ jmap 和mat分析java的內存遠小於實際佔用內存
當然是,其他的也是一樣。
❺ Linux下如何定位JAVA進程直接內存的泄漏及top和jmap查看內存的關系
問題1:top的RES值和JAVA堆內存之間到底是一個什麼關系?
——大概1、2個月有個帖子討論過,挺長的,不過一下子找不到了;總的來說,兩者很難找到非常精確匹配的計算關系,因為兩者統計的口徑是不同的;操作系統關心的是被應用程序所佔用的,而JVM則只是關心堆中被分配出去的;這裡面有JVM自己開銷的、有碎片內存無法使用的、還有已使用完畢待回收的 等等問題。
——總的來說,我覺得如果不是為了底層開發之類的問題,不值得在此問題進行深入研究。
問題2:橋賣如何定位JAVA進程直接內存的泄檔答漏?
——很遺憾,並沒有什麼招數來直接定位,否則內存泄露就不會是一個讓大家聞風喪膽的問題了;各類工具都只行消慧是提供給你一定的手段去發現徵兆、縮小懷疑范圍,沒有說直接幫你定位,那聽起來就不是IT而是神話了。
——常規招數就是:范圍 與 層次,兩個方向不斷通過測試和監控來縮小 懷疑范圍,從而最終定位內存泄漏點。