5

मुझे एक हैश मैप की आवश्यकता है जो एकाधिक धागे से सुलभ है।क्या ConcurrentHashMap के साथ कोई कमी है?

सामान्य हैश मैप का उपयोग करके दो सरल विकल्प हैं और उस पर सिंक्रनाइज़ करना या ConcurrentHashMap का उपयोग करना।

चूंकि ConcurrentHashMap पढ़ने के संचालन पर अवरुद्ध नहीं होता है, इसलिए यह मेरी आवश्यकताओं के लिए बहुत बेहतर अनुकूल लगता है (लगभग विशेष रूप से पढ़ता है, लगभग अपडेट नहीं होता है)। दूसरी ओर, मुझे वैसे भी बहुत कम सहमति की उम्मीद है, इसलिए कोई अवरोध नहीं होना चाहिए (केवल लॉक के प्रबंधन की लागत)।

मानचित्र भी बहुत छोटा होगा (दस प्रविष्टियों के तहत), यदि इससे कोई फर्क पड़ता है।

नियमित हैश मैप की तुलना में, पढ़ने और लिखने के संचालन कितने महंगा हैं (मुझे लगता है कि वे हैं)? या समवर्ती हैशैप बस हमेशा बेहतर होता है जब समवर्ती पहुंच का मामूली स्तर भी हो सकता है, चाहे पढ़ने/अद्यतन अनुपात और आकार के बावजूद?

+0

सटीक अनुलिपि सवाल? http://stackoverflow.com/questions/1378310/performance-concurrenthashmap-vs-hashmap – andersoj

+0

दरअसल। धन्यवाद।(हालांकि अभी तक कोई संतोषजनक उत्तर नहीं है) – Thilo

उत्तर

6

दूसरी तरफ, मुझे बहुत कम सहमति मिलती है, इसलिए कोई अवरोध नहीं होना चाहिए (केवल लॉक के प्रबंधन की लागत)।

प्राप्त करने और एक uncontend जावा म्युटेक्स (आदिम लॉक) जारी करने की लागत कम है। तो यदि आप मानते हैं कि विवाद की संभावना बहुत कम है तो एक साधारण HashMap शायद आपकी सबसे अच्छी शर्त है।

लेकिन यह सब अनुमान है। जब तक कि आपने वास्तव में अपने आवेदन को प्रोफाइल नहीं किया है, तब तक सट्टा अनुकूलन पर खर्च किए गए सभी समय (*) समय बर्बाद हो जाते हैं।

* ... जब तक आपके पास वास्तव में अच्छा अंतर्ज्ञान नहीं है।

+0

स्टीफन सी सही है (उसका प्रतिनिधि सुझाव देता है कि यह एक आदत है)। असंतुलित ताले सामान्य मामले में तेज़ी से होते हैं ... मैं सीएचएम के लिए बहुत जल्दी पहुंचता हूं, शायद। – andersoj

+0

हालांकि स्केलिंग के बारे में क्या? क्या उम्मीद है और क्या हो सकता है पूरी तरह से अलग हैं। यदि लॉकिंग/अनलॉकिंग इतना छोटा है, तो बस 'ConcurrentHashMap' का उपयोग करें और – TheLQ

+1

@TheLQ पर जाएं - यह ConcurrentHashMap का उपयोग करने के लिए अन्य ओवरहेड्स (लॉकिंग के अलावा) है जो चिंता का विषय है। आप इस धारणा पर किसी समस्या पर सीसीएम नहीं फेंकते हैं कि स्केलेबिलिटी * एक मुद्दा होगा। आप पहले मापते हैं! –

2

सीएचएम HashMap की तुलना में, कवर के तहत परमाणु * संचालन के उपयोग के लिए कुछ जुर्माना देता है। कितना? मान लीजिए ... इसे अपने ऐप में मापें ... ;-)

यदि आपको लगता है कि आपको वास्तव में एक प्रदर्शन समस्या है, तो शायद < 10 प्रविष्टियों के लिए एक बहुत ही विशिष्ट समाधान है जो किसी भी समाधान से सस्ता होगा java.util भूमि का, लेकिन जब तक आप जानते हैं कि आपके पास कोई प्रदर्शन समस्या नहीं है, तब तक मैं उस पर कूद नहीं पाऊंगा।

+0

मेरे पास सवाल यह है कि अगर मुझे पता है कि मेरे पास प्रदर्शन समस्या है तो मुझे ConcurrentHashMap का उपयोग करने के लिए कूदना चाहिए। मैं ऐसा नहीं करना चाहूंगा कि यदि कोई समेकन के मामले में सीएचएम वास्तव में हैश मैप से धीमा था। – Thilo

+0

मुझे लगता है कि मैं 'सीएचएम 'का उपयोग करूंगा यदि यह तुरंत स्पष्ट हो कि आप समेकन नियंत्रण प्राप्त कर सकते हैं जिसे आप w /' putIfAbsent() 'और जैसा चाहते हैं; यदि आप पहले से जानते हैं कि 'put() 'ऑपरेशन जटिल होने जा रहा है, तो मैं' सिंक्रनाइज़ (सामान्य हैश मैप) 'का उपयोग करूंगा। (यदि यह कोई समस्या है तो बाद में एक को अनुकूलित करना ...) – andersoj

2

थ्रूपुट और प्रदर्शन के मामले में, ओवरहेड आम तौर पर नगण्य होता है।

एक अलग नोट पर, एक ConcurrentHashMap (उदाहरण स्तर पर) की स्मृति पदचिह्न हैश मैप से कुछ हद तक बड़ा है। यदि आपके पास बड़ी संख्या में छोटे आकार के सीएचएम हैं, तो यह ओवरहेड जोड़ सकता है।

0

मुख्य मुद्दा डब्ल्यू/सीएचएम: जब तक आप सी-टोर कॉल नहीं बदलते हैं, तब तक यह अच्छी तरह से स्केल नहीं करता है, लेकिन अधिकांशतः यह उपलब्ध कोर के लिए स्वचालित रूप से स्केल नहीं होता है। नीचे

3 लिंक लॉक मुक्त करने के लिए hashmap
http://www.azulsystems.com/blog/cliff-click/2007-03-26-non-blocking-hashtable
http://www.azulsystems.com/blog/cliff-click/2007-04-01-non-blocking-hashtable-part-2
http://sourceforge.net/projects/high-scale-lib/