2015-05-19 10 views
5

जावा मानक पुस्तकालय में सबसे अधिक संग्रह के प्रलेखन जैसे ConcurrentLinkedQueue, ConcurrentLinkedDequeue और ConcurrentSkipListSet निम्न अस्वीकरण के साथ आते हैं:समवर्ती संग्रह आकार गणना

कि खबरदार, सबसे संग्रह में विपरीत, आकार विधि नहीं एक है निरंतर समय ऑपरेशन। इन सेट की असीमित प्रकृति की वजह से, तत्वों की वर्तमान संख्या को निर्धारित करने के लिए तत्वों के एक ट्रैवर्सल की आवश्यकता होती है, और यदि यह संग्रह ट्रैवर्सल के दौरान संशोधित किया गया है तो गलत परिणाम रिपोर्ट कर सकते हैं।

इसका क्या अर्थ है? वे काउंटर क्यों नहीं रख सकते (कहें, AtomicInteger) और केवल size() पर कॉल पर मान वापस करें?

ऐसा इसलिए है क्योंकि काउंटर को सिंक्रनाइज़ किया जाना चाहिए और इसलिए एक चोक पॉइंट बनाता है?

एक साइड नोट के रूप में, ConcurrentHashMap में यह समस्या प्रतीत नहीं होती है। ऐसा क्यों है? स्रोत कोड को देखते हुए, ऐसा लगता है कि यह size() पर कॉल पर सम्मिलित किए गए सरणी में रखे गए कई काउंटर का उपयोग करता है। क्या यह चोक पॉइंट को बाधित करने के लिए है या कोई और कारण है?

+0

एक परमाणु काउंटर निश्चित रूप से खराब होगा। – ZhongYu

उत्तर

5

आकार() को बनाए रखने के लिए साझा संसाधन का उपयोग महंगा और बल्कि बेकार दोनों होगा। size() जितनी जल्दी हो सके उतना गलत होने की संभावना है क्योंकि आप संग्रह पर लॉक नहीं रख सकते हैं, इसलिए यह आपको कॉल करने के बीच बदल सकता है और जब आप मान प्राप्त करते हैं।

ConcurentHashMap का एक ही दृष्टिकोण है। विधि वापस आने से पहले आकार() गलत हो सकता है।

+0

बेशक 'आकार()' पूरी तरह से भरोसा नहीं किया जा सकता है, मैं इसे स्वीकार करता हूं। लेकिन मेरे पास समस्या यह है कि उन्हें संग्रहित करने के लिए संग्रह में प्रत्येक तत्व को पार करने की गैर-निरंतर लागत है। लेकिन मुझे लगता है कि मैं चोक पॉइंट के बारे में सही था? –

+1

@ गुस्तावकर्ल्सन पीटर की पहली वाक्य वास्तव में कारण बताती है। एक कतार के संचालन के लिए सिंक्रनाइज़ेशन और कैश अमान्यता बहुत महंगा होगी। हाँ, आप सही थे, निश्चित रूप से वहाँ एक बोतल गर्दन होगी। यह 'ReentrantReadWriteLock' के साथ मुख्य मुद्दों में से एक है –

संबंधित मुद्दे