.NET गारबेज कलेक्टर

हैलो, महान और भयानक फेरीवाले!
जैसा कि मैंने हाल ही में सीखा है, बहुत से लोग नहीं जानते कि कचरा कलेक्टर कैसे काम करता है। हालांकि मैं समझता हूं कि 99% डेवलपर्स को वास्तव में इसकी आवश्यकता नहीं है, लेकिन मैं हर किसी को पसंद करता हूं जो .NET पर एप्लिकेशन विकसित करता है यह जानने के लिए कि यह कैसे काम करता है। इस लेख में मैं संक्षेप में यह बताने का प्रयास करूंगा कि कचरा संग्रहकर्ता वास्तव में कैसे काम करता है।

किसी वस्तु के जीवनकाल के बारे में बुनियादी जानकारी

जैसा कि आप जानते हैं, जब किसी ऑब्जेक्ट को मेमोरी में इनिशियलाइज़ किया जाता है, तो यह ऑब्जेक्ट के लिए आवश्यक स्थान को आवंटित करता है। नए कीवर्ड का उपयोग करने से तथाकथित प्रबंधित ढेर में एक क्लास ऑब्जेक्ट जुड़ जाता है, और ऑब्जेक्ट का एक संदर्भ वापस आ जाता है।
C # में एप्लिकेशन बनाते समय, कोई भी सुरक्षित रूप से मान सकता है कि .NET रनटाइम प्रोग्रामर से सीधे हस्तक्षेप के बिना नियंत्रण हीप का ख्याल रखेगा। वास्तव में, स्मृति के प्रबंधन के लिए " सुनहरा नियम" है:

ऑब्जेक्ट को नए कीवर्ड का उपयोग करके नियंत्रण ढेर में रखें और इसके बारे में भूल जाएं।

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

आइए एक साधारण उदाहरण देखें:

public static void MakeACar() { //  myCar      // Car,      //   Car **  . Car myCar = new Car(); ... } 

ध्यान दें कि कार (myCar) ऑब्जेक्ट का संदर्भ सीधे MakeACar () विधि के अंदर बनाया गया था और इसे परिभाषित दायरे से बाहर पारित नहीं किया गया था (न तो वापसी मूल्य के रूप में, न ही रेफरी / आउट मापदंडों के रूप में)। इसलिए, विधि को कॉल करने के बाद, myCar का लिंक पहुंच से बाहर हो जाएगा, और कार ऑब्जेक्ट कचरा कलेक्टर द्वारा हटाने के लिए एक उम्मीदवार होगा। हालांकि, यह समझा जाना चाहिए कि कोई गारंटी नहीं है कि MakeACar () विधि निष्पादित होने के तुरंत बाद ऑब्जेक्ट हटा दिया जाएगा। फिलहाल यह माना जा सकता है कि सीएलआर वातावरण में अगली बार कचरा संग्रह किया जाता है, हटाने के लिए myCar ऑब्जेक्ट सेट किया जाएगा।

C ++ प्रोग्रामर अच्छी तरह से जानते हैं कि जब तक वे विशेष रूप से ढेर पर वस्तुओं को हटाने का ध्यान नहीं रखते हैं, तब तक "मेमोरी लीक" जल्द ही होने लगेगा। वास्तव में, स्मृति रिसाव की समस्याओं को ट्रैक करना मानव रहित वातावरण में प्रोग्रामिंग के सबसे थकाऊ और लंबे पहलुओं में से एक है।

अनुप्रयोग रूट तत्वों की भूमिका

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

• वैश्विक वस्तुओं के संदर्भ (हालांकि उन्हें C # में अनुमति नहीं है, CIL कोड आपको वैश्विक ऑब्जेक्ट्स रखने की अनुमति देता है
• किसी भी स्थिर वस्तुओं या स्थिर क्षेत्रों के लिंक।
• एप्लिकेशन कोड आधार के भीतर स्थानीय वस्तुओं के लिंक।
• विधि से जुड़े ऑब्जेक्ट पैरामीटर के लिंक।
• अंतिमकरण की प्रतीक्षा में किसी वस्तु के लिंक।
• कोई भी सीपीयू एक वस्तु को संदर्भित करता है।

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

वस्तुओं की उत्पत्ति

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

यह वस्तु जितनी लंबी होती है, उतनी ही अधिक संभावना होती है कि वह वहीं रहेगी।

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

• जनरेशन 0. एक नई, नई स्थित वस्तु की पहचान की गई है जिसे कभी भी कचरा संग्रहण के दौरान हटाने के लिए उपयुक्त नहीं माना गया है।
• सृजन 1. एक ऐसी वस्तु की पहचान करता है जो पहले से ही "बची हुई है" एक कचरा संग्रहण प्रक्रिया है (इसे हटाने के लिए उपयुक्त के रूप में चिह्नित किया गया था, लेकिन ढेर पर पर्याप्त खाली जगह के कारण हटाया नहीं गया था)।
• जनरेशन 2. एक इकाई की पहचान करता है जो एक से अधिक कचरा संग्रह चलाने से बच गई है।

पीढ़ियों को 0 और 1 को पंचांग कहा जाता है।

कचरा इकट्ठा करने वाला पहले उन सभी वस्तुओं का विश्लेषण करता है जो पीढ़ी से संबंधित हैं। 0. यदि उनके हटाने के बाद पर्याप्त मेमोरी शेष है, तो सभी जीवित वस्तुओं की स्थिति पीढ़ी के लिए बढ़ जाती है। 1. यदि पीढ़ी 0 की सभी वस्तुओं की जांच की गई है, लेकिन अतिरिक्त स्थान की आवश्यकता है, तो एक चेक बनाया जाएगा। पीढ़ी की वस्तुएं 1. इस पीढ़ी की वस्तुएं जो जीवित रहने में कामयाब रहीं, वे पीढ़ी की वस्तुएं बन जाएंगी 2. यदि कचरा संग्रहकर्ता को अभी भी मेमोरी की आवश्यकता है, तो पीढ़ी 2 की वस्तुएं कचरा संग्रह से गुजरेंगी। दूसरी पीढ़ी के ऊपर कोई वस्तु नहीं है, तो वस्तुओं की स्थिति नहीं बदलेगी।
पूर्वगामी से, हम यह निष्कर्ष निकाल सकते हैं कि पुराने की तुलना में नई वस्तुओं को तेजी से हटा दिया जाएगा।

.NET 1.0 - .NET 3.5 में समानांतर कचरा संग्रह

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

.NET 4.0 में बैकग्राउंड कचरा संग्रह

और अंत में, मैं आपको .NET 4.0 में कचरा कलेक्टर के सुधार के बारे में बताना चाहूंगा।

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

निष्कर्ष

अंत में, मैं यह कहना चाहूंगा कि .NET कलेक्टर में उपयोग किया जाने वाला कचरा कलेक्टर, कार्यक्रमों के काम को अनुकूलित करने की अनुमति देता है और व्यावहारिक रूप से प्रदर्शन को प्रभावित नहीं करता है।
अगले लेख में मैं आपको बताऊंगा कि आप System.GC नामस्थान का उपयोग करके व्यक्तिगत रूप से कचरा संग्रहण प्रक्रिया का प्रबंधन कैसे कर सकते हैं।

अधिक जानकारी: यहाँ