1. 定义

1
、内存泄漏：一般可以理解为系统资源（各方面的资源，堆、栈、线程等）在错误使用的情况下，导致使用完毕的资源无法回收（或没有回收）,
从而造成那部分内存不可用的情况。

2
、内存溢出：指内存不够使用而抛出异常，内存泄露是其形成的原因之一。

2. 危害

会导致新的资源分配请求无法完成，引起系统错误，最后导致系统崩溃。

3. 内存泄漏分类

类型	描述
常发性内存泄漏	发生内存泄漏的代码会被多次执行到，每次被执行的时候都会导致一块内存泄漏
偶发性内存泄漏	发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生。常发性和偶发性是相对的。对于特定的环境，偶发性的也许就变成了常发性的
一次性内存泄漏	发生内存泄漏的代码只会被执行一次，或者由于算法上的缺陷，导致总会有一块仅且一块内存发生泄漏。比如，在类的构造函数中分配内存，在析构函数中却没有释放该内存，所以内存泄漏只会发生一次
隐式内存泄漏	程序在运行过程中不停的分配内存，但是直到结束的时候才释放内存。严格的说这里并没有发生内存泄漏，因为最终程序释放了所有申请的内存。但是对于一个服务器程序，需要运行几天，几周甚至几个月，不及时释放内存也可能导致最终耗尽系统的所有内存。所以，我们称这类内存泄漏为隐式内存泄漏

4. 内存泄露/溢出发生的区域 

内存区域	发生情况	备注
程序计数器	不可能
虚拟机栈<VM Stack>	Y
本地方法栈	Y
非堆内存	Y	即方法区、持久代
运行时常量池< Runtime Constant Pool >	Y
本机直接内存< Direct Memory >	Y
堆内存	Y

5. 内存溢出异常

内存区域	异常
虚拟机栈<VM Stack>	java.lang.StackOverflowError
本地方法栈	java.lang.OutOfMemoryError: unable to create new native thread
非堆内存	java.lang.OutOfMemoryError:PermGen space
运行时常量池< Runtime Constant Pool >	java.lang.OutOfMemoryError: PermGen space
本机直接内存< Direct Memory >	java.lang.OutOfMemoryError
堆内存	java.lang.OutOfMemoryError: Java heap space

6. 内存溢出常见原因

异常	常见原因	解决办法
java.lang.StackOverflowError	线程栈的溢出，要么是方法调用层次过多（比如存在无限递归调用），要么是线程栈太小	增大线程栈 优化程序设计，减少方法调用层次
java.lang.OutOfMemoryError: unable to create new native thread	Stack空间不足以创建额外的线程，要么是创建的线程过多，要么是Stack空间确实小	1.通过-Xss启动参数减少单个线程栈大小，这样便能开更多线程（当然不能太小，太小会出现StackOverflowError） 2.通过-Xms -Xmx 两参数减少Heap大小，将内存让给Stack（前提是保证Heap空间够用）
java.lang.OutOfMemoryError:PermGen space	Permanent Generation空间不足，不能加载额外的类，可能为运行时常量池溢出或持久代溢出。 大量动态反射生成的类不断被加载可导致此错误	调整PermGen内存
java.lang.OutOfMemoryError	有可能本机直接内存不够用
java.lang.OutOfMemoryError: Java heap space	1、内存泄露 2、堆内存分配不合理引起溢出 3、创建一个占用内存过大的对象	1、调整堆内存 2、根据垃圾回收前后情况对比，同时根据对象引用情况（常见的集合对象引用）分析，基本都可以找到泄漏点，然后修改程序错误

7. 发生内存泄露的情形

Java
内存泄露根本原因是什么呢？

答：长生命周期的对象持有短生命周期对象的引用就很可能发生内存泄露，尽管短生命周期对象已经不再需要，但是因为长生命周期对象持有它的引用而导致不能被回收，这就是
java
中内存泄露的发生场景。

具体主要有如下几大类：

