当内存不足以引发OutOfMemoryError时会发生什么？

我知道每个对象都需要堆内存，而堆栈上的每个基本/引用都需要堆栈内存。

当我尝试在堆上创建对象并且没有足够的内存来执行此操作时，JVM 在堆上创建一个java.lang.OutOfMemoryError并将其扔给我。

因此，隐式地，这意味着JVM在启动时会保留一些内存。

当此保留的内存用完（肯定会用完，请阅读下面的讨论）并且JVM堆上没有足够的内存来创建java.lang.OutOfMemoryError实例时，会发生什么？

它只是挂了吗？还是null因为newOOM实例没有存储空间而将其扔给我？

try {
    Object o = new Object();
    // and operations which require memory (well.. that's like everything)
} catch (java.lang.OutOfMemoryError e) {
    // JVM had insufficient memory to create an instance of java.lang.OutOfMemoryError to throw to us
    // what next? hangs here, stuck forever?
    // or would the machine decide to throw us a "null" ? (since it doesn't have memory to throw us anything more useful than a null)
    e.printStackTrace(); // e.printStackTrace() requires memory too.. =X
}

==

JVM为什么不能保留足够的内存？

无论保留了多少内存，如果JVM无法“回收”该内存，则仍然有可能用完该内存：

try {
    Object o = new Object();
} catch (java.lang.OutOfMemoryError e) {
    // JVM had 100 units of "spare memory". 1 is used to create this OOM.
    try {
        e.printStackTrace();
    } catch (java.lang.OutOfMemoryError e2) {
        // JVM had 99 units of "spare memory". 1 is used to create this OOM.
        try {
            e.printStackTrace();
        } catch (java.lang.OutOfMemoryError e3) {
            // JVM had 98 units of "spare memory". 1 is used to create this OOM.
            try {
                e.printStackTrace();
            } catch (java.lang.OutOfMemoryError e4) {
                // JVM had 97 units of "spare memory". 1 is used to create this OOM.
                try {
                    e.printStackTrace();
                } catch (java.lang.OutOfMemoryError e5) {
                    // JVM had 96 units of "spare memory". 1 is used to create this OOM.
                    try {
                        e.printStackTrace();
                    } catch (java.lang.OutOfMemoryError e6) {
                        // JVM had 95 units of "spare memory". 1 is used to create this OOM.
                        e.printStackTrace();
                        //........the JVM can't have infinite reserved memory, he's going to run out in the end
                    }
                }
            }
        }
    }
}

或更简而言之：

private void OnOOM(java.lang.OutOfMemoryError e) {
    try {
        e.printStackTrace();
    } catch (java.lang.OutOfMemoryError e2) {
        OnOOM(e2);
    }
}

JVM永远不会真正耗尽内存。它预先进行堆堆栈的内存计算。

JVM的结构，第3章，第3.5.2节指出：

• 如果可以动态扩展Java虚拟机堆栈，并且尝试进行扩展，但是可以提供足够的内存来实现扩展，或者如果没有足够的内存来为新线程创建初始Java虚拟机堆栈，则Java虚拟机机器抛出一个OutOfMemoryError。

对于堆，请参阅第3.5.3节。

• 如果计算需要的堆多于自动存储管理系统可以提供的堆，则Java虚拟机将抛出一个OutOfMemoryError。

因此，它在分配对象之前预先进行了计算。

发生的情况是，JVM尝试在称为永久生成区域（或PermSpace）的内存中为对象分配内存。如果分配失败（即使在JVM调用垃圾回收器尝试并分配可用空间之后），也会抛出OutOfMemoryError。即使是异常也需要内存空间，因此错误将无限期抛出。

进一步阅读。？而且，OutOfMemoryError可以在不同的JVM结构中发生。

Graham Borland似乎是对的：至少我的 JVM显然重用了OutOfMemoryErrors。为了对此进行测试，我编写了一个简单的测试程序：

class OOMTest {
    private static void test (OutOfMemoryError o) {
        try {
            for (int n = 1; true; n += n) {
                int[] foo = new int[n];
            }
        } catch (OutOfMemoryError e) {
            if (e == o)
                System.out.println("Got the same OutOfMemoryError twice: " + e);
            else test(e);
        }
    }
    public static void main (String[] args) {
        test(null);
    }
}

运行它会产生以下输出：

$ javac OOMTest.java && java -Xmx10m OOMTest 
Got the same OutOfMemoryError twice: java.lang.OutOfMemoryError: Java heap space

顺便说一句，我正在运行的JVM（在Ubuntu 10.04上）是这样的：

$ java -version
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)

