使用jmap dump 分析JVM記憶體狀態
檢視整個JVM記憶體狀態
jmap -heap [pid]要注意的是在使用CMS GC 情況下，jmap -heap的執行有可能會導致Java 程序掛起
imac:~ xdcoder$ jmap -heap 783 Attaching to process ID 783, please wait... Debugger attached successfully. Server compiler detected. JVM version is 25.101-b13 using thread-local object allocation. Parallel GC with 8 thread(s) Heap Configuration: MinHeapFreeRatio = 0 MaxHeapFreeRatio = 100 MaxHeapSize = 4294967296 (4096.0MB) NewSize = 89128960 (85.0MB) MaxNewSize = 1431306240 (1365.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 = 19526232 (18.621665954589844MB) free = 47582632 (45.378334045410156MB) 29.09635305404663% used From Space: capacity = 11010048 (10.5MB) used = 5619728 (5.3593902587890625MB) free = 5390320 (5.1406097412109375MB) 51.04181198846726% 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 = 32768 (0.03125MB) free = 179273728 (170.96875MB) 0.01827485380116959% used 4904 interned Strings occupying 388552 bytes.
檢視JVM堆中物件詳細佔用情況
jmap -histo [pid]imac:~ xdcoder$ jmap -histo 783 num #instances #bytes class name ---------------------------------------------- 1: 286511 9516456 [Ljava.lang.Object; 2: 113692 9458248 [C 3: 31510 6249248 [B 4: 132529 4240928 java.io.ObjectStreamClass$WeakClassKey 5: 95868 3834720 java.util.TreeMap$Entry 6: 14097 3740048 [I 7: 60312 1447488 java.lang.String 8: 25273 1213104 java.util.HashMap 9: 46425 1114200 java.lang.Long 10: 10056 1045824 java.io.ObjectStreamClass 11: 10429 500592 java.util.TreeMap 12: 7332 470824 [Ljava.util.Hashtable$Entry; 13: 14637 468384 java.util.Vector 14: 4609 442464 java.lang.management.ThreadInfo 15: 12704 406528 java.util.TreeMap$KeyIterator 16: 15719 377256 java.io.SerialCallbackContext 17: 7325 351600 java.util.Hashtable
匯出整個JVM 中記憶體資訊
jmap -dump:format=b,file=檔名 [pid]
jhat是sun 1.6及以上版本中自帶的一個用於分析JVM 堆DUMP 檔案的工具，基於此工具可分析JVM HEAP 中物件的記憶體佔用情況
jhat -J-Xmx1024M [file]
執行後等待console 中輸入start HTTP server on port 7000 即可使用瀏覽器訪問 IP：7000
eclipse Memory Analyzer
Eclipse 提供的一個用於分析JVM 堆Dump檔案的外掛。藉助這個外掛可檢視物件的記憶體佔用狀況，引用關係，分析記憶體洩露等。
http://www.eclipse.org/mat/
終止執行緒活動
kill -3 [pid]
在Linux 上找到Java所在的程序號，然後執行以上命令，執行緒的相關資訊就輸出到console
檢視堆疊資訊
jstack 是sun JDK 自帶的工具，通過該工具可以看到JVM 中執行緒的執行狀況，包括鎖等待，執行緒是否在執行執行 jstack [pid] ,執行緒的所有堆疊資訊，包括死鎖程序。
相關推薦
使用jmap dump 分析JVM記憶體狀態
檢視整個JVM記憶體狀態 jmap -heap [pid] 要注意的是在使用CMS GC 情況下，jmap -heap的執行有可能會導致Java 程序掛起 imac:~ xdcoder$ jmap -heap 783 Attaching to process I
Java VisualVM分析JVM記憶體溢位
我們經常需要對我們的開發的軟體做各種測試, 軟體對系統資源的使用情況更是不可少, 目前有多個監控工具, 相比JProfiler對系統資源尤其是記憶體的消耗是非常龐大,JDK1.6開始自帶的VisualVM就是不錯的監控工具. 這個工具就在JAVA_HOME\bin\目錄下的jvisualvm.exe, 雙擊
利用MAT分析JVM記憶體問題，從入門到精通（二）
上一篇文章MAT入門到精通（一）介紹了MAT的使用場景和基本概念，這篇文章開始介紹MAT的基本功能，後面還有兩篇，一篇是MAT的高階功能，另一篇是MAT實戰案例分析。 三、歡迎頁 使用MAT開啟一個heap dump檔案，解析完成後，預設會進入歡迎頁，歡迎頁裡包含了一些常見的分析：最大記憶體佔用分析、常見的分
使用jmap和MAT分析JVM堆記憶體
我的一臺生產環境機器每次執行幾天之後就會莫名其妙的宕機，分析日誌之後發現在tomcat剛啟動的時候記憶體佔用比較少，但是執行個幾天之後記憶體佔用越來越大，通過jmap命令可以查詢到一些大物件引用沒有被及時GC，這裡就要求解決記憶體洩露的問題。 Java的記憶體洩露多半是因為
JVM：使用 MAT 工具結合jmap命令分析記憶體洩漏
1、下載MAT工具 2、演示記憶體溢位 新建一個springboot專案，新建一個controller @RestController public class HeapControler { private ArrayList<User> a
使用JMAP dump及分析dump文件
entry 使用權 對象 lang jmap 如果 str OS unable 查看整個JVM內存狀態 jmap -heap [pid]要註意的是在使用CMS GC 情況下，jmap -heap的執行有可能會導致JAVA 進程掛起 查看JVM堆中對象詳細占用情況jmap -
Java分析系列之四：jstack生成的Thread Dump日誌執行緒狀態
前面文章中只分析了Thread Dump日誌檔案的結構，今天針對日誌檔案中 Java EE middleware, third party & custom application Threads 部分執行緒的狀態進行詳細的分析。 目錄 [隱藏] 1 Thread Dump日誌
JVM記憶體分析-清晰明瞭非常容易理解
JVM的記憶體區域劃分 學過C語言的朋友都知道C編譯器在劃分記憶體區域的時候經常將管理的區域劃分為資料段和程式碼段，資料段包括堆、棧以及靜態資料區。那麼在Java
jvm記憶體分析和cpu耗時分析
一、常用的jvm工具 除了常用的命令列工具，常用的圖形化工具及其特點如下： 二、記憶體分析 使用MAT匯入dump檔案 1、Problem Suspect 最可能的問題列表，MAT的分析相對準確，複雜問題需要開發者進一步定位 2、進一步定位到問題類 在問題物件上（大物件上或者海量相同物件上）
JVM記憶體佔用情況深入分析，分分鐘解開你的疑惑
很多同學都問過這個問題，為什麼我的Xmx設定4g，但是TOP命令查詢RES卻佔用5G，6G，甚至10G。這個正常嗎？也可以說正常，也可以說不正常，怎麼判斷？筆者今天就要為你解答這個問題，叫你如何分析JVM佔用的記憶體都分配到了哪裡，哪些地方合理，哪些地方異常。 記憶體分佈 首先
JVM記憶體分析
JDK常用內建工具堆疊分析1 jps：檢視當前JVM中執行程序 jstack：列印執行緒堆疊資訊 jstat：JVM監控統計資訊，包括類的載入和解除安裝情況，新生代和老年代的容量、使用情況等資訊 jmap：列印JVM堆內物件情況 定位pid使用 方法1：直接
使用 jvm-profiler 分析 spark 記憶體使用
文章目錄 背景 jvm-profiler 分析 總結 參考 背景 在生產環境中，為了提高任務提交的響應速度，我們研發了類似 Spark Jobserver 的服務，各種型別的 spark 任務複用已經啟動的 Spark
JVM記憶體模型（二）—— HotSpot虛擬機器分析
上一節我們講了Java虛擬機器的理論記憶體模型，同時我們也提到了，這些只是Java虛擬機器規範中的內容，如果我們要研究一個物件是如何建立、如何佈局等一系列細節問題的時候，我們就必須在具體的虛擬機器中分析，因為不同的虛擬機器的實現是不一樣的，下面我們就選最常用、最普遍的虛擬機器
記一次 JVM 原始碼分析(3.記憶體管理與GC)
簡介 miniJVM 的記憶體管理的實現較為簡單 記憶體分配使用了開源的 ltalloc 庫 GC就是經典的 Mark-Sweep GC 物件分配 物件分配要關注的就兩個過程 New 一個 Java 物件的過程 記憶體塊在堆上分配的過程 物件在 JVM
JVM記憶體洩漏分析總結
1，登入linux伺服器 2，觀察JVM記憶體情況 > jps > jstat -class xxxxx 3，FGC檢視 jstat -gcutil pid js
JVM記憶體堆佈局圖解分析
JAVA能夠實現跨平臺的一個根本原因，是定義了class檔案的格式標準,凡是實現該標準的JVM都能夠載入並解釋該class檔案，據此也可以知道，為啥Java語言的執行速度比C/C++語言執行的速度要慢了,當然原因肯定不止這一個，如在JVM中沒有資料暫存器，指令集使用的是棧來儲存中間資料…等,儘管Jav
通過 thread dump 分析找到高CPU耗用與記憶體溢位的Java程式碼
但實際上，我們是可以幫助他們的，效果好的話還可以定位到具體出問題的程式碼行數，思路如下： 1.通過對CPU與記憶體的耗用情況判斷是否存在問題； 2.通過top命令找到可疑的執行緒的ID； 3.確認應用伺服器的console資訊的輸出位置； 4.通過kill -3 ID 的方式獲取thread dump資訊；
JVM 記憶體洩漏分析筆記
elipse JVM arguementsｄ設定 -Xmx20m -Xms20m -XX:+HeapDumpOnOutOfMemoryError -Dcatalina.base="D:\Workspaces\eclipse\.metadata\.plugins\org.eclipse.wst
jmap分析堆記憶體飆升頻繁fullgc
處理問題： 1、對記憶體使用異常和頻繁fullgc jmap用於列印共享物件的記憶體對映或堆記憶體的詳細資訊 語法格式如下： [option] [option] executable [option] [[email prote
JVM記憶體結構分析
對於Java程式設計師來說，記憶體是由JVM自動管理的，所以一旦出現記憶體洩漏或溢位的問題，不瞭解JVM的記憶體結構和各個記憶體區域的工作職責，將對解決問題帶來很大的麻煩，本文參照周志明的《深入理解Java虛擬機器》，介紹JVM的記憶體結構，比較枯燥，但對知其然，不知所以然的