O que acontece quando há memória insuficiente para gerar um OutOfMemoryError?

Estou ciente de que todo objeto requer memória de pilha e toda referência / primitivo na pilha requer memória de pilha.

Quando tento criar um objeto no heap e não há memória suficiente para fazer isso, a JVM cria um java.lang.OutOfMemoryError no heap e o lança para mim.

Então, implicitamente, isso significa que há alguma memória reservada pela JVM na inicialização.

O que acontece quando essa memória reservada é usada (definitivamente seria usada, leia a discussão abaixo) e a JVM não possui memória suficiente no heap para criar uma instância de java.lang.OutOfMemoryError ?

Isso apenas trava? Ou ele me daria uma nullvez que não há memória para newuma instância do 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
}

==

Por que a JVM não pôde reservar memória suficiente?

Independentemente da quantidade de memória reservada, ainda é possível que essa memória seja usada se a JVM não tiver uma maneira de "recuperar" essa memória:

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
                    }
                }
            }
        }
    }
}

Ou, mais concisamente:

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

A JVM realmente nunca fica sem memória. Faz o cálculo de memória da pilha de heap com antecedência.

A estrutura da JVM, capítulo 3 , seção 3.5.2, afirma:

• Se as pilhas da máquina virtual Java puderem ser expandidas dinamicamente e a tentativa de expansão, mas a memória insuficiente puder ser disponibilizada para efetivar a expansão, ou se a memória insuficiente estiver disponível para criar a pilha inicial da máquina virtual Java para um novo encadeamento, o Java virtual máquina lança um OutOfMemoryError.

Para Heap , Seção 3.5.3.

• Se um cálculo exigir mais heap do que o sistema de gerenciamento de armazenamento automático pode ser disponibilizado, a máquina virtual Java lançará um OutOfMemoryError.

Portanto, ele faz um cálculo antecipado antes de fazer a alocação do objeto.

O que acontece é que a JVM tenta alocar memória para um objeto na memória chamado região de geração permanente (ou PermSpace). Se a alocação falhar (mesmo após a JVM chamar o Garbage Collector para tentar alocar espaço livre), ele emitirá um OutOfMemoryError. Mesmo as exceções requerem um espaço de memória para que o erro seja gerado indefinidamente.

Leitura adicional. ? Além disso, OutOfMemoryErrorpode ocorrer em diferentes estruturas da JVM.

Graham Borland parece estar certo : pelo menos minha JVM aparentemente reutiliza OutOfMemoryErrors. Para testar isso, escrevi um programa de teste simples:

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);
    }
}

A execução produz esta saída:

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

BTW, a JVM que estou executando (no Ubuntu 10.04) é esta:

$ 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)

Edit: Tentei ver o que aconteceria se eu obrigasse a JVM a ficar completamente sem memória usando o seguinte programa:

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);
    }
}

Como se vê, parece fazer um loop para sempre. No entanto, curiosamente, tentar finalizar o programa com Ctrl+ Cnão funciona, mas apenas fornece a seguinte mensagem:

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

A maioria dos ambientes de tempo de execução pré-aloca na inicialização ou reserva memória suficiente para lidar com situações de falta de memória. Eu imagino que a maioria das implementações sãs da JVM faria isso.

Na última vez em que estava trabalhando em Java e usando um depurador, o inspetor de heap mostrou que a JVM alocou uma instância de OutOfMemoryError na inicialização. Em outras palavras, ele aloca o objeto antes que seu programa possa começar a consumir, e muito menos ficar sem memória.

Na especificação da JVM, capítulo 3.5.2:

Se as pilhas da Java virtual machine puderem ser expandidas dinamicamente e a tentativa de expansão, mas a memória insuficiente puder ser disponibilizada para efetivar a expansão, ou se a memória insuficiente puder ser disponibilizada para criar a pilha inicial da Java virtual machine para um novo encadeamento, o Java virtual máquina lança umOutOfMemoryError .

Toda Java Virtual Machine tem que garantir que lançará um OutOfMemoryError. Isso implica que ele deve ser capaz de criar uma instância OutOfMemoryError(ou ter que ser criada com antecedência), mesmo que não haja mais espaço de pilha.

Embora não seja necessário garantir, resta memória suficiente para capturá-lo e imprimir um bom rastreamento de pilha ...

Adição

Você adicionou algum código para mostrar, que a JVM pode ficar sem espaço de heap se precisar lançar mais de um OutOfMemoryError. Mas essa implementação violaria o requisito acima.

Não é necessário que as instâncias lançadas OutOfMemoryErrorsejam únicas ou criadas sob demanda. Uma JVM pode preparar exatamente uma instância de OutOfMemoryErrordurante a inicialização e executá-la sempre que ficar sem espaço de heap - que é uma vez, no ambiente normal. Em outras palavras: a instância do OutOfMemoryErrorque vemos pode ser um singleton.

Pergunta interessante :-). Enquanto os outros deram boas explicações sobre os aspectos teóricos, decidi experimentá-lo. Isso está no Oracle JDK 1.6.0_26, Windows 7 de 64 bits.

Configuração de teste

Eu escrevi um programa simples para esgotar a memória (veja abaixo).

