👇 💤 🔑 जावा: चीजें जो एक अनुभवी डेवलपर के लिए उत्सुक लग सकती हैं 📆 ➿ 🦓

दिन का अच्छा समय!

यह लेख एक अन्य लेखक द्वारा "थिंग्स यू [शायद] डोंट नॉट अबाउट जावा" के प्रकाशन के मद्देनजर लिखा गया था, जिसे मैं "शुरुआती के लिए" के रूप में वर्गीकृत करूंगा। उस पर पढ़ना और टिप्पणी करना, मैंने महसूस किया कि बहुत सी दिलचस्प चीजें हैं जो मैंने सीखीं, पहले से ही जावा में एक वर्ष से अधिक समय तक प्रोग्रामिंग। शायद ये बातें किसी और को उत्सुक लगेंगी।

तथ्य जो, मेरे दृष्टिकोण से, शुरुआती के लिए उपयोगी हो सकते हैं, मैंने "स्पॉइलर" में हटा दिया। कुछ चीजें अभी भी अधिक अनुभवी लोगों के लिए दिलचस्प हो सकती हैं। उदाहरण के लिए, मुझे खुद नहीं पता था कि बूलियन.शशकोड (सच्चा) == 1231 और बूलियन.शशकोड (असत्य) == 1237 लेख लिखने के समय तक।

शुरुआती के लिए

बुलियन.शशकोड (सच) == 1231
बूलियन.शशकोड (झूठी) == 1237
Float.hashCode (मान) == Float.floatToIntBits (मान)
Double.hashCode (मान) - पहले और दूसरे 32-बिट हाफ़ के xor डबल.doubleToLongBits (मान)

Object.hashCode () अब मेमोरी में किसी ऑब्जेक्ट का पता नहीं है

अस्वीकरण: यह ओरेकल (हॉटस्पॉट) से एक जेवीएम विवरण है।

एक बार तो ऐसा था।

Jdk1.2.1 / डॉक्स / एपी / जावा / लैंग / Object.html # हैशकोड () से:

जितना हो सके व्यावहारिक रूप से, क्लास ऑब्जेक्ट द्वारा परिभाषित हैशकोड विधि अलग-अलग वस्तुओं के लिए अलग-अलग पूर्णांक लौटाती है। (यह आमतौर पर ऑब्जेक्ट के आंतरिक पते को पूर्णांक में परिवर्तित करके लागू किया जाता है, लेकिन यह कार्यान्वयन तकनीक JavaTM प्रोग्रामिंग भाषा द्वारा आवश्यक नहीं है।)

तब उन्होंने इसके लिए मना कर दिया था। यह javadoc jdk 12 के लिए कहता है।

vladimir_dolzhenko ने सुझाव दिया कि पुराने व्यवहार -XX का उपयोग करके बहाल किया जा सकता है: हैशकोड = 4। और व्यवहार परिवर्तन स्वयं जावा 1.2 संस्करण से लगभग था।

Integer.valueOf (15) == Integer.valueOf (15); Integer.valueOf (128)! = Integer.valueOf (128)

अस्वीकरण: यह jls का हिस्सा है।

यह स्पष्ट है कि जब दो आवरणों की तुलना == (! =) संचालक से की जाती है, तो कोई ऑटोबॉक्सिंग नहीं होता है। सामान्यतया, यह पहली समानता है जो भ्रमित करती है। तथ्य यह है कि पूर्णांक मानों के लिए i: -129 <i <128 पूर्णांक आवरण ऑब्जेक्ट्स कैश्ड हैं। इसलिए, इस सीमा से i के लिए, Integer.valueOf (i) हर बार एक नई वस्तु नहीं बनाता है, लेकिन पहले से ही बनाया गया रिटर्न देता है। क्योंकि मैं इस श्रेणी में नहीं आता, Integer.valueOf (i) हमेशा एक नई वस्तु बनाता है। इसलिए, यदि आप बारीकी से निगरानी नहीं करते हैं कि वास्तव में क्या और कैसे इसकी तुलना की जाती है, तो आप कोड लिख सकते हैं जो काम करने लगता है और यहां तक कि परीक्षणों के साथ कवर किया जाता है, लेकिन एक ही समय में इस तरह के "रेक" के साथ।

ओरेकल (हॉटस्पॉट) से jvm में, कैशिंग की ऊपरी सीमा को "java.lang.Integer.IntegerCache.high" संपत्ति के माध्यम से बदला जा सकता है।

कुछ मामलों में, किसी अन्य वर्ग के आदिम या स्ट्रिंग अंतिम स्थिर क्षेत्रों के मूल्यों का संकलन समय पर किया जाता है

