Java中的OutOfMemoryError和JVM内存结构

转自：http://apps.hi.baidu.com/share/detail/41699413 

 

 

OutOfMemoryError在开发过程中是司空见惯的，遇到这个错误，新手程序员都知道从两个方面入手来解决：一是排查程序是否有BUG导致内存泄漏；二是调整JVM启动参数增大内存。OutOfMemoryError有好几种情况，每次遇到这个错误时，观察OutOfMemoryError后面的提示信息，就可以发现不同之处，如：

java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: unable to create new native thread
java.lang.OutOfMemoryError: PermGen space
java.lang.OutOfMemoryError: Requested array size exceeds VM limit

虽然都叫OutOfMemoryError，但每种错误背后的成因是不一样的，解决方法也要视情况而定，不能一概而论。只有深入了解JVM的内存结构并仔细分析错误信息，才有可能做到对症下药，手到病除。

JVM规范JVM规范对Java运行时的内存划定了几块区域（详见这里），有：JVM栈（Java Virtual Machine Stacks）、堆（Heap）、方法区（Method Area）、常量池（Runtime Constant Pool）、本地方法栈（Native Method Stacks），但对各块区域的内存布局和地址空间却没有明确规定，而留给各JVM厂商发挥的空间。

  HotSpot JVMSun自家的HotSpot JVM实现对堆内存结构有相对明确的说明。按照HotSpot JVM的实现，堆内存分为3个代：Young Generation、Old(Tenured) Generation、Permanent Generation。众所周知，GC（垃圾收集）就是发生在堆内存这三个代上面的。Young用于分配新的Java对象，其又被分为三个部分：Eden Space和两块Survivor Space(称为From和To)，Old用于存放在GC过程中从Young Gen中存活下来的对象，Permanent用于存放JVM加载的class等元数据。详情参见HotSpot内存管理白皮书。堆的布局图示如下：


 
根据这些信息，我们可以推导出JVM规范的内存分区和HotSpot实现中内存区域的对应关系：JVM规范的Heap对应到Young和Old Generation，方法区和常量池对应到Permanent Generation。对于Stack内存，HotSpot实现也没有详细说明，但HotSpot白皮书上提到，Java线程栈是用宿主操作系统的栈和线程模型来表示的，Java方法和native方法共享相同的栈。因此，可以认为在HotSpot中，JVM栈和本地方法栈是一回事。

 操作系统由于一个JVM进程首先是一个操作系统进程，因此会遵循操作系统进程地址空间的规定。32位系统的地址空间为4G，即最多表示4GB的虚拟内存。在Linux系统中，高地址的1G空间（即0xC0000000~0xFFFFFFFF）被系统内核占用，低地址的3G空间（即0×00000000~0xBFFFFFFF）为用户程序所使用（显然JVM进程运行在这3G的地址空间中）。这3G的地址空间从低到高又分为多个段；Text段用于存放程序二进制代码；Data段用于存放编译时已初始化的静态变量；BSS段用于存放未初始化的静态变量；Heap即堆，用于动态内存分配的数据结构，C语言的malloc函数申请的内存即是从此处分配的，Java的new实例化的对象也是自此分配。不同于前面三个段，Heap空间是可变的，其上界由低地址向高地址增长。内存映射区，加载的动态链接库位于这个区中；Stack即栈空间，线程的执行即是占用栈内存，栈空间也是可变的，但它是通过下界从高地址向低地址移动而增长的。详情参见这里。图示如下：


 
 JVM本身是由native code所编写的，所以JVM进程同样具有Text/Data/BSS/Heap/MemoryMapping/Stack等内存段。而Java语言的Heap应当是建立在操作系统进程的Heap之上的，Java语言的Stack应该也是建立操作系统进程Stack之上的。 综合HotSpot的内存区域和操作系统进程的地址空间，可以大致得到下列图示：


 

Java线程的内存是位于JVM或操作系统的栈（Stack）空间中，不同于对象——是位于堆（Heap）中。这是很多新手程序员容易误解的地方。注意，“Java线程的内存”这个用词不是指Java.lang.Thread对象的内存，java.lang.Thread对象本身是在Heap中分配的，当调用start()方法之后，JVM会创建一个执行单元，最终会创建一个操作系统的native thread来执行，而这个执行单元或native thread是使用Stack内存空间的。

经过上述铺垫，可以得知，JVM进程的内存大致分为Heap空间和Stack空间两部分。Heap又分为Young、Old、Permanent三个代。Stack分为Java方法栈和native方法栈（不做区分），在Stack内存区中，可以创建多个线程栈，每个线程栈占据Stack区中一小部分内存，线程栈是一个LIFO数据结构，每调用一个方法，会在栈顶创建一个Frame，方法返回时，相应的Frame会从栈顶移除（通过移动栈顶指针）。在这每一部分内存中，都有可能会出现溢出错误。回到开头的OutOfMemoryError，下面逐个说明错误原因和解决方法（每个OutOfMemoryError都有可能是程序BUG导致，因此解决方法不包括对BUG的排查）。

