विषयों की एक श्रृंखला की निरंतरता में "जावा के बारे में मौलिक बातें, जो जानने लायक हैं, लेकिन बहुतों को नहीं पता है।" पिछला विषय: उदाहरणों में बाइनरी संगतता और न केवल

जावा मेमोरी मॉडल एक ऐसी चीज़ है जो किसी भी जावा डेवलपर के कोड को प्रभावित करती है। हालांकि, काफी कुछ इस महत्वपूर्ण विषय के ज्ञान की उपेक्षा करते हैं, और कभी-कभी उनके अनुप्रयोगों के पूरी तरह से अप्रत्याशित व्यवहार का सामना करते हैं, जिसे जेएमएम डिवाइस की विशेषताओं द्वारा सटीक रूप से समझाया गया है। उदाहरण के लिए डबल-चेक किए गए लॉकिंग पैटर्न का बहुत ही सामान्य और गलत कार्यान्वयन:

public class Keeper { private Data data = null; public Data getData() { if(data == null) { synchronized(this) { if(data == null) { data = new Data(); } } } return data; } }

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

थोड़ा इतिहास

1995 में जावा 1.0 के साथ JMM का पहला संस्करण दिखाई दिया। यह एक सुसंगत और क्रॉस-प्लेटफॉर्म मेमोरी मॉडल बनाने का पहला प्रयास था। दुर्भाग्य से, या सौभाग्य से, इसमें कई गंभीर खामियां और गलतफहमियां थीं। सबसे दुखद समस्याओं में से एक अंतिम क्षेत्रों के लिए किसी भी गारंटी की कमी थी। यही है, एक धागा एक अंतिम फ़ील्ड के साथ एक ऑब्जेक्ट बना सकता है, और दूसरा धागा इस अंतिम फ़ील्ड में मान नहीं देख सकता है। यहां तक कि java.lang.String वर्ग को भी इससे अवगत कराया गया। इसके अलावा, इस मॉडल ने संकलक को कई प्रभावी अनुकूलन करने की अनुमति नहीं दी, और जब बहु-थ्रेडेड कोड लिखते हैं, तो यह सुनिश्चित करना मुश्किल था कि यह वास्तव में अपेक्षा के अनुरूप काम करेगा।

इसलिए, 2004 में, JSR 133 जावा 5 में दिखाई दिया, जिसने मूल मॉडल की कमियों को समाप्त कर दिया। हम बात करेंगे कि क्या हुआ।

atomicity

हालाँकि बहुत से लोग यह जानते हैं, इसलिए मुझे यह याद रखना आवश्यक है कि कुछ प्लेटफार्मों पर कुछ रिकॉर्डिंग ऑपरेशन गैर-परमाणु हो सकते हैं। यही है, जबकि एक मान एक धागे से दर्ज किया जा रहा है, दूसरे धागे में किसी प्रकार की मध्यवर्ती स्थिति देखी जा सकती है। आपको एक उदाहरण के लिए दूर तक जाने की आवश्यकता नहीं है - एक ही लंबे और दोहरे के रिकॉर्ड, यदि उन्हें अस्थिर घोषित नहीं किया गया है, तो उन्हें परमाणु नहीं होना चाहिए और कई प्लेटफार्मों पर दो ऑपरेशनों में लिखे गए हैं: सबसे महत्वपूर्ण और निचले 32 बिट्स अलग से। ( मानक देखें)

दृश्यता

पुराने JMM में, चलने वाले प्रत्येक धागे का अपना कैश (काम करने वाली मेमोरी) होता था, जिसमें वस्तुओं की कुछ स्थिति जिसे इस धागे में हेरफेर किया गया था, संग्रहीत किया गया था। कुछ शर्तों के तहत, कैश को मुख्य मेमोरी के साथ सिंक्रनाइज़ किया गया था, लेकिन फिर भी, समय का एक महत्वपूर्ण हिस्सा, मुख्य मेमोरी में और कैश में मूल्यों को अलग कर सकता है।

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

