Java.lang.outofMemoryError: Ruang timbunan Java menunjukkan memori timbunan yang tidak mencukupi, dan perlu menyemak pemprosesan objek besar, kebocoran memori dan tetapan timbunan, dan cari dan mengoptimumkan kod melalui alat analisis dump heap; 2. Kesilapan metaspace adalah perkara biasa dalam generasi kelas dinamik atau penggunaan panas kerana metadata kelas yang berlebihan, dan maxmetaspacesize harus dibatasi dan pemuatan kelas harus dioptimumkan; 3. 4. Had overhead GC melebihi bermakna GC adalah kerap tetapi kurang kitar semula, dan log GC harus dianalisis, kitaran hayat objek harus dioptimumkan, dan G1GC dan kitar semula lain harus diganti; 5. Saiz array yang diminta melebihi had VM disebabkan oleh limpahan panjang array, dan logik panjang perlu disahkan untuk mengelakkan limpahan integer, dan fail besar diproses menggunakan streaming; Ringkasan: Dump Heap dan Log GC harus diaktifkan, digabungkan dengan penyelesaian masalah alat analisis, dan menyelesaikan masalah pengurusan sumber dari tahap reka bentuk kod, dan bukan hanya memori yang semakin meningkat, yang secara asasnya dapat menyelesaikan masalah OOM.

Java OutOfMemoryError adalah kesilapan kritikal yang biasa pada runtime, biasanya menunjukkan bahawa JVM tidak dapat memperuntukkan objek kerana memori timbunan atau kawasan memori lain habis. Walaupun mesej ralat mungkin kelihatan mudah, terdapat banyak sebab di belakangnya. Berikut adalah beberapa senario OutOfMemoryError biasa dan penyelesaian masalah dan penyelesaiannya.

1. java.lang.OutOfMemoryError: Java heap space

Ini adalah jenis yang paling biasa, menunjukkan bahawa memori timbunan tidak mencukupi untuk memperuntukkan objek baru.

Sebab Biasa:

• Aplikasi ini memuatkan sejumlah besar data (seperti fail besar, cache data penuh).
• Terdapat kebocoran memori (seperti penambahan objek berterusan dalam koleksi statik tidak dibersihkan).
• Tetapan memori timbunan terlalu kecil untuk memenuhi keperluan perniagaan biasa.

Langkah Penyelesaian Masalah:

• Lihat Ralat Log : Sahkan sama ada ia dicetuskan apabila memproses objek besar atau data batch.
• Pantau menggunakan parameter JVM :

   -Xmx2g -xms2g -xx: heapdumponoutofmemoryError -xx: heapdumppath =/path/to/dumps

  Ini menghasilkan fail pembuangan timbunan (timbunan timbunan) apabila OOM.

  
• Menganalisis Dump Heap : Gunakan alat seperti Eclipse Mat atau VisualVM untuk membuka fail .hprof untuk mencari objek yang memakan memori yang paling dan rantaian mereka.
• Semak kod : Fokus pada:
  • Sama ada Map statik dan List tumbuh tak terhingga.
  • Sama ada cache tidak mempunyai mekanisme tamat tempoh (disyorkan untuk menggunakan cache dengan strategi usang seperti WeakHashMap atau Caffeine ).
  • Sama ada untuk memuatkan fail besar atau pangkalan data Jadual Penuh pada satu masa.

Penyelesaian:

• Meningkatkan memori timbunan (penyelesaian sementara):

   -Xmx4g

• Betulkan kod kebocoran memori.
• Pemprosesan Pagination Big Data untuk mengelakkan pemuatan satu kali.

2. java.lang.OutOfMemoryError: Metaspace

JDK 8 dan kemudian, Permgen digantikan dengan Metaspace untuk menyimpan metadata kelas.

Sebab Biasa:

• Aplikasi ini secara dinamik menjana sejumlah besar kelas (seperti menggunakan cglib, ASM, proksi dinamik, skrip groovy, dan lain -lain).
• Menyebarkan sejumlah besar aplikasi perang (seperti pemuat kelas Tomcat Hot yang tidak dibersihkan).
• Saiz metaspace tidak terhad atau ditetapkan terlalu kecil.

Kaedah Penyelesaian Masalah:

• Tambahkan parameter JVM untuk mematuhi penggunaan metaspace:

   -Xx: maxMetaspacesize = 512m -verbose: gc -xx: printgcdetails

• Gunakan jstat -gc <pid> untuk melihat MCMN , MCMX , MC (kapasiti metaspace) dan petunjuk lain.
• Menjana dan menganalisis pembuangan tumpukan (walaupun Metaspace tidak berada di timbunan, ia dapat membantu menilai situasi pemuatan kelas).

Penyelesaian:

• Menetapkan MaxMetaspaceSize yang munasabah menghalang pertumbuhan tanpa had.
• Semak pemuatan kelas/pemunggahan kelas yang kerap, terutamanya untuk senario penyebaran panas.
• Mengoptimumkan tingkah laku GC dengan -XX: UseG1GC dan -XX:MetaspaceSize=256m .
• Elakkan terlalu banyak penjanaan bytecode runtime.

3. java.lang.OutOfMemoryError: Unable to create new native thread

JVM cuba membuat benang baru, tetapi sistem pengendalian tidak dapat memperuntukkan sumber benang asli.

Sebab Biasa:

• Bilangan benang melebihi had sistem (had proses pengguna ulimit -u ).
• Memori sistem tidak mencukupi, dan setiap benang mengambil ruang stack 1MB secara lalai ( -Xss ).
• Aplikasi ini telah mencipta terlalu banyak benang (seperti kolam benang yang tidak digunakan, kebocoran benang).

Kaedah Penyelesaian Masalah:

• Semak nombor benang semasa:

   PS -Elf | Grep Java | WC -L

• Lihat sekatan sistem:

   ULIMIT -U # Proses Pengguna Max
  kucing/proc/sys/kernel/threads-max

• Semak Dump Thread JVM:

   jstack <pid>> thread_dump.txt

  Semak jika terdapat sejumlah besar benang atau benang yang sama yang tidak berakhir.

Penyelesaian:

• Gunakan kolam thread (seperti ThreadPoolExecutor ) dan bukannya membuat benang secara manual.
• Saiz stack thread (berhati -hati):

   -Xss256k # Kurangkan memori bagi setiap tumpukan thread

• Meningkatkan sekatan sistem (kebenaran pentadbir diperlukan):

   ULIMIT -U 65535

• Semak sama ada mana -mana benang tidak ditutup dengan betul (seperti executor.shutdown() tidak dipanggil).

4. java.lang.OutOfMemoryError: GC overhead limit exceeded

JVM menghabiskan banyak masa melakukan GC (lebih daripada 98%), tetapi mengitar semula memori yang sangat sedikit (kurang daripada 2%), dan kesilapan ini dilemparkan secara automatik.

Sebab Biasa:

• Terdapat sejumlah besar objek "perlahan kematian" di timbunan, dengan GC yang kerap tetapi hasil yang lemah.
• Daripada memori atau kebocoran memori membawa kepada ruang kosong yang ketat.

Kaedah Penyelesaian Masalah:

• Dayakan Pembalakan GC:

   -XLOG: GC*, GC HEAP = DEBUG: FILE = GC.LOG: Masa

• Menganalisis kekerapan GC dan jumlah pemulihan dalam log.
• Digabungkan dengan Dump Heap untuk melihat pengedaran objek.

Penyelesaian:

• Meningkatkan memori timbunan.
• Mengoptimumkan kitaran hayat objek dan elakkan memegang objek yang tidak berguna untuk masa yang lama.
• Gunakan pengumpul sampah yang lebih cekap seperti G1GC atau ZGC sebaliknya:

   -Xx: useg1gc

• Semak sama ada objek besar sering dibuat (seperti rentetan besar, tatasusunan besar).

5. java.lang.OutOfMemoryError: Requested array size exceeds VM limit

Cuba buat array yang melebihi had JVM (seperti new int[Integer.MAX_VALUE] ).

Sebab Biasa:

• Integer melimpah apabila mengira saiz array, menghasilkan nombor negatif atau nilai maksimum yang diminta.
• Logik pemprosesan data adalah salah, tersilap merawat saiz fail sebagai panjang array.

Contoh:

 int size = (int) file.length (); // Apabila fail lebih besar daripada 2GB, ia akan dipaksa untuk data byte negatif [] byte baru [saiz]; // oom boleh dicetuskan

Penyelesaian:

• Gunakan long untuk menentukan saiz data dan hadkan peruntukan maksimum.
• Gunakan streaming fail besar untuk mengelakkan memuatkan sekaligus.
• Semak logik pengiraan panjang array untuk mengelakkan limpahan.

Ringkasan cadangan

Apabila menghadapi OutOfMemoryError , jangan hanya mengubah memori menjadi masalah. Langkah utama termasuk:

• ? Enable -XX: HeapDumpOnOutOfMemoryError
• ? Tambahkan log GC dan keupayaan membuang benang
• ? Gunakan alat analisis (MAT, VisualVM, JSTAT, JSTACK)
• ? Ulasan koleksi, cache, benang, logik pemprosesan IO dalam kod

Inti dari kebanyakan masalah OOM adalah reka bentuk kod yang tidak wajar atau pengurusan sumber, dan hanya konfigurasi yang munasabah dan penyiasatan yang teliti dapat diselesaikan.

Pada dasarnya semua itu, tidak rumit tetapi mudah untuk mengabaikan butiran.

Atas ialah kandungan terperinci Penyelesaian masalah senario Java `OutofMemoryError` biasa. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!