This question मुझे उत्सुक बना दिया। इस तरह के प्रश्न हमेशा उत्तर देते हैं जैसे "यह आम तौर पर सुरक्षित है लेकिन आपको यह नहीं मानना चाहिए कि ओएस आपके लिए यह करेगा", जो मुझे अच्छी सलाह की तरह लगता है, लेकिन मुझे आश्चर्य है: क्या कोई सक्रिय रूप से विकसित (जारी) है ऑपरेटिंग सिस्टम जो ऐसा नहीं करते हैं?कौन से ऑपरेटिंग सिस्टम प्रोग्राम से बाहर निकलने पर स्मृति मुक्त नहीं करेंगे?
क्या यह ऐसा कुछ है जो डायनासोर (80 के दशक) में वापस तय किया गया था?
संक्षिप्त उत्तर "कोई नहीं" है। यहां तक कि डॉस साल पहले भी एक कार्यक्रम प्रोग्राम समाप्ति पर स्मृति जारी करेगा (केवल पुण्य से कि प्रोग्राम बंद होने पर स्मृति का प्रबंधन नहीं कर रहा था)। मुझे यकीन है कि कोई यह देख सकता है कि कर्नेल मोड कोड ऐप से बाहर निकलने पर अपनी याददाश्त को मुक्त नहीं करता है या वे कुछ अस्पष्ट एम्बेडेड ओएस का उल्लेख कर सकते हैं .... लेकिन आप यह मान सकते हैं कि ऐप-एक्जिट आपके उपयोगकर्ता मोड कोड को प्राप्त करने वाली सभी मेमोरी देता है । (विंडोज 3.x में यह समस्या हो सकती है कि किस आवंटक का उपयोग किया गया था ...)
पुण्य का कारण है कि आपको "अपनी याददाश्त मुक्त करनी चाहिए" यह है कि बड़े पैमाने पर सॉफ्टवेयर इंजीनियरिंग के लिए, आपको विकसित करने का प्रयास करना चाहिए वे घटक जो उनके उपयोग में लचीले होते हैं क्योंकि आप टीम को छोड़ने के बाद लंबे समय तक किसी और को अपने कोड के उपयोग को बदलने के बारे में नहीं जानते हैं।
इस तरह के बारे में सोचें। आइए मान लें कि आप कुछ वर्ग तैयार करते हैं जो एक सिंगलटन बनने के लिए डिज़ाइन किया गया है (केवल ऐप जीवनकाल के दौरान तुरंत चालू)। इस प्रकार, आप तय करते हैं कि जब आपका घटक नष्ट हो जाता है या अंतिम रूप दिया जाता है तो स्मृति सफाई के साथ परेशान न करें। यह उस पल के लिए एक बिल्कुल अच्छा निर्णय है। सालों बाद, आप हिरण के चरागाहों के लिए छोड़ने के बाद, कोई और साथ आ सकता है और फैसला कर सकता है कि उन्हें अपनी कक्षा का उपयोग कई स्थानों पर करने की आवश्यकता है जैसे कई उदाहरण आते हैं और ऐप के जीवनकाल के दौरान जाते हैं। आपकी स्मृति रिसाव उनकी समस्या बन जाएगी।
मेरी टीम पर, हमने अक्सर उपयोगकर्ता को "क्लोज़" शुरू करने के बारे में बात की है, बिना किसी सफाई के बाहर निकालें()। यदि हम कभी ऐसा करते हैं, तो भी मैं यह लागू करता हूं कि टीम कक्षाओं और घटकों को विकसित करे जो स्वयं के बाद उचित रूप से सफाई करें।
+1। मुझे लगता है कि आप यह बताकर जारी रखते हैं कि मेमोरी लीक के लिए कोई बहाना क्यों नहीं है। – stinky472
हालांकि ऑपरेटिंग सिस्टम द्वारा मेमोरी साफ हो जाएगी, फिर भी 'निकास()' के लिए एक सीधी कॉल अभी भी लीक का कारण बन सकती है (और इसलिए "बंद" की प्रतिक्रिया के रूप में उचित नहीं है)। ऐसे गैर-स्मृति संसाधन हैं जो शायद ऑपरेटिंग सिस्टम (जैसे फ़ाइल-लॉक) द्वारा साफ़ नहीं किए जाएंगे। – Mankarse
कोई हालिया यूनिक्स जैसी ऑपरेटिंग सिस्टम प्रक्रिया समाप्त होने पर सभी प्रक्रिया मेमोरी को मुक्त करने में विफल रहता है, जहां हाल ही में शायद "1 9 70 या उससे भी अधिक" का अर्थ है। मुझे पूरा यकीन है कि बहुत पुराने पीसी ऑपरेटिंग सिस्टम जैसे कि डॉस और सीपी/एम में यह समस्या थी, और विंडोज के कुछ पुराने संस्करण थे। मुझे यकीन है कि हाल ही में विंडोज़ के बारे में पर्याप्त जानकारी नहीं है, लेकिन मुझे आश्चर्य होगा कि अगर किसी भी विंडोज एक्सपी, विस्टा या विंडोज 7 में प्रक्रिया मेमोरी को मुक्त करने में कोई समस्या होगी।
अंगूठे के नियम के रूप में, मैं सुझाव दूंगा कि किसी भी ऑपरेटिंग सिस्टम जो प्रक्रियाओं को अलग करने के लिए वर्चुअल मेमोरी का उपयोग नहीं करता है, अलग-अलग पता रिक्त स्थान संभावित प्रक्रियाओं में विफल होने पर स्मृति को लीक करने के लिए कमजोर हो सकता है। एक बार ओएस ने प्रति-प्रक्रिया वर्चुअल एड्रेस रिक्त स्थान लागू किए हैं, फिर भी इसे किसी भी प्रक्रिया में आवंटित सभी भौतिक स्मृति का ट्रैक रखना होगा, इसलिए इसे विश्वसनीय रूप से मुक्त करना सरल है।
जो कुछ भी कहा गया है, वैसे भी अपने कार्यक्रमों को लिखने के लिए अक्सर एक अच्छा विचार है। यह बेहतर डिज़ाइन किए गए सबकंपोनेंट्स का कारण बनता है, और यह मेमोरी लीक और इसी तरह के टूल को लागू करना भी आसान बनाता है।
डॉस को यह समस्या नहीं थी, और मुझे संदेह है कि सीपी/एम ने भी किया था। कार्यक्रम निकास बस सूचक को अगली आवंटित करने के लिए पॉइंटर को रीसेट करें, जिसका अर्थ यह है कि कार्यक्रम में आवंटित किसी भी स्मृति को अगले प्रोग्राम द्वारा चलाने के लिए ओवरराइट किया जाएगा। –
सीपी/एम में, यह स्मृति को मुक्त करने की बात नहीं थी, क्योंकि आपके प्रोग्राम के लिए रैम का स्थिर क्षेत्र था, और प्रत्येक प्रोग्राम एक ही स्थान पर चला। इसलिए, जब प्रोग्राम ए छोड़ दिया गया, और प्रोग्राम बी भाग गया, बी को बस ए
पर शीर्ष पर लोड किया गया था अब ओएस से स्मृति को आरक्षित करने के लिए तंत्र थे, लेकिन यह आमतौर पर ढेर स्मृति नहीं था (क्लासिक में अगर हम इसे आज मानते हैं), यह विभिन्न कार्यों के लिए विशेष आरक्षित क्षेत्रों का डिजाइन था।
उदाहरण के लिए, डॉस के पास "टर्मिनेट और स्टे रेजीडेंट" नामक यह निकास दिनचर्या थी। इस कार्यक्रम को "छोड़ दिया", लेकिन प्रोग्राम छोड़ने के बाद अंतरिक्ष को रिहा नहीं किया। आम तौर पर इन कार्यक्रमों ने दिनचर्या को ट्रिगर करने के लिए इंटरप्ट वैक्टर (जैसे कि कीबोर्ड इंटरप्ट्स) को लोड किया। बोरलैंड साइडकिक दिन में बहुत लोकप्रिय "टीएसआर" था और कैलकुलेटर और संपर्क सूची जैसी चीज़ों की पेशकश की।
अंत में, चूंकि ये स्मृति प्रणालियों की रक्षा नहीं किए गए थे, इसलिए आपके प्रोग्राम सिस्टम को आप जो भी चाहते हैं उसे करने के सभी तरीकों से दुरुपयोग कर सकते हैं, लेकिन यह एक अलग चर्चा है।
भविष्य के पाठकों के संदर्भ के लिए: डॉस "बाहर निकलें" syscalls 'int 21h (ah = 4ch)', 'int 20h' और' int 21h (ah = 0) 'int 21h (ah = 48h) द्वारा आवंटित मुक्त मेमोरी करें' , "टीएसआर" 'int 21h (आह = 31h) 'के विपरीत, जो नहीं करता है। – Ruslan
विंडोज़ पर एक समान समस्या है: अस्थायी फ़ाइलें। अधिकांश प्रोग्राम जिन्हें उनके परिचालनों के लिए अतिरिक्त मेमोरी की आवश्यकता होती है (और उन कंप्यूटरों पर चलें जिनमें पर्याप्त स्मृति नहीं हो) अस्थायी फ़ाइलों का उपयोग करें। यह देखते हुए कि किसी प्रोग्राम को क्रैश करने या उपयोगकर्ता द्वारा समाप्त करने के लिए कितना आसान है, अस्थायी फ़ाइलें साफ़ नहीं हो रही हैं। – rwong