जावा में तारों के आंतरिक प्रतिनिधित्व में परिवर्तन

प्रविष्टि

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

महत्वपूर्ण: 17 वें अपडेट में, जावा 7 ने अभी भी लेख के बारे में कुछ भी नहीं बदला है।

वर्णों के भाजित वर्ण सरणी []

स्ट्रिंग वर्ग के वर्तमान कार्यान्वयन में, 4 उदाहरण फ़ील्ड हैं: स्ट्रिंग वर्णों वाले वर्णों का एक char [] मान सरणी, int ऑफसेट मूल्य सरणी में उपयोग किए गए पहले वर्ण का सूचकांक है, int count उपयोग किए गए वर्णों की संख्या है, और int hash इस स्ट्रिंग के लिए परिकलित हैश कोड का कैश्ड मान है । जैसा कि आप देख सकते हैं, ज्यादातर मामलों में स्ट्रिंग में मानों की भरपाई होगी = 0 और गिनती = value.length। इस नियम का एकमात्र अपवाद तब संभव है जब कोई स्ट्रिंग viaString.substring विधि या इस पद्धति का उपयोग करने वाली किसी भी विधि (उदाहरण के लिए, विभाजन) को कॉल करके बनाई गई हो।

String.substring एक स्ट्रिंग बनाता है जो वर्ण को साझा करता है [] मूल स्ट्रिंग के साथ वर्णों की आंतरिक सरणी, जो अनुमति देता है:

1. मेमोरी को एक साथ उपयोग करके सहेजें;
2. String.substring विधि का निष्पादन समय स्थिर (O (1)) करें।

उसी समय, इस तरह के कार्यान्वयन के साथ, एक मेमोरी लीक संभव है: यदि आप एक बड़े स्ट्रिंग से एक छोटा सा विकल्प निकालते हैं और आपको अब एक बड़े स्ट्रिंग की आवश्यकता नहीं है, तो आपके पास मूल स्ट्रिंग के वर्णों के एक बड़े सरणी के लिए लिंक होगा। इससे बचने का एकमात्र तरीका कंस्ट्रक्टर नया स्ट्रिंग (स्ट्रिंग) को कॉल करना है, जो आपको वर्णों की सरणी की एक प्रति बनाने के लिए मजबूर करेगा, अर्थात, बड़े "माता-पिता" से अपने छोटे स्ट्रिंग को डिस्कनेक्ट करें।

Java 1.7.0_06 में, ऑफसेट और गिनती फ़ील्ड को स्ट्रिंग वर्ग से हटा दिया गया था। इसका अर्थ है कि हम अब और वर्णों को साझा नहीं कर सकते हैं। अब हम ऊपर वर्णित मेमोरी लीक के बारे में भूल सकते हैं और फिर कभी नए स्ट्रिंग (स्ट्रिंग) कंस्ट्रक्टर का उपयोग नहीं कर सकते हैं। एक दोष के रूप में, आपको हमेशा याद रखना चाहिए कि String.substring पद्धति में अब रैखिक जटिलता है जो उस निरंतरता के विपरीत है जो कभी हुआ करती थी।

हैश लॉजिक चेंज

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

जैसा कि आपने शायद देखा है, ये परिवर्तन केवल उस स्थिति के लिए सही होते हैं जब संग्रह कुंजी स्ट्रिंग होती है। यदि आप इन परिवर्तनों को सक्षम करना चाहते हैं, तो आपको सिस्टम गुण jdk.map.althashing.threshold का मान एक गैर-नकारात्मक मान पर सेट करना होगा (डिफ़ॉल्ट रूप से यह -1 है)। यह मान संग्रह के आकार की सीमा है, जिसके बाद नए हैशिंग एल्गोरिथ्म का उपयोग किया जाएगा। एक छोटा सुधार: हैश एल्गोरिथम केवल तभी बदला जाएगा जब पर्याप्त मेमोरी न हो। यदि संग्रह को आकार = 160 और jdk.map.althashing.threshold = 200 के साथ पुनर्वितरित किया गया था, तो हैशिंग विधि को तभी बदला जाएगा जब संग्रह का आकार 320 हो जाए।

