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文件比对，就能知道具体的是哪里占用

---

以上提到的每一种工具，你们都能搜到很详细的使用说明，这里就不写了免得有骗字数之嫌。