"मिला 1 गतिरोध" लेकिन निशान से पता चलता है कि किसी भी धागा

Question

JVM मुझसे कहता है कि एक गतिरोध उत्पन्न हो गई है द्वारा बंद नहीं:

Found one Java-level deadlock: 
============================= 
"TP-Processor107": 
    waiting for ownable synchronizer 0x00002aaaf58e70f0, (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync), 
    which is held by "indexTrackerThread3" 
"indexTrackerThread3": 
    waiting for ownable synchronizer 0x00002aaaf4394580, (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync), 
    which is held by "TP-Processor16" 
"TP-Processor16": 
    waiting for ownable synchronizer 0x00002aaaf58e70f0, (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync), 
    which is held by "indexTrackerThread3" 

हम देख सकते हैं कि indexTrackerThread3 एक संसाधन TP-Processor16 द्वारा आयोजित के लिए इंतज़ार कर रहा है, और इसके -versa। यह वास्तव में एक डेडलॉक है।

हम देख सकते हैं कि indexTrackerThread30x00002aaaf4394580 के लिए इंतज़ार कर रहा है:

"indexTrackerThread3": 
    - parking to wait for <0x00002aaaf4394580> 

मेरा प्रश्न:

the threads dump में, क्यों वहाँ कोई लाइन - locked <0x00002aaaf4394580> है?

ऐसा लगता है कि 0x00002aaaf58e70f0 वास्तव में किसी भी थ्रेड द्वारा लॉक नहीं है। क्या लॉक हो सकता है?

सभी डेडलॉक दस्तावेज में मैंने पढ़ा है (example), प्रत्येक अलग - parking to wait for <0x123> लाइन के लिए, हमेशा एक - locked <0x123> लाइन होती है। तो मैं एक जेवीएम बग पर संदेह करना शुरू कर देता हूं। क्या मैं कुछ गलत समझ रहा हूँ?

नोट: पेस्टबिन से जोड़ने के लिए खेद है, लेकिन सवाल पूर्ण डंप के बिना उत्तरदायी नहीं है। संक्षिप्तता के लिए, मैंने "लाइन" में मौजूद सभी पंक्तियों को हटा दिया, उनमें कोई ताला जानकारी शामिल नहीं है।

Answer 1

java.util.concurrent पैकेज एक बाह्य, मूल पार्किंग तंत्र (साथ ही अन्य मूल तंत्र, जैसे कि परमाणु तुलना-और-स्वैप) का उपयोग करता है। आप देख सकते हैं कि मैं here के बारे में क्या बात कर रहा हूं।

आमतौर पर थ्रेड डंप में होने वाले पैटर्न को क्लासिक जावा idiom synchronized(lock) { lock.wait(); } से उत्पन्न होता है।

Answer 2

मार्को टॉपोलनिक का जवाब सही है।

आपकी समस्या के समाधान के लिए, JProfiler आपको java.util.concurrent पैकेज से ताले शामिल करने वाली स्थितियों को लॉक करने के लिए थ्रेड और मॉनीटर का एक पूरा ग्राफ दिखाएगा।

अस्वीकरण: मेरी कंपनी को विकसित करता है JProfiler

Answer 3

अलग बातें जावा सूत्र, पर नज़र रखता है गतिरोध कर सकते हैं, सिंक्रनाइज़ कीवर्ड उर्फ, बस एक बात कर रहे हैं।

A lock can be a built-in object monitor, an ownable synchronizer, or the Condition object associated with synchronizers.

आप अधिक जानकारी के लिए ThreadMXBean.findDeadlockedThreads और ThreadMXBean.findMonitorDeadlockedThreads की परिभाषा में खुदाई कर सकते हैं।

जहां तक ​​मेरा संबंध है, यह मॉनीटर लॉकिंग और जावा 5 लॉकिंग है।

थ्रेड डंप में, waiting to lock <0x123> और locked <0x123> संयोजन केवल मॉनिटर लॉकिंग के लिए है। जावा 5 लॉकिंग के साथ आपको केवल पहला भाग मिलता है। कुछ parking to wait for <0x456> की तरह कुछ। फिर आप थ्रेड डंप में कुछ 0x456 खोजते हैं, लेकिन यह कहीं भी नहीं मिला है। यह भ्रामक है।

Answer 4

इस तरह के डेडलॉक के लिए थ्रेड डंप विश्लेषण की जटिलता मुख्य रूप से java.util.concurrent पैकेज के उपयोग के कारण है। यह जावा ऑब्जेक्ट्स को सिंक्रनाइज़ करने के क्लासिक और घुसपैठ तरीके से दूर जाने के लिए बनाया गया था। यह पैकेज बहुत उपयोगी है जब उदाहरण के लिए आप समवर्ती रीड ऑपरेशंस को अनुमति देते हुए WRITE ऑपरेशंस को एक थ्रेड मॉडल पर प्रतिबंधित करना चाहते हैं। यह दृष्टिकोण प्रदर्शन ट्यूनिंग परिप्रेक्ष्य से बहुत अच्छा है, साइड इफेक्ट समेकन समस्याओं से निपटने के दौरान थ्रेड डंप विश्लेषण प्रक्रिया की जटिलता का एक बढ़ता स्तर है।

मेरा सुझाव है कि आप निम्न आलेख की भी समीक्षा करें। यह hidden Java deadlock परिदृश्यों जैसी समस्याओं का वर्णन करता है जहां JVM भी डेडलॉक का पता लगाने में सक्षम नहीं होगा (रीड लॉक के कारण जिन्हें आमतौर पर स्वामित्व की धारणा के लिए डिज़ाइन नहीं किया गया है)। नमूना जावा प्रोग्राम एक उदाहरण के रूप में प्रदान किया जाता है।

Answer 5

स्टैक ट्रेस दिखाता है कि 0x00002aaaf4394580 किसी भी धागे से लॉक नहीं है। यह Java bug #6822370 के कारण हो सकता है। इस अवलोकन में voted answer को बंद करना चाहिए।