यह भ्रामक लगता है, और बयान थोड़ा लंबा है। अर्थ यही है। यदि हमारे पास एक वर्ग है जो तात्कालिक आरंभीकरण के साथ अंतिम स्थिर क्षेत्रों के रूप में आदिम प्रकार या तार के स्थिरांक को परिभाषित करता है,

class AnotherClass { public final static String CASE_1 = "case_1"; public final static String CASE_2 = "case_2"; }

जब अन्य वर्गों में उपयोग किया जाता है,

 class TheClass { // ... public static int getCaseNumber(String caseName) { switch (caseName) { case AnotherClass.CASE_1: return 1; case AnotherClass.CASE_2: return 2; default: throw new IllegalArgumentException("value of the argument caseName does not belong to the allowed value set"); } } }

इन स्थिरांक ("case_1", "case_2") के मूल्यों का संकलन समय पर किया जाता है। और उन्हें कोड में मानों के रूप में डाला जाता है, न कि लिंक के रूप में। यही है, अगर हम पुस्तकालय से ऐसे स्थिरांक का उपयोग करते हैं, और फिर हमें पुस्तकालय का एक नया संस्करण मिलता है जिसमें स्थिरांक के मूल्य बदल गए हैं, हमें परियोजना को फिर से तैयार करना चाहिए। अन्यथा, पुराने निरंतर मान कोड में उपयोग किए जा सकते हैं।

यह व्यवहार उन सभी स्थानों पर देखा जाता है जहां निरंतर अभिव्यक्तियों का उपयोग करने की आवश्यकता होती है (उदाहरण के लिए, स्विच / केस), या संकलक को अभिव्यक्ति को निरंतर में बदलने की अनुमति है और वह ऐसा कर सकता है।

जैसे ही हम स्थैतिक ब्लॉक में आरंभीकरण को स्थानांतरित करके तत्काल प्रारंभ को हटाते हैं, इन फ़ील्ड्स को निरंतर अभिव्यक्तियों में उपयोग नहीं किया जा सकता है।

शुरुआती के लिए

कुछ शर्तों के तहत, कचरा कलेक्टर कभी नहीं चल सकता है।

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

किसी विशिष्ट वस्तु के लिए अंतिम रूप () विधि को एक बार और केवल एक बार कहा जा सकता है।

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

वह धारा जिसमें अंतिम रूप दिया जाएगा () कहा जाएगा, पहले से ज्ञात नहीं है

यह केवल गारंटी है कि यह धागा मुख्य कार्यक्रम द्वारा दिखाई देने वाले तालों से मुक्त होगा।

वस्तुओं पर एक ओवरराइड फ़ाइनलीज़ () विधि की उपस्थिति कचरा संग्रहण प्रक्रिया को धीमा कर देती है

सतह पर क्या है वस्तु उपलब्धता के लिए दोहरी जांच की आवश्यकता है - अंतिम बार कॉल करने से पहले एक बार (), निम्नलिखित में से किसी एक में कचरा संग्रह चलता है।

अंतिम रूप में गतिरोध से लड़ना वास्तव में कठिन है ()

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

Object.finalize () जावा के संस्करण 9 को पदावनत के रूप में चिह्नित किया गया है!

जो कि आश्चर्यजनक नहीं है, ऊपर वर्णित बारीकियों को देखते हुए।

क्लासिक आलसी सिंगलटन आरंभीकरण: डबल लॉकिंग की आवश्यकता

इस विषय पर एक गलत धारणा है कि निम्नलिखित दृष्टिकोण (डबल-चेक मुहावरा), जो बहुत तार्किक लगता है, हमेशा काम करता है:

 public class UnsafeDCLFactory { private Singleton instance; public Singleton get() { if (instance == null) { // read 1, check 1 synchronized (this) { if (instance == null) { // read 2, check 2 instance = new Singleton(); } } } return instance; // read 3 } }

हम देखते हैं कि क्या वस्तु बनाई गई है (1 पढ़ें, 1 देखें)। यदि हां, तो इसे वापस कर दें। यदि नहीं, तो लॉक सेट करें, सुनिश्चित करें कि ऑब्जेक्ट नहीं बना है, ऑब्जेक्ट बनाएं (लॉक हटा दिया गया है), और ऑब्जेक्ट वापस करें।

निम्नलिखित कारणों से दृष्टिकोण काम नहीं करता है। ~~(1 पढ़ें, 1 चेक करें) और (3 पढ़ें) सिंक में नहीं हैं।~~ जावा मेमोरी मॉडल की अवधारणा के अनुसार, किसी अन्य थ्रेड में किए गए परिवर्तन हमारे थ्रेड को तब तक दिखाई नहीं दे सकते हैं जब तक हम सिंक्रनाइज़ नहीं करते हैं। टिप्पणी के लिए धन्यवाद mk2 , यहाँ समस्या का सही वर्णन है:

हां, read1 और read3 सिंक्रनाइज़ नहीं हैं, लेकिन समस्या किसी अन्य थ्रेड में नहीं है। और तथ्य यह है कि असंबद्ध रीडिंग को फिर से व्यवस्थित किया जा सकता है, अर्थात। read1! = null, लेकिन read3 == null। और एक ही समय में, "उदाहरण = नए सिंगलटन ();" के कारण हम ऑब्जेक्ट का संदर्भ प्राप्त कर सकते हैं इससे पहले कि यह पूरी तरह से निर्माण किया गया था, और यह वास्तव में दूसरे धागे के साथ एक सिंक्रनाइज़ेशन समस्या है, लेकिन read1 और read3 नहीं, लेकिन read3 और पहुंच सदस्यों को उदाहरण के लिए।

यह या तो पढ़ने के दौरान सिंक्रनाइज़ेशन जोड़कर, या उस चर को चिह्नित करके व्यवहार किया जाता है जिसमें सिंगलटन का लिंक अस्थिर रहता है। (वाष्पशील के साथ समाधान केवल जावा 5+ के साथ काम करता है। इससे पहले, जावा में इस स्थिति में अनिश्चितता के साथ एक मेमोरी मॉडल था।) यहां एक कार्यशील संस्करण है (अतिरिक्त अनुकूलन के साथ - स्थानीय चर `res` अस्थिर क्षेत्र से रीड की संख्या को कम करने के लिए जोड़ा गया था)।

 public class SafeLocalDCLFactory { private volatile Singleton instance; public Singleton getInstance() { Singleton res = instance; // read 1 if (res == null) { // check 1 synchronized (this) { res = instance; // read 2 if (res == null) { // check 2 res = new Singleton(); instance = res; } } } return res; } }

कोड यहाँ से लिया जाता है , अलेक्सी शिपिलेव की साइट से। इस समस्या पर अधिक विवरण इस पर पाया जा सकता है।

"इनिशियलाइज़ेशन-ऑन-डिमांड होल्डर मुहावरा" - एक बहुत ही सुंदर "आलसी" सिंगलटन की आरंभीकरण

जावा कक्षाओं (क्लास ऑब्जेक्ट्स) को केवल आवश्यकतानुसार और निश्चित रूप से केवल एक बार आरम्भ करता है। और आप इसका फायदा उठा सकते हैं! इनिशियलाइज़ेशन-ऑन-डिमांड होल्डर आइडियल मैकेनिज्म बस यही करता है। (कोड यहाँ से है ।)

 public class Something { private Something() {} private static class LazyHolder { static final Something INSTANCE = new Something(); } public static Something getInstance() { return LazyHolder.INSTANCE; } }

LazyHolder क्लास को पहली बार Some.getInstance () कहा जाता है। जेवीएम यह सुनिश्चित करेगा कि यह केवल एक बार होता है और इसके अलावा, बहुत कुशलता से - यदि वर्ग पहले से ही आरंभिक है, तो कोई हेडहेड नहीं होगा। तदनुसार, LazyHolder.INSTANCE को एक बार "आलसी" और थ्रेड-सुरक्षित भी शुरू किया जाएगा।

ओवरहेड के बारे में कल्पना का टुकड़ा

यदि यह इनिशियलाइज़ेशन प्रक्रिया सामान्य रूप से पूरी हो जाती है और क्लास ऑब्जेक्ट पूरी तरह से इनिशियलाइज़ हो जाता है और उपयोग के लिए तैयार हो जाता है, तो इनिशियलाइज़ेशन प्रक्रिया का मंगलाचरण अब आवश्यक नहीं है और इसे कोड से समाप्त किया जा सकता है - उदाहरण के लिए, इसे पैच करके या फिर कोड रीजनिंग करके ।
स्रोत।

सामान्यतया, सिंगलेट्स को सर्वश्रेष्ठ अभ्यास नहीं माना जाता है।

सामग्री खत्म नहीं हुई है। इसलिए, यदि हाथ "पहुंच" और जो पहले से ही लिखा गया है, वह मांग में होगा, तो मैं इस विषय पर कुछ और लिखूंगा।

रचनात्मक टिप्पणियों के लिए धन्यवाद। लेख में कई स्थानों को सर्गेई-गोरोस्ताव , vladimir_dolzhenko , OlehKurpiak , mk2 के लिए धन्यवाद दिया गया था।

जावा: चीजें जो एक अनुभवी डेवलपर के लिए उत्सुक लग सकती हैं