java.lang.OutOfMemoryError: Java heap space
原因：Heap内存溢出，意味着Young和Old generation的内存不够。
解决：调整java启动参数 -Xms -Xmx 来增加Heap内存。

java.lang.OutOfMemoryError: unable to create new native thread
原因：Stack空间不足以创建额外的线程，要么是创建的线程过多，要么是Stack空间确实小了。
解决：由于JVM没有提供参数设置总的stack空间大小，但可以设置单个线程栈的大小；而系统的用户空间一共是3G，除了Text/Data/BSS/MemoryMapping几个段之外，Heap和Stack空间的总量有限，是此消彼长的。因此遇到这个错误，可以通过两个途径解决：1.通过-Xss启动参数减少单个线程栈大小，这样便能开更多线程（当然不能太小，太小会出现StackOverflowError）；2.通过-Xms -Xmx 两参数减少Heap大小，将内存让给Stack（前提是保证Heap空间够用）。

java.lang.OutOfMemoryError: PermGen space
原因：Permanent Generation空间不足，不能加载额外的类。
解决：调整-XX:PermSize= -XX:MaxPermSize= 两个参数来增大PermGen内存。一般情况下，这两个参数不要手动设置，只要设置-Xmx足够大即可，JVM会自行选择合适的PermGen大小。

java.lang.OutOfMemoryError: Requested array size exceeds VM limit
原因：这个错误比较少见（试着new一个长度1亿的数组看看），同样是由于Heap空间不足。如果需要new一个如此之大的数组，程序逻辑多半是不合理的。
解决：修改程序逻辑吧。或者也可以通过-Xmx来增大堆内存。

在GC花费了大量时间，却仅回收了少量内存时，也会报出OutOfMemoryError，我只遇到过一两次。当使用-XX:+UseParallelGC或-XX:+UseConcMarkSweepGC收集器时，在上述情况下会报错，在HotSpot GC Turning文档上有说明：
The parallel(concurrent) collector will throw an OutOfMemoryError if too much time is being spent in garbage collection: if more than 98% of the total time is spent in garbage collection and less than 2% of the heap is recovered, an OutOfMemoryError will be thrown.
对这个问题，一是需要进行GC turning，二是需要优化程序逻辑。

java.lang.StackOverflowError
原因：这也内存溢出错误的一种，即线程栈的溢出，要么是方法调用层次过多（比如存在无限递归调用），要么是线程栈太小。
解决：优化程序设计，减少方法调用层次；调整-Xss参数增加线程栈大小。

 

 

 

 

 

 

 

 

相信有一定java开发经验的人或多或少都会遇到OutOfMemoryError的问题，这个问题曾困扰了我很长时间，随着解决各类问题经验的积累以及对问题根源的探索，终于有了一个比较深入的认识。
在解决java内存溢出问题之前，需要对jvm（java虚拟机）的内存管理有一定的认识。jvm管理的内存大致包括三种不同类型的内存区域：Permanent Generation space（永久保存区域）、Heap space(堆区域)、Java Stacks(Java栈）。其中永久保存区域主要存放Class（类）和Meta的信息，Class第一次被Load的时候被放入PermGen space区域，Class需要存储的内容主要包括方法和静态属性。堆区域用来存放Class的实例（即对象），对象需要存储的内容主要是非静态属性。每次用new创建一个对象实例后，对象实例存储在堆区域中，这部分空间也被jvm的垃圾回收机制管理。而Java栈跟大多数编程语言包括汇编语言的栈功能相似，主要基本类型变量以及方法的输入输出参数。Java程序的每个线程中都有一个独立的堆栈。容易发生内存溢出问题的内存空间包括：Permanent Generation space和Heap space。

第一种OutOfMemoryError： PermGen space
发生这种问题的原意是程序中使用了大量的jar或class，使java虚拟机装载类的空间不够，与Permanent Generation space有关。解决这类问题有以下两种办法：
1. 增加java虚拟机中的XX:PermSize和XX:MaxPermSize参数的大小，其中XX:PermSize是初始永久保存区域大小，XX:MaxPermSize是最大永久保存区域大小。如针对tomcat6.0，在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虚拟机创建的对象太多，在进行垃圾回收之间，虚拟机分配的到堆内存空间已经用满了，与Heap space有关。解决这类问题有两种思路：
1. 检查程序，看是否有死循环或不必要地重复创建大量对象。找到原因后，修改程序和算法。
我以前写一个使用K-Means文本聚类算法对几万条文本记录（每条记录的特征向量大约10来个）进行文本聚类时，由于程序细节上有问题，就导致了Java heap space的内存溢出问题，后来通过修改程序得到了解决。
2. 增加Java虚拟机中Xms（初始堆大小）和Xmx（最大堆大小）参数的大小。如：set JAVA_OPTS= -Xms256m -Xmx1024m

第三种OutOfMemoryError：unable to create new native thread
这种错误在Java线程个数很多的情况下容易发生，我暂时还没遇到过，发生原意和解决办法可以参考：http://hi.baidu.com/hexiong/blog/item/16dc9e518fb10c2542a75b3c.html