जावा समवर्ती मानचित्र: Difference between revisions

From Vigyanwiki
mNo edit summary
Line 39: Line 39:
=== संशोधन काउंटर ===
=== संशोधन काउंटर ===


समवर्ती संशोधन समस्या के साथ मदद करने के लिए, गैर-समवर्ती आलेखन कार्यान्वयन और अन्य संग्रह आंतरिक संशोधन काउंटरों का उपयोग करते हैं, जिन्हें परिवर्तनों को देखने के लिए पढ़ने से पहले और बाद में परामर्श किया जाता है: लेखक संशोधन काउंटरों को बढ़ाते हैं। java.util.ConcurrentModificationException का उपयोग करके,इस तंत्र द्वारा एक समवर्ती संशोधन का पता लगाया जाना चाहिए, लेकिन यह सभी स्तिथियों में होने का आश्वासन नहीं है और इस पर भरोसा नहीं किया जाना चाहिए। काउंटर रखरखाव भी एक प्रदर्शन क्षीण होना है। प्रदर्शन कारणों से, काउंटर अस्थिर नहीं हैं, इसलिए यह आश्वासन नहीं है कि उनमें परिवर्तन सूत्रण के बीच प्रचारित किए जाएंगे।
समवर्ती संशोधन समस्या के साथ मदद करने के लिए, गैर-समवर्ती आलेखन कार्यान्वयन और अन्य संग्रह आंतरिक संशोधन काउंटरों का उपयोग करते हैं, जिन्हें परिवर्तनों को देखने के लिए पढ़ने से पहले और बाद में परामर्श किया जाता है। लेखक संशोधन काउंटरों का विस्तार करते हैं। java.util.ConcurrentModificationException का उपयोग करके,इस प्रणाली द्वारा एक समवर्ती संशोधन का पता लगाया जाना चाहिए, लेकिन यह सभी स्तिथियों में होने का आश्वासन नहीं है और इस पर भरोसा नहीं किया जाना चाहिए। काउंटर का रखरखाव भी प्रदर्शन क्षीण करता है। प्रदर्शन कारणों से, काउंटर परिवर्तनशील नहीं हैं, इसलिए यह आश्वासन नहीं है कि उनमें परिवर्तन सूत्रण के बीच प्रचारित किए जाएंगे।


=== कलेक्शनंस.सिंक्रोनीजेडमैप() ===
=== कलेक्शनंस.सिंक्रोनीजेडमैप() ===


समवर्ती संशोधन समस्या का एक समाधान संग्रह में कारख़ाने द्वारा प्रदान किए गए एक विशेष अवरोधक वर्ग का उपयोग करता है: <code>public static <K,V> Map<K,V> synchronizedMap(Map<K,V> m)</code> जो उपस्थित गैर-सूत्रण-सुरक्षित आलेखन को आंतरिक म्यूटेक्स पर समकालीन करने वाले तरीकों से लपेटता है। अन्य प्रकार के संग्रहों के लिए भी अवरोधक हैं। यह एक आंशिक समाधान है, क्योंकि यह अभी भी संभव है कि अंतर्निहित आलेखन को सूत्रण द्वारा अनजाने में एक्सेस किया जा सकता है जो अलिखित संदर्भों को रखता है या प्राप्त करता है। साथ ही, सभी संग्रह {{Javadoc:SE|package=java.lang|java/lang|Iterable}}लागू करते हैं लेकिन समकालीन-अवरोधक आलेखन और अन्य अवरोधक संग्रहण समकालीन संयोजन प्रदान नहीं करते हैं, इसलिए समकालीन को क्लाइंट कोड पर छोड़ दिया जाता है, जो धीमा और त्रुटि प्रवण है और समकालीन आलेखन के अन्य उपभोक्ताओं द्वारा प्रतिरूप होने की उम्मीद करना संभव नहीं है। पुनरावृत्ति की पूरी अवधि को भी संरक्षित किया जाना चाहिए। इसके अतिरिक्त, एक आलेखन जो अलग-अलग स्थानों में दो बार लपेटा जाता है जो अतिव्यापी की अनुमति भी देता है और अलग-अलग आंतरिक म्यूटेक्स पदार्थ होते हैं जिन पर समकालीन संचालित होता है। प्रतिनिधित्व से प्रदर्शन क्षीण होता है, लेकिन आधुनिक सही समय पर संकलनकर्ता अक्सर भारी रूप से इनलाइन होते हैं, जो प्रदर्शन में कमी को सीमित करते हैं। यहां बताया गया है कि आवरण अवरोधक के अंदर कैसे काम करता है - म्यूटेक्स सिर्फ एक निर्णायक वस्तु है और m निर्णायक बंधा हुआ आलेखन है:
समवर्ती संशोधन समस्या का एक समाधान संग्रह में कारख़ाने द्वारा प्रदान किए गए एक विशेष अवरोधक वर्ग का उपयोग करता है: <code>public static <K,V> Map<K,V> synchronizedMap(Map<K,V> m)</code> जो उपस्थित गैर-सूत्रण-सुरक्षित आलेखन को आंतरिक म्यूटेक्स पर समकालीन करने वाले तरीकों से लपेटता है। अन्य प्रकार के संग्रहों के लिए भी आवरण हैं। यह एक आंशिक समाधान है, क्योंकि यह अभी भी संभव है कि अंतर्निहित आलेखन को सूत्रण द्वारा अनजाने में एक्सेस किया जा सकता है जो अलिखित संदर्भों को रखता है या प्राप्त करता है। साथ ही, सभी संग्रह {{Javadoc:SE|package=java.lang|java/lang|Iterable}}लागू करते हैं लेकिन समकालीन-अवरोधक आलेखन और अन्य अवरोधक संग्रहण समकालीन संयोजन प्रदान नहीं करते हैं, इसलिए समकालीन को ग्राहक कोड पर छोड़ दिया जाता है, जो धीमा और त्रुटि प्रवण है और समकालीन आलेखन के अन्य उपभोक्ताओं द्वारा प्रतिरूप होने की उम्मीद करना संभव नहीं है। पुनरावृत्ति की पूरी अवधि को भी संरक्षित किया जाना चाहिए। इसके अतिरिक्त, एक आलेखन जो अलग-अलग स्थानों में दो बार लपेटा जाता है जो अतिव्यापी की अनुमति भी देता है और अलग-अलग आंतरिक म्यूटेक्स पदार्थ होते हैं जिन पर समकालीन संचालित होता है। हस्तांतरण करने से भी प्रदर्शन क्षीण होता है, लेकिन आधुनिक समय पर संकलनकर्ता अक्सर भारी रूप से इनलाइन होते हैं, जो प्रदर्शन में कमी को सीमित करते हैं। यहां बताया गया है कि आवरण अवरोधक के अंदर कैसे काम करता है - म्यूटेक्स सिर्फ एक निर्णायक वस्तु है और m निर्णायक बंधा हुआ आलेखन है:


