java性能分析(转)

一直赞叹Sun对待技术的严谨和优雅（可怜的Sun）。Sun JDK中Java库的源代码，连注释都清清楚楚、规规范范，javadoc注解的使用也一丝不苟，读起来很熟舒服。因此，在日常工作和学习中，经常读读 Java库的源代码，不亦乐乎？如果遇到诡异问题，源代码的帮助就更大了。     闲话少说，回归正题。这几天，一直在为Java的“内存泄露”问题纠结。Java应用程序占用的内存在不断的、有规律的上涨，最终超过了监控阈值。福尔摩斯不得不出手了！     说起Java的内存泄露，其实定义不是那么明确。首先，如果JVM没有bug，那么理论上是不会出现“无法回收的堆空间”，也就是说C/C++中的那种内存泄露在Java中不存在的。其次，如果由于Java程序一直持有某个对象的引用，但是从程序逻辑上看，这个对象再也不会被用到了，那么我们可以认为这个对象被泄露了。如果这样的对象数量很多，那么很明显，大量的内存空间就被泄露（“浪费”更准确一些）了。     不过，本文要说的内存泄露，并不属于上述原因，因此打上了引号。其具体原因，确实出乎意料。欲知详情，请看下面讲解。 分析内存泄露的一般步骤     如果发现Java应用程序占用的内存出现了泄露的迹象，那么我们一般采用下面的步骤分析 把Java应用程序使用的heap dump下来 使用Java heap分析工具，找出内存占用超出预期（一般是因为数量太多）的嫌疑对象 必要时，需要分析嫌疑对象和其他对象的引用关系。 查看程序的源代码，找出嫌疑对象数量过多的原因。 dump heap     如果Java应用程序出现了内存泄露，千万别着急着把应用杀掉，而是要保存现场。如果是互联网应用，可以把流量切到其他服务器。保存现场的目的就是为了把运行中JVM的heap dump下来。     JDK自带的jmap工具，可以做这件事情。它的执行方法是： Java代码 jmap -dump:format=b,file=heap.bin   jmap -dump:format=b,file=heap.bin     format=b的含义是，dump出来的文件时二进制格式。     file-heap.bin的含义是，dump出来的文件名是heap.bin。     就是JVM的进程号。     （在linux下）先执行ps aux | grep java，找到JVM的pid；然后再执行jmap -dump:format=b,file=heap.bin ，得到heap dump文件。 analyze heap     将二进制的heap dump文件解析成human-readable的信息，自然是需要专业工具的帮助，这里推荐Memory Analyzer 。     Memory Analyzer，简称MAT，是Eclipse基金会的开源项目，由SAP和IBM捐助。巨头公司出品的软件还是很中用的，MAT可以分析包含数亿级对象的heap、快速计算每个对象占用的内存大小、对象之间的引用关系、自动检测内存泄露的嫌疑对象，功能强大，而且界面友好易用。     MAT的界面基于Eclipse开发，以两种形式发布：Eclipse插件和Eclipe RCP。MAT的分析结果以图片和报表的形式提供，一目了然。总之个人还是非常喜欢这个工具的。下面先贴两张官方的screenshots：     言归正传，我用MAT打开了heap.bin，很容易看出，char[]的数量出其意料的多，占用90%以上的内存 。一般来说，char[]在JVM确实会占用很多内存，数量也非常多，因为String对象以char[]作为内部存储。但是这次的char[]太贪婪了，仔细一观察，发现有数万计的char[]，每个都占用数百K的内存 。这个现象说明，Java程序保存了数以万计的大String对象 。结合程序的逻辑，这个是不应该的，肯定在某个地方出了问题。

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/24537613/viewspace-672466/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/24537613/viewspace-672466/