जावा में मेमोरी लीक के विशिष्ट मामले

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

विशिष्ट स्मृति रिसाव की स्थिति:


कचरा कलेक्टर समय-समय पर अप्रयुक्त वस्तुओं को इकट्ठा करता है, लेकिन हम देखते हैं कि ढेर उपयोग अनुसूची आत्मविश्वास से और सही ढंग से रेंग रही है।

इस स्थिति का कारण क्या हो सकता है?

स्ट्रिंग संचालन

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

String prefix = new String(longString.substring(0,5)); //
String prefix = longString.substring(0,5).intern(); //

ज़ोर्कस इंटर्नल स्ट्रिंग्स के साथ दूसरे विकल्प के लिए एक महत्वपूर्ण नोट: इंटर्नल स्ट्रिंग्स को ढेर में संग्रहीत नहीं किया जाता है, लेकिन परमिशन स्पेस में। इसमें कचरा संग्रह अलग-अलग नियमों के अनुसार होता है, न कि ढेर-ए / युवा / तपस्वी मेमोरी पूल में।

इसी तरह, याद रखें कि विभाजन () विधि का उपयोग करते समय एक समान समस्या होती है।

ObjectInputStream और ObjectOutputStream

ObjectInputStream और ObjectOutputStream क्लासेस उन सभी ऑब्जेक्ट्स के संदर्भों को संग्रहीत करते हैं, जिन्हें उन्होंने प्रतियों के स्थान पर पास करने के लिए काम किया था। यह निरंतर उपयोग के दौरान स्मृति रिसाव का कारण बनता है (उदाहरण के लिए, नेटवर्क संचार के दौरान)।
इस समस्या को हल करने के लिए, आपको समय-समय पर रीसेट () विधि को कॉल करना होगा।

धागे और उनके ढेर

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

गैर-स्थिर आंतरिक वर्ग

प्रत्येक गैर-स्थिर आंतरिक वर्ग जिसे आप स्टोर करते हैं, बाहरी वर्ग के संदर्भ में उपयोग करता है। यह वस्तुओं के एक बड़े ग्राफ के भंडारण की ओर जाता है, जो स्मृति के उपयोग को नकारात्मक रूप से प्रभावित करता है। उन स्थितियों में जहां आपको स्पष्ट रूप से बाहरी वर्ग के संदर्भ का उपयोग करने की आवश्यकता नहीं होती है, आंतरिक कक्षाओं को लागू करते हैं।

ऑब्जर्वर पैटर्न और संबंधित धमकी

ऑब्जर्वर पैटर्न का उपयोग करते समय अक्सर मेमोरी रिसाव की स्थिति उत्पन्न होती है। जैसा कि आप जानते हैं, ऑब्जर्वर अपने श्रोताओं की एक सूची रखता है जिन्हें कुछ कार्यों की सूचनाओं के लिए सदस्यता दी जाती है। इसके अलावा, यदि हम अब एक निश्चित वर्ग का उपयोग नहीं करते हैं जो इस पर्यवेक्षक का ग्राहक है, तो GC इसे "एकत्रित" करने में सक्षम नहीं होगा, क्योंकि यह लिंक ऑब्जर्वर उदाहरण में ही संग्रहीत है।

एकाकी वस्तु

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

थ्रेडलोकल वैरिएबल

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

परस्पर स्थिर वस्तुएँ

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

ऑब्जेक्ट बनाएँ

हम दो मामलों पर विचार करते हैं।
केस 1:

Elem e;
e = new HeavyElem();
e = new HeavyElem();

केस 2:

Elem e;
e = new HeavyElem();
e = null;
e = new HeavyElem();

दूसरा मामला अधिक सही है, क्योंकि ज्यादातर मामलों में यह स्पष्ट रूप से कलेक्टर को मूल रूप से बनाए गए हैवीलेम के अप्रयुक्त उदाहरण को इकट्ठा करने के लिए कहेगा।

क्लास लोडर

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

इनसे कैसे बचें?

और अब स्मृति रिसाव के साथ समस्या से बचने के लिए कुछ सुझाव तय करने के लिए:
1. प्रोफाइल का उपयोग करें। प्रोफाइलर आपको यह देखने में मदद करता है कि कौन सी वस्तुएं ढेर पर स्थित हैं (और उन्हें सीधे उदाहरण से देखें), जो आपको शुरुआती चरणों में लीक को पकड़ने की अनुमति देगा
2. सावधानी के साथ स्ट्रिंग संचालन का उपयोग करें, खासकर जब प्रोग्राम बहुत सारे पाठ डेटा को संसाधित करने पर काम कर रहा हो।
3. यदि आप गैर-स्थिर आंतरिक वर्गों, स्थिर चर की आवश्यकता है तो हमेशा सावधान रहें
4. डेटा संसाधित होने के बाद वस्तुओं के संग्रह को साफ करें और आगे उपयोग की आवश्यकता नहीं है।

एक अच्छा कोड लिखें और स्मृति को संभालने के नियमों के बारे में मत भूलना!