编辑：我尝试查看如果使用以下程序强制 JVM完全耗尽内存，会发生什么情况：

class OOMTest2 {
    private static void test (int n) {
        int[] foo;
        try {
            foo = new int[n];
            test(n * 2);
        }
        catch (OutOfMemoryError e) {
            test((n+1) / 2);
        }
    }
    public static void main (String[] args) {
        test(1);
    }
}

事实证明，它似乎永远循环。但是，奇怪的是，尝试用Ctrl+ 终止程序C不起作用，而仅给出以下消息：

Java HotSpot(TM) 64-Bit Server VM warning: Exception java.lang.OutOfMemoryError occurred dispatching signal SIGINT to handler- the VM may need to be forcibly terminated

大多数运行时环境会在启动时预先分配或保留足够的内存来处理内存不足的情况。我想象大多数理智的JVM实现都会做到这一点。

上一次我使用Java并使用调试器进行工作时，堆检查器显示JVM在启动时分配了OutOfMemoryError实例。换句话说，它在程序有机会开始消耗（更不用说耗尽）内存之前分配对象。

根据JVM Spec第3.5.2章：

如果可以动态扩展Java虚拟机堆栈，并且尝试进行扩展，但是可以提供足够的内存来实现扩展，或者如果没有足够的内存来为新线程创建初始Java虚拟机堆栈，则Java虚拟机机器抛出一个OutOfMemoryError。

每个Java虚拟机都必须保证它将抛出一个OutOfMemoryError。这意味着，OutOfMemoryError即使没有堆空间，它也必须能够创建的实例（或必须事先创建）。

尽管不必保证，但仍有足够的内存来捕获它并打印一个不错的堆栈跟踪...

加成

您添加了一些代码来显示，如果JVM必须抛出多个以上的空间，则它可能会耗尽堆空间OutOfMemoryError。但是这样的实现将违反上面的要求。

并不需要抛出的实例OutOfMemoryError是唯一的或根据需要创建的。JVM可以OutOfMemoryError在启动期间准备好一个实例，并在堆空间用完时抛出该实例-在正常环境下，只有一次。换句话说：OutOfMemoryError我们看到的实例可能是单例。

有趣的问题:-)。当其他人对理论方面做出了很好的解释时，我决定尝试一下。这是在Oracle JDK 1.6.0_26，Windows 7 64位上。

测试设置

我写了一个简单的程序来耗尽内存（见下文）。

该程序只是创建一个static java.util.List，并不断向其中填充新的字符串，直到抛出OOM为止。然后，它将捕获并继续陷入无尽的循环（JVM不良...）。

测试结果

从输出中可以看到，前四次OOME被抛出，它带有堆栈跟踪。之后，后续的OOME仅java.lang.OutOfMemoryError: Java heap space在printStackTrace()被调用时打印。

因此，显然JVM会尽力打印堆栈跟踪，但是如果内存确实很紧，它会忽略该跟踪，就像其他答案所建议的那样。

同样有趣的是OOME的哈希码。请注意，前几个OOME都有不同的哈希值。JVM开始忽略堆栈跟踪后，哈希值始终相同。这表明JVM将尽可能长地使用新鲜的（预分配的？）OOME实例，但是如果推入推挤，它将仅重用同一实例，而不会抛出任何异常。

输出量

注意：我截断了一些堆栈跟踪以使输出更易于阅读（“ [...]”）。

iteration 0
iteration 100000
iteration 200000
iteration 300000
iteration 400000
iteration 500000
iteration 600000
iteration 700000
iteration 800000
iteration 900000
iteration 1000000
iteration 1100000
iteration 1200000
iteration 1300000
iteration 1400000
iteration 1500000
Ouch: java.lang.OutOfMemoryError: Java heap space; hash: 1069480624
Keep on trying...
java.lang.OutOfMemoryError: Java heap space
    at java.util.Arrays.copyOf(Unknown Source)
    at java.util.Arrays.copyOf(Unknown Source)
    at java.util.ArrayList.ensureCapacity(Unknown Source)
    at java.util.ArrayList.add(Unknown Source)
    at testsl.Div.gobbleUpMemory(Div.java:23)
    at testsl.Div.exhaustMemory(Div.java:12)
    at testsl.Div.main(Div.java:7)
java.lang.OutOfMemoryError: Java heap space
    at java.util.Arrays.copyOf(Unknown Source)
[...]
Ouch: java.lang.OutOfMemoryError: Java heap space; hash: 616699029
Keep on trying...
java.lang.OutOfMemoryError: Java heap space
    at java.util.Arrays.copyOf(Unknown Source)
