OM引發你的注意了嗎？

引

曾幾什麼時候java.lang.OutOfMemoryError: Java heap space這句話老是在你的程序中出現，新手search到是什麼問題後就去改了內存大小還老是分不清楚Xms Xmx PermSize MaxNewSize，想的是「總之設大點我就看不到這個錯誤了」。稍微有點經驗的會翻翻code看看什麼地方會出現內存泄露，固然也會改參數，但會有節制的改了。老鳥會使用工具來分析究竟是哪裏形成了泄露？是code的問題仍是內存真的配置不夠？

項目作完後功能測試經過了，拿到客戶那裏跑了沒幾天發現不處理東西了，java傻掉了讓它幹什麼都不動，真不聽話！因而細細的看log發現了java.lang.OutOfMemoryError: Java heap space。性能測試呢？忽略了嗎？

顯

有人也許以爲OM不是多大的事，若是這麼想就錯了！

一個項目從設計、開發、測試、發佈，這中間經歷了多少風雨相信有經歷的朋友確定不會忘記多少個不眠之夜伴隨着你走完了一個項目週期，自覺得把一個精美的產品賣給了客戶，可誰知道這裏面居然有一個潛伏很深的炸彈！說不定何時就會出現炸你一下，讓你手忙腳亂的去找問題點。遇上不能遠程鏈接的，還要去客戶那裏解決，管理嚴格的甚至你帶進去的筆記本都要貼封條全部接口全封，不能聯網，試想身臨其境下，在一個機房孤單的去找OM源頭是什麼感覺？

Function

監控工具：
推薦使用visualvm來監控jvm的內存使用狀況。

既然是要分析jvm，那麼確定得鏈接了，visualvm鏈接jvm有2種方式

1. 在jvm啓動的參數中加入-Dcom.sun.management.jmxremote.port=端口號，jmx鏈接方式

2. 在jdk/bin/執行cp ../jre/lib/security/java.policy ./ 修改java.policy

   grant codeBase "file:{java.home}/../lib/tools.jar"

再啓動jstatd

./jstatd -J-Djava.security.policy=java.policy -J-Djava.rmi.server.hostname=IP

這種是jstatd鏈接方式

分析dump工具：IBM HeapAnalyzer，分析jvm dump出的文件來看具體是哪裏可能存在泄露問題

jdk自帶分析工具：jmap,jstat,jconsole,jps

線程分析：

不知道有沒有碰到這種問題的，看top cpu佔用發現奇高不下，可如今應該什麼都沒幹啊，這是怎麼回事？什麼東西在瘋狂的作事還不讓我知道？每每這時候好多人只能止步了，由於不知道怎麼去追查究竟是誰在佔用cpu。

1. 先使用top肯定你要分析的java進程pid，如：5683

2. 使用jstack導出java的線程列表，如：jstack -l 5683 > 5683.stack

3. 再使用top -H -p PID命令查看java進程裏的子線程的實際佔用，記錄id後和導出的stack文件比對，就能知道具體的是哪裏佔用

---

以上提到的每一種工具，你們都能搜到很詳細的使用說明，這裏就不寫了免得有騙字數之嫌。