Bagaimana mesin maya Java melaksanakan kebuntuan

Setakat ini, saya rasa alat yang paling berkesan untuk menganalisis masalah kod Java ialah java thread dump Sebabnya ialah:

1.

2. Dalam kebanyakan kes, ia boleh digunakan dalam persekitaran pengeluaran.

3. Berbanding dengan alat yang disediakan oleh sistem pengendalian, maklumat yang diberikan oleh java thread dump adalah mudah dan sepadan secara langsung dengan kod aplikasi.

4. Ia mempunyai sedikit gangguan terhadap sistem yang dianalisis, jadi ia boleh mencerminkan masalah sebenar. Banyak alat pemprofilan atau instrumen lain sendiri mempunyai gangguan besar terhadap operasi JVM dan sering gagal mendedahkan masalah sebenar Selain itu, alat tersebut tidak boleh digunakan dalam sistem pengeluaran.

Saya rasa lebih mudah untuk menganalisis kebuntuan mesin maya Java daripada kebocoran memori dalam keadaan biasa. Kerana apabila kebuntuan berlaku, JVM biasanya dalam keadaan digantung (hang), dan pembuangan benang boleh memberikan maklumat statik dan stabil Untuk mencari jalan buntu, anda hanya perlu mencari benang yang dipersoalkan. Masalah kebocoran memori adalah sukar untuk ditakrifkan. Terdapat banyak objek dalam JVM yang sedang berjalan Hanya mereka yang menulis program tahu objek mana yang sampah dan yang tidak, hubungan rujukan objek sangat rumit, menjadikannya sukar untuk diperoleh graf rujukan objek yang jelas.

Apabila kebuntuan mesin maya Java berlaku, perhatikan dari sistem pengendalian bahawa penggunaan CPU mesin maya adalah sifar dan tidak lama lagi akan hilang daripada output atas atau prstat. Pada masa ini, anda boleh mengumpul pembuangan benang Di bawah Unix/Linux, matikan -3 Di bawah Windows, anda boleh menekan Ctrl-Break pada tetingkap konsol JVM. Bergantung pada tetapan, pembuangan benang akan dikeluarkan ke konsol semasa atau log pelayan aplikasi.

Selepas mendapat java thread dump, apa yang anda perlu lakukan ialah mencari thread "menunggu kemasukan monitor". hanya terdapat satu utas untuk kunci objek), ini menunjukkan bahawa kebuntuan mungkin berlaku. Sebagai contoh:

"service-j2ee" prio=5 tid=0x024f1c28 nid=0x125 waiting for monitor entry  [62a3e000..62a3f690]  [27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at  com.sun.enterprise.resource.IASNonSharedResourcePool.internalGetResource(IASNonS  haredResourcePool.java:625)  [27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: - waiting to  lock <0x965d8110> (a com.sun.enterprise.resource.IASNonSharedResourcePool)  [27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at  com.sun.enterprise.resource.IASNonSharedResourcePool.getResource(IASNonSharedRes  ourcePool.java:520)  ................

Untuk menentukan masalah, selalunya perlu mengumpul semula pembuangan benang selepas dua minit Jika output yang diperolehi adalah sama, masih terdapat sejumlah besar benang menunggu untuk mengunci alamat yang sama, maka Ia mesti buntu.

Cara mencari benang yang sedang memegang kunci adalah kunci untuk menyelesaikan masalah. Kaedahnya ialah mencari tempat pembuangan benang, cari "terkunci <0x965d8110>", dan cari benang yang memegang kunci.

[27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: "Thread-20" daemon prio=5 tid=0x01394f18 nid=0x109 runnable [6716f000..6716fc28]  [27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at  java.net.SocketInputStream.socketRead0(Native Method)  [27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at  java.net.SocketInputStream.read(SocketInputStream.java:129)  [27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at oracle.net.ns.Packet.receive(Unknown  Source)  [27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at  oracle.net.ns.DataPacket.receive(Unknown Source)  [27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at  oracle.net.ns.NetInputStream.getNextPacket(Unknown Source)  [27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at  oracle.net.ns.NetInputStream.read(Unknown Source)  [27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at  oracle.net.ns.NetInputStream.read(Unknown Source)  [27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at  oracle.net.ns.NetInputStream.read(Unknown Source)  [27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at  oracle.jdbc.ttc7.MAREngine.unmarshalUB1(MAREngine.java:929)  [27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at  oracle.jdbc.ttc7.MAREngine.unmarshalSB1(MAREngine.java:893)  [27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at  oracle.jdbc.ttc7.Ocommoncall.receive(Ocommoncall.java:106)  [27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at  oracle.jdbc.ttc7.TTC7Protocol.logoff(TTC7Protocol.java:396)  [27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: - locked <0x954f47a0> (a  oracle.jdbc.ttc7.TTC7Protocol)  [27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at  oracle.jdbc.driver.OracleConnection.close(OracleConnection.java:1518)  [27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: - locked <0x954f4520> (a  oracle.jdbc.driver.OracleConnection)  [27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at  com.sun.enterprise.resource.JdbcUrlAllocator.destroyResource(JdbcUrlAllocator.java:122)  [27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at  com.sun.enterprise.resource.IASNonSharedResourcePool.destroyResource(IASNonSharedResourcePool.java:8 72)  [27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at  com.sun.enterprise.resource.IASNonSharedResourcePool.resizePool(IASNonSharedResourcePool.java:1086)  [27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: - locked <0x965d8110> (a  com.sun.enterprise.resource.IASNonSharedResourcePool)  [27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at  com.sun.enterprise.resource.IASNonSharedResourcePool$Resizer.run(IASNonSharedResourcePool.java:1178)  [27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at  java.util.TimerThread.mainLoop(Timer.java:432)  [27/Jun/2006:10:03:08] WARNING (26140): CORE3283: stderr: at  java.util.TimerThread.run(Timer.java:382)

Dalam contoh ini, benang yang memegang kunci sedang menunggu Oracle untuk mengembalikan hasil, tetapi ia tidak pernah menunggu respons, jadi kebuntuan berlaku.

Jika benang yang memegang kunci masih menunggu untuk mengunci objek lain, maka ikuti kaedah di atas sehingga anda menemui punca kebuntuan.

Selain itu, benang sedemikian sering dilihat dalam pembuangan benang Ia adalah benang yang menunggu keadaan dan secara aktif melepaskan kunci.
Contohnya:

"Thread-1" daemon prio=5 tid=0x014e97a8 nid=0x80 in Object.wait() [68c6f000..68c6fc28]  at java.lang.Object.wait(Native Method)  - waiting on <0x95b07178> (a java.util.LinkedList)  at com.iplanet.ias.util.collection.BlockingQueue.remove(BlockingQueue.java:258)  - locked <0x95b07178> (a java.util.LinkedList)  at com.iplanet.ias.util.threadpool.FastThreadPool$ThreadPoolThread.run(FastThreadPool.java:241)  at java.lang.Thread.run(Thread.java:534)

Kadang-kadang perlu menganalisis jenis benang ini, terutamanya syarat untuk menunggu benang.

Sebenarnya, pelupusan benang Java bukan sahaja digunakan untuk menganalisis gelagat pelik lain apabila menjalankan aplikasi Java boleh dianalisis dengan pembuangan benang.

***, dalam Java SE 5, alat jstack ditambah, dan pembuangan benang juga boleh diperolehi. Dalam Java SE 6, anda juga boleh mencari kebuntuan dengan mudah yang melibatkan pemantau objek dan java.util.concurrent.locks melalui alat grafik jconsole.

Atas ialah kandungan terperinci Bagaimana mesin maya Java melaksanakan kebuntuan. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!