深入理解Java虚拟机--OutOfMemoryError异常

       在Java虚拟机规范的描述中,除了程序计数器外,虚拟机内存的其他几个运行时区域都有发生OutOfMemoryError(下文称OOM )异常的可能。

• Java堆溢出

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

        下列代码限制Java堆的大小为20MB,不可扩展(将堆的最小值-Xms参数与最大值-Xmx参数设置为一样即可避免堆自动扩展),通过参数-XX:+HeapDumpOnOutOfMemoryError可以让虚拟机在出现内存溢出异常时Dump出当前的内存堆转储快照以便事后进行分析。

       Java堆内存的OOM异常是实际应用中常见的内存溢出异常情况。

       要解决这个区域的异常,一般的手段是先通过内存映像分析工具(如Eclipse Memory Analyzer ) 对Dump出来的堆转储快照进行分析,重点是确认内存中的对象是否是必要的,也就是要先分清楚到底是出现了内存泄漏(Memory Leak ) 还是内存溢出(Memory Overflow ) 。

       如果是内存泄露,可进一步通过工具查看泄露对象到GC Roots的引用链。于是就能找到泄露对象是通过怎样的路径与GC Roots相关联并导致垃圾收集器无法自动回收它们的。掌握了泄露对象的类型信息及GC Roots引用链的信息,就可以比较准确地定位出泄露代码的位置。
       如果不存在泄露,换句话说,就是内存中的对象确实都还必须存活着,那就应当检查虛拟机的堆参数(-Xmx与-Xms ) ,与机器物理内存对比看是否还可以调大,从代码上检查是否存在某些对象生命周期过长、持有状态时间过长的情况,尝试减少程序运行期的内存消耗。

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

        由于在HotSpot虚拟机中并不区分虚拟机栈和本地方法栈,因此 ,对于HotSpot来 说 ,虽然-Xoss参数 (设置本地方法栈大小)存在 ,但实际上是无效的,栈容量只由-Xss参数设定。 关于虚拟机栈和本地方法栈,在Java虚拟机规范中描述了两种异常:
        如果线程请求的栈深度大于虚拟机所允许的最大深度,将拋出StackOverflowError异常。
        如果虚拟机在扩展栈时无法申请到足够的内存空间,则拋出OutOMemoryError异常。
        这里把异常分成两种情况,看似更加严谨,但却存在着一些互相重叠的地方:当栈空间无法继续分配时,到底是内存太小,还是已使用的栈空间太大,其本质上只是对同一件事情的两种描述而已。
        在笔者的实验中,将实验范围限制于单线程中的操作,尝试了下面两种方法均无法让虚拟机产生OutOfMemoryError异常 ,尝试的结果都是获得StackOverflowError异 常 ,测试代码如下述所示。

        使用-Xss参数减少栈内存容量。结果 :拋出StackOverflowError异常 ,异常出现时输出的堆栈深度相应缩小。或者定义了大量的本地变量,增大此方法帧中本地变量表的长度。结果 :拋出 StackOverflowError异常时输出的堆栈深度相应缩小。

       实验结果表明:在单个线程下,无论是由于栈帧（一个方法中包含的本地变量数）太大还是虚拟机栈容量（-Xss参数减少每个线程栈内存容量）太小,当内存无法分配的时候,虚拟机拋出的都是StackOverflowError异常。
       如果测试时不限于单线程,通过不断地建立线程的方式倒是可以产生内存溢出异常,如代码清单2-5所示。但是这样产生的内存溢出异常与栈空间是否足够大并不存在任何联系,或者准确地说，在这种情况下，为每个线程的栈分配的内存越大，反而越容易产生内存溢出异常。
       其实原因不难理解,操作系统分配给每个进程的内存是有限制的,譬如32位的Windows 限制为2GB。虚拟机提供了参数来控制Java堆和方法区的这两部分内存的最大值。剩余的内存为2GB ( 操作系统限制)减去Xmx ( 最大堆容量),再减去MaxPermSize (最大方法区容量 ),程序计数器消耗内存很小,可以忽略掉。如果虚拟机进程本身耗费的内存不计算在内 ,剩下的内存就由虚拟机栈和本地方法栈“瓜分” 了。每个线程分配到的栈容量越大,可以建立的线程数量自然就越少,建立线程时就越容易把剩下的内存耗尽。

• 运行时常量池溢出

       String.intern() 是一个Native方法,它的作用是:如果字符串常量池中已经包含一个等于此String对象的字符串,则返回代表池中这个字符串的String对 象 ;否则 ,将此String对象包含的字符串添加到常量池中,并且返回此String对象的引用。在JDK 1.6及之前的版本中,由于常量池分配在永久代内,我们可以通过-XX : PermSize和-XX : MaxPermSize限制方法区大小 ,从而间接限制其中常量池的容量。

• 方法区溢出

       方法区用于存放Class的相关信息,如类名、访问修饰符、常量池、字段描述、方法描述 等。对于这些区域的测试,基本的思路是运行时产生大量的类去填满方法区,直到溢出。笔者借助CGLib直接操作字节码运行时生成了大量的动态类。
       值得特别注意的是,我们在这个例子中模拟的场景并非纯粹是一个实验,这样的应用经常会出现在实际应用中:当前的很多主流框架,如Spring、Hibernate ,在对类进行增强时, 都会使用到CGLib这类字节码技术,增强的类越多,就需要越大的方法区来保证动态生成的 Class可以加载入内存。另外,JVM上的动态语言(例如Groovy等 )通常都会持续创建类来实现语言的动态性,随着这类语言的流行,也越来越容易遇到相似的溢出场景。

• 本机直接内存溢出