[...]
Ouch: java.lang.OutOfMemoryError: Java heap space; hash: 2136955031
Keep on trying...
java.lang.OutOfMemoryError: Java heap space
    at java.util.Arrays.copyOf(Unknown Source)
[...]
Ouch: java.lang.OutOfMemoryError: Java heap space; hash: 1535562945
Keep on trying...
java.lang.OutOfMemoryError: Java heap space
Ouch: java.lang.OutOfMemoryError: Java heap space; hash: 1734048134
Keep on trying...
Ouch: java.lang.OutOfMemoryError: Java heap space; hash: 1734048134
Keep on trying...
java.lang.OutOfMemoryError: Java heap space
Ouch: java.lang.OutOfMemoryError: Java heap space; hash: 1734048134
Keep on trying...
[...]

该程序

public class Div{
    static java.util.List<String> list = new java.util.ArrayList<String>();

    public static void main(String[] args) {
        exhaustMemory();
    }

    private static void exhaustMemory() {
        try {
            gobbleUpMemory();
        } catch (OutOfMemoryError e) {
            System.out.println("Ouch: " + e+"; hash: "+e.hashCode());
            e.printStackTrace();
            System.out.println("Keep on trying...");
            exhaustMemory();
        }
    }

    private static void gobbleUpMemory() {
        for (int i = 0; i < 10000000; i++) {
            list.add(new String("some random long string; use constructor to force new instance"));
            if (i % 10000000== 0) {
                System.out.println("iteration "+i);
            }
        }

    }
}

我很确定，JVM将绝对确保它至少有足够的内存来在内存不足之前引发异常。

表示尝试违反托管内存环境边界的异常由所述环境的运行时处理，在这种情况下为JVM。JVM是它自己的进程，正在运行应用程序的IL。如果程序尝试进​​行调用以将调用堆栈扩展到限制之外，或者分配的内存超出JVM可以保留的内存，则运行时本身将注入异常，这将导致调用堆栈被取消。无论您的程序当前需要多少内存，或者其调用堆栈有多深，JVM都会在其自己的进程范围内分配足够的内存来创建所述异常并将其注入到您的代码中。

您似乎将JVM在其中运行Java程序的JVM保留的虚拟内存与主机OS在其中将JVM作为本地进程运行的本地内存混淆了。您机器上的JVM在操作系统管理的内存中运行，而不是在JVM保留用于运行Java程序的内存中运行。

进一步阅读：

• http://java.sys-con.com/node/1229281
• http://publib.boulder.ibm.com/infocenter/javasdk/tools/index.jsp?topic=%2Fcom.ibm.java.doc.igaa%2F_1vg000121410cbe-1195c23a635-7ffa_1001.html

而作为最后一点，试图赶上一个java.lang.Error的（和它的子类），以打印堆栈跟踪可能不会给你任何有用的信息。您需要堆转储。

为了从功能上进一步阐明@Graham Borland的答案，JVM在启动时执行了以下操作：

private static final OutOfMemoryError OOME = new OutOfMemoryError();

后来，JVM执行以下Java字节码之一：“ new”，“ anewarray”或“ multianewarray”。该指令使JVM在内存不足的情况下执行许多步骤：

1. 调用本地函数，例如allocate()。 allocate()尝试为特定类或数组的新实例分配内存。
2. 该分配请求失败，因此JVM调用了另一个本机函数，例如doGC()，尝试进行垃圾回收。
3. 当该函数返回时，allocate()尝试再次为该实例分配内存。
4. 如果失败（*），则JVM在allocate（）中仅执行一个throw OOME;，引用其在启动时实例化的OOME。注意，它不必分配该OOME，而只是引用它。

显然，这些不是文字上的步骤；在实现中，它们因JVM而异，但这是高级概念。

（*）在失败之前，这里需要进行大量工作。JVM将尝试清除SoftReference对象，使用世代收集器时尝试将其直接分配到使用权的世代中，并可能进行其他操作（例如终结处理）。

JVM将预分配的答案OutOfMemoryErrors确实是正确的。
除了通过引起内存不足的情况进行测试外，我们还可以检查任何JVM的堆（我使用了一个只做睡眠的小程序，使用Java 8 update 31中的Oracle Hotspot JVM运行它）。

使用jmap我们可以看到似乎有9个OutOfMemoryError实例（即使我们有足够的内存）：

> jmap -histo 12103 | grep OutOfMemoryError
 71：9288 java.lang.OutOfMemoryError