<syntaxhighlight lang="java">
<syntaxhighlight lang="java">
Line 138: Line 138:
'''<big>समुदाय</big>'''
'''<big>समुदाय</big>'''


पारस्परिक अपवाद में अवरोधक समुदाय की समस्या है, जिसमें सूत्रण अवरोधक पर इकठ्ठे हो सकते हैं, जिससे जेवीएम को सर्वर की बहुमूल्य पंक्ति बनाए रखने और प्रतीक्षा सूत्रण को 'पार्क' करने की आवश्यकता होती है। किसी सूत्रण को पार्क और अनपार्क करना महंगा होता है, और धीमा संदर्भ स्विच हो सकता है। संदर्भ स्विच को माइक्रोसेकंड से मिलीसेकंड तक की आवश्यकता होती है, जबकि आलेखन के अपने स्थानीय संचालन सामान्य रूप से नैनोसेकंड लेते हैं। विवाद बढ़ने पर प्रदर्शन एकल सूत्रण की क्षमता के एक छोटे से अंश तक गिर सकता है। जब अवरोधक के लिए कोई या कम विवाद नहीं होता है, हालांकि, अवरोधक के विवाद परीक्षण को छोड़कर प्रदर्शन पर बहुत कम प्रभाव पड़ता है। आधुनिक जेवीएम अधिकांश अवरोधक कोड को इनलाइन करेंगे, इसे केवल कुछ निर्देशों तक कम कर देंगे, नो-कंटेनमेंट केस को बहुत तेज रखेंगे। स्थानीय समकालीनता या java.util.concurrent.ReentrantReadWriteLock जैसी रीएन्ट्रेंट तकनीकों में रीएन्ट्रेंसी डेप्थ के रखरखाव में अतिरिक्त प्रदर्शन-कम करने वाला सामान होता है, जो नो-कंटेनमेंट केस को भी प्रभावित करता है। आधुनिक जेवीएमएस के साथ समुदाय की समस्या कम होती दिख रही है, लेकिन इसे धीमी संदर्भ स्विचिंग से छिपाया जा सकता है: इस मामले में, विलंबता बढ़ेगी, लेकिन थ्रूपुट स्वीकार्य रहेगा। सैकड़ों सूत्रण्स के साथ, 10ms का संदर्भ स्विच समय सेकंड में विलंबता पैदा करता है।
पारस्परिक अपवाद में अवरोधक समुदाय की समस्या है, जिसमें सूत्रण अवरोधक पर इकठ्ठे हो सकते हैं, जिससे जेवीएम को सर्वर की बहुमूल्य पंक्ति बनाए रखने और प्रतीक्षा सूत्रण को 'पार्क' करने की आवश्यकता होती है। किसी सूत्रण को पार्क और अनपार्क करना महंगा होता है, और धीमा संदर्भ स्विच हो सकता है। संदर्भ स्विच को माइक्रोसेकंड से मिलीसेकंड तक की आवश्यकता होती है, जबकि आलेखन के अपने स्थानीय संचालन सामान्य रूप से नैनोसेकंड लेते हैं। विवाद बढ़ने पर प्रदर्शन एकल सूत्रण की क्षमता के एक छोटे से अंश तक गिर सकता है। जब अवरोधक के लिए कोई या कम विवाद नहीं होता है। हालांकि, अवरोधक के विवाद परीक्षण को छोड़कर प्रदर्शन पर बहुत कम प्रभाव पड़ता है। आधुनिक जेवीएम अधिकांश अवरोधक कोड को इनलाइन करेंगे, इसे केवल कुछ निर्देशों तक कम कर देंगे, विवाद रहित स्तिथियों को बहुत तेज रखेंगे। स्थानीय समकालीनता या java.util.concurrent.ReentrantReadWriteLock जैसी पुन:प्रवेशी तकनीकों में पुन:प्रवेशी डेप्थ के रखरखाव में अतिरिक्त प्रदर्शन-कम करने वाला सामान होता है, जो विवाद रहित स्तिथियों को भी प्रभावित करता है। आधुनिक जेवीएमएस के साथ समुदाय की समस्या कम होती दिख रही है, लेकिन इसे धीमी संदर्भ स्विचिंग से छिपाया जा सकता है: इस स्तिथि में, विलंबता बढ़ेगी, लेकिन थ्रूपुट स्वीकार्य रहेगा। सैकड़ों सूत्रण्स के साथ, 10ms का संदर्भ स्विच समय सेकंड में विलंबता पैदा करता है।


