java 語言, 開發者不能直接控制程序運行內存, 對象的創建都是由類加載器一步步解析, 執行與生成與內存區域中的; 并且jvm有自己的垃圾回收器對內存區域管理, 回收; 但是我們已經可以通過一些工具來在程序運行時查看對應的jvm內存使用情況, 幫助更好的分析與優化我們的代碼;
注: 查看系統里java進程信息
|
1
2
3
4
|
// 查看當前機器上所有運行的java進程名稱與pid(進程編號)jps -l // 顯示指定的jvm進程所有的屬性設置和配置參數jinfo pid |
1 . jmap : 內存占用情況查詢 (位于”jdk_home/bin”目錄下)
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
|
// 查詢某個pid進程對應的應用程序內存占用情況jmap -heap pid// 示例jmap -heap 5940attaching to process id 5940, please wait...debugger attached successfully.server compiler detected.jvm version is 25.92-b14using thread-local object allocation.parallel gc with 4 thread(s)heap configuration: minheapfreeratio = 0 maxheapfreeratio = 100 maxheapsize = 734003200 (700.0mb) newsize = 44040192 (42.0mb) maxnewsize = 244318208 (233.0mb) oldsize = 88080384 (84.0mb) newratio = 2 survivorratio = 8 metaspacesize = 21807104 (20.796875mb) compressedclassspacesize = 1073741824 (1024.0mb) maxmetaspacesize = 17592186044415 mb g1heapregionsize = 0 (0.0mb)heap usage:ps young generationeden space: capacity = 32505856 (31.0mb) used = 13906760 (13.262519836425781mb) free = 18599096 (17.73748016357422mb) 42.782322052986395% usedfrom space: capacity = 6291456 (6.0mb) used = 294912 (0.28125mb) free = 5996544 (5.71875mb) 4.6875% usedto space: capacity = 7340032 (7.0mb) used = 0 (0.0mb) free = 7340032 (7.0mb) 0.0% usedps old generation capacity = 41943040 (40.0mb) used = 6127536 (5.8436737060546875mb) free = 35815504 (34.15632629394531mb) 14.609184265136719% used8535 interned strings occupying 710344 bytes. |
2 . jstack : 進程所包含線程情況查詢 (位于”jdk_home/bin”目錄下)
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
|
// 命令幫助jstach -h // 顯示進程詳情jstack pid// 示例jstach 5940full thread dump java hotspot(tm) 64-bit server vm (25.92-b14 mixed mode):"rmi tcp connection(10)-10.2.13.162" #32 daemon prio=5 os_prio=0 tid=0x00000000179dc000 nid=0x1f60 in object.wait() [0x000000001d7dd000] java.lang.thread.state: timed_waiting (on object monitor) at java.lang.object.wait(native method) at com.sun.jmx.remote.internal.arraynotificationbuffer.fetchnotifications(arraynotificationbuffer.java:449) - locked <0x00000000d462ec18> (a com.sun.jmx.remote.internal.arraynotificationbuffer) at com.sun.jmx.remote.internal.arraynotificationbuffer$sharebuffer.fetchnotifications(arraynotificationbuffer.java:227) at com.sun.jmx.remote.internal.servernotifforwarder.fetchnotifs(servernotifforwarder.java:274) at javax.management.remote.rmi.rmiconnectionimpl$4.run(rmiconnectionimpl.java:1270) at javax.management.remote.rmi.rmiconnectionimpl$4.run(rmiconnectionimpl.java:1268) at javax.management.remote.rmi.rmiconnectionimpl.fetchnotifications(rmiconnectionimpl.java:1274) at sun.reflect.generatedmethodaccessor59.invoke(unknown source) at sun.reflect.delegatingmethodaccessorimpl.invoke(delegatingmethodaccessorimpl.java:43) at java.lang.reflect.method.invoke(method.java:498) at sun.rmi.server.unicastserverref.dispatch(unicastserverref.java:324).............."gc task thread#1 (parallelgc)" os_prio=0 tid=0x0000000002d10000 nid=0x27dc runnable"gc task thread#2 (parallelgc)" os_prio=0 tid=0x0000000002d11800 nid=0x2d84 runnable"gc task thread#3 (parallelgc)" os_prio=0 tid=0x0000000002d13800 nid=0x118 runnable"vm periodic task thread" os_prio=2 tid=0x0000000015ccb000 nid=0x2fd4 waiting on conditionjni global references: 239 |
3 . jstat: 可以實時監測系統資源占用與jvm運行情況 (位于”jdk_home/bin”目錄下)
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
|
// 命令語法結構：usage: jstat -help|-options jstat -<option> [-t] [-h<lines>] <vmid> [<interval> [<count>]]// 參數解釋：options — 選項，我們一般使用 -gcutil 查看gc情況vmid — vm的進程號，即當前運行的java進程號interval– 間隔時間，單位為秒或者毫秒count — 打印次數，如果缺省則打印無數次s0 — heap上的 survivor space 0 區已使用空間的百分比s1 — heap上的 survivor space 1 區已使用空間的百分比e — heap上的 eden space 區已使用空間的百分比o — heap上的 old space 區已使用空間的百分比p — perm space 區已使用空間的百分比ygc — 從應用程序啟動到采樣時發生 young gc 的次數ygct– 從應用程序啟動到采樣時 young gc 所用的時間(單位秒)fgc — 從應用程序啟動到采樣時發生 full gc 的次數fgct– 從應用程序啟動到采樣時 full gc 所用的時間(單位秒)gct — 從應用程序啟動到采樣時用于垃圾回收的總時間(單位秒)//示例jstat -options -class -compiler -gc -gccapacity -gccause -gcmetacapacity -gcnew -gcnewcapacity -gcold -gcoldcapacity -gcutil -printcompilationjstat -class -t 5940timestamp loaded bytes unloaded bytes time6188.4 3898 7178.4 40 58.3 1.78jstat -gcutil 5940 1000 5s0 s1 e o m ccs ygc ygct fgc fgct gct0.00 25.00 98.55 15.37 96.94 94.88 21 0.069 7 0.237 0.3060.00 25.00 99.59 15.37 96.94 94.88 21 0.069 7 0.237 0.3060.00 25.00 99.59 15.37 96.94 94.88 21 0.069 7 0.237 0.3060.00 25.00 100.00 15.37 96.94 94.88 21 0.069 7 0.237 0.3060.00 25.00 100.00 15.37 96.94 94.88 21 0.069 7 0.237 0.306 |
4 . jconsole 以gui的方式更直觀化呈現jvm進程的實時情況, 比如內存占用, 線程執行情況等;
在jdk_home/bin目錄下執行 jconsole.exe 打開圖形化界面, 然后選擇要檢查的進程就可以查看所有相關jvm情況的信息了.
5 . jprofiler 一個付費的商業jvm分析監控工具, 可查看概況, 內存, gc活動, class 狀況, 線程信息, cpu 占用情況, 內存對象信息, 還有數據庫連接等, 是一個非常優秀的分析工具;
以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持服務器之家。
原文鏈接：https://blog.csdn.net/HinstenyHisoka/article/details/54311722
