HashMapदो महत्वपूर्ण गुण हैं: sizeऔर load factor। मैं जावा प्रलेखन के माध्यम से चला गया और यह कहता 0.75fहै कि प्रारंभिक लोड कारक है। लेकिन मुझे इसका वास्तविक उपयोग नहीं मिल रहा है।
क्या कोई वर्णन कर सकता है कि अलग-अलग परिदृश्य क्या हैं जहां हमें लोड कारक निर्धारित करने की आवश्यकता है और विभिन्न मामलों के लिए कुछ नमूना आदर्श मूल्य क्या हैं?
जवाबों:
प्रलेखन यह बहुत अच्छी तरह से बताते हैं:
HashMap के एक उदाहरण के दो पैरामीटर हैं जो इसके प्रदर्शन को प्रभावित करते हैं: प्रारंभिक क्षमता और लोड फैक्टर। क्षमता हैश तालिका में बाल्टी की संख्या है, और प्रारंभिक क्षमता बस उस समय क्षमता है जब हैश तालिका बनाई जाती है। लोड फैक्टर इस बात का एक पैमाना है कि हैश टेबल को अपनी क्षमता के बढ़ने से पहले कैसे भरा जाए। जब हैश तालिका में प्रविष्टियों की संख्या लोड कारक और वर्तमान क्षमता के उत्पाद से अधिक हो जाती है, तो हैश तालिका को फिर से विभाजित किया जाता है (अर्थात, आंतरिक डेटा संरचनाएं फिर से बनाई जाती हैं) ताकि हैश तालिका में बाल्टी की संख्या लगभग दोगुनी हो।
एक सामान्य नियम के रूप में, डिफ़ॉल्ट लोड कारक (.75) समय और अंतरिक्ष लागत के बीच एक अच्छा व्यापार प्रदान करता है। उच्च मूल्यों से अंतरिक्ष में कमी होती है, लेकिन लुकअप लागत (हाशप वर्ग के अधिकांश परिचालनों में परिलक्षित होती है, जिसमें गेट और पुट शामिल हैं) में वृद्धि होती है। मानचित्र में प्रविष्टियों की अपेक्षित संख्या और इसके लोड कारक को इसकी प्रारंभिक क्षमता निर्धारित करते समय ध्यान में रखा जाना चाहिए, ताकि पुन: संचालन की संख्या को कम से कम किया जा सके। यदि प्रारंभिक क्षमता लोड फैक्टर द्वारा विभाजित प्रविष्टियों की अधिकतम संख्या से अधिक है, तो कोई भी पुन: संचालन नहीं होगा।
जैसा कि सभी प्रदर्शन अनुकूलन के साथ है, समय से पहले चीजों को अनुकूलित करने से बचने के लिए यह एक अच्छा विचार है (यानी जहां पर अड़चनें हैं, बिना हार्ड डेटा के)।
ले की डिफ़ॉल्ट प्रारंभिक क्षमता HashMap16 है और लोड फैक्टर 0.75f (यानी वर्तमान मानचित्र आकार का 75%) है। लोड फैक्टर यह दर्शाता है कि HashMapक्षमता किस स्तर पर दोगुनी होनी चाहिए।
उदाहरण के लिए क्षमता और लोड फैक्टर के उत्पाद 16 * 0.75 = 12। यह दर्शाता है कि 12 वीं कुंजी मूल्य जोड़ी को स्टोर करने के बाद HashMap, इसकी क्षमता 32 हो जाती है।
दरअसल, मेरी गणना से, "पूर्ण" लोड कारक लॉग 2 (~ 0.7) के करीब है। हालांकि इससे कम लोड फैक्टर बेहतर प्रदर्शन देगा। मुझे लगता है कि .75 शायद एक टोपी से बाहर निकाला गया था।
सबूत:
एक बाल्टी खाली है या नहीं, इसकी भविष्यवाणी करके शोषण की शाखा से बचा जा सकता है। एक बाल्टी शायद खाली है अगर इसके खाली होने की संभावना अधिक है ।5।
चलो आकार का प्रतिनिधित्व करते हैं और n कुंजी की संख्या जोड़ी। द्विपद प्रमेय का उपयोग करते हुए, एक बाल्टी खाली होने की संभावना है:
P(0) = C(n, 0) * (1/s)^0 * (1 - 1/s)^(n - 0)इस प्रकार, एक बाल्टी शायद खाली है अगर वहाँ से कम कर रहे हैं
log(2)/log(s/(s - 1)) keysजैसा कि अनंत तक पहुंचता है और यदि जोड़ी गई कुंजियों की संख्या ऐसी है कि P (0) = .5 है, तो n / s दृष्टिकोण लॉग (2) तेजी से होता है:
lim (log(2)/log(s/(s - 1)))/s as s -> infinity = log(2) ~ 0.693....75अंश को समझने के लिए निकटतम आसान के लिए गोल किया गया था log(2), और एक जादू की संख्या की तरह कम दिखता है। मैं JDK डिफ़ॉल्ट मान के अपडेट को देखना पसंद करूंगा, इसके कार्यान्वयन के ऊपर टिप्पणी के साथ: D
अपनी क्षमता बढ़ाने के लिए हाशप के लिए कितनी क्षमता होनी चाहिए?
लोड फैक्टर प्रारंभिक क्षमता के डिफ़ॉल्ट रूप से 0.75 (16) है, इसलिए क्षमता में वृद्धि होने से पहले 25% बाल्टियां मुक्त हो जाएंगी और इससे कई नए बाल्टी नए हैशकोड के साथ इशारा करते हैं जो वृद्धि के बाद ही मौजूद हैं। बाल्टियों की संख्या।
यदि आप 1.0 को कहने के लिए लोडिंग कारक सेट करते हैं, तो कुछ बहुत दिलचस्प हो सकता है।
मान लें कि आप अपने हैशमैप में एक ऑब्जेक्ट x जोड़ रहे हैं जिसका हैशकोड 888 है और आपके हैशमैप में बाल्टी हैशकोड का प्रतिनिधित्व करने के लिए स्वतंत्र है, इसलिए ऑब्जेक्ट x को बाल्टी में जोड़ा जाता है, लेकिन अब फिर से कहें कि क्या आप कोई ऑब्जेक्ट y जोड़ रहे हैं जिसका हैशकोड है यह भी 888 तो आपकी वस्तु y बाल्टी के अंत में निश्चित BUT के लिए जुड़ जाएगी ( क्योंकि बाल्टी कुछ भी नहीं हैं, लेकिन लिंक्लिस्ट कार्यान्वयन कुंजी, मूल्य और अगले भंडारण ) अब यह एक प्रदर्शन प्रभाव पड़ता है! चूँकि आपकी वस्तु y अब बाल्टी के सिर में मौजूद नहीं है, यदि आप लुकअप करते हैं तो लिया गया समय O (1) नहीं है।इस बार यह निर्भर करता है कि एक ही बाल्टी में कितने आइटम हैं। इसे हैश टक्कर कहा जाता है और यह तब भी होता है जब आपका लोडिंग फैक्टर 1 से कम हो।
लोअर लोड फैक्टर = अधिक फ्री बकेट्स = टक्कर की कम संभावना = उच्च प्रदर्शन = उच्च स्थान की आवश्यकता।
अगर मैं कहीं गलत हूं तो मुझे सुधारो।
LinkedListको संदर्भित किया जाता है Amortized Constant Execution Timeऔर इसे एक के +रूप में दर्शाया जाता हैO(1)+
से प्रलेखन :
लोड फैक्टर इस बात का एक पैमाना है कि हैश टेबल को अपनी क्षमता के बढ़ने से पहले कैसे भरा जाए
यह वास्तव में आपकी विशेष आवश्यकताओं पर निर्भर करता है, प्रारंभिक लोड कारक को निर्दिष्ट करने के लिए "अंगूठे का नियम" नहीं है।
HashMap DEFAULT_INITIAL_CAPACITY = 16 और DEFAULT_LOAD_FACTOR = 0.75f के लिए
इसका अर्थ है कि HashMap = 16 * 0.75 = 12 में सभी प्रविष्टियों की अधिकतम संख्या । जब तेरहवें तत्व HashMap की क्षमता (सरणी आकार) जोड़ा जाएगा दोगुना हो जाएगा! सही चित्रण ने इस सवाल का जवाब दिया:
छवि यहाँ से ली गई है:
https://javabypatel.blogspot.com/2015/10/what-is-load-factor-and-rehashing-in-hashmap.html
यदि बाल्टियाँ बहुत अधिक भर जाती हैं, तो हमें देखना होगा
एक बहुत लंबी जुड़ी हुई सूची।
और बात को हराने की तरह है।
तो यहाँ एक उदाहरण है जहाँ मेरे पास चार बाल्टियाँ हैं।
मेरे हाथसेट में अब तक हाथी और बेजर है।
यह एक बहुत अच्छी स्थिति है, है ना?
प्रत्येक तत्व में शून्य या एक तत्व होता है।
अब हम दो और तत्वों को अपने HashSet में डालते हैं।
buckets elements
------- -------
0 elephant
1 otter
2 badger
3 catयह भी बुरा नहीं है।
हर बाल्टी में केवल एक तत्व होता है। तो अगर मुझे पता है, क्या इसमें पांडा शामिल है?
मैं बहुत जल्दी बाल्टी नंबर 1 को देख सकता हूं और यह नहीं है
वहाँ और
मुझे पता है कि यह हमारे संग्रह में नहीं है।
अगर मुझे पता है कि अगर इसमें बिल्ली है, तो मैं बाल्टी को देखता हूं
संख्या 3,
मुझे बिल्ली मिलती है, मुझे बहुत जल्दी पता है कि क्या यह हमारे में है
संग्रह।
क्या हुआ अगर मैं कोआला जोड़ता हूं, तो यह अच्छा नहीं है।
buckets elements
------- -------
0 elephant
1 otter -> koala
2 badger
3 catशायद अब बाल्टी नंबर 1 के बजाय केवल देख रहे हैं
एक तत्व,
मुझे दो देखने की जरूरत है।
लेकिन कम से कम मुझे हाथी, बेजर और देखने की ज़रूरत नहीं है
बिल्ली।
अगर मुझे फिर से पांडा की तलाश है, तो यह केवल बाल्टी में हो सकता है
नंबर 1 और
मुझे कुछ और नहीं देखना है तो ओटर और
कोअला।
लेकिन अब मैंने बाल्टी नंबर 1 में मगरमच्छ डाल दिया और आप कर सकते हैं
शायद देखें कि यह कहाँ जा रहा है।
कि अगर बाल्टी नंबर 1 बड़ा और बड़ा हो रहा है और
बड़ा है, तो मैं मूल रूप से सभी के माध्यम से देख रहा हूँ
उन तत्वों को खोजने के लिए
कुछ है जो बाल्टी नंबर 1 में होना चाहिए।
buckets elements
------- -------
0 elephant
1 otter -> koala ->alligator
2 badger
3 catअगर मैं अन्य बाल्टियों में तार जोड़ना शुरू करूँ,
सही है, समस्या बस और हर में बड़ा हो जाता है
एक बाल्टी।
हम अपनी बाल्टियों को बहुत अधिक भरने से कैसे रोकेंगे?
इसका समाधान यह है कि
"the HashSet can automatically
resize the number of buckets."हैशसेट को पता चलता है कि बाल्टी मिल रही है
अधिक भरा।
यह सभी के लिए यह देखने का यह लाभ खो रहा है
तत्वों।
और यह सिर्फ और अधिक बाल्टी (आम तौर पर पहले से दोगुना) और पैदा करेगा
फिर तत्वों को सही बाल्टी में रखें।
तो यहाँ अलग से हमारा HashSet कार्यान्वयन है
चेनिंग। अब मैं एक "सेल्फ-रिसाइज़िंग हैशसेट" बनाने जा रहा हूं।
इस हैशसेट को एहसास होने वाला है कि बाल्टी हैं
बहुत भरा हुआ और
इसे और अधिक बाल्टी की जरूरत है।
loadFactor हमारे HashSet वर्ग का एक और क्षेत्र है।
loadFactor प्रति तत्वों की औसत संख्या का प्रतिनिधित्व करता है
बाल्टी,
ऊपर जो हम आकार बदलना चाहते हैं।
loadFactor अंतरिक्ष और समय के बीच एक संतुलन है।
यदि बाल्टियाँ बहुत अधिक भर जाती हैं तो हम आकार बदल देंगे।
यह समय लगता है, लेकिन
यदि बाल्टियाँ हैं तो यह हमें सड़क से नीचे का समय बचा सकती है
थोड़ा और खाली।
एक उदाहरण देखते हैं।
यहाँ एक HashSet है, हमने अब तक चार तत्व जोड़े हैं।
हाथी, कुत्ता, बिल्ली और मछली।
buckets elements
------- -------
0
1 elephant
2 cat ->dog
3 fish
4
5इस बिंदु पर, मैंने फैसला किया है कि लोडफैक्टर, द
सीमा,
बाल्टी प्रति तत्वों की औसत संख्या जो मैं ठीक हूं
के साथ, 0.75 है।
बाल्टियों की संख्या बकेट.लिफ्ट है, जो 6 है, और
इस बिंदु पर हमारे हैशट में चार तत्व हैं, इसलिए
वर्तमान आकार 4 है।
हम अपने हैशसेट का आकार बदल देंगे, यानी हम और बाल्टी जोड़ेंगे,
जब प्रति बाल्टी तत्वों की औसत संख्या पार हो जाती है
भारक।
यह तब है जब बकेट.लिफ्ट द्वारा विभाजित वर्तमान आकार है
लोडफैक्टर से अधिक।
इस बिंदु पर, प्रति बाल्टी तत्वों की औसत संख्या
4 को 6 से विभाजित किया गया है।
4 तत्वों, 6 बाल्टी, कि 0.67 है।
हम 0.75 की सीमा से कम हैं इसलिए हम कर रहे हैं
ठीक है।
हमें आकार बदलने की आवश्यकता नहीं है।
लेकिन अब हम कहते हैं कि हम वुडकॉक जोड़ते हैं।
buckets elements
------- -------
0
1 elephant
2 woodchuck-> cat ->dog
3 fish
4
5वुडकॉक बाल्टी नंबर 3 में समाप्त हो जाएगा।
इस बिंदु पर, वर्तमानाइज 5 है।
और अब प्रति बाल्टी तत्वों की औसत संख्या
बकेट.लिफ्ट द्वारा विभाजित विद्युत प्रवाह है।
5 तत्वों को 6 बाल्टी से विभाजित किया गया है जो 0.83 है।
और यह लोडफैक्टर से अधिक था जो 0.75 था।
इस समस्या को हल करने के क्रम में, बनाने के लिए
बाल्टी शायद थोड़ी
अधिक खाली ताकि संचालन यह निर्धारित करने की तरह हो कि क्या ए
बाल्टी में होता है
एक तत्व थोड़ा कम जटिल होगा, मैं आकार बदलना चाहता हूं
मेरे हशसेट।
हैशसेट का आकार बदलने के दो चरण होते हैं।
पहले मैं बाल्टियों की संख्या दोगुनी कर दूंगा, मेरे पास 6 बाल्टियाँ थीं,
अब मेरे पास 12 बाल्टियाँ होने वाली हैं।
यहाँ ध्यान दें कि लोडफ़ैक्टर जो मैंने 0.75 पर सेट किया है, वही रहता है।
लेकिन बाल्टियों की संख्या 12 है,
तत्वों की संख्या समान रही, 5 है।
5 को 12 से विभाजित किया गया है, यह लगभग 0.42 है, यह हमारे अधीन है
लोड फैक्टर,
तो हम अब ठीक हैं।
लेकिन हम ऐसा नहीं कर रहे हैं क्योंकि इनमें से कुछ तत्व अंदर हैं
अब गलत बाल्टी है।
मसलन, हाथी।
हाथी बाल्टी नंबर 2 में था क्योंकि की संख्या
हाथी में वर्ण
8 था।
हमारे पास 6 बाल्टियाँ हैं, 8 माइनस 6 2 है।
इसलिए यह नंबर 2 में समाप्त हो गया।
लेकिन अब जब हमारे पास 12 बाल्टी हैं, तो 8 मॉड 12 8 है, इसलिए
हाथी अब बाल्टी नंबर 2 में नहीं है।
हाथी बाल्टी नंबर 8 में है।
वुडकॉक के बारे में क्या?
वुडकुक वह था जिसने इस पूरी समस्या को शुरू किया।
वुडकॉक बाल्टी नंबर 3 में समाप्त हुआ।
क्योंकि 9 मॉड 6 3 है।
लेकिन अब हम 9 मॉड 12 करते हैं।
9 मॉड 12 9 है, वुडकॉक बाल्टी नंबर 9 पर जाता है।
और आप इस सब का फायदा देखें।
अब बकेट नंबर 3 में केवल दो तत्व हैं जबकि इससे पहले यह 3 था।
तो यहाँ हमारा कोड है,
जहाँ हमने अलग-अलग चैनिंग के साथ अपना हैशसेट रखा था
किसी भी आकार परिवर्तन नहीं किया।
अब, यहाँ एक नया कार्यान्वयन है जहाँ हम आकार बदलने का उपयोग करते हैं।
इस कोड के अधिकांश समान हैं,
हम अभी भी यह निर्धारित करने जा रहे हैं कि इसमें यह शामिल है या नहीं
पहले से ही मूल्य।
यदि ऐसा नहीं होता है, तो हम यह पता लगाएंगे कि यह किस बाल्टी में है
में और जाना चाहिए
फिर इसे उस बाल्टी में जोड़ें, इसे उस लिंक्डलिस्ट में जोड़ें।
लेकिन अब हम वर्तमान क्षेत्र में वृद्धि करते हैं।
currentSize वह क्षेत्र था जो संख्या का ट्रैक रखता था
तत्वों का हमारे HashSet में।
हम इसे बढ़ाने जा रहे हैं और फिर हम देखने जा रहे हैं
औसत लोड पर,
प्रति बाल्टी तत्वों की औसत संख्या।
हम यहाँ वह विभाजन करेंगे।
हमें यह सुनिश्चित करने के लिए यहां थोड़ी सी कास्टिंग करनी होगी
कि हम एक डबल मिलता है।
और फिर, हम उस औसत लोड की तुलना फ़ील्ड से करेंगे
जो मैंने निर्धारित किया है
उदाहरण के लिए, जब मैंने यह हैशट बनाया था, तो 0.75 था
भारक।
यदि औसत भार लोडफ़ैक्टर से अधिक है,
इसका मतलब है कि प्रति बाल्टी में बहुत सारे तत्व हैं
औसत, और मुझे नए सिरे से स्थापित करने की आवश्यकता है।
तो यहाँ है हमारी रीज़निंग करने की विधि का कार्यान्वयन
सभी तत्व।
सबसे पहले, मैं एक स्थानीय वैरिएबल बनाऊंगा जिसे ओल्डबकेट कहा जाता है।
जो कि वर्तमान में खड़े होने के कारण बाल्टियों का जिक्र है
इससे पहले कि मैं सब कुछ आकार बदलना शुरू कर दूं।
नोट मैं अभी तक लिंक की गई नई सूचियों को नहीं बना रहा हूँ।
मैं सिर्फ पुरानी बकेट्स के रूप में बाल्टी का नाम बदल रहा हूं।
अब याद रखें कि बाल्टी हमारी कक्षा में एक क्षेत्र थी, मैं जा रहा हूँ
अब एक नई सरणी बनाने के लिए
लिंक की गई सूचियों में, लेकिन इसमें कई तत्वों के दोगुने भाग होंगे
जैसा कि पहली बार किया था।
अब मुझे वास्तव में पुनर्व्याख्या करने की आवश्यकता है,
मैं पुराने सभी बाल्टी के माध्यम से पुनरावृत्ति करने जा रहा हूं।
OldBuckets में प्रत्येक तत्व स्ट्रिंग्स का एक लिंक्डलिस्ट है
वह एक बाल्टी है।
मैं उस बाल्टी के माध्यम से जाऊँगा और उसमें प्रत्येक तत्व प्राप्त करूँगा
बाल्टी।
और अब मैं इसे नए बकेट्स में फिर से डालने जा रहा हूं।
मुझे इसका हैशकोड मिलेगा।
मैं यह पता लगाऊंगा कि यह कौन सा सूचकांक है।
और अब मुझे नई बकेट मिलती है, नई लिंक्डलिस्ट की
तार और
मैं इसे उस नई बाल्टी में जोड़ दूंगा।
इसलिए पुन: जोड़ने के लिए, हैशसेट जैसा कि हमने देखा है लिंक्ड के ऐरे हैं
सूची, या बाल्टियाँ।
HashSet का आकार बदलने वाला स्वयं कुछ अनुपात का उपयोग करके महसूस कर सकता है
मैं n * 1.5 या n + (n >> 1) की एक टेबल का आकार चुनूंगा, यह .66666 ~ का एक लोड फैक्टर देगा, जो कि ज्यादातर सिस्टम पर धीमा है, खासकर पोर्टेबल सिस्टम पर जहां कोई विभाजन नहीं है हार्डवेयर।
capacity = N/0.75बता रहे हैं कि रिहा करने से बचने के लिए निर्दिष्ट करें , लेकिन मेरा प्रारंभिक विचार अभी निर्धारित थाload factor = 1। वहाँ उस दृष्टिकोण के लिए downsides होगा? लोड फैक्टर प्रभावितget()औरput()संचालन लागत क्यों होगा ?