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

---

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