Что происходит, когда недостаточно памяти для выброса ошибки OutOfMemoryError?

Я знаю, что каждый объект требует кучи памяти, и каждый примитив / ссылка в стеке требует стековой памяти.

Когда я пытаюсь создать объект в куче, и для этого недостаточно памяти, JVM создает в куче java.lang.OutOfMemoryError и выдает его мне.

Таким образом, это неявно означает, что JVM зарезервировала некоторую память при запуске.

Что происходит, когда эта зарезервированная память израсходована (она, безусловно, будет израсходована, см. Обсуждение ниже), а JVM не хватает памяти в куче для создания экземпляра java.lang.OutOfMemoryError ?

Это просто висит? Или он бросит мне, nullтак как нет памяти для newэкземпляра OOM?

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 никогда не хватает памяти. Это делает вычисление памяти стека кучи заранее.

Структура виртуальной машины Java, глава 3 , раздел 3.5.2 гласит:

• Если стеки виртуальных машин Java могут динамически расширяться, и предпринимается попытка расширения, но может быть недостаточно доступной памяти, чтобы осуществить расширение, или если недостаточно памяти может быть доступно для создания начального стека виртуальной машины Java для нового потока, виртуальная Java машина кидает OutOfMemoryError.

Для кучи , раздел 3.5.3.

• Если для вычислений требуется больше кучи, чем может быть сделано доступной системой автоматического управления хранением, виртуальная машина Java выдает OutOfMemoryError.

Таким образом, он делает вычисления заранее, прежде чем делать выделение объекта.

Что происходит, так это то, что JVM пытается выделить память для объекта в памяти, называемой областью постоянного поколения (или PermSpace). Если распределение завершается неудачно (даже после того, как JVM вызовет сборщик мусора, чтобы попытаться выделить свободное пространство), он выбрасывает OutOfMemoryError. Даже для исключений требуется место в памяти, поэтому ошибка будет генерироваться бесконечно.

Дальнейшее чтение. ? Кроме того, OutOfMemoryErrorмогут возникнуть различные структуры JVM.

Грэм Борланд, кажется, прав : по крайней мере, моя 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, глава 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 бит.

Испытательная установка

Я написал простую программу для исчерпания памяти (см. Ниже).

Программа просто создает статический элемент 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, в которой JVM запускает программы Java с собственной памятью хост-ОС, в которой 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 (и его потомков классов), чтобы напечатать StackTrace не может дать вам никакой полезной информации. Вы хотите кучу свалки вместо этого.

Чтобы дополнительно уточнить ответ @Graham Borland, функционально JVM делает это при запуске:

private static final OutOfMemoryError OOME = new OutOfMemoryError();

Позже JVM выполняет один из следующих байт-кодов Java: «новый», «anewarray» или «multianewarray». Эта инструкция заставляет JVM выполнить несколько шагов в состоянии нехватки памяти:

1. Вызов родной функции, скажем, allocate() . allocate()пытается выделить память для какого-то нового экземпляра определенного класса или массива.
2. Этот запрос на выделение не выполняется, поэтому JVM вызывает другую собственную функцию, скажем, doGC() , , которая пытается выполнить сборку мусора.
3. Когда эта функция возвращается, allocate() пытается выделить память для экземпляра еще раз.
4. Если это не удается (*), то JVM внутри allocate () просто выполняет throw OOME; allocate , ссылаясь на OOME, который был создан при запуске. Обратите внимание, что ему не нужно выделять этот OOME, он просто ссылается на него.

Очевидно, это не буквальные шаги; В зависимости от реализации они будут варьироваться от JVM к JVM, но это идея высокого уровня.

(*) Значительный объем работы происходит здесь до сбоя. JVM будет пытаться очистить объекты SoftReference, попытаться выделить непосредственно в поколение с правами владения при использовании сборщика поколений и, возможно, другие вещи, такие как финализация.

Ответы, которые говорят, что JVM будет предварительно распределять OutOfMemoryErrors, действительно верны.
В дополнение к проверке этого путем провоцирования ситуации нехватки памяти мы можем просто проверить кучу любой JVM (я использовал небольшую программу, которая просто спит, запустив ее с помощью Oracle Hotspot JVM из Java 8 update 31).

С помощью jmap мы видим, что, похоже, существует 9 экземпляров OutOfMemoryError (хотя у нас достаточно памяти):

> jmap -histo 12103 | grep OutOfMemoryError
 71: 9 288 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;
  }
}