Apa yang terjadi ketika ada memori yang tidak cukup untuk melempar OutOfMemoryError?

Saya sadar bahwa setiap objek membutuhkan memori tumpukan dan setiap primitif / referensi pada stack memerlukan memori tumpukan.

Ketika saya mencoba membuat objek di heap dan ada memori yang tidak cukup untuk melakukannya, JVM membuat java.lang.OutOfMemoryError pada heap dan melemparkannya ke saya.

Jadi secara implisit, ini berarti bahwa ada beberapa memori yang disediakan oleh JVM saat startup.

Apa yang terjadi ketika memori yang dicadangkan ini digunakan (pasti akan digunakan, baca diskusi di bawah) dan JVM tidak memiliki cukup memori pada heap untuk membuat instance java.lang.OutOfMemoryError ?

Apakah hanya menggantung? Atau apakah dia akan melemparkan saya nullkarena tidak ada memori untuk newinstance 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
}

==

Mengapa JVM tidak dapat menyimpan memori yang cukup?

Tidak peduli berapa banyak memori yang dicadangkan, masih mungkin memori itu digunakan jika JVM tidak memiliki cara untuk "merebut kembali" memori itu:

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

Atau lebih ringkas:

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

JVM tidak pernah benar-benar kehabisan memori. Itu perhitungan memori tumpukan tumpukan di muka.

The Struktur JVM, Bab 3 , bagian 3.5.2 negara:

• Jika tumpukan mesin virtual Java dapat diperluas secara dinamis, dan ekspansi dilakukan tetapi memori yang tidak mencukupi dapat dibuat untuk mempengaruhi ekspansi, atau jika memori yang tidak cukup dapat dibuat tersedia untuk membuat tumpukan mesin virtual Java awal untuk utas baru, Java virtual mesin melempar OutOfMemoryError.

Untuk Heap , Bagian 3.5.3.

• Jika perhitungan membutuhkan lebih banyak tumpukan daripada yang dapat disediakan oleh sistem manajemen penyimpanan otomatis, mesin virtual Java melempar OutOfMemoryError .

Jadi, ia melakukan perhitungan terlebih dahulu sebelum melakukan alokasi objek.

Apa yang terjadi adalah bahwa JVM mencoba mengalokasikan memori untuk objek dalam memori yang disebut Permanent Generation region (atau PermSpace). Jika alokasi gagal (bahkan setelah JVM meminta Pengumpul Sampah untuk mencoba & mengalokasikan ruang kosong), itu melempar OutOfMemoryError. Bahkan pengecualian membutuhkan ruang memori sehingga kesalahan akan dibuang tanpa batas.

Bacaan lebih lanjut. ? Selanjutnya, OutOfMemoryErrordapat terjadi dalam struktur JVM yang berbeda .

Graham Borland tampaknya benar : setidaknya JVM saya tampaknya menggunakan kembali OutOfMemoryErrors. Untuk menguji ini, saya menulis sebuah program tes sederhana:

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

Menjalankannya menghasilkan output ini:

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

BTW, JVM yang saya jalankan (di Ubuntu 10,04) adalah ini:

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

Sunting: Saya mencoba melihat apa yang akan terjadi jika saya memaksa JVM untuk kehabisan memori menggunakan program berikut:

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

Ternyata, itu tampaknya berulang selamanya. Namun, anehnya, mencoba untuk menghentikan program dengan Ctrl+ Ctidak berhasil, tetapi hanya memberikan pesan berikut:

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

Sebagian besar lingkungan runtime akan melakukan pra-alokasi pada saat startup, atau sebaliknya cadangan, cukup memori untuk menangani situasi kelaparan memori. Saya membayangkan implementasi JVM paling waras akan melakukan ini.

Terakhir kali saya bekerja di Java dan menggunakan debugger, inspektur heap menunjukkan bahwa JVM mengalokasikan instance OutOfMemoryError pada startup. Dengan kata lain, itu mengalokasikan objek sebelum program Anda memiliki kesempatan untuk mulai mengkonsumsi, apalagi kehabisan, memori.