== एकाधिक कोर ==
== एकाधिक कोर ==

Revision as of 10:28, 18 June 2023

जावा समवर्ती आलेखन जावा प्रोग्रामिंग भाषा का जावा संग्रह ढांचा संस्करण 1.5 और उसके बाद के संस्करण में वास्तविक नियमित एकल सूत्रण आलेखन को परिभाषित और लागू करता है। साथ ही साथ java.util.concurrent.ConcurrentMap अन्य समवर्ती संयोजन के बीच नए सूत्रण-सुरक्षित आलेखन भी लागू करते है।

जावा 1.6 में,java.util.NavigableMapसंयोजन जोड़ा गया था और java.util.SortedMap तक विस्तार किया गया था।

और यहjava.util.concurrent.ConcurrentNavigableMap संयोजन को उपसंयोजन के रूप में जोड़ा गया था।

जावा आलेखन संयोजन

संस्करण 1.8 आलेखन संयोजन आरेख का आकार नीचे है। समूह को संबंधित आलेखनों के उप-स्तिथियों के रूप में माना जा सकता है जिसमें मान हमेशा एक विशेष स्थिरांक होते हैं जिन्हें उपेक्षित किया जा सकता है, हालांकि समूह एपीआई संबंधित लेकिन अलग-अलग नामित विधियों का उपयोग करता है। नीचे java.util.concurrent.ConcurrentNavigableMap है, जो एक एकाधिक-वंशानुक्रम है।

कार्यान्वयन

समवर्ती हाश आलेखन

Java.util.Map संयोजन java.util.concurrent.ConcurrentHashMap में परिभाषित अक्रमित एक्सेस के लिए Java.util.concurrent.ConcurrentMap लागू करता है। प्रणाली प्रविष्टियों की सूची के साथ हैश तालिका के लिए एक हैश एक्सेस है, प्रत्येक प्रविष्टि में एक कुंजी, एक मान, हैश और एक अगला संदर्भ होता है। जावा 8 से पहले, तालिका के एक 'अनुभाग' तक एक्सेस को क्रमबद्ध करने के लिए कई अवरोधक थे। जावा 8 में, स्थानीय समकालीनता का उपयोग स्वयं सूचियों के शीर्ष पर किया जाता है, और सूचियाँ छोटे वृक्षों में परिवर्तित हो सकते हैं जब वे दुर्भाग्यपूर्ण हैश टकरावों के कारण बहुत बड़े होने की धमकी देते हैं। इसके अतिरिक्त, जावा 8 प्रारंभिक हेड्स को तालिका में रखने के लिए आशावादी रूप से तुलनात्मक और स्थिर प्राथमिक का उपयोग करता है, जो बहुत तीव्र है। प्रदर्शन O(n) है, लेकिन जब पुन: साझा करना आवश्यक होता है तो कभी कभी देरी हो सकती है। हैश तालिका के विस्तार के बाद, यह कभी सिकुड़ता नहीं है, संभवतः प्रविष्टियों को हटा दिए जाने के बाद मेमोरी 'लीक' हो सकती है।

समवर्ती स्किप सूची आलेखन

Java.util.NavigableMap संयोजन द्वारा परिभाषित क्रमित पहुँच के लिए, Java.util.concurrent.ConcurrentSkipListMap जावा 1.6 में जोड़ा गया था, और java.util.concurrent.ConcurrentMap और java.util.concurrent.ConcurrentNavigableMap को लागू करता है। प्रदर्शन O(log(n)) है और यह एक स्किप सूची है जो वृक्ष बनाने के लिए अवरोध मुक्त तकनीकों का उपयोग करती है।

सीटीआरई

  • Ctrie एक त्रि-आधारित अवरोध मुक्त वृक्ष है।

समवर्ती संशोधन समस्या

जावा 1.5 java.util.concurrent पैकेज द्वारा हल की गई एक समस्या समवर्ती संशोधन की है। इसके द्वारा प्रदान की जाने वाली संग्रह श्रेणियों को विभिन्न सूत्रण द्वारा मज़बूती से उपयोग किया जा सकता है।

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

