一个大型的Java项目也许从开发到测试结束并可能不能未发现一些重大的问题，但是在生产环境中还是会出现一些非常棘手的问题，如内存泄漏直接导致服务宕机，遇到这样的问题对于一个经验尚浅的开发人员来说难度非常大，好的一点是JVM 能够记录下问题发生时系统的部分运行状态，并将其存储在堆转储 (Heap Dump) 文件中，从而为我们分析和诊断问题提供了重要的依据。要生存Heap Dump文件的前提是需要在服务的启动脚本添加一些jvm参数。
注：本文基于JDK 7，对于其他JDK版本用法也是类似的。
接下来将讲解如何生产Heap Dump文件到如何使用Memory Analyzer Tool分析Heap Dump文件。Memory Analyzer Tool是一款“傻瓜式“的堆转储文件分析工具，通过该工具可以生成一个专业的分析报告，从而准确的定位到问题的所在位置。
1、安装 Memory Analyzer Tool
方式一：直接从官网下载程序包 http://www.eclipse.org/mat/downloads.php ，解压可直接使用。
方式二：在Eclipse中通过 Help -> Install New Software，输入地址http://download.eclipse.org/mat/1.9.0/update-site/进行安装
方式三：Eclipse 的可插拔式插件安装方式
2、配置环境参数
为了更有效率的使用Memory Analyzer Tool，还需要做一些配置工作。因为通常而言，分析一个堆转储文件需要消耗很多的堆空间，为了保证分析的效率和性能，在有条件的情况下，建议分配给 Memory Analyzer Tool尽可能多的内存资源。可以采用如下两种方式来分配内存更多的内存资源给 Memory Analyzer Tool 。
方式一：修改启动参数 MemoryAnalyzer.exe -vmargs -Xmx4g
方式二：编辑文件 MemoryAnalyzer.ini，在里面添加类似信息 -vmargs – Xmx4g
3、如何获得堆转储文件
方式一：在Eclipse中配置JVM启动参数 -XX:+HeapDumpOnOutOfMemoryError
方式二：通过JDK自带的工具jmap，jconsole来获得一个堆转储文件
这里使用方式一来获得。
4、Java中OutOfMemoryError(内存溢出)的三种情况及解决办法
在解决java内存溢出问题之前，需要对jvm（java虚拟机）的内存管理有一定的认识。jvm管理的内存大致包括三种不同类型的内存区域：PermanentGeneration space（永久保存区域）、Heap space(堆区域)、JavaStacks(Java栈）。其中永久保存区域主要存放Class（类）和Meta的信息，Class第一次被Load的时候被放入PermGenspace区域，Class需要存储的内容主要包括方法和静态属性。堆区域用来存放Class的实例（即对象），对象需要存储的内容主要是非静态属性。每次用new创建一个对象实例后，对象实例存储在堆区域中，这部分空间也被jvm的垃圾回收机制管理。而Java栈跟大多数编程语言包括汇编语言的栈功能相似，主要基本类型变量以及方法的输入输出参数。Java程序的每个线程中都有一个独立的堆栈。容易发生内存溢出问题的内存空间包括：PermanentGeneration space和Heap space。
第一种 OutOfMemoryError：PermGenspace
发生这种问题的原意是程序中使用了大量的jar或class，使java虚拟机装载类的空间不够，与PermanentGeneration space有关。解决这类问题有以下两种办法：
1、增加java虚拟机中的XX:PermSize和XX:MaxPermSize参数的大小，其中XX:PermSize是初始永久保存区域大小，XX:MaxPermSize是最大永久保存区域大小。如针对tomcat，在catalina.sh或catalina.bat文件中一系列环境变量名说明结束处（大约在70行左右） 增加一行：
JAVA_OPTS=" -XX:PermSize=64M -XX:MaxPermSize=128m"
如果是windows服务器还可以在系统环境变量中设置。感觉用tomcat发布sprint+struts+hibernate架构的程序时很容易发生这种内存溢出错误。使用上述方法，我成功解决了部署ssh项目的tomcat服务器经常宕机的问题。
2、清理应用程序中web-inf/lib下的jar，如果tomcat部署了多个应用，很多应用都使用了相同的jar，可以将共同的jar移到tomcat共同的lib下，减少类的重复加载。这种方法是网上部分人推荐的，我没试过，但感觉减少不了太大的空间，最靠谱的还是第一种方法。
第二种 OutOfMemoryError：Java heap space
发生这种问题的原因是java虚拟机创建的对象太多，在进行垃圾回收之间，虚拟机分配的到堆内存空间已经用满了，与Heapspace有关。解决这类问题有两种思路：
1、检查程序，看是否有死循环或不必要地重复创建大量对象。找到原因后，修改程序和算法。我以前写一个使用K-Means文本聚类算法对几万条文本记录（每条记录的特征向量大约10来个）进行文本聚类时，由于程序细节上有问题，就导致了Java heap space的内存溢出问题，后来通过修改程序得到了解决。
2、增加Java虚拟机中Xms（初始堆大小）和Xmx（最大堆大小）参数的大小。如：set JAVA_OPTS= -Xms256m-Xmx1024m
第三种 OutOfMemoryError：unable to create new nativethread
在java应用中，有时候会出现这样的错误：OutOfMemoryError: unable to create new native thread.这种怪事是因为JVM已经被系统分配了大量的内存(比如1.5G)，并且它至少要占用可用内存的一半。有人发现，在线程个数很多的情况下，你分配给JVM的内存越多，那么，上述错误发生的可能性就越大。
那么是什么原因造成这种问题呢？
每一个32位的进程最多可以使用2G的可用内存，因为另外2G被操作系统保留。这里假设使用1.5G给JVM，那么还余下500M可用内存。这500M内存中的一部分必须用于系统dll的加载，那么真正剩下的也许只有400M，现在关键的地方出现了：当你使用Java创建一个线程，在JVM的内存里也会创建一个Thread对象，但是同时也会在操作系统里创建一个真正的物理线程(参考JVM规范)，操作系统会在余下的400兆内存里创建这个物理线程，而不是在JVM的1500M的内存堆里创建。在jdk1.4里头，默认的栈大小是256KB，但是在jdk1.5里头，默认的栈大小为1M每线程，因此，在余下400M的可用内存里边我们最多也只能创建400个可用线程。
这样结论就出来了，要想创建更多的线程，你必须减少分配给JVM的最大内存。还有一种做法是让JVM宿主在你的JNI代码里边。
给出一个有关能够创建线程的最大个数的估算公式：
(MaxProcessMemory - JVMMemory - ReservedOsMemory) / (ThreadStackSize) = Number of threads
对于jdk1.5而言，假设操作系统保留120M内存：
1.5GB JVM: (2GB-1.5Gb-120MB)/(1MB) = ~380 threads
1.0GB JVM: (2GB-1.0Gb-120MB)/(1MB) = ~880 threads
对于栈大小为256KB的jdk1.4而言，
1.5GB allocated to JVM: ~1520 threads
1.0GB allocated to JVM: ~3520 threads
对于这个异常我们首先需要判断下，发生内存溢出时进程中到底都有什么样的线程，这些线程是否是应该存在的，是否可以通过优化来降低线程数； 另外一方面默认情况下java为每个线程分配的栈内存大小是1M，通常情况下，这1M的栈内存空间是足足够用了，因为在通常在栈上存放的只是基础类型的数据或者对象的引用，这些东西都不会占据太大的内存， 我们可以通过调整jvm参数，降低为每个线程分配的栈内存大小来解决问题，例如在jvm参数中添加-Xss128k将线程栈内存大小设置为128k。
5、实例分析 编写例子获取Heap Dump文件
import java.util.ArrayList;
import java.util.List;
public class HeapDumpMain {
static class OOMHeapDumpObject{
String str ="1234567890";
}
public static void main(String[] args) {
List<OOMHeapDumpObject> ooms = new ArrayList<OOMHeapDumpObject>();
while (true) {
ooms.add(new OOMHeapDumpObject());
}
}
}
Eclipse中VM参数配置如下
-Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError
运行示例代码即可生成Heap Dump文件
一般在项目的当目前目录下
运行Memory Analyzer Tool（个人比较喜欢独立运行的Memory Analyzer Tool）
报告分析
内存使用整体情况
直接点击下方的 Reports->Leak Suspects 链接来生成报告，查看导致内存泄露的罪魁祸首
从图上可以清晰地看到一个可疑对象消耗了系统近 98% 的内存。再往下看饼图下方文字简短描述了大量的内存是由属于Object实例的对象所消耗的，system class loader 负责加载这个对象。也许从这里还不能找出内存泄漏的具体原因，接着往下看。点击下图标志的地方
可以看到如下
备注：
Shallow Heap 为对象自身占用的内存大小，不包括它引用的对象。
Retained Heap 为当前对象大小 + 当前对象可直接或间接引用到的对象的大小总和
在这张图上可以清楚的看到，这个对象集合中保存了大量 OOMHeapDumpObject 对象的引用，就是它导致的内存泄露。这时就需要排查程序中为什么会创建这么多OOMHeapDumpObject 对象，然后解决问题。
本文转自 https://cloud.tencent.com/developer/article/1480977，如有侵权，请联系删除。