Pertama, jelaskan jenis masalah, dan kemudian selesaikannya dengan cara yang disasarkan: 1. Tentukan sama ada ruang tumpukan Java, metaspace, penciptaan benang gagal atau overhead GC terlalu tinggi berdasarkan maklumat ralat; 2. Dayakan log GC dan gunakan alat untuk menganalisis trend memori; 3. Menjana fail pembuangan timbunan apabila ralat berlaku, dan gunakan alat seperti tikar gerhana untuk mencari sumber kebocoran memori; 4. Gunakan JSTAT, JMAP, JCONSOLE dan alat lain untuk memantau memori dan status GC semasa runtime; 5. Laraskan saiz timbunan mengikut punca akar, tetapkan had atas metaspace, kebocoran memori pembaikan (seperti koleksi statik yang tidak dibersihkan, sumber tidak ditutup), dan gunakan kolam benang untuk mengawal jumlah benang; 6. Langkah -langkah pencegahan termasuk menggunakan cache yang dibatasi, melakukan analisis memori dalam ujian prestasi, memantau memori dan tingkah laku GC dalam persekitaran pengeluaran dan menetapkan penggera; Akhirnya, menyelesaikan masalah OutofMemoryError melalui proses lengkap log, pembuangan tumpukan, analisis, pembaikan dan pemantauan berterusan.

Berjalan ke java.lang.OutOfMemoryError adalah pengalaman biasa tetapi mengecewakan dalam pembangunan Java. Ia tidak selalu bermakna anda keluar dari ingatan fizikal -biasanya menunjuk kepada kesilapan, kod penting, atau kebocoran memori. Mari kita pecahkan cara mendiagnosis dan memperbaikinya dengan berkesan.

Memahami jenis outofMemoryError

Tidak semua contoh OutOfMemoryError adalah sama. Mesej ralat biasanya memberi petunjuk mengenai masalahnya:

• Java heap space
  Ini adalah yang paling biasa. Ini bermakna timbunan tidak mempunyai ruang yang cukup untuk memperuntukkan objek baru. Boleh disebabkan oleh terlalu banyak data, pengurusan memori yang lemah, atau kebocoran memori.

  

• Metaspace
  Berlaku apabila JVM kehabisan ruang untuk memuat kelas baru. Biasa dalam aplikasi yang menjana atau memuatkan banyak kelas secara dinamik (contohnya, refleksi, penjanaan kod, mikroservis dengan kerangka berat).

• Unable to create new native thread
  Bukan masalah timbunan -ini bermakna OS tidak dapat membuat lebih banyak benang. Selalunya disebabkan oleh had peringkat OS atau kebocoran benang.

  

• GC Overhead limit exceeded
  Pemungut sampah terus berjalan tetapi menuntut semula hampir tiada ingatan. Tanda tekanan ingatan yang teruk dan mungkin kebocoran memori.

Mendiagnosis punca akar

Sebelum melompat ke penyelesaian, sahkan apa yang sebenarnya berlaku.

1. Membolehkan dan menganalisis log GC

Hidupkan pembalakan koleksi sampah untuk melihat trend memori:

 -Xx: printgc -xx: printgcdetails -xx: printgcdatestamps -xloggc: gc.log

Cari:

• GCS yang kerap
• Penggunaan timbunan mendaki dari masa ke masa
• Pemulihan Memori Rendah Selepas GC

Alat seperti gcviewer atau gceasy.io dapat membantu memvisualisasikan log.

2. Tangkap pembuangan tumpukan

Apabila ralat berlaku, tangkap pembuangan timbunan untuk menganalisis pengekalan objek:

 -Xx: HeapdumponoutofMemoryError -xx: HeapDumpPath =/Path/To/Dumps

Kemudian buka fail .hprof dalam alat seperti:

• Mat Eclipse (Penganalisis Memori)
• Visualvm
• Yourkit

Cari:

• Pokok dominator menunjukkan penahan objek besar
• Koleksi (contohnya, HashMap , ArrayList ) memegang data yang tidak dijangka
• Cache tanpa had saiz
• Pendengar atau panggilan balik tidak dibatalkan berdaftar

3. Gunakan alat runtime

Semak penggunaan memori dalam masa nyata:

• jstat -gc <pid> -Menunjukkan GC dan Penggunaan Heap
• jmap -histo <pid> -Tunjukkan histogram objek langsung
• jconsole atau jvisualvm - Alat GUI untuk Pemantauan

Memperbaiki sebab -sebab yang sama

? Meningkatkan saiz timbunan (apabila sesuai)

Jika aplikasi anda umumnya memerlukan lebih banyak memori, laraskan -Xmx :

 java -xms512m -xmx2g myapp

Tetapi jangan hanya membuang ingatan pada masalah -kebocoran topeng ini.

? Tune Metaspace

Untuk kesilapan Metaspace :

 -Xx: MaxMeTaspacesize = 512m

Juga pertimbangkan untuk mengurangkan penggunaan pemuatan kelas dinamik (contohnya, penggunaan cglib, refleksi, atau enjin skrip yang berlebihan).

? Betulkan kebocoran memori

Sumber Biasa:

• Koleksi statik yang tumbuh selama -lamanya
• Sumber yang tidak tertutup (sungai, sambungan)
• Pendengar tidak dikeluarkan dari bas acara
• Pembolehubah ThreadLocal dalam benang lama (misalnya, di kolam benang)

Contoh:

 peta statik peribadi <string, object> cache = hashmap baru <> ();
// Ini tumbuh selama -lamanya - Gunakan kelembutan yang lemah atau cache yang dibatasi seperti kafein

Ganti dengan:

 Cache <string, object> cache = kafeine.newBuilder ()
    .MaximumSize (1000)
    .build ();

? Hadkan penciptaan benang

Untuk kesilapan benang asli:

• Mengurangkan pemijahan benang yang tidak perlu
• Gunakan kolam renang thread ( ExecutorService )
• Semak Had OS ( ulimit -u di Linux)
• Tetapkan -Xss untuk mengurangkan saiz timbunan per -thread jika selamat

? Mengoptimumkan penciptaan objek

Elakkan membuat objek jangka pendek dalam gelung yang ketat. Gunakan pengumpulan objek atau pembina apabila sesuai.

Petua Pencegahan

• Gunakan koleksi ingatan yang selamat (contohnya, cache dibatasi)
• Penggunaan memori profil semasa ujian beban
• Memantau penggunaan timbunan dalam pengeluaran
• Tetapkan makluman pada trend memori
• Tinjauan Log GC secara kerap

Memperbaiki OutOfMemoryError bukan sekadar meningkatkan ingatan -ini tentang memahami bagaimana aplikasi anda menggunakannya. Dengan alat yang betul dan pendekatan teknikal, anda boleh menentukan kebocoran, konfigurasi tune, dan membina lebih banyak aplikasi Java yang berdaya tahan.

Pada asasnya: log, membuang, menganalisis, memperbaiki, dan memantau.

Atas ialah kandungan terperinci Mendiagnosis dan menetapkan Java OutofMemoryError. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!