💇🏻 🐛 🍘 उपलब्ध स्मृति या सही ढंग से स्मृति को बचाने के लिए गार्ड के लिए नरम लिंक 👩🏿‍🌾 👴🏾 ⛱️

  सभी जावा डेवलपर्स, जल्दी या बाद में, कुख्यात OutOfMemoryError त्रुटि का सामना करते हैं।

इस बैठक के बाद, हम इसे सहेजने के लिए उपयोग की जाने वाली मेमोरी के बारे में अधिक सावधान रहना शुरू करते हैं। संस्करण 1.2 के साथ शुरू, java.lang.ref। * जावा में छपी सॉफ्टरफेफरेंस, वीकररेंस, फैंटम रीफरेंस कक्षाओं के साथ पैकेज। इसके बाद, मैं आपको बताऊंगा कि ये कक्षाएं आउटऑफमेरीऑरर के खिलाफ लड़ाई में कैसे मदद करेंगी। और अधिक दिलचस्प बात यह है कि मैं उनके उपयोग के वास्तविक उदाहरण दूंगा। चलिए शुरू करते हैं।

सामान्य विवरण

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

StringBuilder builder = new StringBuilder();

बिल्डर यह StringBuilder वस्तु का एक मजबूत-संदर्भ है।
और लिंक के 3 "विशेष" प्रकार हैं - सॉफ्टरफरेंस, कमजोरप्रतिबंध, फैंटम रीफरेंस। वास्तव में, सभी प्रकार के लिंक के बीच केवल एक ही अंतर है - जिन वस्तुओं का वे संदर्भ देते हैं, उनके साथ जीसी का व्यवहार। हम बाद में प्रत्येक प्रकार की लिंक की विशेषताओं के बारे में विस्तार से चर्चा करेंगे, लेकिन अभी के लिए, निम्नलिखित ज्ञान पर्याप्त होगा:

SoftReference - यदि GC यह देखता है कि ऑब्जेक्ट केवल सॉफ्ट लिंक की एक श्रृंखला के माध्यम से सुलभ है, तो यह इसे मेमोरी से हटा देगा। तब। शायद।
WeakReference - यदि GC देखता है कि ऑब्जेक्ट केवल कमजोर लिंक की एक श्रृंखला के माध्यम से सुलभ है, तो यह इसे मेमोरी से हटा देगा।
PhantomReference - यदि GC देखता है कि ऑब्जेक्ट केवल फ़ैंटम लिंक की एक श्रृंखला के माध्यम से सुलभ है, तो यह इसे मेमोरी से हटा देगा। जीसी की कई शुरुआत के बाद।

यदि यह अभी तक स्पष्ट नहीं है कि अंतर क्या है, तो चिंता न करें, जल्द ही सब कुछ ठीक हो जाएगा। छोटी चीजें विवरण में हैं, और विवरण आगे आएगा।
ये 3 प्रकार के लिंक एक माता-पिता के संदर्भ से विरासत में मिले हैं, जहां से वे वास्तव में अपने सभी सार्वजनिक तरीकों और निर्माणकर्ताओं को लेते हैं।

 StringBuilder builder = new StringBuilder(); SoftReference<StringBuilder> softBuilder = new SoftReference(builder);

इन दो पंक्तियों को पूरा करने के बाद, हमारे पास 1 स्ट्रिंगबुलस्ट ऑब्जेक्ट के 2 प्रकार होंगे:

बिल्डर - मजबूत लिंक
softBuilder - सॉफ्ट लिंक (औपचारिक रूप से यह सॉफ्ट लिंक की एक मजबूत कड़ी है, लेकिन सादगी के लिए मैं एक सॉफ्ट लिंक लिखूंगा)