यह ध्यान रखना महत्वपूर्ण है कि, समान C ++ के विपरीत, "आउट-ऑफ-थिन-एयर" मान कभी नहीं लिया जाता है: किसी भी चर के लिए, यह सच है कि धारा द्वारा मनाया गया मान या तो इसे सौंपा गया था या एक मूल्य है डिफ़ॉल्ट रूप से।

पुन: क्रम

लेकिन यह, जैसा कि वे कहते हैं, सब कुछ नहीं है। ~~यदि आप अभी एक आदेश देते हैं, तो आपके निर्देशों को मुफ्त में स्वैप किया जाएगा!~~ अनुदेश निष्पादन को अनुकूलित करने में प्रोसेसर अविश्वसनीय रूप से फुर्तीले होते हैं। कंपाइलर और जेआईटी भी इसमें मदद करते हैं। उल्लेखनीय प्रभावों में से एक यह हो सकता है कि क्रियाएं एक धागे से की जाती हैं, दूसरा धागा एक अलग क्रम में दिखाई देगा। यह वाक्यांश समझना काफी मुश्किल है, बस इसे पढ़ना, इसलिए मैं एक उदाहरण दूंगा। ऐसे कोड होने दें:

 public class ReorderingSample { boolean first = false; boolean second = false; void setValues() { first = true; second = true; } void checkValues() { while(!second); assert first; } }

और इस कोड में, checkValues विधि को एक थ्रेड से कहा जाता है, और checkValues को दूसरे थ्रेड से कहा जाता है। ऐसा लगता है कि कोड को समस्याओं के बिना चलना चाहिए, क्योंकि second फ़ील्ड first फ़ील्ड की तुलना में बाद में true सेट होता true , और इसलिए जब (अधिक सटीक, यदि) हम देखते हैं कि दूसरा फ़ील्ड सत्य है, तो पहला भी ऐसा होना चाहिए। लेकिन वहाँ यह था।

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

TSO वाली मशीनों पर (जिस पर x86 लागू होता है) यह दिखाना काफी कठिन है
तोड़ना। यह कुछ ARM'e या पर दिखाया जा सकता है
PowerPC। आप अल्फा को भी संदर्भित कर सकते हैं - सबसे कमजोर ऑर्डरिंग नियमों के साथ प्रोसेसर। अल्फा कंपाइलर्स और ऑपरेटिंग सिस्टम गुठली के डेवलपर्स के लिए एक बुरा सपना था। यह सौभाग्य की बात है कि उनकी मृत्यु हो गई। नेट पर आप इसके बारे में कहानियों के टन पा सकते हैं।

क्लासिक उदाहरण:
(एक उदाहरण उपरोक्त के समान है - लेखक की टिप्पणी)
... x86 पर यह हमेशा सही ढंग से काम करेगा, क्योंकि अगर आपने देखा
"बी" में स्टोर करें, आप देखेंगे और "ए" में स्टोर करेंगे।

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

इसलिए, हमारे मूल उदाहरण पर वापस जाएं और समझें कि कैसे पुन: व्यवस्थित करना इसे बर्बाद कर सकता है। कंस्ट्रक्टर में हमारे Data वर्ग को कुछ बहुत तुच्छ गणनाएँ नहीं करने दें और, सबसे महत्वपूर्ण बात, गैर-अंतिम क्षेत्रों में कुछ मान लिखें:

 public class Data { String question; int answer; int maxAllowedValue; public Data() { this.answer = 42; this.question = reverseEngineer(this.answer); this.maxAllowedValue = 9000; } }

यह पता चला है कि थ्रेड जो पहले उस data == null पता लगाता है data == null निम्न कार्य करेगा:

एक नई वस्तु के लिए स्मृति आवंटित करें
Data वर्ग का निर्माता Data जाएगा Data
Data वर्ग के answer क्षेत्र में 42 लिखता है
क्लास Data के question क्षेत्र में कुछ लाइन लिखेंगे
Data श्रेणी के maxAllowedValue फ़ील्ड में मान 9000 लिखता है
Keeper वर्ग के data क्षेत्र में नव निर्मित वस्तु को लिखता है

क्या आप पकड़ महसूस करते हैं? इससे पहले कि खंड 3-5 में क्या हुआ है, यह देखने से पहले कि खंड 6 में क्या हुआ है, यह देखने से कुछ भी नहीं रोकता है। नतीजतन, यह थ्रेड ऑब्जेक्ट को एक गलत स्थिति में देखेगा जब उसके फ़ील्ड अभी तक सेट नहीं किए गए हैं। यह, ज़ाहिर है, किसी के अनुरूप नहीं होगा, और इसलिए नियमों का एक सख्त सेट है जिसके द्वारा अनुकूलन करने के लिए ऑप्टिमाइज़र / कंपाइलर / आपकी बुराई डबल के लिए मना किया जाता है।

क्या होता है-पहले

परिभाषा

इन सभी नियमों को तथाकथित होने से पहले संबंधों का उपयोग करके परिभाषित किया गया है। इसे निम्नानुसार परिभाषित किया गया है:

चलो एक धारा एक्स और एक धारा वाई (जरूरी नहीं कि धारा एक्स से अलग हो)। और ऑपरेशन ए (थ्रेड एक्स पर चल रहा है) और बी (थ्रेड वाई पर चल रहा है) होने दें।

इस मामले में, ए होता है-बी से पहले का अर्थ है कि ऑपरेशन ए के क्षण से पहले थ्रेड एक्स द्वारा किए गए सभी परिवर्तन और इस ऑपरेशन के बी के संचालन के बाद और इस ऑपरेशन के निष्पादन के समय थ्रेड वाई को दिखाई देने वाले परिवर्तन दिखाई देते हैं।

शब्दों में, इस तरह की परिभाषा को बहुत अच्छी तरह से नहीं माना जा सकता है, इसलिए मैं थोड़ा समझाता हूं। आइए सबसे सरल मामले से शुरू करें जहां धारा केवल एक है, अर्थात, X और Y समान हैं। एक सूत्र के अंदर, जैसा कि हमने पहले ही कहा है, कोई समस्या नहीं है, क्योंकि ऑपरेशन एक-दूसरे के सापेक्ष होते हैं-उस क्रम के अनुसार जिसमें वे स्रोत कोड (प्रोग्राम ऑर्डर) में इंगित किए जाते हैं। एक बहु-थ्रेडेड मामले के लिए, सब कुछ कुछ अधिक जटिल है, और यहां बिना ... चित्रों का पता नहीं लगाया जा सकता है। और यहाँ वह है:

यहां बाईं ओर, उन कार्यों को जो कि स्ट्रीम Y को देखने की गारंटी है, हरे रंग में चिह्नित हैं और जो लाल रंग में नहीं दिख सकते हैं। दाईं ओर, उन ऑपरेशनों को लाल रंग में चिह्नित किया जाता है, जिसके निष्पादन के दौरान बाईं ओर हरे रंग के संचालन के परिणाम अभी भी दिखाई नहीं दे सकते हैं, और हरे रंग में, जो सभी में दिखाई देंगे। यह ध्यान रखना महत्वपूर्ण है कि क्या होता है-पहले संबंध सकर्मक है , अर्थात, यदि ए -से पहले बी और बी होता है- सी से पहले , तो ए होता है-पहले सी।

संचालन होता है-रिलेशनशिप से पहले

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