170：1 32 [Ljava.lang.OutOfMemoryError;

然后我们可以生成一个堆转储：

> jmap -dump：format = b，file = heap.hprof 12315

并使用Eclipse Memory Analyzer打开它，其中的OQL查询显示JVM实际上似乎已OutOfMemoryErrors为所有可能的消息预分配：

实际上可以预先分配它们的Java 8 Hotspot JVM的代码可以在此处找到，看起来像这样（省略了一些部分）：

...
// Setup preallocated OutOfMemoryError errors
k = SystemDictionary::resolve_or_fail(vmSymbols::java_lang_OutOfMemoryError(), true, CHECK_false);
k_h = instanceKlassHandle(THREAD, k);
Universe::_out_of_memory_error_java_heap = k_h->allocate_instance(CHECK_false);
Universe::_out_of_memory_error_metaspace = k_h->allocate_instance(CHECK_false);
Universe::_out_of_memory_error_class_metaspace = k_h->allocate_instance(CHECK_false);
Universe::_out_of_memory_error_array_size = k_h->allocate_instance(CHECK_false);
Universe::_out_of_memory_error_gc_overhead_limit =
  k_h->allocate_instance(CHECK_false);

...

if (!DumpSharedSpaces) {
  // These are the only Java fields that are currently set during shared space dumping.
  // We prefer to not handle this generally, so we always reinitialize these detail messages.
  Handle msg = java_lang_String::create_from_str("Java heap space", CHECK_false);
  java_lang_Throwable::set_message(Universe::_out_of_memory_error_java_heap, msg());

  msg = java_lang_String::create_from_str("Metaspace", CHECK_false);
  java_lang_Throwable::set_message(Universe::_out_of_memory_error_metaspace, msg());
  msg = java_lang_String::create_from_str("Compressed class space", CHECK_false);
  java_lang_Throwable::set_message(Universe::_out_of_memory_error_class_metaspace, msg());

  msg = java_lang_String::create_from_str("Requested array size exceeds VM limit", CHECK_false);
  java_lang_Throwable::set_message(Universe::_out_of_memory_error_array_size, msg());

  msg = java_lang_String::create_from_str("GC overhead limit exceeded", CHECK_false);
  java_lang_Throwable::set_message(Universe::_out_of_memory_error_gc_overhead_limit, msg());

  msg = java_lang_String::create_from_str("/ by zero", CHECK_false);
  java_lang_Throwable::set_message(Universe::_arithmetic_exception_instance, msg());

  // Setup the array of errors that have preallocated backtrace
  k = Universe::_out_of_memory_error_java_heap->klass();
  assert(k->name() == vmSymbols::java_lang_OutOfMemoryError(), "should be out of memory error");
  k_h = instanceKlassHandle(THREAD, k);

  int len = (StackTraceInThrowable) ? (int)PreallocatedOutOfMemoryErrorCount : 0;
  Universe::_preallocated_out_of_memory_error_array = oopFactory::new_objArray(k_h(), len, CHECK_false);
  for (int i=0; i<len; i++) {
    oop err = k_h->allocate_instance(CHECK_false);
    Handle err_h = Handle(THREAD, err);
    java_lang_Throwable::allocate_backtrace(err_h, CHECK_false);
    Universe::preallocated_out_of_memory_errors()->obj_at_put(i, err_h());
  }
  Universe::_preallocated_out_of_memory_error_avail_count = (jint)len;
}
...

并且此代码显示JVM将首先尝试使用预先分配的错误之一来为堆栈跟踪留出空间，然后回落到没有堆栈跟踪的错误中：

oop Universe::gen_out_of_memory_error(oop default_err) {
  // generate an out of memory error:
  // - if there is a preallocated error with backtrace available then return it wth
  //   a filled in stack trace.
  // - if there are no preallocated errors with backtrace available then return
  //   an error without backtrace.
  int next;
  if (_preallocated_out_of_memory_error_avail_count > 0) {
    next = (int)Atomic::add(-1, &_preallocated_out_of_memory_error_avail_count);
    assert(next < (int)PreallocatedOutOfMemoryErrorCount, "avail count is corrupt");
  } else {
    next = -1;
  }
  if (next < 0) {
    // all preallocated errors have been used.
    // return default
    return default_err;
  } else {
    // get the error object at the slot and set set it to NULL so that the
    // array isn't keeping it alive anymore.
    oop exc = preallocated_out_of_memory_errors()->obj_at(next);
    assert(exc != NULL, "slot has been used already");
    preallocated_out_of_memory_errors()->obj_at_put(next, NULL);

    // use the message from the default error
    oop msg = java_lang_Throwable::message(default_err);
    assert(msg != NULL, "no message");
    java_lang_Throwable::set_message(exc, msg);

    // populate the stack trace and return it.
    java_lang_Throwable::fill_in_stack_trace_of_preallocated_backtrace(exc);
    return exc;
  }
}