संशोधन काउंटर

समवर्ती संशोधन समस्या के साथ मदद करने के लिए, गैर-समवर्ती आलेखन कार्यान्वयन और अन्य संग्रह आंतरिक संशोधन काउंटरों का उपयोग करते हैं, जिन्हें परिवर्तनों को देखने के लिए पढ़ने से पहले और बाद में परामर्श किया जाता है। लेखक संशोधन काउंटरों का विस्तार करते हैं। java.util.ConcurrentModificationException का उपयोग करके,इस प्रणाली द्वारा एक समवर्ती संशोधन का पता लगाया जाना चाहिए, लेकिन यह सभी स्तिथियों में होने का आश्वासन नहीं है और इस पर भरोसा नहीं किया जाना चाहिए। काउंटर का रखरखाव भी प्रदर्शन क्षीण करता है। प्रदर्शन कारणों से, काउंटर परिवर्तनशील नहीं हैं, इसलिए यह आश्वासन नहीं है कि उनमें परिवर्तन सूत्रण के बीच प्रचारित किए जाएंगे।

कलेक्शनंस.सिंक्रोनीजेडमैप()

समवर्ती संशोधन समस्या का एक समाधान संग्रह में कारख़ाने द्वारा प्रदान किए गए एक विशेष अवरोधक वर्ग का उपयोग करता है: public static <K,V> Map<K,V> synchronizedMap(Map<K,V> m) जो उपस्थित गैर-सूत्रण-सुरक्षित आलेखन को आंतरिक म्यूटेक्स पर समकालीन करने वाले तरीकों से लपेटता है। अन्य प्रकार के संग्रहों के लिए भी आवरण हैं। यह एक आंशिक समाधान है, क्योंकि यह अभी भी संभव है कि अंतर्निहित आलेखन को सूत्रण द्वारा अनजाने में एक्सेस किया जा सकता है जो अलिखित संदर्भों को रखता है या प्राप्त करता है। साथ ही, सभी संग्रह java.lang.Iterableलागू करते हैं लेकिन समकालीन-अवरोधक आलेखन और अन्य अवरोधक संग्रहण समकालीन संयोजन प्रदान नहीं करते हैं, इसलिए समकालीन को ग्राहक कोड पर छोड़ दिया जाता है, जो धीमा और त्रुटि प्रवण है और समकालीन आलेखन के अन्य उपभोक्ताओं द्वारा प्रतिरूप होने की उम्मीद करना संभव नहीं है। पुनरावृत्ति की पूरी अवधि को भी संरक्षित किया जाना चाहिए। इसके अतिरिक्त, एक आलेखन जो अलग-अलग स्थानों में दो बार लपेटा जाता है जो अतिव्यापी की अनुमति भी देता है और अलग-अलग आंतरिक म्यूटेक्स पदार्थ होते हैं जिन पर समकालीन संचालित होता है। हस्तांतरण करने से भी प्रदर्शन क्षीण होता है, लेकिन आधुनिक समय पर संकलनकर्ता अक्सर भारी रूप से इनलाइन होते हैं, जो प्रदर्शन में कमी को सीमित करते हैं। यहां बताया गया है कि आवरण अवरोधक के अंदर कैसे काम करता है - म्यूटेक्स सिर्फ एक निर्णायक वस्तु है और m निर्णायक बंधा हुआ आलेखन है:

    public V put(K key, V value) {
        synchronized (mutex) { return m.put(key, value); }
    }

पुनरावृत्ति के तुल्यकालन की अनुशंसा निम्नानुसार की जाती है, हालाँकि, यह आंतरिक म्यूटेक्स के बजाय आवरण पर तुल्यकालन करता है, ओवरलैप की अनुमति देता है:[1]

    Map<String, String> wrappedMap = Collections.synchronizedMap(map);
          ...
    synchronized (wrappedMap) {
        for (String s : wrappedMap.keySet()) {
            // some possibly long operation executed possibly 
            // many times, delaying all other accesses
        }
    }


स्थानीय समकालीन

किसी भी आलेखन को विभिन्न सूत्रण प्रणाली में सुरक्षित रूप से उपयोग किया जा सकता है, यह सुनिश्चित करके कि इसके सभी एक्सेस जावा समकालीन तंत्र द्वारा नियंत्रित किए जाते हैं:

    Map<String, String> map = new HashMap<String, String>();
    ...
    // Thread A
    // Use the map itself as the lock. Any agreed object can be used instead.
    synchronized(map) {
       map.put("key","value");
    }
    ..
    // Thread B
    synchronized (map) {
        String result = map.get("key");
         ...
     }
    ...
    // Thread C
    synchronized (map) {
        for (Entry<String, String> s : map.entrySet()) {
            /*
             * Some possibly slow operation, delaying all other supposedly fast operations. 
             * Synchronization on individual iterations is not possible.
             */ 
            ...
        }
    }


रेंट्रेंट रीड राइट लॉक