और अगर, रन टाइम पर, बिल्डर वेरिएबल अनुपलब्ध हो जाता है, लेकिन सॉफ्टबर्स्ट द्वारा संदर्भित ऑब्जेक्ट का लिंक अभी भी उपलब्ध है और जीसी -> शुरू होता है, तो स्ट्रिंगब्यूलर ऑब्जेक्ट को केवल सॉफ्ट लिंक की एक श्रृंखला के माध्यम से सुलभ के रूप में चिह्नित किया जाएगा।
उपलब्ध तरीकों पर विचार करें:
softBuilder.get () - GC इस मेमोरी के साथ इस ऑब्जेक्ट को डिलीट नहीं करने की स्थिति में StringBuilder ऑब्जेक्ट के लिए एक मजबूत संदर्भ लौटाएगा। अन्यथा, शून्य वापस कर दिया जाएगा।
softBuilder.clear () - StringBuilder ऑब्जेक्ट के लिंक को हटा देता है (अर्थात, इस ऑब्जेक्ट के लिए अधिक नरम लिंक नहीं हैं)
सभी WeakReference और PhantomReference के लिए समान कार्य करता है। सच है, PhantomReference.get () हमेशा अशक्त लौटेगा, लेकिन बाद में और अधिक।
अभी भी ऐसा एक वर्ग है - ReferenceQueue। यह आपको ट्रैक करने की अनुमति देता है जब जीसी निर्धारित करता है कि ऑब्जेक्ट की अब आवश्यकता नहीं है और इसे हटाया जा सकता है। यह वह जगह है जहाँ संदर्भ ऑब्जेक्ट को उस ऑब्जेक्ट के बाद मिलता है जिसे वह संदर्भित करता है मेमोरी से हटा दिया जाता है। एक संदर्भ बनाते समय, हम ReferenceQueue कंस्ट्रक्टर में पास कर सकते हैं, जिसमें लिंक को हटाने के बाद रखा जाएगा।

सॉफ्टरफेर विवरण

जीसी सुविधाएँ

तो फिर भी, GC कैसे व्यवहार करता है जब यह देखता है कि एक वस्तु केवल नरम लिंक की श्रृंखला के माध्यम से सुलभ है? आइए GC को अधिक विस्तार से देखें:
और इसलिए, जीसी ने अपना काम शुरू किया और ढेर पर सभी वस्तुओं के माध्यम से चला जाता है। यदि ढेर पर ऑब्जेक्ट संदर्भ है, तो जीसी इस ऑब्जेक्ट को एक विशेष कतार में रखता है जिसमें सभी संदर्भ ऑब्जेक्ट स्थित हैं। सभी वस्तुओं के माध्यम से जाने के बाद, जीसी संदर्भ वस्तुओं को कतार में ले जाता है और उनमें से प्रत्येक के लिए इसे स्मृति से हटाने या न करने का फैसला करता है। किसी ऑब्जेक्ट को हटाने का निर्णय वास्तव में JVM पर निर्भर करता है। लेकिन सामान्य अनुबंध इस प्रकार है: जीसी को आउटऑफमेमोरी एर्र फेंकने से पहले केवल नरम लिंक द्वारा सुलभ सभी वस्तुओं को ढेर से हटाने की गारंटी है ।
SoftReference मेमोरी में ऑब्जेक्ट्स को कैशिंग करने के लिए हमारा तंत्र है, लेकिन एक महत्वपूर्ण स्थिति में, जब उपलब्ध मेमोरी बाहर निकलती है, तो GC मेमोरी से अप्रयुक्त वस्तुओं को हटा देगा और इस तरह जेवीएम को बंद होने से बचाने की कोशिश करेगा। क्या यह अद्भुत नहीं है?
इस तरह से हॉटस्पॉट ने सॉफ्टरेंस को हटाने का फैसला किया है: यदि आप सॉफ्टरफेर के कार्यान्वयन को देखते हैं, तो आप देख सकते हैं कि कक्षा में 2 चर हैं - निजी स्थिर लंबी घड़ी और निजी लंबे टाइमस्टैम्प। हर बार जीसी शुरू होता है, यह घड़ी के चर के लिए वर्तमान समय निर्धारित करता है। जब भी कोई SoftReference बनाया जाता है, तो वर्तमान घड़ी का मूल्य टाइमस्टैम्प को लिखा जाता है। टाइमस्टैम्प को हर बार अपडेट किया जाता है () विधि कहा जाता है (हर बार जब हम एक मजबूत ऑब्जेक्ट संदर्भ बनाते हैं)। यह आपको गणना करने की अनुमति देता है कि अंतिम कॉल के बाद एक नरम लिंक कितनी देर तक मौजूद है। हम पत्र I द्वारा इस अंतराल को निरूपित करते हैं। हमें अक्षर F से MB (मेगाबाइट्स) में ढेर पर खाली जगह की मात्रा को निरूपित करते हैं। लगातार MSPerMB द्वारा हम मिलीसेकंड की संख्या को दर्शाते हैं कि ढेर में प्रत्येक मुक्त मेगाबाइट के लिए कितने नरम लिंक मौजूद होंगे।
फिर सब कुछ सरल है, अगर मैं <= F * MSPerMB, तो हम ऑब्जेक्ट को नहीं हटाते हैं। ज्यादा हो तो हटवाएं।
MSPerMB को बदलने के लिए, -XX स्विच का उपयोग करें : SoftRefLRUPolicyMSPerMB । डिफ़ॉल्ट मान 1000 एमएस है, जिसका अर्थ है कि नरम लिंक मौजूद होगा (मजबूत लिंक हटा दिए जाने के बाद) ढेर पर मुफ्त मेमोरी के प्रत्येक मेगाबाइट के लिए 1 सेकंड। मुख्य बात यह नहीं भूलना है कि ये सभी अनुमानित गणना हैं, क्योंकि वास्तव में नरम लिंक केवल जीसी लॉन्च होने के बाद हटा दिया जाएगा।
ध्यान दें कि किसी ऑब्जेक्ट को हटाने के लिए, मुझे F * MSPerMB से सख्ती से बड़ा होना चाहिए। यह निम्नानुसार है कि बनाया गया SoftReference कम से कम 1 GC लॉन्च से बचेगा। (* यदि यह स्पष्ट नहीं है कि क्यों, तो यह आपका होमवर्क रहेगा)
आईबीएम के वीएम के मामले में, सॉफ्ट लिंक के जीवनकाल को जोड़ने का समय नहीं है, लेकिन जीवित रहने वाले जीसी लॉन्च की संख्या।