1. मॉनीटर का विमोचन उसी मॉनीटर को प्राप्त करने से पहले होता है । कृपया ध्यान दें: यह रिलीज है, निकास नहीं है, अर्थात, आपको wait का उपयोग करते समय सुरक्षा के बारे में चिंता करने की ज़रूरत नहीं है।

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

 public class Keeper { private Data data = null; public Data getData() { synchronized(this) { if(data == null) { data = new Data(); } } return data; } }

2. वाष्पशील चर को लिखना उसी चर से पढ़ने से पहले होता है ।

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

तो, हमारे डबल-लॉकिंग मेढ़े पर वापस जाएं। अस्थिर का उपयोग करके, आप इस तरह की स्थिति को ठीक कर सकते हैं:

 public class Keeper { private volatile Data data = null; public Data getData() { if(data == null) { synchronized(this) { if(data == null) { data = new Data(); } } } return data; } }

यहां हमारे पास अभी भी एक ताला है, लेकिन केवल अगर data == null । बाकी मामले हम वाष्पशील रीड का उपयोग करके फ़िल्टर करते हैं। इस तथ्य से सुधार सुनिश्चित किया जाता है कि अस्थिर स्टोर होता है- वाष्पशील रीड से पहले , और कंस्ट्रक्टर में होने वाले सभी ऑपरेशन फ़ील्ड के मूल्य को पढ़ने वालों को दिखाई देते हैं।

इसके अलावा, यहां एक दिलचस्प धारणा का उपयोग किया जाता है, जो जांचने योग्य है: वाष्पशील स्टोर + रीड लॉकिंग से तेज है। हालाँकि, जैसा कि एक ही प्रदर्शन अभियंता अथक रूप से हमें दोहराते हैं, माइक्रोबेनचर्च का वास्तविकता से कोई लेना-देना नहीं है, खासकर यदि आप नहीं जानते कि यह कैसे काम करता है जिसे आप मापने की कोशिश कर रहे हैं। इसके अलावा, अगर आपको लगता है कि आप जानते हैं कि यह कैसे काम करता है, तो आप सबसे अधिक गलत हैं और किसी भी महत्वपूर्ण कारक को ध्यान में नहीं रखते हैं। मुझे अपने बेंचमार्क का निर्माण करने के लिए अपने ज्ञान की गहराई में पर्याप्त विश्वास नहीं है, इसलिए यहां ऐसा कोई माप नहीं होगा। हालाँकि, स्लाइड # 54 से शुरू होने वाली इस प्रस्तुति में अस्थिर प्रदर्शन के बारे में कुछ जानकारी है (हालाँकि मैं दृढ़ता से यह सब पढ़ने की सलाह देता हूँ)। यूपीडी: एक दिलचस्प टिप्पणी है , जिसमें वे कहते हैं कि वाष्पीकरण, डिजाइन द्वारा सिंक्रनाइज़ेशन की तुलना में काफी तेज है।

3. final फ़ील्ड में मान लिखना (और, यदि यह फ़ील्ड एक लिंक है, तो इस फ़ील्ड से प्राप्त होने वाले सभी चर (dereference- श्रृंखला)) तब होता है जब -पहले ऑब्जेक्ट का निर्माण करते हैं, इस ऑब्जेक्ट को कुछ वैरिएबल पर लिखते हैं जो बाहर होता है। यह निर्माता।

यह भी भ्रामक लग रहा है, लेकिन सार सरल है: यदि कोई ऐसी वस्तु है जिसमें final फ़ील्ड है, तो इस ऑब्जेक्ट का उपयोग केवल इस final फ़ील्ड को सेट करने के बाद किया जा सकता है (और वह सब कुछ जो यह फ़ील्ड संदर्भित कर सकता है)। हालांकि, यह मत भूलो कि यदि आप कंस्ट्रक्टर से कंस्ट्रक्शन ऑब्जेक्ट (यानी this ) के लिए एक लिंक बाहर से पास करते हैं, तो कोई आपकी वस्तु को अपूर्ण स्थिति में देख सकता है।