Java.util.concurrent.ReentrantReadWriteLock का उपयोग करने वाला कोड स्थानीय समकालीनता के समान है। हालांकि, सुरक्षा के लिए, अवरोधक को प्रयत्न/अंततः खंड में इस्तेमाल किया जाना चाहिए ताकि प्रारंभिक निकास जैसे अपवाद फेंकना या तोड़ना/जारी रखना अनलॉक से गुजरना सुनिश्चित हो। यह तकनीक समकालीनता का उपयोग करने से बेहतर है क्योंकि पढ़ना एक दूसरे को ओवरलैप कर सकता है, पढ़ने के संबंध में लिखने को प्राथमिकता देने का निर्णय लेने में एक नया विवाद है। सरलता के लिए इसके बजाय java.util.concurrent.ReentrantLock का उपयोग किया जा सकता है, जो पढ़ने/लिखने में कोई अंतर नहीं करता है। समकालीनता की तुलना में अवरोधकों पर अधिक संचालन संभव है, जैसे tryLock()और tryLock(long timeout, TimeUnit unit).

    final ReentrantReadWriteLock lock = new ReentrantReadWriteLock();
    final ReadLock readLock = lock.readLock();
    final WriteLock writeLock = lock.writeLock();
    ..
    // Thread A
    try {
        writeLock.lock();
        map.put("key","value");
        ...
    } finally {
        writeLock.unlock();
    }
    ...
    // Thread B
    try {
        readLock.lock();
        String s = map.get("key");
        ..
    } finally {
        readLock.unlock();
    }
     // Thread C
    try {
        readLock.lock();
        for (Entry<String, String> s : map.entrySet()) {
            /*
             * Some possibly slow operation, delaying all other supposedly fast operations. 
             * Synchronization on individual iterations is not possible.
             */ 
            ...
        }
    } finally {
        readLock.unlock();
    }


समुदाय

पारस्परिक अपवाद में अवरोधक समुदाय की समस्या है, जिसमें सूत्रण अवरोधक पर इकठ्ठे हो सकते हैं, जिससे जेवीएम को सर्वर की बहुमूल्य पंक्ति बनाए रखने और प्रतीक्षा सूत्रण को 'पार्क' करने की आवश्यकता होती है। किसी सूत्रण को पार्क और अनपार्क करना महंगा होता है, और धीमा संदर्भ स्विच हो सकता है। संदर्भ स्विच को माइक्रोसेकंड से मिलीसेकंड तक की आवश्यकता होती है, जबकि आलेखन के अपने स्थानीय संचालन सामान्य रूप से नैनोसेकंड लेते हैं। विवाद बढ़ने पर प्रदर्शन एकल सूत्रण की क्षमता के एक छोटे से अंश तक गिर सकता है। जब अवरोधक के लिए कोई या कम विवाद नहीं होता है। हालांकि, अवरोधक के विवाद परीक्षण को छोड़कर प्रदर्शन पर बहुत कम प्रभाव पड़ता है। आधुनिक जेवीएम अधिकांश अवरोधक कोड को इनलाइन करेंगे, इसे केवल कुछ निर्देशों तक कम कर देंगे, विवाद रहित स्तिथियों को बहुत तेज रखेंगे। स्थानीय समकालीनता या java.util.concurrent.ReentrantReadWriteLock जैसी पुन:प्रवेशी तकनीकों में पुन:प्रवेशी डेप्थ के रखरखाव में अतिरिक्त प्रदर्शन-कम करने वाला सामान होता है, जो विवाद रहित स्तिथियों को भी प्रभावित करता है। आधुनिक जेवीएमएस के साथ समुदाय की समस्या कम होती दिख रही है, लेकिन इसे धीमी संदर्भ स्विचिंग से छिपाया जा सकता है: इस स्तिथि में, विलंबता बढ़ेगी, लेकिन थ्रूपुट स्वीकार्य रहेगा। सैकड़ों सूत्रण्स के साथ, 10ms का संदर्भ स्विच समय सेकंड में विलंबता पैदा करता है।

एकाधिक कोर

पारस्परिक अपवाद समाधान एकाधिक -कोर प्रणाली की सभी गणनीय शक्ति का लाभ उठाने में विफल होते हैं, क्योंकि एक समय में आलेखन कोड के अंदर केवल एक सूत्रण की अनुमति होती है। जावा संग्रह ढांचा द्वारा प्रदान किए गए विशेष समवर्ती आलेखनों के कार्यान्वयन और अन्य कभी-कभी अवरोधक मुक्त प्रोग्रामिंग तकनीकों का उपयोग करके कई कोर का लाभ उठाते हैं। अवरोधक मुक्त तकनीक कई जावा वर्गों पर उपलब्ध कंपेयरएंडसेट () जैसे परमाणु संदर्भ, कुछ आलेखन-आंतरिक संरचनाओं के परमाणु-संबंधी सशर्त नवीनीकरण करने के लिए आंतरिक विधि जैसे सञ्चालन का उपयोग करती है। कंपेयरएंडसेट () प्राथमिक को जेसीएफ श्रेणी में स्थानीय कोड द्वारा संवर्धित किया जाता है जो कुछ कलन विधि के लिए कुछ उत्पादों के विशेष आंतरिक भागों पर कंपेयरएंडसेट कर सकता है ('असुरक्षित' एक्सेस का उपयोग करके)। तकनीकें जटिल हैं, जो अस्थिर चरों द्वारा प्रदान किए गए अन्तः-सूत्रण संचार के नियमों पर निर्भर करती हैं, संबंध से पहले होता है, विशेष प्रकार के अवरोधक मुक्त 'रिट्री लूप्स' (जो स्पिन लॉक की तरह नहीं होते हैं जिसमें वे हमेशा प्रगति करते हैं) . कंपेयरएंडसेट () विशेष प्रोसेसर-विशिष्ट निर्देशों पर निर्भर करता है। किसी भी जावा कोड के लिए अवरोधक मुक्त या यहां तक ​​​​कि प्रतीक्षा-मुक्त समेकन प्राप्त करने के लिए विभिन्न समवर्ती कक्षाओं पर तुलना एंडसेट () विधि का अन्य उद्देश्यों के लिए उपयोग करना संभव है, जो परिमित विलंबता प्रदान करता है। कई सामान्य स्तिथियों में और स्टैक जैसे कुछ सरल संग्रहों के साथ अवरोधक मुक्त तकनीक सरल हैं।