Dari Spesifikasi JVM, Bab 3.5.2:

Jika tumpukan mesin virtual Java dapat diperluas secara dinamis, dan ekspansi dilakukan tetapi memori yang tidak mencukupi dapat tersedia untuk memengaruhi ekspansi, atau jika memori yang tidak cukup dapat dibuat tersedia untuk membuat tumpukan mesin virtual Java awal untuk utas baru, Java virtual mesin melemparOutOfMemoryError .

Setiap Java Virtual Machine harus menjamin bahwa ia akan melempar OutOfMemoryError. Itu menyiratkan, bahwa ia harus mampu membuat contohOutOfMemoryError (atau harus dibuat di muka) bahkan jika tidak ada ruang tumpukan yang tersisa.

Meskipun tidak harus menjamin, bahwa ada memori yang tersisa untuk menangkapnya dan mencetak stacktrace yang bagus ...

Tambahan

Anda menambahkan beberapa kode untuk ditampilkan, bahwa JVM mungkin kehabisan ruang tumpukan jika harus membuang lebih dari satu OutOfMemoryError . Tetapi implementasi seperti itu akan melanggar persyaratan dari atas.

Tidak ada persyaratan bahwa instance yang dilemparkan OutOfMemoryErroritu unik atau dibuat atas permintaan. JVM dapat menyiapkan tepat satu contoh OutOfMemoryErrorselama startup dan melemparkan ini setiap kali kehabisan ruang tumpukan - yang pernah, dalam lingkungan normal. Dengan kata lain: contoh OutOfMemoryErroryang kita lihat bisa saja singleton.

Pertanyaan menarik :-). Sementara yang lain telah memberikan penjelasan yang baik tentang aspek-aspek teoretis, saya memutuskan untuk mencobanya. Ini ada di Oracle JDK 1.6.0_26, Windows 7 64 bit.

Pengaturan tes

Saya menulis sebuah program sederhana untuk menghabiskan memori (lihat di bawah).

Program ini hanya membuat statis java.util.List, dan terus memasukkan string segar ke dalamnya, hingga OOM terlempar. Kemudian menangkapnya dan terus mengisi dalam loop tanpa akhir (JVM yang buruk ...).

Hasil tes

Seperti yang dapat dilihat dari output, OOME empat kali pertama dilempar, ia datang dengan jejak tumpukan. Setelah itu, OOME berikutnya hanya mencetak java.lang.OutOfMemoryError: Java heap spacejika printStackTrace()dipanggil.

Jadi rupanya JVM berusaha untuk mencetak jejak stack jika itu bisa, tetapi jika memori benar-benar ketat, itu hanya menghilangkan jejak, seperti jawaban yang disarankan lainnya.

Yang juga menarik adalah kode hash OOME. Perhatikan bahwa beberapa OOME pertama semuanya memiliki hash yang berbeda. Setelah JVM mulai menghilangkan jejak stack, hash selalu sama. Ini menunjukkan bahwa JVM akan menggunakan instance OOME baru (preallocated?) Selama mungkin, tetapi jika push datang untuk mendorong, itu hanya akan menggunakan kembali contoh yang sama daripada tidak memiliki apa pun untuk dilemparkan.

Keluaran

Catatan: Saya memotong beberapa jejak tumpukan untuk membuat output lebih mudah dibaca ("[...]").

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

Program

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

    }
}

Saya cukup yakin, JVM akan memastikan bahwa ia memiliki setidaknya memori yang cukup untuk melempar pengecualian sebelum kehabisan memori.