7.1 静态集合类引起内存泄露

像
HashMap
、
Vector
等的使用最容易出现内存泄露，这些静态变量的生命周期和应用程序一致，他们所引用的所有的对象
Object
也不能被释放，因为他们也将一直被
Vector
等引用着。 

例
: 

import java.util.Vector; /**  *  */ public class VectorMemoryOOM {        public static void main(String[] args) {               Vector vobj = new Vector(10);               for (int i = 0; i < 100; i++) {                      Object obj = new Object();                      //注意此处Java如何清除内存                       vobj.add(obj);                       obj = null;                       //GC会清除这一块内存吗？                 }               System.out.print("end");        } }

解析：

在这个例子中，循环申请
Object
对象，并将所申请的对象放入一个
Vector
中，如果仅仅释放引用本身（
o=null
），那么
Vector
仍然引用该对象，所以这个对象对
GC
来说是不可回收的。因此，如果对象加入到
Vector
后，还必须从
Vector
中删除，最简单的方法就是将
Vector
对象设置为
null
。

7.2 创建过大对象

public class VectorMemoryOOM {        /**         * @param args         */        public static void main(String[] args) {               Vector vobj = new Vector(999999999);        } }

运行结果：

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space        at java.util.Vector.<init>(Vector.java:131)        at java.util.Vector.<init>(Vector.java:144)        at test.VectorMemoryOOM.main(VectorMemoryOOM.java:19)

以上代码运行时瞬间报错。

7.3 监听器

在
java
编程中，我们都需要和监听器打交道，通常一个应用当中会用到很多监听器，我们会调用一个控件的诸如
addXXXListener()
等方法来增加监听器，但往往在释放对象的时候却没有记住去删除这些监听器，从而增加了内存泄漏的机会。

7.4 各种连接

比如数据库
连接（
dataSourse.getConnection()
），网络连接
(socket)
和
io
连接，除非其显式的调用了其
close
（）方法将其连接关闭，否则是不会自动被
GC
回收的。对于
Resultset
和
Statement
对象可以不进行显式回收，但
Connection
一定要显式回收，因为
Connection
在任何时候都无法自动回收，而
Connection
一旦回收，
Resultset
和
Statement
对象就会立即为
NULL
。但是如果使用连接池，情况就不一样了，除了要显式地关闭连接，还必须显式地关闭
Resultset Statement
对象（关闭其中一个，另外一个也会关闭），否则就会造成大量的
Statement
对象无法释放，从而引起内存泄漏。这种情况下一般都会在
try
里面去的连接，在
finally
里面释放连接。

7.5 内部类和外部模块等的引用

内部类的引用是比较容易遗忘的一种，而且一旦没释放可能导致一系列的后继类对象没有释放。此外程序员还要小心外部模块不经意的引用，例如程序员
A
负责
A
模块，调用了
B
模块的一个方法如： 

public void registerMsg(Object b); 

这种调用就要非常小心了，传入了一个对象，很可能模块
B
就保持了对该对象的引用，这时候就需要注意模块
B
是否提供相应的操作去除引用。

7.6 单例模式

不正确使用单例模式是引起内存泄露的一个常见问题，单例对象在被初始化后将在
JVM
的整个生命周期中存在（以静态变量的方式），如果单例对象持有外部对象的引用，那么这个外部对象将不能被
jvm
正常回收，导致内存泄露

8. JVM监控分析

8.1 查看系统资源的基本使用情况

8.2 查看内存使用情况

8.3 典型内存泄露堆内存情况

9. 内存溢出/泄露实战

9.1 模拟Java堆溢出

说明：Java堆用于存储对象实例，只要不断地创建对象，并且保证GC Roots到对象之间有可达路径来避免垃圾回收机制清除这些对象，那么在对象数量到达最大堆的容量限制后就会产生内存溢出异常。

通过设置参数-XX:+HeapDumpOnOutOfMemoryError可以让虚拟机
在出现内存溢出异常时Dump出当前的内存堆转储快照以便事后进行分析。

代码清单1　Java堆内存溢出异常测试

/**  * VM Args：-Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError  *   */ public class TestOutOfMemoryError {        static class OOMObject {        }        public static void main(String[] args) {               List<OOMObject> list = new ArrayList<OOMObject>();               while (true) {                      list.add(new OOMObject());               }        } }

运行结果：

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space        at java.util.Arrays.copyOf(Arrays.java:2245)        at java.util.Arrays.copyOf(Arrays.java:2219)        at java.util.ArrayList.grow(ArrayList.java:242)        at java.util.ArrayList.ensureExplicitCapacity(ArrayList.java:216)        at java.util.ArrayList.ensureCapacityInternal(ArrayList.java:208)        at java.util.ArrayList.add(ArrayList.java:440)        at test.TestOutOfMemoryError.main(TestOutOfMemoryError.java:22) *** java.lang.instrument ASSERTION FAILED ***: "error == JVMTI_ERROR_NONE" at ../../../src/share/instrument/Reentrancy.c line: 161

Java
堆内存的OOM异常是实际应用中常见的内存溢出异常情况。当出现Java堆内存溢出时，异常堆栈信息“java.lang.OutOfMemoryError”会跟着进一步提示“Java heap space”。

重点是确认内存中的对象是否是必要的，也就是要先分清楚到底是出现了内存泄漏（
Memory Leak
）还是内存溢出（
Memory Overflow
）。图
2-5
显示了使用
Eclipse Memory Analyzer
打开的堆转储快照文件。

如果是内存泄露，可进一步通过工具查看泄露对象到GC Roots的引用链。于是就能找到泄露对象是通过怎样的路径与GC Roots相关联并导致垃圾收集器无法自动回收它们的。掌握了泄露对象的类型信息及GC Roots引用链的信息，就可以比较准确地定位出泄露代码的位置。

如果不存在泄露，换句话说，就是内存中的对象确实都还必须存活着，那就应当检查虚拟机
的堆参数（-Xmx与-Xms），与机器物理内存对比看是否还可以调大，从代码上检查是否存在某些对象生命周期过长、持有状态时间过长的情况，尝试减少程序运行期的内存消耗。

以上是处理Java
堆内存问题的简单思路，处理这些问题所需要的知识、工具与经验是后面
3
章的主题。

9.2 虚拟机栈和本地方法栈溢出

JMV
并不区分虚拟机
栈和本地方法栈，栈部分通常会出现两种异常：

1
、如果线程请求的栈深度大于虚拟机所允许的最大深度，将抛出StackOverflowError异常。

2
、如果虚拟机在扩展栈时无法申请到足够的内存空间，则抛出OutOfMemoryError异常。

代码清单2　虚拟机栈和本地方法栈OOM测试

/**  * VM Args：-Xss128k  *   */ public class JavaVMStackSOF {   private int stackLength = 1;   public void stackLeak() {    stackLength++;    stackLeak();   }   public static void main(String[] args) throws Throwable {    JavaVMStackSOF oom = new JavaVMStackSOF();    try {     oom.stackLeak();    } catch (Throwable e) {     System.out.println("stack length:" + oom.stackLength);     throw e;    }   } } 运行结果： stack length:2402 Exception in thread "main" java.lang.StackOverflowError         at org.fenixsoft.oom.VMStackSOF.leak(VMStackSOF.java:20)         at org.fenixsoft.oom.VMStackSOF.leak(VMStackSOF.java:21)         at org.fenixsoft.oom.VMStackSOF.leak(VMStackSOF.java:21) ……后续异常堆栈信息省略

实验结果表明：在单个线程下，无论是由于栈帧太大还是虚拟机栈容量太小，当内存无法分配的时候，虚拟机抛出的都是StackOverflowError异常。

如果测试时不限于单线程，通过不断地建立线程的方式倒是可以产生内存溢出异常，如代码清单2所示。但是这样产生的内存溢出异常与栈空间是否足够大并不存在任何联系，或者准确地说，在这种情况下，为每个线程的栈分配的内存越大，反而越容易产生内存溢出异常。

其实原因不难理解，操作系统分配给每个进程的内存是有限制的，譬如32位的Windows限制为2GB。虚拟机提供了参数来控制Java堆和方法区的这两部分内存的最大值。剩余的内存为2GB（操作系统限制）减去Xmx（最大堆容量），再减去MaxPermSize（最大方法区容量），程序计数器消耗内存很小，可以忽略掉。如果虚拟机进程本身耗费的内存不计算在内，剩下的内存就由虚拟机栈和本地方法栈“瓜分”了。每个线程分配到的栈容量越大，可以建立的线程数量自然就越少，建立线程时就越容易把剩下的内存耗尽。

这一点读者需要在开发多线程的应用时特别注意，出现StackOverflowError异常时有错误堆栈可以阅读
，相对来说，比较容易找到问题的所在。而且，如果使用虚拟机默认参数，栈深度在大多数情况下（因为每个方法压入栈的帧大小并不是一样的，所以只能说在大多数情况下）达到1000～2000完全没有问题，对于正常的方法调用（包括递归），这个深度应该完全够用了。但是，如果是建立过多线程导致的内存溢出，在不能减少线程数或者更换64位虚拟机的情况下，就只能通过减少最大堆和减少栈容量来换取更多的线程。如果没有这方面的处理经验，这种通过“减少内存”的手段来解决内存溢出的方式会比较难以想到。

代码清单2-5　创建线程导致内存溢出异常

/**  * VM Args：-Xss2M （这时候不妨设置大些）  *   */ public class JavaVMStackOOM {          private void dontStop() {               while (true) {               }        }          public void stackLeakByThread() {               while (true) {                      Thread thread = new Thread(new Runnable() {                             @Override                             public void run() {                                    dontStop();                             }                      });                      thread.start();               }        }          public static void main(String[] args) throws Throwable {               JavaVMStackOOM oom = new JavaVMStackOOM();               oom.stackLeakByThread();        } }  

注意　特别提示一下，如果读者要尝试运行上面这段代码，记得要先保存当前的工作。由于在Windows平台的虚拟机中，Java的线程是映射到操作系统
的内核线程上的，因此上述代码执行时有较大的风险，可能会导致操作系统
假死。

运行结果：

Exception in thread "main" java.lang.OutOfMemoryError: unable to create new native thread

9.3 运行时常量池溢出

如果要向运行时常量池中添加内容，最简单的做法就是使用String.intern()这个Native方法。该方法的作用是：如果池中已经包含一个等于此String对象的字符串，则返回代表池中这个字符串的String对象；否则，将此String对象包含的字符串添加到常量池中，并且返回此String对象的引用。由于常量池分配在方法区内，我们可以通过-XX:PermSize和-XX:MaxPermSize限制方法区的大小，从而间接限制其中常量池的容量，如代码清单2-4所示。

代码清单2-4　运行时常量池导致的内存溢出异常

/**   * VM Args：-XX:PermSize=10M -XX:MaxPermSize=10M  *    */   public class RuntimeConstantPoolOOM {     public static void main(String[] args) {       // 使用List保持着常量池引用，避免Full GC回收常量池行为       List<String> list = new ArrayList<String>();       // 10MB的PermSize在integer范围内足够产生OOM了       int i = 0;       while (true) {           list.add(String.valueOf(i++).intern());       }   }   } 

运行结果：

Exception in thread "main" java.lang.OutOfMemoryError: PermGen space at java.lang.String.intern(Native Method) at org.fenixsoft.oom.RuntimeConstantPoolOOM.main(RuntimeConstantPoolOOM.java:18)

从运行结果中可以看到，运行时常量池溢出，在
OutOfMemoryError
后面跟随的提示信息是“
PermGen space
”，说明运行时常量池属于方法区（
HotSpot
虚拟机中的永久代）的一部分。

9.4 方法区溢出

方法区用于存放Class的相关信息，如类名、访问修饰符、常量池、字段描述、方法描述等。对于这些区域的测试，基本的思路是运行时产生大量的类去填满方法区，直到溢出。虽然直接使用Java 
SE API
也可以动态产生类（如反射时的GeneratedConstructorAccessor和动态代理等），但在本次实验中操作起来比较麻烦。在代码清单2-8中，笔者借助CGLib直接操作字节码运行时生成了大量的动态类。

值得特别注意的是，我们在这个例子中模拟的场景并非纯粹是一个实验，这样的应用经常会出现在实际应用中：当前的很多主流框架，如Spring、Hibernate，在对类进行增强时，都会使用到CGLib这类字节码技术，增强的类越多，就需要越大的方法区来保证动态生成的Class可以加载入内存。另外，JVM上的动态语言（例如Groovy等）通常都会持续创建类来实现语言的动态性，随着这类语言的流行，也越来越容易遇到与代码清单2-8相似的溢出场景。

代码清单2-8　借助CGLib使方法区出现内存溢出异常

/**  * VM Args： -XX:PermSize=10M -XX:MaxPermSize=10M  *   */ public class JavaMethodAreaOOM {   public static void main(String[] args) {    while (true) {     Enhancer enhancer = new Enhancer();     enhancer.setSuperclass(OOMObject.class);     enhancer.setUseCache(false);     enhancer.setCallback(new MethodInterceptor() {      public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable {       return proxy.invokeSuper(obj, args);      }     });     enhancer.create();    }   }  static class OOMObject {  } } 运行结果： Caused by: java.lang.OutOfMemoryError: PermGen space  at java.lang.ClassLoader.defineClass1(Native Method)  at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)  at java.lang.ClassLoader.defineClass(ClassLoader.java:616)  … 8 more  

方法区溢出也是一种常见的内存溢出异常，一个类要被垃圾收集器回收掉，判定条件是比较苛刻的。在经常动态生成大量
Class
的应用中，需要特别注意类的回收状况。这类场景除了上面提到的程序使用了
CGLib
字节码增强和动态语言之外，常见的还有：大量
JSP
或动态产生
JSP
文件的应用（
JSP
第一次运行时需要编译为
Java
类）、基于
OSGi
的应用（即使是同一个类文件，被不同的加载器加载也会视为不同的类）等。

9.5 本机直接内存溢出

DirectMemory
容量可通过-XX：MaxDirectMemorySize指定，如果不指定，则默认与Java
堆最大值（-Xmx指定）一样，代码清单2-9越过了DirectByteBuffer类，直接通过反射获取Unsafe实例进行内存分配（Unsafe类的getUnsafe()方法限制了只有引导类加载器才会返回实例，也就是设计者希望只有rt.jar中的类才能使用Unsafe的功能）。因为，虽然使用DirectByteBuffer分配内存也会抛出内存溢出异常，但它抛出异常时并没有真正向操作系统
申请分配内存，而是通过计算得知内存无法分配，于是手动抛出异常，真正申请分配内存的方法是unsafe.allocateMemory()。

代码清单2-9　使用unsafe分配本机内存

/**  * VM Args：-Xmx20M -XX:MaxDirectMemorySize=10M  *  */ public class DirectMemoryOOM {   private static final int _1MB = 1024 * 1024;   public static void main(String[] args) throws Exception {    Field unsafeField = Unsafe.class.getDeclaredFields()[0];    unsafeField.setAccessible(true);    Unsafe unsafe = (Unsafe) unsafeField.get(null);    while (true) {     unsafe.allocateMemory(_1MB);    }   } } 运行结果： Exception in thread "main" java.lang.OutOfMemoryError  at sun.misc.Unsafe.allocateMemory(Native Method)  at org.fenixsoft.oom.DMOOM.main(DMOOM.java:20)  

由
DirectMemory
导致的内存溢出，一个明显的特征是在
Heap Dump
文件中不会看见明显的异常，如果读者发现
OOM
之后
Dump
文件很小，而程序中又直接或间接使用了
NIO
，那就可以考虑检查一下是不是这方面的原因。

10. 内存溢出预防与解决办法

10.1 避免内存泄露/溢出措施

1
、尽早释放无用对象的引用；

2
、优化算法，减小空间复杂度。

3
、尽量少用静态变量， 
因为静态变量是全局的，
GC
不会回收。

4
、 
避免集中创建对象尤其是超大对象，如果可以的话尽量使用流操作。

5
、 
尽量运用对象池技术以提高系统性能，例如连接池。

6
、不要在经常调用的方法中创建对象，尤其是忌讳在循环中创建对象。

7
、优化配置

10.2 查看系统状态

监控显示：

10.3 发现内存泄露

通常情况下，内存问题的可能会表现为：

1、运行一段时间后系统崩溃，报java.lang.OutOfMemoryError异常

2、启动时直接崩溃，报错java.lang.OutOfMemoryError

3、系统已经不能正常提供服务，但无错误日志

4、系统运行正常，响应速度逐渐减慢

为了分析判断内存问题，通常除了查看基本的系统状态信息外，还可以对内存、CPU、线程分别进详细分析。

例如：对内存堆DUMP进行分析,如下图所示：（报表清晰的显示发现内存泄露的个数）

另外，还可以通过一些性能监测分析工具辅助分析，如 JProfiler、Optimizeit Profiler进行分析。

10.4 定位内存泄露

思路：

     1、查看线程独占的超长生命周期对象，及其代码调用关系

     2、查看占用空间较多的对象及其代码调用关系

为解决内存泄露问题，一般需要Dump出内存快照转储文件，再通过内存映像分析工具（如Eclipse Memory Analyzer）对Dump出来的堆转储快照进行分析。

从上图信息可知，dump文件在位置：C:\Users\ADMINI~1\AppData\Local\Temp\visualvm.dat\localhost_368\heapdump-1464919773882.hprof

内存泄露的关键位置

将dump文件导入eclipse中，经Eclipse Memory Analyzer分析，得出报表。

在
Accumulated Objects by Class
区域，可以看到垃圾对象占用内存空间的信息，如下如所示：

由上图可以清晰的看到哪些类占用了内存空间，便可以进行响应代码查错与修改。

 

该专题是一个系列，参照了一系列JVM资料，对JVM基础知识做了摘要总结，并结合实战做了总结：

【基础+实战】JVM原理及优化系列之一：JVM体系结构

【基础+实战】JVM原理及优化系列之二：JVM内存管理

【基础+实战】JVM原理及优化系列之三：JVM垃圾收集器

【基础+实战】JVM原理及优化系列之四：JVM参数说明

【基础+实战】JVM原理及优化系列之五：JVM默认设置

【基础+实战】JVM原理及优化系列之六：JVM主要调优参数

【基础+实战】JVM原理及优化系列之七：JVM调优注意事项

【基础+实战】JVM原理及优化系列之八：如何查看JVM参数配置？

【基础+实战】JVM原理及优化系列之九：JVM监控、分析与故障处理实战

【基础+实战】JVM原理及优化系列之十：JVM内存泄漏专题实战

通览该系列文章之后，对JVM会有一个整体的认识，对于JVM问题排查和优化会有一定的帮助，如果想对JVM有更深入的理解和认知，建议深入看一下这本书《Java虚拟机：JVM高级特性与最佳实践（最新第二版）》，网上可以找到pdf版的，大家可以自己百度一下。

---

博主：诸葛本不亮

简介：毕业后做过多年程序猿、架构设计、项目经理、部门总监，待过传统软件公司，也在大型互联网公司负责过平台研发部，在这个行业浸淫十多年，在系统架构、SaaS平台搭建、项目管理以及部门管理等方面有着多年的一线实践经验。

微信号：danwang2138