हमारे उदाहरण में, यह पता चला है कि यह क्षेत्र बनाने के लिए पर्याप्त है, अंतिम रिकॉर्ड जिसमें होता है, final , हर बार जादुई रूप से और बिना सिंक्रनाइज़ेशन के बिना जादुई तरीके से सब कुछ कैसे काम करेगा:

 public class Data { String question; int answer; final int maxAllowedValue; public Data() { this.answer = 42; this.question = reverseEngineer(this.answer); this.maxAllowedValue = 9000; } private String reverseEngineer(int answer) { return null; } }

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

UPD: यह सच नहीं है। टिप्पणियों का वर्णन क्यों । UPD2 : मुद्दे की चर्चा के बाद, रुस्लान ने एक लेख लिखा।

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

 public class Singleton { private Singleton() {} private static class InstanceContainer { private static final Singleton instance = new Singleton(); } public Singleton getInstance() { return InstanceContainer.instance; } }

यह, ज़ाहिर है, सिंगलटन को लागू करने के बारे में सलाह नहीं है, क्योंकि हर कोई जो प्रभावी जावा पढ़ता है वह जानता है कि अगर ~~किसी कारण से आपने अचानक~~ इसे ~~किसी कारण~~ से लिखने का फैसला किया, तो एनम का उपयोग करना और इससे प्राप्त करना सबसे अच्छा है। मल्टीथ्रेडिंग के साथ और क्रमबद्धता के साथ, और क्लोनिंग के साथ सभी समस्याओं का समाधान बॉक्स। UPD: सिंगलटन को लागू करने के लिए सबसे अच्छा है, आप इस विषय को पढ़ सकते हैं।

वैसे, उन लोगों के लिए जो जानते हैं कि अंतिम क्षेत्रों को परावर्तन के माध्यम से बदला जा सकता है और जो लोग इस तरह के बदलावों में रुचि रखते हैं वे कैसे दिखाई देंगे, मैं यह कह सकता हूं: "सब कुछ ठीक लग रहा है, यह स्पष्ट नहीं है कि क्यों, और यह स्पष्ट नहीं है कि क्या सब कुछ वास्तव में है अच्छा है। " इस विषय पर कई विषय हैं, यह सबसे आंतरिक है। अगर कोई टिप्पणी में बताता है कि यह वास्तव में कैसा है, तो मुझे बेहद खुशी होगी। हालांकि, अगर कोई नहीं बताता है, तो मैं खुद पता लगाऊंगा और बताना सुनिश्चित करूंगा। UPD : उन्होंने टिप्पणियों में कहा ।

निश्चित रूप से होने वाले रिश्तों से पहले कुछ अन्य ऑपरेशन हैं, जिन्हें मैंने इस लेख में शामिल नहीं किया है, लेकिन वे पहले से ही अधिक विशिष्ट हैं, और यदि आपकी रुचि है, तो आप उन्हें स्वयं मानक या कहीं और पा सकते हैं, और फिर साझा कर सकते हैं टिप्पणियों में हर कोई।

क्रेडिट, लिंक और सामान

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

मैं उन स्रोतों की एक सूची भी देता हूं, जिनका उपयोग मैंने लेख लिखते समय और विषय पर सिर्फ अच्छे लिंक:

डॉग ली द्वारा कम्पाइलर राइटर्स के लिए JSR-133 कुकबुक
सर्गेई कुक्सेंको द्वारा जावा मेमोरी मॉडल के बारे में बात से स्लाइड
अध्याय 17. जावा भाषा विशिष्टता के धागे और ताले
आर्टेम डेनिलोव द्वारा संक्षेप में जावा मेमोरी मॉडल
अभ्यास में जावा कॉन्सैरेसी

टिप्पणियों में दिलचस्प सवाल, परिवर्धन और सुधार छोड़ दें, मुझे पढ़ने और जवाब देने में खुशी होगी।

उदाहरणों में स्मृति मॉडल और न केवल