Dalam artikel ini, saya akan mengajari Anda cara menganalisis tumpukan utas JVM dan bagaimana menemukan akar penyebab masalah dari informasi tumpukan. Menurut pendapat saya, Teknologi Analisis Stack Thread adalah teknologi yang harus dikuasai oleh insinyur pendukung produk Java EE. Informasi yang disimpan dalam tumpukan utas biasanya jauh di luar imajinasi Anda.
Tujuan saya adalah berbagi pengetahuan dan pengalaman yang terakumulasi dalam analisis utas selama sepuluh tahun terakhir. Pengetahuan dan pengalaman ini diperoleh dalam analisis in -Depth dari berbagai versi JVM dan pemasok JVM dari berbagai produsen.
Jadi, apakah Anda siap, sekarang artikel ini ditambahkan ke bookmark. Apa yang Anda tunggu, silakan cepat dan bagikan rencana pelatihan analisis utas ini dengan kolega dan teman Anda.
Kedengarannya bagus.
Saran saya adalah mengikuti saya untuk menyelesaikan rencana pelatihan analisis utas ini. Berikut adalah konten pelatihan yang akan kami bahas. Pada saat yang sama, saya akan berbagi dengan Anda kasus -kasus aktual yang telah saya tangani agar semua orang belajar dan memahami dengan semua orang.
1) Tinjauan Tumpukan Utas dan Pengetahuan Dasar
2) Prinsip dan alat terkait tumpukan utas
3) Format tumpukan benang JVM yang berbeda (hotspot matahari, IBM JRE, oracal Jrockit)
4) Metode Pendahuluan dan Analisis Log Stack Thread
5) Analisis tumpukan utas dan teknologi terkait
6) Template masalah umum (threading, kunci mati, io memanggil kematian, sampah daur ulang/masalah outofmemoryError, siklus mati, dll.)
7) Misalnya analisis masalah tumpukan utas
Saya harap serangkaian pelatihan ini akan memberi Anda bantuan sejati, jadi silakan terus perhatikan pembaruan artikel mingguan.
Tetapi apa yang harus saya lakukan jika saya memiliki pertanyaan dalam proses studi atau saya tidak dapat memahami konten dalam artikel?
Jangan khawatir, perlakukan saja saya sebagai mentor Anda. Anda dapat berkonsultasi dengan saya dengan pertanyaan tentang tumpukan utas (asalkan masalahnya tidak bisa terlalu rendah). Pilih cara berikut untuk menghubungi saya:
1) Berkomentar langsung dalam artikel ini (jika Anda menyesal, Anda bisa anonim)
2) Kirim data tumpukan utas Anda ke Forum Analisis Penyebab Akar
3) Kirimi saya email, alamatnya adalah@[email protected]
Bisakah Anda membantu saya menganalisis masalah yang dihadapi pada produk kami?
Tentu saja, jika Anda bersedia, Anda dapat mengirimkan saya data langsung tumpukan melalui forum analisis Mail atau Forum Root Capes. Masalah yang sebenarnya adalah raja belajar untuk meningkatkan keterampilan.
Saya sangat berharap semua orang dapat menyukai pelatihan ini. Jadi saya akan melakukan yang terbaik untuk memberi Anda bahan berkualitas tinggi dan menjawab berbagai pertanyaan Anda.
Sebelum memperkenalkan Teknologi Analisis Stack Thread dan Model Masalah, Anda harus terlebih dahulu memberi tahu Anda konten dasarnya. Jadi dalam posting ini, saya akan membahas konten paling dasar, sehingga semua orang dapat lebih memahami interaksi antara JVM, middleware, dan wadah Java EE.
Ikhtisar Java VM
Java Virtual Machine adalah dasar dari platform Jave EE. Ini adalah tempat di mana middleware dan aplikasi digunakan dan berjalan.
JVM memberikan hal -hal berikut ke perangkat lunak middleware dan program Java/Java EE Anda:
(Formulir Biner) Program Java / Java EE Menjalankan lingkungan Beberapa karakteristik dan alat fungsional program (infrastruktur IO, struktur data, manajemen utas, keamanan, pemantauan, dll.).).
Alokasi dan manajemen memori dinamis dengan bantuan pemulihan sampah
JVM Anda dapat tetap pada banyak sistem operasi (Solaris, AIX, Windows, dll.), Dan dapat dikonfigurasi sesuai dengan server fisik Anda.
Interaksi antara JVM dan middleware
Diagram berikut ini menunjukkan model interaktif rise tinggi antara JVM, middleware dan aplikasi.
Beberapa interaksi sederhana dan khas antara JVM, middleware dan aplikasi yang ditampilkan pada gambar. Seperti yang Anda lihat, alokasi utas aplikasi Java EE standar selesai antara inti bagian tengah dan JVM. (Tentu saja, ada pengecualian. Aplikasi dapat secara langsung memanggil API untuk membuat utas. Pendekatan ini tidak umum, dan perlu untuk berhati -hati selama penggunaan)
Pada saat yang sama, harap dicatat bahwa beberapa utas dikelola oleh JVM.
Karena sebagian besar distribusi utas dilakukan oleh wadah Java EE, penting untuk memahami dan memahami pelacakan tumpukan utas, dan dapat mengidentifikasinya dari data tumpukan utas, yang penting bagi Anda. Permintaan akan mengeksekusi wadah Java EE.
Dari perspektif analisis tumpukan penyimpanan utas, Anda akan dapat memahami perbedaan antara kumpulan utas yang ditemukan dari JVM dan mengidentifikasi jenis permintaan.
Bagian terakhir akan memberi Anda ikhtisar tumpukan utas JVM untuk Hotsop V kepada Anda.
Harap dicatat bahwa Anda dapat memperoleh contoh tumpukan utas untuk artikel ini dari alasan mendasar.
JVM Thread Stack -Apa?
Tumpukan utas JVM adalah snapshot waktu tertentu yang dapat memberi Anda daftar lengkap semua utas Java yang dibuat.
Setiap utas Java yang ditemukan akan memberi Anda informasi berikut:
Nama utas;
Jenis & prioritas utas, misalnya: Daemon Prio = 3 ** Program middlewar umumnya membuat utas mereka dalam bentuk perwalian latar belakang, yang berarti bahwa utas ini berjalan di latar belakang; Ke aplikasi Java EE Anda **
ID utas java, seperti: tid = 0x000000011e52a800 ** Ini adalah ID utas java yang diperoleh melalui java.lang.thread.getId ().
Native Thread ID, seperti: NID = 0x251c **, kuncinya adalah karena ID utas asli memungkinkan Anda untuk mendapatkan Anda dari perspektif sistem operasi.
Status Thread Java dan informasi terperinci, seperti: Menunggu entri monitor [0xFFFFFFFFEA5AFB000] java.lang.thread.state: blok (pada monitor objek)
** Anda dapat dengan cepat memahami alasan yang mungkin mengapa status utas sangat diblokir **
Java Thread Stack Tracing; Penyebab banyak jenis masalah, 90%dari informasi yang diperlukan.
Java Stack Decomposition memori; Informasi ini sangat berguna ketika menganalisis masalah yang disebabkan oleh sering GC. Anda dapat menggunakan data atau mode utas yang diketahui untuk membuat posisi cepat.
Heappsynggen Total 466944K, Digunakan 178734K [0xFFFFFFFFFFFF45C00000, 0XFFFFFFFFF70800000, 0XFFFFFFFFFFFFFF70800000) EDEN 233472K, 76% Digunakan F45C00000, 0XFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFFF62400000, 0XFFFFFFF62400000,0XFFFFFFFFF70800000) E 233472K, 0% userd [0xffffffffff54000000, 0xFFFFFFFFFF54000000 , 0xFFFFFFFF62400000) PSOLDGEN Total 1400832k, digunakan 1400831k [0xFFFFFFFFF0400000, 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 00000) PSPERMGEN Total 262144K, Digunakan 248475K, 0xFFFFFFEE0400000, 0XFFFFFFFFFFFF0400000) Ruang objek 262144K, 94 % Digunakan [0xFFFFFFFED0400000 , 0xffffFFedF6F08.0XFFFFFFFFFFEE0400000)
Pembongkaran besar informasi tumpukan utas
Untuk memungkinkan semua orang untuk lebih memahami, gambar berikut disediakan untuk semua orang.
Pada gambar di atas, dapat dilihat bahwa tumpukan utas terdiri dari beberapa bagian yang berbeda. Informasi ini penting untuk analisis masalah, tetapi analisis mode masalah yang berbeda akan menggunakan bagian yang berbeda (mode masalah akan mensimulasikan dan menunjukkan dalam artikel selanjutnya.)
Sekarang melalui contoh analisis ini, saya akan menjelaskan secara rinci komponen -komponen hotespot pada informasi tumpukan yang beracun:
# Dump utas penuh
"Full Thread Dump" adalah kata kunci hanya global. Ini adalah awal dari snapshot tumpukan utas.
DUMP BASA PENUH DUMP JAVA HOTSPOT (TM) 64-Bit Server VM (Mode Campuran 20.0-B11):
# Java EE Middleware, pihak ketiga, dan utas dalam perangkat lunak aplikasi khusus
Bagian ini adalah bagian inti dari seluruh tumpukan utas, dan juga merupakan bagian yang biasanya perlu menganalisis waktu. Jumlah midline stack tergantung pada middleware yang Anda gunakan, perpustakaan -bagian ketiga (mungkin memiliki utas independen) dan aplikasi Anda (jika Anda membuat utas khusus, ini biasanya bukan praktik yang baik).
Dalam contoh tumpukan utas kami, WebLogic adalah middleware yang kami gunakan. Mulai dari WebLogic 9.2, Anda akan menggunakan kumpulan utas unik yang dapat dikelola oleh "
"[Siaga] ExecuteThread: '414' untuk antrian: 'WebLogic.Kernel.default (self-tuning)'" Daemon prio = 3 tid = 0x000000010916a800 nid = 0x2613 di objek .Wait () [0xFFFFFFFFFFFFOR000] Negara: Menunggu (pada monitor objek) di java.lang.object.wait (metode asli) -Waiting di <0xfffffff27d44de0> (a WebLogic.Work.executetethread). Work.work.cutethread.waitforRequest (executethread.java:160) -locked <0xffffffFff27d4de0> (a WebLogic.Work.Executetethread) c.work.executethread.run (executethread.java:181)
# Utas VM Hotspot
Ini adalah utas internal yang dikelola oleh Hotspot VM untuk operasi asli operasi internal. Secara umum, Anda tidak perlu melakukan terlalu banyak tentang ini, kecuali jika Anda menemukan tingkat pekerjaan CPU yang tinggi kecuali Anda (melalui tumpukan utas terkait dan prstat atau ID utas asli).
"Utas tugas periodik VM" prio = 3 tid = 0x0000000101238800 nid = 0x19 menunggu kondisi
# Utas hotspot gc
Saat menggunakan hotspot untuk GC paralel (sekarang adalah umum di lingkungan beberapa inti fisik), ketika hotspot VM yang dibuat secara default, atau setiap JVM mengelola utas GC dengan logo tertentu. Pembersihan GC berkala akan menyebabkan pengurangan keseluruhan waktu GC;
"Utas tugas GC#0 (paralelgc)" prio = 3 tid = 0x0000000100120000 nid = 0x3 runnable "GC Task Thread#1 (paralelgc)" prio = 3 tid = 0x0000131000 nid = 0x444 runnable ………………………………………………………………………………………………………………………………………………………………………………………………………………………………… ……………………………………… …………………………………………………………………………………………… …………………………………………………………
Ini adalah data penting, karena ketika Anda mengalami masalah yang terkait dengan GC, seperti GC yang berlebihan dan kebocoran memori, Anda akan dapat menggunakan sistem operasi atau utas Java yang terkait dengan nilai ID asli dari utas ini, dan kemudian menemukan hak apa pun benar.
# JNI Global Reference Count
Referensi Global JNI (Java Local Interface) adalah dari kode lokal ke objek dasar objek Java yang dikelola oleh Java Garbage Collector. koleksi sampah.
Pada saat yang sama, penting juga untuk memperhatikan referensi JNI untuk mendeteksi kebocoran terkait JNI.
JNI Referensi Global: 1925
# Java stack menggunakan tampilan
Data ini telah ditambahkan kembali ke JDK 1.6, memberikan Anda tampilan hotspot yang singkat dan cepat. Dan tumpukan java dalam snapshot terpisah, sehingga Anda dapat menganalisis (atau mengecualikan) dalam ruang memori java spesifik pada waktu itu.
HEAP PSYOUNGGEN Total 466944K, digunakan 178734K [0xFFFFFFFFFF45C00000, 0XFFFFFFFFFF70800000, 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFFFFFF62400000, 0xFFFFFFF62400000,0XFFFFFFFFF70800000) E 233472K, 0% Digunakan [0xffffffFFFF54000000, 0xFFFFFFFFF540000, 0XFFFFFFFFFF62400000) PSOLDGEN TOTAL 1400832K, Digunakan 1400831K [0xFFFFFFFFFF0400000, 0XFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF yang ” FFFFFFFF45BFFFFB8.0XFFFFFFFFF45C00000) PSPERMGEN TOTAL 262144K, Digunakan 248475K [0 XFFFFFFFFFFED0400000, 0xFFFFFFFFEE0400000, 0XFFFFFFFFF0400000) Ruang objek 262144k, 94% Digunakan [0xFFFFFFFFFFFED0400000,0XFFFFFFFFFFFFFF6A6F08,0XFFFFFFFFFEE040000