आरेख इंगित करता है कि कैसे समकालीनCollections.synchronizedMap(java.util.Map) का उपयोग करके एक नियमित हैश(बैंगनी) आलेखन के साथ-साथ समवर्ती हैश मैप (लाल) लपेटकर माप नहीं कर सकता है। अन्य क्रमित किए गए ConcurrentNavigableMaps AirConcurrentMap (नीला) और ConcurrentSkipListMap (CSLM हरा) हैं। (समतल स्थान नर्सरी से बड़े टेबल बनाने के लिए नए सिरे से हो सकते हैं, और ConcurrentHashMap अधिक जगह लेता है। ध्यान दें कि y अक्ष को 'पुट्स K' कहना चाहिए। सिस्टम 8-कोर i7 2.5 GHz है, GC को रोकने के लिए -Xms5000m के साथ)। जीसी और जेवीएम प्रक्रिया के विस्तार से वक्र काफी बदल जाते हैं, और कुछ आंतरिक अवरोधक मुक्त तकनीकें विवाद पर कचरा उत्पन्न करती हैं।

केवल आदेशित मानचित्र स्केलिंग कर रहे हैं, और सिंक्रनाइज़ मानचित्र वापस गिर रहा है सिंक्रोनाइज़्ड मैप वापस स्केल किए गए ऑर्डर किए गए मैप्स के समान हो गया है

अनुमानित विलंबता

फिर भी परस्पर अपवाद दृष्टिकोण के साथ एक और समस्या यह है कि कुछ एकल-सूत्रण कोड द्वारा बनाई गई पूर्ण परमाणुता की धारणा एक समवर्ती परिस्थिति में विकीर्ण अस्वीकार्य रूप से लंबी अन्तः-सूत्रण देरी बनाती है। विशेष रूप से,अभ्यास और विस्तृत सञ्चालन जैसे putAll () और अन्य आलेखन के आकार के अनुपात में समय अवधि ले सकते हैं, अन्य सूत्रण में देरी कर सकते हैं जो गैर-विस्तृत सञ्चालन के लिए अनुमानित रूप से कम विलंबता की उम्मीद करते हैं। उदाहरण के लिए, एकाधिक सूत्रण वेब सर्वर किसी विशेष मान की खोज करने वाले अन्य अनुरोधों को निष्पादित करने वाले अन्य सूत्रण के लंबे समय तक चलने वाले पुनरावृत्तियों द्वारा कुछ प्रतिक्रियाओं को विलंबित करने की अनुमति नहीं दे सकता है। इससे संबंधित तथ्य यह है कि आलेखन को लॉक करने वाले सूत्रण को वास्तव में कभी भी लॉक को छोड़ने की आवश्यकता नहीं होती है, और अधिकारी सूत्रण में एक अनंत लूप अन्य सूत्रण को स्थायी अवरुद्ध का प्रचार कर सकता है। धीमे अधिकारी सूत्रण कभी-कभी बाधित हो सकते हैं। हैश-आधारित आलेखन भी अभ्यास के दौरान स्वतःस्फूर्त देरी के अधीन होते हैं।

कमजोर संगति