आवेदन

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

 public class ImageProcessor { private static final String IMAGE_NAME = "bigImage.jpg"; public InputStream concatenateImegeWithDefaultVersion(InputStream userImageAsStream) { InputStream defaultImage = this.getClass().getResourceAsStream(IMAGE_NAME); // calculate and return concatenated image } }

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

 public class CachedImageProcessor { private static final String IMAGE_NAME = "bigImage.jpg"; private InputStream defaultImage; public InputStream concatenateImegeWithDefaultVersion(InputStream userImageAsStream) { if (defaultImage == null) { defaultImage = this.getClass().getResourceAsStream(IMAGE_NAME); } // calculate and return concatenated image } }

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

 public class SoftCachedImageProcessor { private static final String IMAGE_NAME = "bigImage.jpg"; private SoftReference<InputStream> defaultImageRef = new SoftReference(loadImage()); public InputStream concatenateImegeWithDefaultVersion(InputStream userImageAsStream) { if (defaultImageRef.get() == null) { // 1 defaultImage = this.getClass().getResourceAsStream(IMAGE_NAME); defaultImageRef = new SoftReference(defaultImage); } defaultImage = defaultImageRef.get(); // 2 // calculate and return concatenated image } }

यह संस्करण पूर्ण नहीं है, लेकिन यह दिखाता है कि हम कैश द्वारा कब्जा किए गए आकार को कितनी आसानी से नियंत्रित कर सकते हैं, या बल्कि, वर्चुअल मशीन को नियंत्रण सौंप सकते हैं। इस कार्यान्वयन का खतरा इस प्रकार है। लाइन नंबर 1 में हम एक शून्य जांच करते हैं, वास्तव में हम यह जांचना चाहते हैं कि जीसी ने मेमोरी से डेटा हटा दिया है या नहीं। मान लें कि उसने इसे नहीं हटाया है। लेकिन लाइन नंबर 2 को निष्पादित करने से पहले, जीसी काम करना शुरू कर सकता है और डेटा को हटा सकता है। इस स्थिति में, पंक्ति संख्या 2 का परिणाम defaultImage = null होगा। स्मृति में किसी ऑब्जेक्ट के अस्तित्व को सुरक्षित रूप से सत्यापित करने के लिए, हमें एक मजबूत लिंक बनाने की आवश्यकता है, defaultImage = defaultImageRef.get (); यहां अंतिम क्रियान्वयन कैसा दिखेगा:

 public class SoftCachedImageProcessor { private static final String IMAGE_NAME = "bigImage.jpg"; private SoftReference<InputStream> defaultImageRef = new SoftReference(loadImage());; public InputStream concatenateImegeWithDefaultVersion(InputStream userImageAsStream) { defaultImage = defaultImageRef.get(); if (defaultImage == null) { defaultImage = this.getClass().getResourceAsStream(IMAGE_NAME); defaultImageRef = new SoftReference(defaultImage); } // calculate and return concatenated image } }

और आगे चलते हैं। java.lang.Class भी कैशिंग के लिए सॉफ्टरेंस का उपयोग करता है। यह क्लास के कंस्ट्रक्टर्स, मेथड्स और फील्ड्स के डेटा को कैश करता है। यह देखना दिलचस्प है कि वे वास्तव में क्या कैश करते हैं। जब आप कैशिंग के लिए सॉफ्टरियर का उपयोग करने का निर्णय लेते हैं, तो आपको यह तय करने की आवश्यकता होती है कि कैश क्या करना है। मान लीजिए कि हमें सूची को कैश करने की आवश्यकता है। हम सूची <शीतल संदर्भ> और शीतलता <सूची> दोनों का उपयोग कर सकते हैं। दूसरा विकल्प अधिक स्वीकार्य है। यह याद रखना चाहिए कि संदर्भ ऑब्जेक्ट्स को संसाधित करते समय जीसी विशिष्ट तर्क को लागू करता है, और मेमोरी को तेजी से मुक्त किया जाएगा यदि हमारे पास 1 सॉफ्टरिनेंस है और उनकी सूची नहीं है। यह वह है जो हम कक्षा के कार्यान्वयन में देखते हैं - डेवलपर्स ने निर्माणकर्ताओं, फ़ील्ड्स और विधियों की एक सरणी के लिए एक नरम लिंक बनाया। यदि हम प्रदर्शन के बारे में बात करते हैं, तो यह ध्यान देने योग्य है कि अक्सर, ग़लती से, लोग कैश बनाने के लिए WeakReference का उपयोग करते हैं जहां यह SoftReference का उपयोग करने के लायक है। इसके परिणामस्वरूप खराब कैश प्रदर्शन होता है। व्यवहार में, कमजोर लिंक जल्दी से मेमोरी से हटा दिया जाएगा जैसे ही ऑब्जेक्ट के लिए मजबूत लिंक गायब हो जाते हैं। और जब हमें वास्तव में कैश से किसी ऑब्जेक्ट को खींचने की आवश्यकता होती है, तो हम देखेंगे कि यह अब नहीं है।
खैर, SoftReference पर आधारित कैश का उपयोग करने का एक और उदाहरण। Google अमरूद में मैपमेकर क्लास है। यह हमें एक समवर्ती मानचित्र बनाने में मदद करेगा, जिसमें निम्नलिखित विशेषता होगी - मानचित्र की कुंजियाँ और मूल्य WeakReference या SoftReference में लपेटे जा सकते हैं। मान लीजिए कि हमारे एप्लिकेशन में वह डेटा है जो उपयोगकर्ता अनुरोध कर सकता है और यह डेटा डेटाबेस से एक बहुत ही जटिल क्वेरी द्वारा प्राप्त किया जाता है। उदाहरण के लिए, यह पिछले वर्ष के लिए एक उपयोगकर्ता की खरीदारी सूची होगी। हम एक कैश बना सकते हैं जिसमें सॉफ्ट लिंक का उपयोग करके मूल्यों (खरीदारी की सूची) को संग्रहीत किया जाएगा। और अगर कैश में कोई मूल्य नहीं है, तो आपको इसे डेटाबेस से खींचने की आवश्यकता है। कुंजी उपयोगकर्ता आईडी है। यहाँ कार्यान्वयन कैसा दिख सकता है:

 ConcurrentMap<Long, List<Product>> oldProductsCache = new MapMaker().softValues(). .makeComputingMap(new Function<User, List<Product>>() { @Override public List<Product> apply(User user) { return loadProductsFromDb(user); } });

WeakReference

जीसी सुविधाएँ

अब आइए अधिक विस्तार से विचार करें कि WeakReference क्या है। जब जीसी यह निर्धारित करता है कि कोई वस्तु केवल कमजोर लिंक के माध्यम से सुलभ है, तो यह ऑब्जेक्ट मेमोरी से "तुरंत" हटा दिया जाता है। यह ReferenceQueue के बारे में याद रखने और स्मृति से किसी ऑब्जेक्ट को हटाने के लिए प्रक्रिया का पालन करने के लायक है। आपको याद दिला दूं कि WeakReference और SoftReference के लिए ReferenceQueue में आने के लिए एल्गोरिथ्म समान है। इसलिए, जीसी ने शुरू किया और निर्धारित किया कि वस्तु केवल कमजोर लिंक के माध्यम से सुलभ है। यह ऑब्जेक्ट इस तरह बनाया गया था:

 StrIngBuilder AAA = new StringBuilder(); ReferenceQueue queue = new ReferenceQueue(); WeakReference weakRef = new WeakReference(AAA, queue);

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

आवेदन

बेशक WeakHashMap। यह मानचित्र <K, V> का एक कार्यान्वयन है जो एक कमजोर लिंक का उपयोग करके कुंजी को संग्रहीत करता है। और जब GC मेमोरी से कुंजी को हटाता है, तो मैप से पूरा रिकॉर्ड हटा दिया जाता है। मुझे लगता है कि यह समझना मुश्किल नहीं है कि यह कैसे होता है। जब एक नया जोड़ा <key, value> जोड़ते हैं, तो WeakReference कुंजी के लिए बनाया जाता है और ReferenceQueue कंस्ट्रक्टर को पास किया जाता है। जब GC मेमोरी से कुंजी को हटाता है, तो ReferenceQueue उस कुंजी के लिए संगत WeakReference को लौटाता है। उसके बाद, संबंधित प्रविष्टि को मानचित्र से निकाल दिया जाता है। सब कुछ बहुत सरल है। लेकिन मैं कुछ विवरणों पर ध्यान देना चाहता हूं।

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

खैर, फिर किन मामलों में WeakHashMap का उपयोग करना सुविधाजनक है? मान लीजिए हमें उपयोगकर्ता के लिए एक XML दस्तावेज़ बनाने की आवश्यकता है। दस्तावेज़ का डिज़ाइन कई सेवाओं द्वारा संभाला जाएगा जो org.w3c.Node प्राप्त करेंगे जिसमें वे आवश्यक तत्व जोड़ देंगे। इसके अलावा, सेवाओं के लिए, आपको डेटाबेस से उपयोगकर्ता के बारे में बहुत सारी जानकारी चाहिए। हम इस डेटा को UserInfo वर्ग में संग्रहीत करेंगे। UserInfo वर्ग बहुत अधिक मेमोरी स्पेस लेता है और केवल एक विशिष्ट XML दस्तावेज़ बनाने के लिए प्रासंगिक है। कैशिंग यूजरइन्फो का कोई मतलब नहीं है। हमें केवल इसे एक दस्तावेज़ के साथ जोड़ना होगा और यह मेमोरी से हटाने की सलाह दी जाती है जब दस्तावेज़ को प्रोग्राम द्वारा अब उपयोग नहीं किया जाता है। हमें बस इतना करना चाहिए:

 private static final NODE_TO_USER_MAP = new WeakHashMap<Node, UserInfo>();

XML दस्तावेज़ बनाना कुछ इस तरह दिखाई देगा:

 Node mainDocument = createBaseNode(); NODE_TO_USER_MAP.put(mainDocument, loadUserInfo());

खैर, यहाँ पढ़ने है:

 UserInfo userInfo = NODE_TO_USER_MAP.get(mainDocument); If(userInfo != null) { // … }

UserInfo, WeakHashMap में तब तक रहेगा जब तक कि केवल कमजोर लिंक mainDocument पर नहीं रहते।
WeakHashMap का उपयोग करने का एक और उदाहरण। String.intern () पद्धति के बारे में बहुत से लोग जानते हैं। इसलिए WeakReference का उपयोग करके आप कुछ समान बना सकते हैं। (आइए इस लेख के ढांचे के भीतर, इस समाधान की उपयुक्तता पर चर्चा न करें, और इस तथ्य को स्वीकार करें कि इस समाधान में इंटर्न () की तुलना में कुछ फायदे हैं। इसलिए, हमारे पास कई लाइनें हैं। हम जानते हैं कि लाइनें दोहराई जाती हैं। स्मृति को बचाने के लिए, हम उसी तर्ज के लिए नई वस्तुओं को बनाने के बजाय मौजूदा वस्तुओं का पुन: उपयोग करना चाहते हैं। यहां बताया गया है कि WeakHashMap कैसे हमारी मदद कर सकता है:

 private static Map<String, WeakReference<String>> stringPool = new WeakHashMap<String, WeakReference<String>>; public String getFromPool(String value) { WeakReference<String> stringRef = stringPool.get(value); if (stringRef == null || stringRef.get() == null ) { stringRef = new WeakReference<String>(value); stringPool.put(value, stringRef); } return stringRef.get(); }

और अंत में, मैं जोड़ूंगा कि WeakReference को कई वर्गों में उपयोग किया जाता है - थ्रेड, थ्रेडलोक, ऑब्जेक्टऑटप्यूस्ट्रीम, प्रॉक्सी, लॉगमैन। यह समझने के लिए कि WeakReference आपको किन मामलों में मदद कर सकता है, आप उनके कार्यान्वयन को देख सकते हैं।

PhantomReference

जीसी सुविधाएँ

इस प्रकार के लिंक की दो विशेषताएं हैं। पहला यह है कि प्राप्त () विधि हमेशा शून्य रहती है। इसका कारण यह है कि PhantomReference केवल ReferenceQueue के साथ एक साथ उपयोग करने के लिए समझ में आता है। दूसरी विशेषता - सॉफ्टरफेरेंस और वीइक रीफरेंस के विपरीत, जीसी फाइनल () पद्धति के निष्पादित होने के बाद रेफरेंसक्यू के लिए एक फैंटम लिंक जोड़ देगा। यही है, वास्तव में, SoftReference और WeakReference के विपरीत, ऑब्जेक्ट अभी भी मेमोरी में है।

अभ्यास

पहली नज़र में, यह स्पष्ट नहीं है कि इस प्रकार के लिंक का उपयोग कैसे किया जाए। उन्हें कैसे उपयोग किया जाए, यह समझाने के लिए, आइए हम पहले अंतिम () विधि का उपयोग करते समय आने वाली समस्याओं से खुद को परिचित करें: इस पद्धति को ओवरराइड करने से हमें ऑब्जेक्ट से जुड़े संसाधनों को साफ करने की अनुमति मिलती है। जब जीसी यह निर्धारित करता है कि ऑब्जेक्ट अब उपलब्ध नहीं है, तो इसे मेमोरी से हटाने से पहले, यह इस विधि को निष्पादित करता है। इससे जुड़ी समस्याएं इस प्रकार हैं:

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

वापस प्रेतसंवाद के लिए। ReferenceQueue के साथ संयोजन में इस प्रकार के लिंक हमें यह पता लगाने की अनुमति देते हैं कि ऑब्जेक्ट अब उपलब्ध नहीं है और इसके लिए कोई अन्य लिंक नहीं हैं। यह हमें एप्लिकेशन स्तर पर ऑब्जेक्ट द्वारा उपयोग किए गए संसाधनों को साफ करने की अनुमति देता है। अंतिम रूप देने () के विपरीत, हम स्वयं सफाई संसाधनों की प्रक्रिया को नियंत्रित करते हैं। इसके अलावा, हम नई वस्तुओं को बनाने की प्रक्रिया को नियंत्रित कर सकते हैं। मान लीजिए कि हमारे पास एक कारखाना है जो हमें HdImage ऑब्जेक्ट लौटाएगा। हम नियंत्रित कर सकते हैं कि ऐसी कितनी वस्तुओं को मेमोरी में लोड किया जाएगा:

 public HdImageFabric { public static final int IMAGE_LIMIT = 10; public static int count = 0; public static ReferenceQueue<HdImage> queue = new ReferenceQueue<HdImage>(); public HdImage loadHdImage(String imageName) { while (true) { if (count < IMAGE_LIMIT) { return wrapImage(loadImage(imageName)); } else { Reference<HdImage> ref = queue.remove(500); if (ref != null) { count--; System.out.println(“remove old image”); } } } } private HdImage wrapImage(HdImage image) { PhantomReference<HdImage> refImage = new PhantomReference(image, queue); count++; return refImage ; } }

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

अनुबंध की गारंटी है कि लिंक जीसी नोटिस के बाद कतार में दिखाई देता है कि ऑब्जेक्ट केवल फैंटम लिंक के माध्यम से सुलभ है और इससे पहले कि ऑब्जेक्ट मेमोरी से हटा दिया जाता है। अनुबंध यह गारंटी नहीं देता है कि ये घटनाएं एक के बाद एक घटित होंगी। वास्तव में, कोई भी समय इन घटनाओं के बीच बीत सकता है। इसलिए, महत्वपूर्ण संसाधनों को साफ करने के लिए PhantomReference पर भरोसा न करें।
अंतिम रूप () विधि से बाहर निकलने और रेफरेंस क्यू के लिए फैंटम लिंक को जोड़ने के लिए अलग-अलग जीसी लॉन्च पर प्रदर्शन किया जाता है। इसलिए, यदि किसी ऑब्जेक्ट में अंतिम () विधि ओवरराइड की जाती है, तो इसे हटाने के लिए 3 GC प्रारंभ की आवश्यकता होती है, और यदि विधि को ओवरराइड नहीं किया जाता है, तो कम से कम 2 GC प्रारंभ की आवश्यकता होती है

।

निष्कर्ष के रूप में, मैं कहना चाहता हूं कि java.lang.ref। * हमें JVM मेमोरी के साथ काम करने के अच्छे अवसर प्रदान करता है और आपको इन वर्गों की उपेक्षा नहीं करनी चाहिए, वे हमारी बहुत मदद कर सकते हैं। उनका उपयोग बड़ी संख्या में त्रुटियों के साथ जुड़ा हुआ है, और वांछित परिणाम प्राप्त करने के लिए आपको बेहद सावधान रहने की आवश्यकता है। लेकिन क्या इन कठिनाइयों ने हमें एक बार रोक दिया? वह सब है। अंत तक पढ़ने वाले सभी को धन्यवाद। मैं उन टिप्पणियों में उन सवालों के जवाब देने की कोशिश करूंगा जो मैं इस लेख में नहीं बता सकता।

उपलब्ध स्मृति या सही ढंग से स्मृति को बचाने के लिए गार्ड के लिए नरम लिंक

सामान्य विवरण

सॉफ्टरफेर विवरण

जीसी सुविधाएँ

आवेदन

WeakReference

जीसी सुविधाएँ

आवेदन

PhantomReference

जीसी सुविधाएँ

अभ्यास

More articles: