一次OutOfMemoryError异常的分析

为什么我给JVM分配的堆已经足够大了，但在给一个数据结构分配内存的时候却抛出了OutOfMemoryError异常?这是我最近面临的一个问题。


看了下开发人员这段代码到底是干什么的并且再三确认了通过-Xmx参数给JVM设置的堆大小之后，看样子问题确实是有点诡异了。


半小时后我们终于知道是怎么回事并解决了这个疑案。不过这个问题的确在一开始并不是那么明显，所以我想如果我把底层的问题描述得清楚点的话，或者以后能替大家节省掉一天的排查问题的时间。


通常来说，想弄清楚一个问题的最好方式就是通过一个实例来进行说明。这里我创建一个小的测试用例：

package eu.plumbr.demo;
class ArraySize {
public static void main(String... args) {
int[] array = new int[1024*1024*1024];
}
}
 

代码很简单——它要做的就是分配一个1G大小的数组。现在你想下，Java的int类型需要4个字节，那如果用个6G大小的堆来运行这个程序应该就没问题了。毕竟10亿个整型数值也就占用4G内存而已。那为什么我执行这段代码的时候会出现下面的结果？

My Precious:bin me$ java –Xms6g –Xmx6g eu.plumbr.demo.ArraySize
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
 at eu.plumbr.demo.ArraySize.main(ArraySize.java:6)
 

在增加堆的大小之前(事实上，如果使用-Xmx7g来运行上述程序就没问题了)，我们先来看下为什么出现的不是我们预期的结果。


首先，int类型在Java的确是占用4个字节。因此这并不是我们的JVM在晚上突然发疯了。而且我还可以很确定地告诉你，我的计算也没有问题——1024*1024*1024个整型的确是需要4,294,967,296字节，也就是4G内存。


想知道发生了什么，我们先使用–XX:+PrintGCDetails参数把GC的日志打开之后再运行一遍这个程序看看：

My Precious:bin me$ java –Xms6g -Xmx6g -XX:+PrintGCDetails eu.plumbr.demo.ArraySize

-- cut for brevity --

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at eu.plumbr.demo.ArraySize.main(ArraySize.java:6)

Heap
 PSYoungGen      total 1835008K, used 125829K [0x0000000780000000, 0x0000000800000000, 0x0000000800000000)
  eden space 1572864K, 8% used [0x0000000780000000,0x0000000787ae15a8,0x00000007e0000000)
  from space 262144K, 0% used [0x00000007e0000000,0x00000007e0000000,0x00000007f0000000)
  to   space 262144K, 0% used [0x00000007f0000000,0x00000007f0000000,0x0000000800000000)
 ParOldGen       total 4194304K, used 229K [0x0000000680000000, 0x0000000780000000, 0x0000000780000000)
  object space 4194304K, 0% used [0x0000000680000000,0x0000000680039608,0x0000000780000000)
 PSPermGen       total 21504K, used 2589K [0x000000067ae00000, 0x000000067c300000, 0x0000000680000000)
  object space 21504K, 12% used [0x000000067ae00000,0x000000067b087668,0x000000067c300000)
 

答案现在一目了然：尽管我们总的堆大小是足够的，但堆中没有一个单独的区域能容下4G的对象。我们这个6G的堆被划分成了四个不同的区域，它们的大小分别是：


- Eden区：1536M
- Survivor区(包括from区及to区)：分别是256M
- 老生代：4096M


现在，请记住了，对象只能在一个独立的区中进行分配，而现在我们看到，这个程序是不可能了——没有任何一个区能有足够的空间来满足这个单次的4G内存的分配的。


因此——我们只能寄希望于增加堆的大小了吗？尽管我们已经多提供了差不多50%的内存——为一个4G大小的数据结构提供了一个6G的堆？先别着急——还有另一个解决方案。你可以设置内存中不同的区域的大小。但这并不是你想像的那么简单明了，你需要对启动配置做两点小的改动。在运行这段相同的程序时，得多增加两个额外的参数：

My Precious:bin me$ java -Xms6g -Xmx6g -XX:NewSize=5g -XX:SurvivorRatio=10 eu.plumbr.demo.ArraySize
 

这样程序就能完成它的使命也不会抛出OutOfMemoryError了。启动时加上-XX:+PrintGCDetails参数的话可以印证这一点：

Heap
 PSYoungGen      total 4806144K, used 4369080K [0x00000006c0000000, 0x0000000800000000, 0x0000000800000000)
  eden space 4369408K, 99% used [0x00000006c0000000,0x00000007caaae228,0x00000007cab00000)
  from space 436736K, 0% used [0x00000007e5580000,0x00000007e5580000,0x0000000800000000)
  to   space 436736K, 0% used [0x00000007cab00000,0x00000007cab00000,0x00000007e5580000)
 ParOldGen       total 1048576K, used 0K [0x0000000680000000, 0x00000006c0000000, 0x00000006c0000000)
  object space 1048576K, 0% used [0x0000000680000000,0x0000000680000000,0x00000006c0000000)
 PSPermGen       total 21504K, used 2563K [0x000000067ae00000, 0x000000067c300000, 0x0000000680000000)
  object space 21504K, 11% used [0x000000067ae00000,0x000000067b080c90,0x000000067c300000)
 

我们可以看到，各个区的大小的确是我们想要的：


- 新生代的总大小是5G，确如-XX:NewSize=5g所指定的那样
- Eden区是Survior区的10倍，正如我们通过-XX:SurvivorRatio=10参数指定的那样


注意，在这个例子中，两个参数都是必须的。如果你只指定了-XX:NewSize=5g的话，新生代划分成eden和survivor区的结果就没有一个能大于4G的区域了。


希望这篇文章将来能省掉你一天的调试时间。或者让你避免提供不必要的资源（分配过大的Java堆）。


译注：仔细观察了下他的日志可以发现，他分配6G内存的时候，新生代占了大概2G，老生代刚刚好是4G的大小，并且程序退出的时候老生代中还占用了200多K的大小，这样正好存放不下这个数组。作者这个解决方法也有点奇怪，还有一个方案就是将新生代的大小稍微调小一点，比如-XX:MaxNewSize=1800M，这样的话这个数组就可以直接在老生代中进行分配了：

 ParOldGen       total 4448256K, used 4194304K [0x0000000680000000, 0x000000078f800000, 0x000000078f800000)
  object space 4448256K, 94% used [0x0000000680000000,0x0000000780000010,0x000000078f800000)
 

原创文章转载请注明出处：http://it.deepinmind.com

英文原文链接

评论

10 楼 Tyrion 2014-05-20  

全文重点是“请记住了，对象只能在一个独立的区中进行分配，而现在我们看到，这个程序是不可能了——没有任何一个区能有足够的空间来满足这个单次的4G内存的分配的。 ”，举的例子比较极端，真正生产上SurvivorRatio的值记得有个公式的。

9 楼 deepinmind 2014-05-20  

caizi12 写道

white_crucifix 写道

可能作者不太愿意把4G的对象放在老年代吧，毕竟老年代撑爆了做一次full GC代价不小

新生代的gc频率都比较高，这么大个对象放在新生代也不是太合适，这样的话老年代就要设置比4g还要大才行，尽量减少full gc。

你说的这个很对。原文底下有个评论提到了，如果这么大的对象生命周期还较长的话，老年代也得设置到4G以上，至少得分配8，9G内存了。

8 楼 deepinmind 2014-05-20  

white_crucifix 写道

可能作者不太愿意把4G的对象放在老年代吧，毕竟老年代撑爆了做一次full GC代价不小

嗯，也许这个4G的对象生命周期比较短，下一次young gc就回收掉了。

7 楼 caizi12 2014-05-20  

引用

My Precious:bin me$ java -Xms6g -Xmx6g -XX:NewSize=5g -XX:SurvivorRatio=10 eu.plumbr.demo.ArraySize

另外对这个有些疑问，指定了新生代为5g，SurvivorRatio=10那就是eden：Survivor=10：1，eden=4.16G，按jvm默认规则大对象都是直接进入老年代的，按lz的说法是已经没有oom了，难道是jvm会根据实际情况此时并不会把大对象直接放入老年区吗？

6 楼 white_crucifix 2014-05-19  

caizi12 写道

white_crucifix 写道

可能作者不太愿意把4G的对象放在老年代吧，毕竟老年代撑爆了做一次full GC代价不小

新生代的gc频率都比较高，这么大个对象放在新生代也不是太合适，这样的话老年代就要设置比4g还要大才行，尽量减少full gc。

嗯，其实这么大对象，放哪里都不合适啦。
如果按照原文的意思推测的话，场景的确是非常特殊。首先，这个大对象的运行范围非常小，使用后立刻丢失引用，能够严格控制一次Minor GC就能马上消灭，不然拷贝到老年代的过程要人命。
若按照这个前提，那不愿意直接放入老年代也可以理解。老年代GC少，如果一直没有突破Full GC，这4G可就长年屯在那边也没什么用处吧。

5 楼 caizi12 2014-05-19  

white_crucifix 写道

可能作者不太愿意把4G的对象放在老年代吧，毕竟老年代撑爆了做一次full GC代价不小

新生代的gc频率都比较高，这么大个对象放在新生代也不是太合适，这样的话老年代就要设置比4g还要大才行，尽量减少full gc。

4 楼 caizi12 2014-05-19  

white_crucifix 写道

可能作者不太愿意把4G的对象放在老年代吧，毕竟老年代撑爆了做一次full GC代价不小

这么大的对象，默认情况下jvm肯定会要往老年代放的。

3 楼 white_crucifix 2014-05-19  

可能作者不太愿意把4G的对象放在老年代吧，毕竟老年代撑爆了做一次full GC代价不小

2 楼 deepinmind 2014-05-19  

在世界的中心呼喚愛 写道

Heap
 PSYoungGen      total 4806144K, used 4369080K [0x00000006c0000000, 0x0000000800000000, 0x0000000800000000)
  eden space 4369408K, 99% used [0x00000006c0000000,0x00000007caaae228,0x00000007cab00000)
  from space 436736K, 0% used [0x00000007e5580000,0x00000007e5580000,0x0000000800000000)
  to   space 436736K, 0% used [0x00000007cab00000,0x00000007cab00000,0x00000007e5580000)
 ParOldGen       total 1048576K, used 0K [0x0000000680000000, 0x00000006c0000000, 0x00000006c0000000)
  object space 1048576K, 0% used [0x0000000680000000,0x0000000680000000,0x00000006c0000000)
 PSPermGen       total 21504K, used 2563K [0x000000067ae00000, 0x000000067c300000, 0x0000000680000000)
  object space 21504K, 11% used [0x000000067ae00000,0x000000067b080c90,0x000000067c300000)
 

这段我没有

得再加上一个参数指定-Xloggc:gc.log指定下输出文件才行

1 楼 在世界的中心呼喚愛 2014-05-18  

Heap
 PSYoungGen      total 4806144K, used 4369080K [0x00000006c0000000, 0x0000000800000000, 0x0000000800000000)
  eden space 4369408K, 99% used [0x00000006c0000000,0x00000007caaae228,0x00000007cab00000)
  from space 436736K, 0% used [0x00000007e5580000,0x00000007e5580000,0x0000000800000000)
  to   space 436736K, 0% used [0x00000007cab00000,0x00000007cab00000,0x00000007e5580000)
 ParOldGen       total 1048576K, used 0K [0x0000000680000000, 0x00000006c0000000, 0x00000006c0000000)
  object space 1048576K, 0% used [0x0000000680000000,0x0000000680000000,0x00000006c0000000)
 PSPermGen       total 21504K, used 2563K [0x000000067ae00000, 0x000000067c300000, 0x0000000680000000)
  object space 21504K, 11% used [0x000000067ae00000,0x000000067b080c90,0x000000067c300000)
 

这段我没有