स्मृति रिसाव

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

एक संबंधित अवधारणा अंतरिक्ष रिसाव है, जो तब होता है जब कोई प्रोग्राम अत्यधिक मेमोरी का उपभोग करता है लेकिन अंततः इसे जारी करता है। क्योंकि वे उपलब्ध सिस्टम मेमोरी को समाप्त कर सकते हैं क्योंकि एप्लिकेशन चलता है, मेमोरी लीक अक्सर सॉफ़्टवेयर उम्र बढ़ने का कारण या योगदान कारक होता है।

परिणाम

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

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

बहुत अधिक गंभीर लीक में वे शामिल हैं:

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

स्मृति रिसाव का एक उदाहरण

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

जब एक बटन दबाया जाता है:
  कुछ मेमोरी प्राप्त करें, जिसका उपयोग फ्लोर नंबर याद रखने के लिए किया जाएगा
  मेमोरी में फ्लोर नंबर डालें
  क्या हम पहले से ही लक्ष्य मंजिल पर हैं?
    अगर ऐसा है, तो हमें कुछ नहीं करना है: समाप्त
    अन्यथा:
      लिफ्ट के निष्क्रिय होने तक प्रतीक्षा करें
      आवश्यक मंजिल पर जाएं
      उस मेमोरी को रिलीज़ करें जिसे हम फ़्लोर नंबर याद करते थे

स्मृति रिसाव तब होगा जब अनुरोधित मंजिल संख्या वही मंजिल है जिस पर लिफ्ट चालू है; स्मृति जारी करने की शर्त छोड़ दी जाएगी। हर बार यह मामला होने पर, अधिक मेमोरी लीक हो जाती है।

इस तरह के मामलों का आमतौर पर कोई तत्काल प्रभाव नहीं होता है। लोग अक्सर फर्श के लिए बटन नहीं दबाते हैं, और किसी भी मामले में, लिफ्ट में पर्याप्त अतिरिक्त मेमोरी हो सकती है कि ऐसा सैकड़ों या हजारों बार हो सकता है। हालांकि, लिफ्ट अंततः स्मृति से बाहर हो जाएगी। इसमें महीनों या साल लग सकते हैं, इसलिए पूरी तरह से परीक्षण के बावजूद इसे खोजा नहीं जा सकता है।

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

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

उपरोक्त उदाहरण में लीक को सशर्त के बाहर 'रिलीज़' ऑपरेशन लाकर ठीक किया जा सकता है:

जब एक बटन दबाया जाता है:
  कुछ मेमोरी प्राप्त करें, जिसका उपयोग फ्लोर नंबर याद रखने के लिए किया जाएगा
  मेमोरी में फ्लोर नंबर डालें
  क्या हम पहले से ही लक्ष्य मंजिल पर हैं?
    अगर नहीं:
      लिफ्ट के निष्क्रिय होने तक प्रतीक्षा करें
      आवश्यक मंजिल पर जाएं
  उस मेमोरी को रिलीज़ करें जिसे हम फ़्लोर नंबर याद करते थे

प्रोग्रामिंग मुद्दे

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

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

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

RAII

Main article: Resource Acquisition Is Initialization

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

<वाक्यविन्यास हाइलाइट लैंग = सी> /* सी संस्करण */

1. शामिल करें <stdlib.h>

शून्य एफ (इंट एन) {

 इंट * सरणी = कॉलोक (एन, आकार (इंट));
 do_some_work (सरणी);
 मुक्त (सरणी);

} </वाक्यविन्यास हाइलाइट>

<वाक्यविन्यास हाइलाइट लैंग = सीपीपी> // सी ++ संस्करण

1. शामिल करें <वेक्टर>

शून्य एफ (इंट एन) {

 एसटीडी :: वेक्टर <int> सरणी (एन);
 do_some_work (सरणी);

} </वाक्यविन्यास हाइलाइट>

सी संस्करण, जैसा कि उदाहरण में लागू किया गया है, को स्पष्ट डीलोकेशन की आवश्यकता है; सरणी गतिशील स्मृति आवंटन (अधिकांश सी कार्यान्वयन में ढेर से) है, और स्पष्ट रूप से मुक्त होने तक मौजूद है।

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

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

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

संदर्भ गणना और चक्रीय संदर्भ

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

निम्न Visual Basic कोड विहित संदर्भ-गणना स्मृति रिसाव को दिखाता है:

<वाक्यविन्यास हाइलाइट लैंग = वीबी> मंद ए, बी सेट ए = क्रिएटऑब्जेक्ट (कुछ। कुछ) सेट बी = क्रिएटऑब्जेक्ट (कुछ। कुछ) ' इस बिंदु पर, दो वस्तुओं में से प्रत्येक का एक संदर्भ है,

सेट ए.सदस्य = बी सेट B.सदस्य = A ' अब उनमें से प्रत्येक के पास दो संदर्भ हैं।

सेट ए = कुछ नहीं ' आप अभी भी इससे बाहर निकल सकते हैं ...

सेट बी = कुछ नहीं 'और अब आपके पास मेमोरी लीक है!