Java.util.concurrency संकुल समवर्ती संशोधन समस्या, समुदाय की समस्या, अनुमानित विलंबता समस्या और एकाधिक-कोर समस्या के समाधान में एक वास्तु-संबंधी विकल्प सम्मिलित है जिसे कमजोर स्थिरता कहा जाता है। इस विकल्प का अर्थ है कि रीड्स जैसे गेट () नवीनतम होने पर भी अवरुद्ध नहीं होगा, और यह अपडेट को खुद के साथ और रीड्स के साथ ओवरलैप करने के लिए भी स्वीकार्य है। कमजोर संगति, उदाहरण के लिए, समवर्ती आलेखन की सामग्री को एकल सूत्रण द्वारा पुनरावृत्ति के दौरान बदलने की अनुमति देती है। संयोजन को एक समय में एक सूत्रण द्वारा उपयोग करने के लिए रचित किया गया है। इसलिए, उदाहरण के लिए, एक आलेखन जिसमें दो प्रविष्टियाँ हैं जो अंतर-निर्भर हैं, एक पाठक सूत्रण द्वारा किसी अन्य सूत्रण द्वारा संशोधन के दौरान असंगत तरीके से देखा जा सकता है। एक अद्यतन जो एक प्रविष्टि (k1,v) की कुंजी को एक प्रविष्टि (k2,v) में बदलने के लिए माना जाता है, परमाणु रूप से एक हटाने (k1) और फिर एक पुट (k2, v) करने की आवश्यकता होगी, जबकि एक पुनरावृत्ति छूट सकती है प्रवेश या इसे दो स्थानों पर देखें। पुनर्प्राप्ति किसी दी गई कुंजी के लिए मान लौटाती है जो उस कुंजी के लिए नवीनतम पिछले पूर्ण अद्यतन को दर्शाती है। इस प्रकार यह एक कार्य होने से पहले संबंध को दर्शाता है।

समवर्ती आलेखन के लिए संपूर्ण तालिका को लॉक करने का कोई तरीका नहीं है। गैर-समवर्ती ConcurrentModificationException के अनजाने समवर्ती संशोधन के साथ होने की कोई संभावना नहीं क्योंकि संबंधित गैर-समवर्ती एस और अन्य संग्रहों के विपरीत विधि में लंबा समय लग सकता है। आकार () पद्धति में लंबा समय लग सकता है, क्योंकि संबंधित गैर-समवर्ती आलेखनों और अन्य संग्रहों के विपरीत, जिसमें सामान्यतौर पर तेजी से पहुंच के लिए एक आकार क्षेत्र सम्मिलित होता है, क्योंकि उन्हें किसी तरह पूरे आलेखन को स्कैन करने की आवश्यकता हो सकती है। जब समवर्ती संशोधन हो रहे हों, तो परिणाम कुछ समय में आलेखन की स्थिति को दर्शाते हैं, लेकिन जरूरी नहीं कि एक सुसंगत स्थिति हो, इसलिए आकार (), isEmpty () और सम्‍मिलित मान() का उपयोग केवल निगरानी के लिए किया जा सकता है।

समवर्ती आलेखन 1.5 तरीके

समवर्ती आलेखन द्वारा प्रदान किए गए कुछ सञ्चालन हैं जो आलेखन में नहीं हैं - जो संशोधनों की परमाणुता की अनुमति देने के लिए इसे विस्तारित करता है। प्रतिस्थापन (K, v1, v2)) के द्वारा पहचानी गई प्रविष्टि में v1 के अस्तित्व के लिए परीक्षण करेगा और केवल अगर पाया जाता है, तो v1 को परमाणु रूप से v2 द्वारा प्रतिस्थापित किया जाता है। नया प्रतिस्थापन (k,v) केवल एक पुट (k,v) करेगा यदि k पहले से ही आलेखन में है। साथ ही, putIfAbsent(k,v) केवल एक put(k,v) करेगा यदि k पहले से आलेखन में नहीं है, और निकालें(k, v) केवल v के लिए प्रविष्टि को हटा देगा यदि v सम्मिलित है। कुछ एकाधिक सूत्रण उपयोग स्तिथियों के लिए यह परमाणु महत्वपूर्ण हो सकता है, लेकिन यह कमजोर-स्थिरता बाधा से संबंधित नहीं है।

समवर्ती आलेखनों के लिए, निम्नलिखित परमाणु हैं।

m.putIfAbsent(k, v) परमाणु है लेकिन इसके समतुल्य है:

    if (k == null || v == null)
        throw new NullPointerException();
    if (!m.containsKey(k)) {
        return m.put(k, v);
    } else {
        return m.get(k);
    }

m.replace(k, v) परमाणु है लेकिन इसके बराबर है:

    if (k == null || v == null)
        throw new NullPointerException();
    if (m.containsKey(k)) {
        return m.put(k, v);
    } else {
        return null;
    }

m.replace(k, v1, v2)परमाणु है लेकिन इसके समतुल्य है:

    if (k == null || v1 == null || v2 == null)
        throw new NullPointerException();
    if (m.containsKey(k) && Objects.equals(m.get(k), v1)) {
        m.put(k, v2);
        return true;
    } else
        return false;
    }

m.remove(k, v) परमाणु है लेकिन इसके बराबर है:

    // if Map does not support null keys or values (apparently independently)
    if (k == null || v == null)
        throw new NullPointerException();
    if (m.containsKey(k) && Objects.equals(m.get(k), v)) {
        m.remove(k);
        return true;
    } else
       return false;
    }


समवर्ती आलेखन 1.8 विधियाँ

