स्ट्रिंग में परिवर्तन। जावा 7

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

अनुकूलित String.split () विधि

एकल-वर्ण पैरामीटर के लिए पंक्ति विभाजन विधि तेज़ हो गई है। अब विधि बिल्कुल भी रेगेक्सपी का उपयोग नहीं करेगी और इंडेक्सऑफ लूप में लागू होगी।
यह था :

public String[] split(String regex, int limit) { return Pattern.compile(regex).split(this, limit); } 

यह बन गया :

 public String[] split(String regex, int limit) { if (((regex.value.length == 1 && ".$|()[{^?*+\\".indexOf(ch = regex.charAt(0)) == -1) || ...)) { ... while ((next = indexOf(ch, off)) != -1) { ... } ... return result; } return Pattern.compile(regex).split(this, limit); } 

2 फ़ील्ड निकाले गए

7 वें जावा के 6 वें अपडेट से शुरू होकर, 2 क्षेत्रों को पंक्ति वर्ग से हटा दिया गया था:

 private int offset; private int count; 

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

नई हैश एल्गोरिथ्म

 private transient int hash32 = 0; int hash32() { int h = hash32; if (0 == h) { // harmless data race on hash32 here. h = sun.misc.Hashing.murmur3_32(HASHING_SEED, value, 0, value.length); // ensure result is not zero to avoid recalcing h = (0 != h) ? h : 1; hash32 = h; } return h; } 

2 हटाए गए फ़ील्ड के बजाय, 1 नया पूर्णांक दिखाई दिया - hash32। एक स्ट्रिंग के नए हैश को स्टोर करने के लिए डिज़ाइन किया गया। नए हैश का उपयोग किया जाता है, उदाहरण के लिए, हैशमैप में :

 transient int hashSeed = useAltHashing ? sun.misc.Hashing.randomHashSeed(this) : 0; final int hash(Object k) { int h = hashSeed; if (0 != h && k instanceof String) { return sun.misc.Hashing.stringHash32((String) k); } ... } 

नए हैशिंग एल्गोरिथ्म को स्ट्रिंग्स के लिए हैश के वितरण में सुधार करना चाहिए (मुझे यह नहीं मिला कि यह विशेष रूप से मौजूदा एक से बेहतर क्या है, कोई मुझे टिप्पणियों में बता सकता है)। नया हैश फ़ंक्शन डिफ़ॉल्ट रूप से अक्षम है और इसे सक्षम करने के लिए आपको "jdk.map.althashing.threshold" विकल्प की आवश्यकता होगी। हालाँकि, 6 वें अपडेट के जारी होने के कुछ ही समय बाद, यह पता चला कि अत्यधिक प्रतिस्पर्धी बहु-थ्रेडेड वातावरण में, क्योंकि sun.misc.Hashing.randomHashSeed () विधि है, हैशप सेट बनाना अद्यतन से पहले की तुलना में बहुत धीमा है, क्योंकि randomHashSeed पद्धति रैंडम के अंदर का उपयोग करती है, जो इसके अंदर है। कतार एटॉमिकलॉन्ग पर आधारित है, जो प्रदर्शन की समस्याओं का कारण बनी।
अपडेट 40 से शुरू होकर, बग पहले ही तय हो चुका है।

जावा 8 अपडेट

जैसा कि मुझे बताया गया था, जावा 8 में, नए हैश एल्गोरिथ्म को हटा दिया गया था।

अधिक विभाजन अनुकूलन

ऐसा हुआ कि अधिकांश डेवलपर्स मानक कक्षाओं के आंतरिक तरीकों पर शायद ही कभी गौर करते हैं। फिर भी, अंदर आप अनुकूलन के लिए बहुत गुंजाइश पा सकते हैं। विभाजन रेखा विधि के साथ भी यही हुआ। कोड के महत्वपूर्ण खंडों के बजाय:

 someString.split("[_,;,-]"); 

कर सकते हैं:

 private static final Pattern PATTERN = Pattern.compile("[_,;,-]"); PATTERN.split(someString); 

और विभाजन विधि के प्रदर्शन लाभ के बारे में दो बार प्राप्त करें।