समाप्त </वाक्यविन्यास हाइलाइट> व्यवहार में, यह तुच्छ उदाहरण तुरंत देखा जाएगा और तय किया जाएगा। अधिकांश वास्तविक उदाहरणों में, संदर्भों का चक्र दो से अधिक वस्तुओं तक फैला होता है, और इसका पता लगाना अधिक कठिन होता है।

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

प्रभाव

यदि किसी प्रोग्राम मुख्य स्मृति लीक है और इसका मेमोरी उपयोग लगातार बढ़ रहा है, तो आमतौर पर तत्काल लक्षण नहीं होंगे। प्रत्येक भौतिक प्रणाली में स्मृति की एक सीमित मात्रा होती है, और यदि स्मृति रिसाव शामिल नहीं है (उदाहरण के लिए, लीकिंग प्रोग्राम को पुनरारंभ करके) यह अंततः समस्याएं पैदा करेगा।

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

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

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

स्मृति उपयोग का चूरा पैटर्न: उपयोग की गई स्मृति में अचानक गिरावट स्मृति रिसाव के लिए एक उम्मीदवार लक्षण है।

यदि मेमोरी लीक कर्नेल (ऑपरेटिंग सिस्टम) में है, तो ऑपरेटिंग सिस्टम स्वयं विफल हो जाएगा। परिष्कृत स्मृति प्रबंधन के बिना कंप्यूटर, जैसे एम्बेडेड सिस्टम, लगातार स्मृति रिसाव से पूरी तरह विफल हो सकते हैं।

सार्वजनिक रूप से सुलभ सिस्टम जैसे वेब सर्वर या राउटर (कंप्यूटिंग) सेवा से इनकार करने के लिए प्रवृत्त होते हैं यदि कोई हमलावर संचालन के अनुक्रम का पता लगाता है जो एक रिसाव को ट्रिगर कर सकता है। इस तरह के अनुक्रम को एक्सप्लॉइट (कंप्यूटर सुरक्षा) के रूप में जाना जाता है।

स्मृति उपयोग का एक चूरा पैटर्न किसी अनुप्रयोग के भीतर स्मृति रिसाव का एक संकेतक हो सकता है, खासकर यदि ऊर्ध्वाधर बूँदें उस अनुप्रयोग के रिबूट या पुनरारंभ के साथ मेल खाती हैं। हालांकि सावधानी बरतनी चाहिए क्योंकि कचरा संग्रह (कंप्यूटर विज्ञान) अंक भी इस तरह के पैटर्न का कारण बन सकते हैं और ढेर के स्वस्थ उपयोग को दिखाएंगे।

अन्य स्मृति उपभोक्ता

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

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

==C++== . में एक साधारण उदाहरण निम्न C++ प्रोग्राम आबंटित मेमोरी में पॉइंटर खोकर जानबूझकर मेमोरी को लीक करता है।

<वाक्यविन्यास हाइलाइट लैंग= c++ >

मुख्य प्रवेश बिंदु() {

    इंट* ए = नया इंट(5);
    ए = नलप्टर;
   /* 'ए' में सूचक अब मौजूद नहीं है, और इसलिए मुक्त नहीं किया जा सकता है,
    लेकिन स्मृति अभी भी सिस्टम द्वारा आवंटित की जाती है।
    यदि प्रोग्राम ऐसे पॉइंटर्स को मुक्त किए बिना बनाना जारी रखता है,
    यह लगातार स्मृति का उपभोग करेगा।
    इसलिए, एक रिसाव होगा। */

} </वाक्यविन्यास हाइलाइट>

यह भी देखें

• बफ़र अधिकता
• स्मृति प्रबंधन
• मेमोरी डिबगर
• प्लंब्री जावा वर्चुअल मशीन पर चलने वाले एप्लिकेशन के लिए एक लोकप्रिय मेमोरी लीक डिटेक्शन टूल है।
• nmon (निगेल मॉनिटर के लिए संक्षिप्त) AIX और Linux ऑपरेटिंग सिस्टम के लिए एक लोकप्रिय सिस्टम मॉनिटर टूल है।

इस पृष्ठ में अनुपलब्ध आंतरिक कड़ियों की सूची

• सॉफ्टवेयर उम्र बढ़ने
• स्मृति प्रबंधन
• शारेड मेमोरी
• स्यूडोकोड
• लिफ़्ट
• बाउंड चेकर
• सी++
• नल पॉइंटर
• अदा (प्रोग्रामिंग भाषा)
• संदर्भ गिनती
• दस्तावेज़ वस्तु मॉडल
• शोषण (कंप्यूटर सुरक्षा)
• सर्विस अटैक से इनकार

बाहरी संबंध

• Visual Leak Detector Archived 2015-12-15 at the Wayback Machine for Visual Studio, open source
• Valgrind, open source
• Deleaker for Visual Studio, proprietary
• Detecting a Memory Leak (Using MFC Debugging Support)
• Article "Memory Leak Detection in Embedded Systems" by Cal Erickson
• WonderLeak, a high performance Windows heap and handle allocation profiler, proprietary