O programa apenas cria uma estática java.util.Liste continua colocando novas seqüências nela, até que o OOM seja acionado. Em seguida, ele o captura e continua a acumular em um loop sem fim (pobre JVM ...).

Resultado do teste

Como se pode ver pela saída, as quatro primeiras vezes que o OOME é lançado, ele vem com um rastreamento de pilha. Depois disso, os OOMEs subsequentes são impressos apenas java.lang.OutOfMemoryError: Java heap spacese printStackTrace()forem invocados.

Então, aparentemente, a JVM faz um esforço para imprimir um rastreamento de pilha, se puder, mas se a memória estiver realmente fraca, ela simplesmente omite o rastreamento, exatamente como as outras respostas sugerem.

Também interessante é o código de hash do OOME. Observe que os primeiros OOME têm hashes diferentes. Depois que a JVM começa a omitir rastreamentos de pilha, o hash é sempre o mesmo. Isso sugere que a JVM usará instâncias OOME novas (pré-alocadas?) O maior tempo possível, mas, se for necessário pressionar, apenas reutilizará a mesma instância em vez de não ter nada para lançar.

Resultado

Nota: Truncei alguns rastreios de pilha para facilitar a leitura da saída ("[...]").

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...
[...]

O programa

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);
            }
        }

    }
}

Tenho certeza de que a JVM garantirá que tenha pelo menos memória suficiente para lançar uma exceção antes de ficar sem memória.

Exceções indicando uma tentativa de violar os limites de um ambiente de memória gerenciada são tratadas pelo tempo de execução do referido ambiente, neste caso a JVM. A JVM é seu próprio processo, que está executando a IL do seu aplicativo. Se um programa tentar fazer uma chamada que estenda a pilha de chamadas além dos limites ou alocar mais memória do que a JVM pode reservar, o próprio tempo de execução injetará uma exceção, o que fará com que a pilha de chamadas seja desenrolada. Independentemente da quantidade de memória que seu programa precisa atualmente ou da profundidade de sua pilha de chamadas, a JVM terá alocado memória suficiente dentro de seus próprios limites do processo para criar a exceção e injetar em seu código.

Você parece estar confundindo a memória virtual reservada pela JVM na qual a JVM executa programas Java com a memória nativa do SO host na qual a JVM é executada como um processo nativo. A JVM em sua máquina está sendo executada na memória gerenciada pelo sistema operacional, não na memória que a JVM reservou para executar programas Java.

Leitura adicional:

• 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

E, como observação final, tentar capturar um java.lang.Error (e suas classes descendentes) para imprimir um rastreamento de pilha pode não fornecer informações úteis. Você deseja um despejo de pilha.

Para esclarecer melhor a resposta de @Graham Borland, funcionalmente, a JVM faz isso na inicialização:

private static final OutOfMemoryError OOME = new OutOfMemoryError();

Posteriormente, a JVM executa um dos seguintes bytecodes Java: 'new', 'anewarray' ou 'multianewarray'. Esta instrução faz com que a JVM execute várias etapas em uma condição de falta de memória:

1. Invoque uma função nativa, digamos allocate(). allocate()tenta alocar memória para alguns uma nova instância de uma classe ou matriz específica.
2. Como a solicitação de alocação falha, a JVM chama outra função nativa, por exemplo doGC(), que tenta fazer a coleta de lixo.
3. Quando essa função retorna, allocate()tenta alocar memória para a instância novamente.
4. Se isso falhar (*), a JVM, dentro de throw OOME;assignate (), simplesmente executa a , referindo-se ao OOME que foi instanciado na inicialização. Observe que ele não precisava alocar esse OOME, apenas se refere a ele.

Obviamente, essas não são etapas literais; eles variam de JVM para JVM na implementação, mas essa é a ideia de alto nível.

(*) Uma quantidade significativa de trabalho acontece aqui antes de falhar. A JVM tentará limpar objetos do SoftReference, tentará alocar diretamente na geração ocupada ao usar um coletor de gerações e possivelmente outras coisas, como finalização.

As respostas que dizem que a JVM será pré-alocada OutOfMemoryErrorsestão realmente corretas.
Além de testar isso provocando uma situação de falta de memória, podemos apenas verificar a pilha de qualquer JVM (usei um pequeno programa que apenas dorme, executando-o usando o Hotspot JVM da Oracle a partir do Java 8, atualização 31).

Usando jmap, vemos que parece haver 9 instâncias de OutOfMemoryError (embora tenhamos muita memória):

> jmap -histo 12103 | grep OutOfMemoryError
 71: 9 288 java.lang.OutOfMemoryError
170: 1 32 [Ljava.lang.OutOfMemoryError;

Em seguida, podemos gerar um dump de heap:

> jmap -dump: format = b, arquivo = heap.hprof 12315

e abra-o usando o Eclipse Memory Analyzer , onde uma consulta OQL mostra que a JVM realmente parece pré-alocada OutOfMemoryErrorspara todas as mensagens possíveis:

O código da JVM do Java 8 Hotspot que realmente os pré-aloca pode ser encontrado aqui e se parece com este (com algumas partes omitidas):

...
// 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;
}
...

e esse código mostra que a JVM primeiro tentará usar um dos erros pré-alocados com espaço para um rastreamento de pilha e, em seguida, retornará a um sem rastreamento de pilha:

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;
  }
}