Java OutOfMemoryError 奇怪的行为

Question

假设我们有 256M 的最大内存，为什么这段代码可以工作:

public static void main(String... args) {
  for (int i = 0; i < 2; i++)
  {
      byte[] a1 = new byte[150000000];
  }
  byte[] a2 = new byte[150000000];
}

但是这个会引发 OOME？

public static void main(String... args) {
  //for (int i = 0; i < 2; i++)
  {
      byte[] a1 = new byte[150000000];
  }
  byte[] a2 = new byte[150000000];
}

Answer 1

为了保持全局，考虑使用 -Xmx64m 运行此代码:

static long sum;
public static void main(String[] args) {
  System.out.println("Warming up...");
  for (int i = 0; i < 100_000; i++) test(1);
  System.out.println("Main call");
  test(5_500_000);
  System.out.println("Sum: " + sum);
}

static void test(int size) {
//  for (int i = 0; i < 1; i++)
  {
    long[] a2 = new long[size];
    sum += a2.length;
  }
  long[] a1 = new long[size];
  sum += a1.length;
}

取决于你是做热身还是跳过它，它会吹还是不吹。这是因为 JITted 代码正确地 null 排除了 var，而解释代码则没有。这两种行为在 Java 语言规范下都是可以接受的，这意味着你可以任由 JVM 摆布。

<支持>在 OS X 上使用 Java HotSpot(TM) 64 位服务器 VM(内部版本 23.3-b01，混合模式) 进行测试。

字节码分析

用 for 循环查看字节码(简单代码，没有 sum 变量):

static void test(int);
  Code:
   0: iconst_0
   1: istore_1
   2: goto  12
   5: iload_0
   6: newarray long
   8: astore_2
   9: iinc  1, 1
   12:  iload_1
   13:  iconst_1
   14:  if_icmplt 5
   17:  iload_0
   18:  newarray long
   20:  astore_1
   21:  return

和没有:

static void test(int);
  Code:
   0: iload_0
   1: newarray long
   3: astore_1
   4: iload_0
   5: newarray long
   7: astore_1
   8: return

在这两种情况下都没有显式 null，但请注意，在 no-for 示例中，实际上重用了相同的内存位置，而 例如。如果有的话，这将导致与观察到的行为相反的预期。

一个转折...

根据我们从字节码中学到的知识，尝试运行这个:

public static void main(String[] args) {
  {
    long[] a1 = new long[5_000_000];
  }
  long[] a2 = new long[0];
  long[] a3 = new long[5_000_000];
}

没有抛出 OOME。把a2的声明注释掉，就回来了。我们分配更多，但占用更少？看字节码:

public static void main(java.lang.String[]);
  Code:
     0: ldc           #16                 // int 5000000
     2: istore_1      
     3: ldc           #16                 // int 5000000
     5: newarray       long
     7: astore_2      
     8: iconst_0      
     9: newarray       long
    11: astore_2      
    12: ldc           #16                 // int 5000000
    14: newarray       long
    16: astore_3      
    17: return        

a1 使用的位置 2 被 a2 重用。 OP 的代码也是如此，但现在我们使用对无害零长度数组的引用覆盖该位置，并使用另一个位置来存储对我们巨大数组的引用。

总结一下……

Java 语言规范没有指定任何垃圾对象必须被收集，并且 JVM 规范只说带有局部变量的“框架”在方法完成时作为一个整体被销毁。因此，我们目睹的所有行为都是书本上的。对象的 invisible 状态(在 keppil 链接的文档中提到)只是描述在某些实现和某些情况下发生的事情的一种方式，但是绝不是任何规范的行为。