मैनुअल मेमोरी प्रबंधन: Difference between revisions
(Created page with "{{Short description|Computer memory management methodology}} {{Multiple issues| {{One source|date=June 2009}} {{Only primary sources|date=July 2018}} {{No footnotes|date=July...") |
(TEXT) |
||
| Line 5: | Line 5: | ||
{{No footnotes|date=July 2018}} | {{No footnotes|date=July 2018}} | ||
}} | }} | ||
[[कंप्यूटर विज्ञान]] में, | [[कंप्यूटर विज्ञान]] में, स्वतः मेमोरी प्रबंधन, प्रोग्रामर द्वारा स्वतः निर्देशों के उपयोग को अप्रयुक्त वस्तुओं, या [[कचरा (कंप्यूटर विज्ञान)|अपशिष्ट (कंप्यूटर विज्ञान)]] की पहचान करने और हटाने के लिए संदर्भित करता है। 1990 के दशक के मध्य तक, उद्योग में उपयोग की जाने वाली अधिकांश [[प्रोग्रामिंग भाषा]]एं स्वतः मेमोरी प्रबंधन का समर्थन करती थी, हालांकि [[कचरा संग्रह (कंप्यूटर विज्ञान)|अपशिष्ट संग्रह (कंप्यूटर विज्ञान)]] 1959 से अस्तित्व में है, जब इसे [[लिस्प (प्रोग्रामिंग भाषा)]] के साथ प्रस्तुत किया गया था। आज, हालांकि, [[जावा (प्रोग्रामिंग भाषा)]] जैसे अपशिष्ट संग्रह वाली भाषाएं तेजी से लोकप्रिय हैं और [[उद्देश्य सी|वस्तुिव C]] और [[स्विफ्ट (प्रोग्रामिंग भाषा)]] भाषाएं स्वत: संदर्भ गणना के माध्यम से समान कार्यक्षमता प्रदान करती हैं। मुख्य रूप से स्वतः रूप से प्रबंधित भाषाएं [[सी (प्रोग्रामिंग भाषा)]] और [[सी ++]] आज भी व्यापक रूप से उपयोग में हैं - [[सी गतिशील स्मृति आवंटन|सी गतिशील मेमोरी आवंटन]] देखें। | ||
== विवरण == | == विवरण == | ||
कई प्रोग्रामिंग | कई प्रोग्रामिंग भाषा स्वतः तकनीकों का उपयोग यह निर्धारित करने के लिए करती हैं कि मुक्त संग्रहागार से एक नई वस्तु कब आवंटित की जाए। C <code>[[malloc|मल्लोक]]</code>फलन का उपयोग करता है ; C++ और Java <code>[[new (C++)|न्यू]]</code> संचालक का उपयोग करते हैं; और कई अन्य भाषाएँ (जैसे कि पायथन) सभी वस्तुओं को मुफ्त संग्रहागार से आवंटित करती हैं। यह निर्धारित करना कि किसी वस्तु को कब बनाया जाना चाहिए ([[वस्तु निर्माण]]) सामान्यतः तुच्छ और अप्रमाणिक है, हालांकि [[वस्तु पूल]] जैसी तकनीकों का मतलब है कि तत्काल उपयोग से पहले एक वस्तु बनाई जा सकती है। वास्तविक चुनौती [[वस्तु विनाश]] है - यह निर्धारित करना कि कब किसी वस्तु की आवश्यकता नहीं है (अर्थात अपशिष्ट है), और इसके अंतर्निहित भंडारण को फिर से उपयोग के लिए मुफ्त संग्रहागार में वापस करने की व्यवस्था करना। स्वतः मेमोरी आवंटन में, यह प्रोग्रामर द्वारा स्वतः रूप से भी निर्दिष्ट किया जाता है; जैसे कार्यों के माध्यम से C में <code>free()</code>, या C ++ में <code>delete</code> संचालक - यह [[स्वचालित चर]] में रखी गई वस्तुओं के स्वत: विनाश के विपरीत है, विशेष रूप से (गैर-स्थैतिक) कार्यों के [[स्थानीय चर]], जो C और C ++ में उनके दायरे के अंत में नष्ट हो जाते हैं। | ||
== | == स्वतः मेमोरी प्रबंधन तकनीक == | ||
{{Expand section|date=January 2022}} | {{Expand section|date=January 2022}} | ||
उदाहरण के लिए | उदाहरण के लिए | ||
* मॉलोक/मुक्त | * मॉलोक/मुक्त | ||
* [[स्मृति अखाड़ा]] | * [[स्मृति अखाड़ा|मेमोरी कार्यक्षेत्र]] | ||
* स्क्रैच बफर | * स्क्रैच बफर | ||
* ... | * ... | ||
== | == स्वतः प्रबंधन और शुद्धता == | ||
{{main| | {{main|स्मृति सुरक्षा}} | ||
स्वतः मेमोरी प्रबंधन को गलत तरीके से उपयोग किए जाने पर प्रोग्राम में बग के कई प्रमुख वर्गों को सक्षम करने के लिए जाना जाता है, विशेष रूप से मेमोरी सुरक्षा या मेमोरी रहस्योद्घाटन का उल्लंघन। ये [[सुरक्षा बग]] का एक महत्वपूर्ण स्रोत हैं। | |||
जो भाषाएँ विशेष रूप से | * जब किसी अप्रयुक्त वस्तु को कभी भी मुफ्त संग्रहागार में वापस नहीं छोड़ा जाता है, इसे मेमोरी रहस्योद्घाटन के रूप में जाना जाता है। कुछ स्तिथियों में, [[स्मृति रिसाव|मेमोरी रिसाव]] सहनीय हो सकता है, जैसे कि एक प्रोग्राम जो अपने जीवनकाल में सीमित मात्रा में मेमोरी को रहस्योद्घाटन करता है, या एक लघु-संचालन प्रोग्राम जो एक [[ऑपरेटिंग सिस्टम|संचालन प्रणाली]] पर निर्भर करता है जब वह समाप्त होने पर अपने संसाधनों को हटा देता है। हालाँकि, कई स्तिथियों में लंबे समय तक चलने वाले कार्यक्रमों में मेमोरी रहस्योदघाटित होती है, और ऐसे स्तिथियों में मेमोरी की असीमित मात्रा रहस्योदघाटित हो जाती है। जब ऐसा होता है, तो उपलब्ध मुफ्त संग्रहागार का आकार समय के साथ घटता रहता है; जब यह अंततः समाप्त हो जाता है, तब प्रोग्राम ध्वस्त हो जाता है। | ||
* [[गतिशील स्मृति प्रबंधन|गतिशील मेमोरी प्रबंधन]] प्रणाली की भयावह विफलता का परिणाम तब हो सकता है जब किसी वस्तु की पश्च मेमोरी को उसके नीचे से एक से अधिक बार हटा दिया जाता है; एक वस्तु स्पष्ट रूप से एक से अधिक बार नष्ट हो जाती है; जब, मुफ्त संग्रहागार पर आवंटित नहीं की गई वस्तु में प्रकलन करने के लिए एक सूचक का उपयोग करते समय, एक प्रोग्रामर उक्त सूचक के लक्ष्य वस्तु की पश्च मेमोरी को अ'''वमुक्त करने का प्रयास क'''रता है; या जब, किसी वस्तु को सूचक के माध्यम से दूसरे में प्रकलन करते समय, किसी अज्ञात बाहरी कार्य, थ्रेड या प्रक्रिया द्वारा प्रबंधित मेमोरी के मनमाना क्षेत्र, एक प्रोग्रामर उस वस्तु की स्थिति को दूषित करता है, संभवतः इस तरह से अपनी सीमाओं के बाहर लिखने और भ्रष्ट करने के लिए इसकी मेमोरी प्रबंधन डेटा। इस तरह की कार्रवाइयों के परिणाम में [[ढेर भ्रष्टाचार]], एक अलग (और नव निर्मित) वस्तु का समय से पहले विनाश शामिल हो सकता है जो मेमोरी में उसी स्थान पर कब्जा करने के लिए होता है, जो कि हटाए गए वस्तु के रूप में होता है, एक विभाजन दोष ([[[[स्मृति सुरक्षा|मेमोरी सुरक्षा]]]] का उल्लंघन) के कारण प्रोग्राम ध्वस्त हो जाता है। और [[अपरिभाषित व्यवहार]] के अन्य रूप। | |||
* हटाए गए वस्तु्स के सूचक्स जंगली सूचक्स बन जाते हैं यदि पोस्ट-डिलीशन का उपयोग किया जाता है; इस तरह के सूचक्स का उपयोग करने का प्रयास करने से मुश्किल-से-निदान बग हो सकते हैं। | |||
जो भाषाएँ विशेष रूप से अपशिष्ट संग्रह (कंप्यूटर विज्ञान) का उपयोग करती हैं, वे दोषों के अंतिम दो वर्गों से बचने के लिए जानी जाती हैं। मेमोरी रहस्योद्घाटन अभी भी हो सकता है (और बाउंडेड रहस्योद्घाटन अक्सर जेनरेशनल या रूढ़िवादी अपशिष्ट संग्रह के साथ होता है), लेकिन आमतौर पर स्वतः प्रणाली में मेमोरी रहस्योद्घाटन से कम गंभीर होता है। | |||
== संसाधन अधिग्रहण प्रारंभ है == | == संसाधन अधिग्रहण प्रारंभ है == | ||
{{main|Resource Acquisition Is Initialization}} | {{main|Resource Acquisition Is Initialization}} | ||
स्वतः मेमोरी प्रबंधन का एक शुद्धता लाभ है, जो यह है कि यह [[संसाधन अधिग्रहण प्रारंभ है]] (RAII) प्रतिमान के माध्यम से स्वचालित [[संसाधन प्रबंधन (कंप्यूटिंग)]] की अनुमति देता है। | |||
यह तब उत्पन्न होता है जब | यह तब उत्पन्न होता है जब वस्तु दुर्लभ [[सिस्टम संसाधन|प्रणाली संसाधन]]ों (जैसे ग्राफिक्स संसाधन, फ़ाइल हैंडल, या डेटाबेस कनेक्शन) के मालिक होते हैं, जिन्हें किसी वस्तु के नष्ट होने पर छोड़ देना चाहिए - जब संसाधन स्वामित्व का जीवनकाल वस्तु के जीवनकाल से बंधा होना चाहिए। स्वतः प्रबंधन वाली भाषाएं वस्तु इनिशियलाइज़ेशन (निर्माणकर्ता में) के दौरान संसाधन प्राप्त करके और वस्तु विनाश ([[विध्वंसक (कंप्यूटर विज्ञान)]] में) के दौरान जारी करके इसे व्यवस्थित कर सकती हैं, जो एक सटीक समय पर होता है। इसे रिसोर्स एक्विजिशन इज़ इनिशियलाइज़ेशन के रूप में जाना जाता है। | ||
इसका उपयोग नियतात्मक संदर्भ गणना के साथ भी किया जा सकता है। सी ++ में, इस क्षमता को अन्यथा | इसका उपयोग नियतात्मक संदर्भ गणना के साथ भी किया जा सकता है। सी ++ में, इस क्षमता को अन्यथा स्वतः ढांचे के भीतर मेमोरी डीलोकेशन को स्वचालित करने के लिए आगे उपयोग करने के लिए रखा जाता है, का उपयोग <code>[[shared_ptr]]</code> मेमोरी प्रबंधन करने के लिए भाषा के मानक पुस्तकालय में टेम्पलेट एक सामान्य प्रतिमान है। <code>shared_ptr</code> हालाँकि, सभी वस्तु उपयोग पैटर्न के लिए उपयुक्त नहीं है। | ||
यह दृष्टिकोण अधिकांश | यह दृष्टिकोण अधिकांश अपशिष्ट एकत्रित भाषाओं में उपयोग करने योग्य नहीं है - विशेष रूप से अपशिष्ट कलेक्टरों का पता लगाने या अधिक उन्नत संदर्भ गिनती - अंतिम रूप से गैर-नियतात्मक होने के कारण, और कभी-कभी बिल्कुल भी नहीं होता है। यही है, यह परिभाषित करना (या निर्धारित करना) मुश्किल है कि कब या एक [[finalizer]] विधि को बुलाया जा सकता है; इसे आमतौर पर [[फाइनलाइज़र समस्या]] के रूप में जाना जाता है। जावा और अन्य GC'd भाषाएं [[निपटान पैटर्न]] के माध्यम से मेमोरी के अलावा दुर्लभ प्रणाली संसाधनों के लिए अक्सर स्वतः प्रबंधन का उपयोग करती हैं: कोई भी वस्तु जो संसाधनों का प्रबंधन करती है, उसे लागू करने की उम्मीद है <code>dispose()</code> विधि, जो ऐसे किसी भी संसाधन को जारी करती है और वस्तु को निष्क्रिय के रूप में चिह्नित करती है। प्रोग्रामर को आमंत्रित करने की उम्मीद है <code>dispose()</code> स्वतः रूप से दुर्लभ ग्राफिक्स संसाधनों के रिसाव को रोकने के लिए उपयुक्त है। निर्भर करना <code>finalize()</code> ग्राफिक्स संसाधनों को जारी करने के लिए विधि (कैसे जावा फाइनलाइज़र लागू करता है) व्यापक रूप से जावा प्रोग्रामर के बीच खराब प्रोग्रामिंग अभ्यास के रूप में देखा जाता है, और इसी तरह <code>__del__()</code> संसाधनों को जारी करने के लिए पायथन में विधि पर भरोसा नहीं किया जा सकता है। स्टैक संसाधनों के लिए (संसाधन प्राप्त किए गए और कोड के एक ब्लॉक के भीतर जारी किए गए), इसे विभिन्न भाषा निर्माणों द्वारा स्वचालित किया जा सकता है, जैसे कि पायथन <code>with</code>, सी#एस <code>using</code> या जावा का <code>try</code>-संसाधनों के साथ। | ||
== प्रदर्शन == | == प्रदर्शन == | ||
स्वतः मेमोरी प्रबंधन के कई समर्थकों का तर्क है कि अपशिष्ट संग्रह (कंप्यूटर विज्ञान) जैसी स्वचालित तकनीकों की तुलना में यह बेहतर प्रदर्शन प्रदान करता है। परंपरागत रूप से विलंबता सबसे बड़ा लाभ था, लेकिन अब ऐसा नहीं है। स्वतः आवंटन में अक्सर संदर्भ का बेहतर स्थान होता है।{{Citation needed|date=December 2011}} | |||
स्वतः आवंटन उन प्रणालियों के लिए अधिक उपयुक्त माना जाता है जहां तेजी से सुधार के कारण मेमोरी एक दुर्लभ संसाधन है। मेमोरी प्रणाली बार-बार थ्रैश कर सकता है और कर सकता है क्योंकि प्रोग्राम के [[कार्य का संग्रह]] का आकार उपलब्ध मेमोरी के आकार तक पहुंचता है; अपशिष्ट-एकत्रित प्रणाली में अप्रयुक्त वस्तुएँ स्वतः रूप से प्रबंधित प्रणालियों की तुलना में लंबे समय तक अप्रयुक्त स्थिति में रहती हैं, क्योंकि वे प्रभावी कार्य सेट आकार को बढ़ाते हुए तुरंत पुनः दावा नहीं किए जाते हैं। | |||
स्वतः प्रबंधन के कई प्रलेखित प्रदर्शन नुकसान हैं: | |||
* को कॉल करता है <code>delete</code> और हर बार जब वे बनाए जाते हैं तो एक ओवरहेड होता है, इस ओवरहेड को | * को कॉल करता है <code>delete</code> और हर बार जब वे बनाए जाते हैं तो एक ओवरहेड होता है, इस ओवरहेड को अपशिष्ट संग्रह चक्रों में परिशोधित किया जा सकता है। यह मल्टीथ्रेडेड एप्लिकेशन के लिए विशेष रूप से सच है, जहां डिलीट कॉल को सिंक्रोनाइज़ किया जाना चाहिए। | ||
* आवंटन दिनचर्या अधिक जटिल और धीमी हो सकती है। कुछ | * आवंटन दिनचर्या अधिक जटिल और धीमी हो सकती है। कुछ अपशिष्ट संग्रह योजनाएँ, जैसे कि [[हीप (स्मृति प्रबंधन)|हीप (मेमोरी प्रबंधन)]] संघनन के साथ, मुफ्त संग्रहागार को मेमोरी की एक साधारण सरणी के रूप में बनाए रख सकती हैं (जैसा कि स्वतः प्रबंधन योजनाओं के लिए आवश्यक जटिल कार्यान्वयन के विपरीत)। | ||
लेटेंसी एक विवादित बिंदु है जो समय के साथ बदल गया है, प्रारंभिक | लेटेंसी एक विवादित बिंदु है जो समय के साथ बदल गया है, प्रारंभिक अपशिष्ट संग्रहकर्ता और सरल कार्यान्वयन स्वतः मेमोरी प्रबंधन की तुलना में बहुत खराब प्रदर्शन करते हैं, लेकिन परिष्कृत आधुनिक अपशिष्ट संग्रहकर्ता अक्सर स्वतः मेमोरी प्रबंधन की तुलना में अच्छा या बेहतर प्रदर्शन करते हैं। | ||
स्वतः आवंटन लंबे ठहराव के समय से ग्रस्त नहीं होता है जो सरल स्टॉप-द-वर्ल्ड अपशिष्ट संग्रह में होता है, हालांकि आधुनिक अपशिष्ट कलेक्टरों में संग्रह चक्र होते हैं जो अक्सर ध्यान देने योग्य नहीं होते हैं।{{Citation needed|date=September 2021}} | |||
स्वतः मेमोरी प्रबंधन और अपशिष्ट संग्रह दोनों ही संभावित असीमित डीललोकेशन समय से ग्रस्त हैं - स्वतः मेमोरी प्रबंधन क्योंकि किसी एक वस्तु को हटाने के लिए इसके सदस्यों को हटाने की आवश्यकता हो सकती है, और इसके सदस्यों के सदस्यों आदि की पुनरावर्ती आवश्यकता हो सकती है, जबकि अपशिष्ट संग्रह में लंबे संग्रह चक्र हो सकते हैं। यह विशेष रूप से [[रीयल-टाइम कंप्यूटिंग]] प्रणाली में एक समस्या है, जहां असीमित संग्रह चक्र सामान्यतः अस्वीकार्य होते हैं; अपशिष्ट संग्राहक को रोककर रीयल-टाइम अपशिष्ट संग्रह संभव है, जबकि रीयल-टाइम स्वतः मेमोरी प्रबंधन के लिए बड़े डीललोकेशन से बचने या स्वतः रूप से डीललोकेशन को रोकने की आवश्यकता होती है। | |||
==संदर्भ== | ==संदर्भ== | ||
Revision as of 23:42, 27 February 2023
 | This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these template messages)
(Learn how and when to remove this template message)
|
कंप्यूटर विज्ञान में, स्वतः मेमोरी प्रबंधन, प्रोग्रामर द्वारा स्वतः निर्देशों के उपयोग को अप्रयुक्त वस्तुओं, या अपशिष्ट (कंप्यूटर विज्ञान) की पहचान करने और हटाने के लिए संदर्भित करता है। 1990 के दशक के मध्य तक, उद्योग में उपयोग की जाने वाली अधिकांश प्रोग्रामिंग भाषाएं स्वतः मेमोरी प्रबंधन का समर्थन करती थी, हालांकि अपशिष्ट संग्रह (कंप्यूटर विज्ञान) 1959 से अस्तित्व में है, जब इसे लिस्प (प्रोग्रामिंग भाषा) के साथ प्रस्तुत किया गया था। आज, हालांकि, जावा (प्रोग्रामिंग भाषा) जैसे अपशिष्ट संग्रह वाली भाषाएं तेजी से लोकप्रिय हैं और वस्तुिव C और स्विफ्ट (प्रोग्रामिंग भाषा) भाषाएं स्वत: संदर्भ गणना के माध्यम से समान कार्यक्षमता प्रदान करती हैं। मुख्य रूप से स्वतः रूप से प्रबंधित भाषाएं सी (प्रोग्रामिंग भाषा) और सी ++ आज भी व्यापक रूप से उपयोग में हैं - सी गतिशील मेमोरी आवंटन देखें।
विवरण
कई प्रोग्रामिंग भाषा स्वतः तकनीकों का उपयोग यह निर्धारित करने के लिए करती हैं कि मुक्त संग्रहागार से एक नई वस्तु कब आवंटित की जाए। C मल्लोकफलन का उपयोग करता है ; C++ और Java न्यू संचालक का उपयोग करते हैं; और कई अन्य भाषाएँ (जैसे कि पायथन) सभी वस्तुओं को मुफ्त संग्रहागार से आवंटित करती हैं। यह निर्धारित करना कि किसी वस्तु को कब बनाया जाना चाहिए (वस्तु निर्माण) सामान्यतः तुच्छ और अप्रमाणिक है, हालांकि वस्तु पूल जैसी तकनीकों का मतलब है कि तत्काल उपयोग से पहले एक वस्तु बनाई जा सकती है। वास्तविक चुनौती वस्तु विनाश है - यह निर्धारित करना कि कब किसी वस्तु की आवश्यकता नहीं है (अर्थात अपशिष्ट है), और इसके अंतर्निहित भंडारण को फिर से उपयोग के लिए मुफ्त संग्रहागार में वापस करने की व्यवस्था करना। स्वतः मेमोरी आवंटन में, यह प्रोग्रामर द्वारा स्वतः रूप से भी निर्दिष्ट किया जाता है; जैसे कार्यों के माध्यम से C में free(), या C ++ में delete संचालक - यह स्वचालित चर में रखी गई वस्तुओं के स्वत: विनाश के विपरीत है, विशेष रूप से (गैर-स्थैतिक) कार्यों के स्थानीय चर, जो C और C ++ में उनके दायरे के अंत में नष्ट हो जाते हैं।
स्वतः मेमोरी प्रबंधन तकनीक
![[icon]](/wiki/File:Wiki_letter_w_cropped.svg){kind=small} | This section needs expansion. You can help by adding to it. (January 2022) |
उदाहरण के लिए
- मॉलोक/मुक्त
- मेमोरी कार्यक्षेत्र
- स्क्रैच बफर
- ...
स्वतः प्रबंधन और शुद्धता
स्वतः मेमोरी प्रबंधन को गलत तरीके से उपयोग किए जाने पर प्रोग्राम में बग के कई प्रमुख वर्गों को सक्षम करने के लिए जाना जाता है, विशेष रूप से मेमोरी सुरक्षा या मेमोरी रहस्योद्घाटन का उल्लंघन। ये सुरक्षा बग का एक महत्वपूर्ण स्रोत हैं।
- जब किसी अप्रयुक्त वस्तु को कभी भी मुफ्त संग्रहागार में वापस नहीं छोड़ा जाता है, इसे मेमोरी रहस्योद्घाटन के रूप में जाना जाता है। कुछ स्तिथियों में, मेमोरी रिसाव सहनीय हो सकता है, जैसे कि एक प्रोग्राम जो अपने जीवनकाल में सीमित मात्रा में मेमोरी को रहस्योद्घाटन करता है, या एक लघु-संचालन प्रोग्राम जो एक संचालन प्रणाली पर निर्भर करता है जब वह समाप्त होने पर अपने संसाधनों को हटा देता है। हालाँकि, कई स्तिथियों में लंबे समय तक चलने वाले कार्यक्रमों में मेमोरी रहस्योदघाटित होती है, और ऐसे स्तिथियों में मेमोरी की असीमित मात्रा रहस्योदघाटित हो जाती है। जब ऐसा होता है, तो उपलब्ध मुफ्त संग्रहागार का आकार समय के साथ घटता रहता है; जब यह अंततः समाप्त हो जाता है, तब प्रोग्राम ध्वस्त हो जाता है।
- गतिशील मेमोरी प्रबंधन प्रणाली की भयावह विफलता का परिणाम तब हो सकता है जब किसी वस्तु की पश्च मेमोरी को उसके नीचे से एक से अधिक बार हटा दिया जाता है; एक वस्तु स्पष्ट रूप से एक से अधिक बार नष्ट हो जाती है; जब, मुफ्त संग्रहागार पर आवंटित नहीं की गई वस्तु में प्रकलन करने के लिए एक सूचक का उपयोग करते समय, एक प्रोग्रामर उक्त सूचक के लक्ष्य वस्तु की पश्च मेमोरी को अवमुक्त करने का प्रयास करता है; या जब, किसी वस्तु को सूचक के माध्यम से दूसरे में प्रकलन करते समय, किसी अज्ञात बाहरी कार्य, थ्रेड या प्रक्रिया द्वारा प्रबंधित मेमोरी के मनमाना क्षेत्र, एक प्रोग्रामर उस वस्तु की स्थिति को दूषित करता है, संभवतः इस तरह से अपनी सीमाओं के बाहर लिखने और भ्रष्ट करने के लिए इसकी मेमोरी प्रबंधन डेटा। इस तरह की कार्रवाइयों के परिणाम में ढेर भ्रष्टाचार, एक अलग (और नव निर्मित) वस्तु का समय से पहले विनाश शामिल हो सकता है जो मेमोरी में उसी स्थान पर कब्जा करने के लिए होता है, जो कि हटाए गए वस्तु के रूप में होता है, एक विभाजन दोष ([[मेमोरी सुरक्षा]] का उल्लंघन) के कारण प्रोग्राम ध्वस्त हो जाता है। और अपरिभाषित व्यवहार के अन्य रूप।
- हटाए गए वस्तु्स के सूचक्स जंगली सूचक्स बन जाते हैं यदि पोस्ट-डिलीशन का उपयोग किया जाता है; इस तरह के सूचक्स का उपयोग करने का प्रयास करने से मुश्किल-से-निदान बग हो सकते हैं।
जो भाषाएँ विशेष रूप से अपशिष्ट संग्रह (कंप्यूटर विज्ञान) का उपयोग करती हैं, वे दोषों के अंतिम दो वर्गों से बचने के लिए जानी जाती हैं। मेमोरी रहस्योद्घाटन अभी भी हो सकता है (और बाउंडेड रहस्योद्घाटन अक्सर जेनरेशनल या रूढ़िवादी अपशिष्ट संग्रह के साथ होता है), लेकिन आमतौर पर स्वतः प्रणाली में मेमोरी रहस्योद्घाटन से कम गंभीर होता है।
संसाधन अधिग्रहण प्रारंभ है
स्वतः मेमोरी प्रबंधन का एक शुद्धता लाभ है, जो यह है कि यह संसाधन अधिग्रहण प्रारंभ है (RAII) प्रतिमान के माध्यम से स्वचालित संसाधन प्रबंधन (कंप्यूटिंग) की अनुमति देता है।
यह तब उत्पन्न होता है जब वस्तु दुर्लभ प्रणाली संसाधनों (जैसे ग्राफिक्स संसाधन, फ़ाइल हैंडल, या डेटाबेस कनेक्शन) के मालिक होते हैं, जिन्हें किसी वस्तु के नष्ट होने पर छोड़ देना चाहिए - जब संसाधन स्वामित्व का जीवनकाल वस्तु के जीवनकाल से बंधा होना चाहिए। स्वतः प्रबंधन वाली भाषाएं वस्तु इनिशियलाइज़ेशन (निर्माणकर्ता में) के दौरान संसाधन प्राप्त करके और वस्तु विनाश (विध्वंसक (कंप्यूटर विज्ञान) में) के दौरान जारी करके इसे व्यवस्थित कर सकती हैं, जो एक सटीक समय पर होता है। इसे रिसोर्स एक्विजिशन इज़ इनिशियलाइज़ेशन के रूप में जाना जाता है।
इसका उपयोग नियतात्मक संदर्भ गणना के साथ भी किया जा सकता है। सी ++ में, इस क्षमता को अन्यथा स्वतः ढांचे के भीतर मेमोरी डीलोकेशन को स्वचालित करने के लिए आगे उपयोग करने के लिए रखा जाता है, का उपयोग shared_ptr मेमोरी प्रबंधन करने के लिए भाषा के मानक पुस्तकालय में टेम्पलेट एक सामान्य प्रतिमान है। shared_ptr हालाँकि, सभी वस्तु उपयोग पैटर्न के लिए उपयुक्त नहीं है।
यह दृष्टिकोण अधिकांश अपशिष्ट एकत्रित भाषाओं में उपयोग करने योग्य नहीं है - विशेष रूप से अपशिष्ट कलेक्टरों का पता लगाने या अधिक उन्नत संदर्भ गिनती - अंतिम रूप से गैर-नियतात्मक होने के कारण, और कभी-कभी बिल्कुल भी नहीं होता है। यही है, यह परिभाषित करना (या निर्धारित करना) मुश्किल है कि कब या एक finalizer विधि को बुलाया जा सकता है; इसे आमतौर पर फाइनलाइज़र समस्या के रूप में जाना जाता है। जावा और अन्य GC'd भाषाएं निपटान पैटर्न के माध्यम से मेमोरी के अलावा दुर्लभ प्रणाली संसाधनों के लिए अक्सर स्वतः प्रबंधन का उपयोग करती हैं: कोई भी वस्तु जो संसाधनों का प्रबंधन करती है, उसे लागू करने की उम्मीद है dispose() विधि, जो ऐसे किसी भी संसाधन को जारी करती है और वस्तु को निष्क्रिय के रूप में चिह्नित करती है। प्रोग्रामर को आमंत्रित करने की उम्मीद है dispose() स्वतः रूप से दुर्लभ ग्राफिक्स संसाधनों के रिसाव को रोकने के लिए उपयुक्त है। निर्भर करना finalize() ग्राफिक्स संसाधनों को जारी करने के लिए विधि (कैसे जावा फाइनलाइज़र लागू करता है) व्यापक रूप से जावा प्रोग्रामर के बीच खराब प्रोग्रामिंग अभ्यास के रूप में देखा जाता है, और इसी तरह __del__() संसाधनों को जारी करने के लिए पायथन में विधि पर भरोसा नहीं किया जा सकता है। स्टैक संसाधनों के लिए (संसाधन प्राप्त किए गए और कोड के एक ब्लॉक के भीतर जारी किए गए), इसे विभिन्न भाषा निर्माणों द्वारा स्वचालित किया जा सकता है, जैसे कि पायथन with, सी#एस using या जावा का try-संसाधनों के साथ।
प्रदर्शन
स्वतः मेमोरी प्रबंधन के कई समर्थकों का तर्क है कि अपशिष्ट संग्रह (कंप्यूटर विज्ञान) जैसी स्वचालित तकनीकों की तुलना में यह बेहतर प्रदर्शन प्रदान करता है। परंपरागत रूप से विलंबता सबसे बड़ा लाभ था, लेकिन अब ऐसा नहीं है। स्वतः आवंटन में अक्सर संदर्भ का बेहतर स्थान होता है।[citation needed] स्वतः आवंटन उन प्रणालियों के लिए अधिक उपयुक्त माना जाता है जहां तेजी से सुधार के कारण मेमोरी एक दुर्लभ संसाधन है। मेमोरी प्रणाली बार-बार थ्रैश कर सकता है और कर सकता है क्योंकि प्रोग्राम के कार्य का संग्रह का आकार उपलब्ध मेमोरी के आकार तक पहुंचता है; अपशिष्ट-एकत्रित प्रणाली में अप्रयुक्त वस्तुएँ स्वतः रूप से प्रबंधित प्रणालियों की तुलना में लंबे समय तक अप्रयुक्त स्थिति में रहती हैं, क्योंकि वे प्रभावी कार्य सेट आकार को बढ़ाते हुए तुरंत पुनः दावा नहीं किए जाते हैं।
स्वतः प्रबंधन के कई प्रलेखित प्रदर्शन नुकसान हैं:
- को कॉल करता है
deleteऔर हर बार जब वे बनाए जाते हैं तो एक ओवरहेड होता है, इस ओवरहेड को अपशिष्ट संग्रह चक्रों में परिशोधित किया जा सकता है। यह मल्टीथ्रेडेड एप्लिकेशन के लिए विशेष रूप से सच है, जहां डिलीट कॉल को सिंक्रोनाइज़ किया जाना चाहिए। - आवंटन दिनचर्या अधिक जटिल और धीमी हो सकती है। कुछ अपशिष्ट संग्रह योजनाएँ, जैसे कि हीप (मेमोरी प्रबंधन) संघनन के साथ, मुफ्त संग्रहागार को मेमोरी की एक साधारण सरणी के रूप में बनाए रख सकती हैं (जैसा कि स्वतः प्रबंधन योजनाओं के लिए आवश्यक जटिल कार्यान्वयन के विपरीत)।
लेटेंसी एक विवादित बिंदु है जो समय के साथ बदल गया है, प्रारंभिक अपशिष्ट संग्रहकर्ता और सरल कार्यान्वयन स्वतः मेमोरी प्रबंधन की तुलना में बहुत खराब प्रदर्शन करते हैं, लेकिन परिष्कृत आधुनिक अपशिष्ट संग्रहकर्ता अक्सर स्वतः मेमोरी प्रबंधन की तुलना में अच्छा या बेहतर प्रदर्शन करते हैं।
स्वतः आवंटन लंबे ठहराव के समय से ग्रस्त नहीं होता है जो सरल स्टॉप-द-वर्ल्ड अपशिष्ट संग्रह में होता है, हालांकि आधुनिक अपशिष्ट कलेक्टरों में संग्रह चक्र होते हैं जो अक्सर ध्यान देने योग्य नहीं होते हैं।[citation needed] स्वतः मेमोरी प्रबंधन और अपशिष्ट संग्रह दोनों ही संभावित असीमित डीललोकेशन समय से ग्रस्त हैं - स्वतः मेमोरी प्रबंधन क्योंकि किसी एक वस्तु को हटाने के लिए इसके सदस्यों को हटाने की आवश्यकता हो सकती है, और इसके सदस्यों के सदस्यों आदि की पुनरावर्ती आवश्यकता हो सकती है, जबकि अपशिष्ट संग्रह में लंबे संग्रह चक्र हो सकते हैं। यह विशेष रूप से रीयल-टाइम कंप्यूटिंग प्रणाली में एक समस्या है, जहां असीमित संग्रह चक्र सामान्यतः अस्वीकार्य होते हैं; अपशिष्ट संग्राहक को रोककर रीयल-टाइम अपशिष्ट संग्रह संभव है, जबकि रीयल-टाइम स्वतः मेमोरी प्रबंधन के लिए बड़े डीललोकेशन से बचने या स्वतः रूप से डीललोकेशन को रोकने की आवश्यकता होती है।
संदर्भ
- Berger, E. D.; Zorn, B. G.; McKinley, K. S. (November 2002). "Reconsidering Custom Memory Allocation" (PDF). Proceedings of the 17th ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications. OOPSLA '02. pp. 1–12. CiteSeerX 10.1.1.119.5298. doi:10.1145/582419.582421. ISBN 1-58113-471-1.
बाहरी संबंध
- The Memory Management Reference
- Richard Jones and Rafael Lins, Garbage Collection: Algorithms for Automated Dynamic Memory Management, Wiley and Sons (1996), ISBN 0-471-94148-4
