java.util.concurrent में अजीब कोड। लिंक्डब्लॉकिंग क्यूयू

Question

सब!

मैं LinkedBlockingQueue में अजीब कोड मिला:

private E dequeue() { 
     // assert takeLock.isHeldByCurrentThread(); 
     Node<E> h = head; 
     Node<E> first = h.next; 
     h.next = h; // help GC 
     head = first; 
     E x = first.item; 
     first.item = null; 
     return x; 
} 

कौन समझा सकता है इसलिए हम स्थानीय चर ज की जरूरत है? यह जीसी के लिए कैसे मदद कर सकता है?

Answer 1

बेहतर समझने के लिए कि क्या होता है देखते हैं कि कोड को निष्पादित करने के बाद सूची कैसी दिखती है।

1 -> 2 -> 3 

फिर h अंक head को

और firsth.next करने के लिए:: सबसे पहले एक प्रारंभिक सूची पर विचार

1 -> 2 -> 3 
| | 
h first 

फिर h को h.next अंक और first को head अंक:

1 -> 2 -> 3 
| /\ 
h head first 

अब, व्यावहारिक रूप से हम जानते हैं कि वें ere केवल पहले तत्व को इंगित करने वाला सक्रिय संदर्भ है, जो स्वयं (h.next = h) है, और हम यह भी जानते हैं कि जीसी उन वस्तुओं को एकत्र करता है जिनके पास कोई सक्रिय संदर्भ नहीं है, इसलिए जब विधि समाप्त होती है, तो सूची के पुराने (पुराने) सिर जीसी द्वारा सुरक्षित रूप से एकत्र किया जाना चाहिए क्योंकि h केवल विधि के दायरे में मौजूद है।

यह कहा है, यह बताया गया है, और मैं इस बात से सहमत है कि यहां तक ​​कि क्लासिक विपंक्ति विधि के साथ (यानी सिर्फ first बिंदु head.next को बनाने के लिए और head बिंदु first करने के लिए) वहाँ कोई और अधिक पुराने सिर की ओर इशारा संदर्भ हैं । हालांकि, इस परिदृश्य में, पुराना सिर स्मृति में लटक रहा है और अभी भी next क्षेत्र first की ओर इशारा करते हुए फ़ील्ड है, जबकि आपके द्वारा पोस्ट किए गए कोड में, केवल एक चीज शेष एक अलग वस्तु है जो स्वयं को इंगित करती है। यह तेजी से कार्य करने के लिए जीसी को ट्रिगर कर सकता है।

Answer 2

यहां एक कोड नमूना है जो प्रश्न को दर्शाता है: http://pastebin.com/zTsLpUpq। runWith() के बाद एक जीसी निष्पादित करना और दोनों संस्करणों के लिए एक ढेर डंप लेना कहता है कि केवल एक आइटम उदाहरण है।

Answer 3

शायद थोड़ा देर हो चुकी है, लेकिन वर्तमान स्पष्टीकरण मेरे लिए पूरी तरह असंतोषजनक है और मुझे लगता है कि मुझे एक और समझदार स्पष्टीकरण मिला है।

सभी जावा जीसी पहले रूट रूट से किसी तरह का ट्रेसिंग करता है। इसका मतलब है कि यदि पुराना सिर एकत्र किया जाता है तो हम next वैरिएबल को किसी भी तरह से नहीं पढ़ेंगे - ऐसा करने का कोई कारण नहीं है। इसलिए IF अगले पुनरावृत्ति में सिर एकत्र किया जाता है इससे कोई फर्क नहीं पड़ता।

उपर्युक्त वाक्य में आईएफ यहां महत्वपूर्ण हिस्सा है। कुछ अलग के बगल में सेटिंग के बीच का अंतर सिर एकत्र करने के लिए कोई फर्क नहीं पड़ता है, लेकिन अन्य वस्तुओं के लिए एक अंतर बना सकता है।

चलो एक साधारण पीढ़ी जीसी मानते हैं: यदि सिर युवा सेट में है, तो इसे अगले जीसी में किसी भी तरह से एकत्र किया जाएगा। लेकिन अगर यह पुराने सेट में है तो यह केवल तभी एकत्र किया जाएगा जब हम एक पूर्ण जीसी करते हैं जो शायद ही कभी होता है।

तो क्या होता है यदि सिर पुराने सेट में है और हम एक युवा जीसी करते हैं?इस मामले में जेवीएम मानता है कि पुराने ढेर में हर वस्तु अभी भी जिंदा है और युवा जीसी के लिए रूट सेट में पुराने से युवा वस्तुओं से प्रत्येक संदर्भ जोड़ती है। और यही वही है जो असाइनमेंट से बचाता है: पुरानी ढेर में लिखना आमतौर पर एक लिखने की बाधा या कुछ के साथ संरक्षित होता है ताकि JVM ऐसे असाइनमेंट को पकड़ सके और उन्हें सही तरीके से संभाल सके - हमारे मामले में यह ऑब्जेक्ट next रूट सेट से इंगित करता है जिसके परिणाम हैं।

लघु उदाहरण:

मान लें हम 1 (old) -> 2 (young) -> 3 (xx) है। अगर हम अपनी सूची से अब 1 और 2 हटा देते हैं, तो हम उम्मीद कर सकते हैं कि दोनों तत्व अगले जीसी द्वारा एकत्र किए जाएंगे। लेकिन अगर केवल एक युवा जीसी होता है और हमने पुराने में next पॉइंटर को नहीं हटाया है, तो तत्व 1 और 2 एकत्र नहीं किए जाएंगे। इसके विपरीत हम 1 में सूचक को हटा दिया है, तो, 2 जवान जीसी द्वारा एकत्र की जाएगी ..

Answer 4

आप jsr166 src को देखो तो आप हमलावर प्रतिबद्ध

http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/LinkedBlockingQueue.java?view=log (v 1.51 देख पाएंगे)

इससे पता चलता है इस सवाल का जवाब इस बग रिपोर्ट

http://bugs.sun.com/view_bug.do?bug_id=6805775

पूरी चर्चा इस सूत्र में है

http://thread.gmane.org/gmane.comp.java.jsr.166-concurrency/5758

"सहायता जीसी" बिट कार्यकाल में खून बहने से बचने के बारे में है।

चीयर्स

मैट