Pengecualian yang menunjukkan upaya untuk melanggar batas-batas lingkungan memori terkelola ditangani oleh runtime dari lingkungan tersebut, dalam hal ini JVM. JVM adalah prosesnya sendiri, yang menjalankan IL aplikasi Anda. Jika suatu program mencoba untuk membuat panggilan yang memperpanjang tumpukan panggilan melampaui batas, atau mengalokasikan lebih banyak memori daripada yang dapat dipesan JVM, runtime itu sendiri akan menyuntikkan pengecualian, yang akan menyebabkan tumpukan panggilan dibatalkan. Terlepas dari jumlah memori yang dibutuhkan oleh program Anda saat ini, atau seberapa dalam tumpukan panggilannya, JVM akan mengalokasikan cukup memori dalam batas prosesnya sendiri untuk membuat pengecualian dan menyuntikkannya ke dalam kode Anda.

Anda tampaknya membingungkan memori virtual yang disediakan oleh JVM di mana JVM menjalankan program Java dengan memori asli OS host di mana JVM dijalankan sebagai proses asli. JVM pada mesin Anda berjalan di memori yang dikelola oleh OS, bukan di memori yang disediakan JVM untuk menjalankan program Java.

Bacaan lebih lanjut:

• 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

Dan sebagai catatan akhir, mencoba untuk menangkap sebuah java.lang.Error (dan kelas turunannya) untuk mencetak stacktrace mungkin tidak memberikan informasi yang berguna. Anda ingin tumpukan tumpukan sebagai gantinya.

Untuk lebih memperjelas jawaban @ Boraham Borland, secara fungsional, JVM melakukan hal ini pada saat startup:

private static final OutOfMemoryError OOME = new OutOfMemoryError();

Kemudian, JVM mengeksekusi salah satu bytecode Java berikut: 'baru', 'anewarray', atau 'multianewarray'. Instruksi ini menyebabkan JVM untuk melakukan sejumlah langkah dalam kondisi kehabisan memori:

1. Meminta fungsi asli, katakanlah allocate(). allocate()mencoba mengalokasikan memori untuk beberapa instance baru dari kelas atau array tertentu.
2. Permintaan alokasi itu gagal, sehingga JVM memanggil fungsi asli lain, misalnya doGC(), yang mencoba melakukan pengumpulan sampah.
3. Ketika fungsi itu kembali, allocate()cobalah untuk mengalokasikan memori untuk instance sekali lagi.
4. Jika itu gagal (*), maka JVM, dalam mengalokasikan (), cukup melakukan a throw OOME;, mengacu pada OOME yang dipakai saat startup. Perhatikan bahwa itu tidak harus mengalokasikan OOME itu, itu hanya merujuk padanya.

Jelas, ini bukan langkah literal; mereka akan bervariasi dari JVM ke JVM dalam implementasi, tetapi ini adalah ide tingkat tinggi.

(*) Sejumlah besar pekerjaan terjadi di sini sebelum gagal. JVM akan berusaha untuk menghapus objek SoftReference, mencoba alokasi langsung ke generasi bertenor saat menggunakan kolektor generasi, dan mungkin hal-hal lain, seperti finalisasi.

Jawaban yang mengatakan bahwa JVM akan melakukan pra-alokasi OutOfMemoryErrorsmemang benar.
Selain menguji ini dengan memprovokasi situasi kehabisan memori kita hanya dapat memeriksa tumpukan JVM (saya menggunakan program kecil yang hanya tidur, menjalankannya menggunakan Oracle Hotspot JVM dari Java 8 update 31).

Menggunakan jmap kami melihat bahwa tampaknya ada 9 contoh dari OutOfMemoryError (walaupun kami memiliki banyak memori):

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

Kami kemudian dapat menghasilkan heap dump:

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

dan membukanya menggunakan Eclipse Memory Analyzer , di mana kueri OQL menunjukkan bahwa JVM sebenarnya pra-alokasi OutOfMemoryErrorsuntuk semua pesan yang mungkin:

Kode untuk Java 8 Hotspot JVM yang sebenarnya preallocates ini dapat ditemukan di sini , dan terlihat seperti ini (dengan beberapa bagian dihilangkan):

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

dan kode ini menunjukkan bahwa JVM pertama-tama akan mencoba menggunakan salah satu kesalahan yang dialokasikan sebelumnya dengan ruang untuk jejak stack, dan kemudian kembali ke kesalahan tanpa jejak stack:

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