क्योंकि आलेखन और समवर्ती आलेखन संयोजन हैं, कार्यान्वयन को तोड़े बिना उनमें नए तरीके नहीं जोड़े जा सकते। हालाँकि, जावा 1.8 ने पूर्वनिर्धारित संयोजन कार्यान्वयन की क्षमता को जोड़ा और यह कुछ नए तरीकों getOrDefault(Object, V), forEach(BiConsumer), replaceAll(BiFunction), ComputeIfAbsent(K, Function), ComputeIfPresent(K, BiFunction), कंप्यूट(K, BiFunction) के आलेखन पूर्वनिर्धारित संयोजन कार्यान्वयन में जोड़ा गया और merge(K, V, BiFunction)। आलेखन में पूर्वनिर्धारित कार्यान्वयन परमाणुता की गारंटी नहीं देता है, लेकिन समवर्ती आलेखन ओवरराइडिंग पूर्वनिर्धारित में ये परमाणुता प्राप्त करने के लिए अवरोधक मुक्त तकनीकों का उपयोग करते हैं, और मौजूदा समवर्ती आलेखन कार्यान्वयन स्वचालित रूप से परमाणु होंगे। समवर्ती कक्षाओं में अवरोधक मुक्त तकनीक ओवरराइड की तुलना में धीमी हो सकती है, इसलिए ठोस वर्ग उन्हें परमाणु रूप से लागू करने या न करने और समवर्ती गुणों को दस्तावेज करने का विकल्प चुन सकते हैं।

अवरोधक मुक्त परमाणुता

समवर्ती आलेखन के साथ अवरोधक मुक्त तकनीकों का उपयोग करना संभव है क्योंकि उनमें पर्याप्त उच्च आम सहमति संख्या के तरीके शामिल हैं, अर्थात् अनंत, जिसका अर्थ है कि किसी भी धागे को समन्वित किया जा सकता है। यह उदाहरण जावा 8 मर्ज () के साथ लागू किया जा सकता है, लेकिन यह समग्र अवरोधक मुक्त श्रृंखला दिखाता है, जो अधिक सामान्य है। यह उदाहरण समवर्ती आलेखन के आंतरिक भाग से संबंधित नहीं है, बल्कि ग्राहक कोड के समवर्ती आलेखन के उपयोग से संबंधित है। उदाहरण के लिए, यदि हम आलेखन में किसी मान को परमाणु रूप से स्थिर C से गुणा करना चाहते हैं:

    static final long C = 10;
    void atomicMultiply(ConcurrentMap<Long, Long> map, Long key) {
        for (;;) {
            Long oldValue = map.get(key);
            // Assuming oldValue is not null. This is the 'payload' operation, and should not have side-effects due to possible re-calculation on conflict
            Long newValue = oldValue * C;
            if (map.replace(key, oldValue, newValue))
                break;
        }
    }

putIfAbsent(k, v) तब भी उपयोगी होता है जब कुंजी के लिए प्रविष्टि को अनुपस्थित रहने की अनुमति दी जाती है। यह उदाहरण जावा 8 कंप्यूट () के साथ लागू किया जा सकता है, लेकिन यह समग्र अवरोधक मुक्त श्रृंखला दिखाता है, जो अधिक सामान्य है। प्रतिस्थापन (k,v1,v2) शून्य मापदंड स्वीकार नहीं करता है, इसलिए कभी-कभी उनका संयोजन आवश्यक होता है। दूसरे शब्दों में, यदि v1 शून्य है, तो putIfAbsent(k, v2) लागू किया जाता है, अन्यथा प्रतिस्थापित (k,v1,v2) लागू किया जाता है।

    void atomicMultiplyNullable(ConcurrentMap<Long, Long> map, Long key) {
        for (;;) {
            Long oldValue = map.get(key);
            // This is the 'payload' operation, and should not have side-effects due to possible re-calculation on conflict
            Long newValue = oldValue == null ? INITIAL_VALUE : oldValue * C;
            if (replaceNullable(map, key, oldValue, newValue))
                break;
        }
    }
    ...
    static boolean replaceNullable(ConcurrentMap<Long, Long> map, Long key, Long v1, Long v2) {
        return v1 == null ? map.putIfAbsent(key, v2) == null : map.replace(key, v1, v2);
    }

इतिहास

जावा संग्रह ढांचे को मुख्य रूप से जोशुआ बलोच द्वारा डिजाइन और विकसित किया गया था, और इसे J2SE 1.2|JDK 1.2 में पेश किया गया था।[2] मूल संगामिति वर्ग डौग ली के संग्रह पैकेज से आया था [3]

यह भी देखें

संदर्भ

  1. "java.util.Collections.synchronizedMap". Java / Java SE / 11 / API / java.base. Oracle Help Center. September 19, 2018. Retrieved 2020-07-17.
  2. Vanhelsuwé, Laurence (January 1, 1999). "The battle of the container frameworks: which should you use?". JavaWorld. Retrieved 2020-07-17.
  3. Lea, Doug. "Overview of package util.concurrent Release 1.3.4". Retrieved 2011-01-01.
  • Goetz, Brian; Joshua Bloch; Joseph Bowbeer; Doug Lea; David Holmes; Tim Peierls (2006). Java Concurrency in Practice. Addison Wesley. ISBN 0-321-34960-1. OL 25208908M.
  • Lea, Doug (1999). Concurrent Programming in Java: Design Principles and Patterns. Addison Wesley. ISBN 0-201-31009-0. OL 55044M.


बाहरी संबंध