स्ट्रिंग क्लास में अब एक हैश 32 () विधि है, जिसके परिणाम को इंट हैश 32 फ़ील्ड में कैश किया गया है। समान स्ट्रिंग्स के लिए हैश 32 () विधि का परिणाम अलग-अलग जेवीएम लॉन्च के लिए अलग-अलग हो सकता है (वास्तव में, यह लगभग हमेशा अलग होगा क्योंकि यह System.currentTimeMillis () और प्रारंभ के लिए System.nanoTime के लिए दो कॉल का उपयोग करता है। नतीजतन, अलग-अलग प्रोग्राम लॉन्च के लिए एक ही संग्रह पर चलना अलग हो सकता है। वास्तव में, मैं इस पद्धति से थोड़ा आश्चर्यचकित था। अगर हैशकोड पद्धति का वास्तविक कार्यान्वयन पर्याप्त रूप से काम करता है तो हमें इसकी आवश्यकता क्यों है? मैंने यह जांचने का निर्णय लिया कि हैश 32 () पद्धति का उपयोग करके कितनी टक्कर प्राप्त की जाएगी। String.hash32 () विधि सार्वजनिक नहीं है, लेकिन मैंने इसे कैसे कॉल किया, यह निर्धारित करने के लिए हाशप वर्ग के कार्यान्वयन को देखा। उत्तर: sun.misc.Hashing.stringHash32 (स्ट्रिंग)। String.hashCode विधि का उपयोग करके एक से अधिक टकराव की तुलना में, एक मिलियन पंक्तियों वाले परीक्षण पर विधि ने 304 टकराव लौटाए। मुझे लगता है कि हमें और सुधार की प्रतीक्षा करनी चाहिए।

नए हैश तर्क बहु-थ्रेडेड कोड को गंभीरता से प्रभावित कर सकते हैं

निम्न कक्षाओं में हैशिंग को लागू करते समय ओरेकल ने एक गलती की: हैशपॉश, हैशटेबल, हैशसेट, लिंक्डहाशसेट, वीकहाशमैप। केवल ConcurentHashMap में यह त्रुटि नहीं है। समस्या यह है कि सभी गैर-समानांतर वर्गों में अब एक क्षेत्र है:

/** *            . */ transient final int hashSeed = sun.misc.Hashing.randomHashSeed(this); 

इसका मतलब है कि हर बार जब आप उपरोक्त संग्रह बनाते हैं, तो sun.misc.Hashing.randomHashSeed पद्धति को बुलाया जाएगा। बदले में, randomHashSeed पद्धति java.util.Random.nextInt विधि को कॉल करती है। जैसा कि आप जानते हैं, रैंडम वर्ग मल्टीथ्रेडिंग के साथ बहुत अनुकूल नहीं है: इसमें निजी अंतिम एटॉमिकलॉन्ग बीज क्षेत्र शामिल है। एटॉमिक्स औसत लोड के तहत अच्छी तरह से काम करते हैं, लेकिन खराब लोड के तहत खराब।

परिणामस्वरूप, HTTP / JSON / XML को संसाधित करने वाले कई अत्यधिक लोड किए गए वेब अनुप्रयोग इस त्रुटि से प्रभावित हो सकते हैं, क्योंकि लगभग सभी ज्ञात पार्सर (पार्सर) प्रभावित वर्गों में से कम से कम एक का उपयोग करते हैं। ये सभी पार्स नेस्टेड मैप कलेक्शन बना सकते हैं, जिससे प्रति सेकंड बनाए गए मैप कलेक्शन की संख्या बढ़ जाएगी।

इस समस्या को कैसे हल करें?

1. समवर्ती हाशम पथ: यादृच्छिकहैश विधि को तभी कॉल करें जब सिस्टम गुण jdk.map.althashing.threshold परिभाषित किया गया हो। हालाँकि, यह केवल JDK कर्नेल डेवलपर्स के लिए उपलब्ध है।

 /** *            . */ private transient final int hashSeed = randomHashSeed(this); private static int randomHashSeed(ConcurrentHashMap instance) { if (sun.misc.VM.isBooted() && Holder.ALTERNATIVE_HASHING) { return sun.misc.Hashing.randomHashSeed(instance); } return 0; } 

2. हैकर तरीका: वर्ग sun.misc.Hashing बदल जाते हैं। अति हतोत्साहित। यदि आप अभी भी ऐसा करने का निर्णय लेते हैं, तो आप ऐसा कर सकते हैं: java.util। आयामी वर्ग अंतिम नहीं है। आप इसका विस्तार कर सकते हैं और इसकी अगली विधि को ओवरराइड कर सकते हैं, उदाहरण के लिए, एक स्थिर मान। तब आपको फ़ील्ड को बदलने की आवश्यकता है। sun.misc.Hashing.Holder.SEED_MAKER इसे रैंडम से विरासत में मिली अपनी कक्षा में सेट करके। चिंता न करें कि यह क्षेत्र निजी है, स्थिर और अंतिम है - प्रतिबिंब आपको मदद करेगा।

सारांश

• Java 1.7.0_06 से शुरू होकर, String.substring विधि हमेशा प्रत्येक स्ट्रिंग बनाने के लिए चार [] वर्ण का एक नया सरणी बनाता है। इसका मतलब है कि अब इस पद्धति में पिछले संस्करणों की तरह निरंतरता की तुलना में रैखिक जटिलता है। इस परिवर्तन के परिणामस्वरूप, स्ट्रिंग पहले की तुलना में 4 बाइट्स कम हो जाती है, और यह गारंटी दी जाती है कि String.substring विधि के कारण होने वाली मेमोरी लीक समाप्त हो जाती है।
• इसी अद्यतन के साथ, हैशिंग के लिए एक दूसरी विधि, जिसे हैश 32 कहा जाता है, स्ट्रिंग कक्षा में दिखाई दी। यह विधि सार्वजनिक नहीं है और केवल sun.misc.Hashing.stringHash32 (स्ट्रिंग) विधि को कॉल करके प्रतिबिंब के बिना पहुँचा जा सकता है। JDK 7 में हैश-आधारित संग्रहों द्वारा इस पद्धति का उपयोग किया जाता है यदि उनका आकार सिस्टम गुण jdk.map.althashing.threshold के मान से अधिक हो। यह एक प्रयोगात्मक विधि है, और मैं अपने कोड में इसका उपयोग करने की अनुशंसा नहीं करता हूं।
• जावा 1.7.0_06 के साथ शुरू, सभी मानक गैर-मल्टीथ्रेडेड संग्रह में नए हैशिंग एल्गोरिथ्म के कारण अवांछनीय दुष्प्रभाव होता है। यह त्रुटि केवल उन मल्टीथ्रेड अनुप्रयोगों में स्वयं प्रकट होती है जो प्रति सेकंड कई मानचित्र संग्रह बनाते हैं।

खुद से

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

.NET में, स्ट्रिंग्स शुरू में स्थिर नहीं थे। यहां एरिक लिपर्ट के एक दिलचस्प लेख की एक कड़ी है, जिसमें उन्होंने विस्तार से बताया कि ऐसा क्यों है।

पढ़ने के लिए धन्यवाद।
मुझे उम्मीद है कि यह लेख मददगार रहा है।