सी # भाग 2 में दिलचस्प क्षण

इस लेख में, मैं .Net में मेमोरी में ऑब्जेक्ट्स का प्रतिनिधित्व करने की कुछ विशेषताओं के बारे में बात करना चाहूंगा, कंपाइलरों द्वारा किए गए अनुकूलन, और mynameco कॉमरेड की परंपरा को जारी रखना, जिन्होंने यह लेख लिखा था

यह पोस्ट kulhackers पर केंद्रित नहीं है, इसलिए यदि आप जानते हैं कि एन्यूमरेटर के लिए डिस्पोज़ कॉल डिज़ाइन के साथ कंपाइल का उपयोग करते हुए, कि फ़ार्च ऑपरेटर के लिए काम करने के लिए इंटरफेस का उपयोग करना आवश्यक नहीं है, तो गेटनुमरेटर विधि के लिए सही हस्ताक्षर वाले एन्यूमरेटर को लौटाया जाना आवश्यक है, जिससे एन्युमेटर स्वयं ही परिवर्तनशील होता है ) संरचना, जो एक अप्रत्याशित बग पैदा कर सकती है ... फिर, कृपया अंदर न जाएं और पढ़ें, अपना समय बचाएं, "केजी \", "बॉयन्स" और "कैप्टन ओटके" जैसे पदों को न छोड़ें। मैं बिल्ली के नीचे आराम करने के लिए कहता हूं।

मेमोरी प्रबंधन .Net में

सामान्य तौर पर, इस विषय पर बहुत कुछ लिखा गया है, इसलिए आइए इस संक्षेप में ध्यान दें:

जब आवेदन बस शुरू होता है, तो तथाकथित जीसी जड़ें इसमें बनाई जाती हैं। जड़ों को वस्तुओं का एक ग्राफ बनाने की आवश्यकता होती है जो कुछ इस तरह दिखती है:



एक नियम के रूप में, यह निष्पादन थ्रेड के समानांतर एक अलग थ्रेड में बनाया गया है। इसके अलावा, यह धागा उन वस्तुओं को चिह्नित करता है , जो जीसी जड़ों से पहुंच योग्य नहीं हैं (यदि ऑब्जेक्ट का फिलहाल जड़ों से कोई संदर्भ नहीं है, तो भविष्य में कोई भी इसे संदर्भित नहीं कर सकेगा) "हटाए जाने" के रूप में (चित्र में 9 और 10 नोड्स)। जब प्रोग्राम द्वारा कब्जा की गई मेमोरी एक निश्चित सीमा से अधिक हो जाती है या GC.Collect विधि कहलाती है, तो कचरा संग्रहण स्वयं शुरू हो जाता है।

अधिक जानकारी इस लेख में मिल सकती है।

यह सब क्यों?

लेकिन क्या। तथ्य यह है कि

ऑब्जेक्ट जिस ऑब्जेक्ट को कॉल करता है, उसे निष्पादित करने से पहले किसी ऑब्जेक्ट को हटाया जा सकता है।

मान लीजिए कि हमारे पास इतना सरल वर्ग है:

public class SomeClass { public int I; public SomeClass(int input) { I = input; Console.WriteLine("I = {0}", I); } ~SomeClass() { Console.WriteLine("deleted"); } public void Foo() { Thread.Sleep(1000); Console.WriteLine("Foo"); } } 

और हम इसे इस तरह कहेंगे:

 public class Program { private static void Main() { new Thread(() => { Thread.Sleep(100); GC.Collect(); }) {IsBackground = true}.Start(); new SomeClass(10).Foo(); } }} 

थ्रेड की आवश्यकता है ताकि कलेक्टर ऑब्जेक्ट को संभव होने के तुरंत बाद हटा देगा। वास्तव में, निश्चित रूप से, जीसी को नहीं छूना बेहतर है, जिन आंकड़ों पर यह काम करता है वे बहुत ही बेवकूफ लोगों द्वारा विकसित किए गए थे, और GC.Collect विधि का मैनुअल कॉल केवल परेशान करता है और वास्तुकला की समस्याओं को इंगित करता है।

इस प्रोग्राम को चलाएं और इस आउटपुट को प्राप्त करें (आपको कंपाइलर को ऑप्टिमाइज़ करने की अनुमति देने के लिए रिलीज़ मोड में संकलन करना होगा):

वास्तव में, बेशक, यह प्राप्त करना मुश्किल है, सीएलआर (अच्छी तरह से, या डीएलआर) को इस समय इस विधि को निष्पादित करने का निर्णय लेना चाहिए, लेकिन विनिर्देश के अनुसार यह काफी संभव है!

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

विध्वंसक की विशेषताएं

C # में विध्वंसक: सत्य या मिथक?

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

श्रोताओं से सवाल: फिर क्यों डिसपोज से परेशान हैं अगर C # में ऐसे अद्भुत उपकरण हैं जो C ++ डिस्ट्रक्टर्स से बदतर नहीं हैं?

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

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

  public virtual void Close() //    Stream { this.Dispose(true); GC.SuppressFinalize((object) this); } public void Dispose() { this.Close(); } /// <summary> /// ,        ,     FileStream. /// </summary> [SecuritySafeCritical] ~FileStream() { if (this._handle == null) return; this.Dispose(false); } 

और यह सब क्यों?

और अब, फाइनल की संरचना के बारे में ज्ञान से लैस, हम वस्तुओं को पूरी तरह से "पुनरुत्थान" कर सकते हैं!

हम फाइनल में इस तरह से लिखते हैं:

  ~SomeClass() { Console.WriteLine("deleted"); Program.SomeClassInstance = this; GC.ReRegisterForFinalize(this); } 

और प्रोग्राम को थोड़ा बदलें

  public class Program { public static SomeClass SomeClassInstance; private static void Main() { new Thread(() => { Thread.Sleep(100); GC.Collect(); }) {IsBackground = true}.Start(); var wr = new WeakReference(new SomeClass(10)); Console.WriteLine("IsAlive = {0}", wr.IsAlive); ((SomeClass)wr.Target).Foo(); Console.WriteLine("IsAlive = {0}", wr.IsAlive); } } 

अब, शुरू करने के बाद, हम अंतहीन मुद्रित लाइन हटाई जाती हैं, क्योंकि ऑब्जेक्ट को स्थायी रूप से हटा दिया जाएगा, पुनर्जीवित किया जाएगा, फिर से हटा दिया जाएगा, और इसलिए विज्ञापन infinitum पर ... _{(3 बिट के लिए aegis के साथ कंकाल King'a की तरह थोड़ा सा :))}

फ़ाइनलीज़र को कभी नहीं बुलाया जा सकता है

ठीक है, सबसे सरल बात यह है कि यदि प्रोग्राम कार्य प्रबंधक के माध्यम से या किसी अन्य गैर-कोषेर तरीके से बंद हो जाता है (आईडी प्लस प्रयोज्य पिगी बैंक में)। लेकिन किन अन्य मामलों में इसे नहीं कहा जाएगा?

एक निष्कर्ष के बजाय

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

फाइनल का उपयोग करने पर थोड़ा टिप:

• यदि आपकी कक्षा अप्रबंधित संसाधनों का उपयोग करती है, तो आईडीसोफ़रेबल लागू करना सुनिश्चित करें, और नि: शुल्क संसाधनों को निपटान विधि में
• इसके अलावा, बस के मामले में, आपको एक अंतिम रूप निर्धारित करना चाहिए जो निपटान को बुलाएगा। कहीं न कहीं झूलते संसाधनों से बेहतर फाइनल
• डिस्पोज़ विधि में, GC.SuppressFinalize (यह) को कॉल करना वांछनीय है ; । यह विधि ऑब्जेक्ट को अंतिम रूप देने वाली कतार से हटा देगी, क्योंकि इस वर्ग की वस्तुओं का उपयोग करने के लिए ओवरहेड न्यूनतम होगा, और, वास्तव में, केवल अंतिम कतार में एक अतिरिक्त लिंक जोड़ना होगा।

ठीक है, जैसा कि कॉमरेड मेयरोवप ने सही कहा था

किसी भी अप्रबंधित संसाधन को SafeHandle या CriticalHandle में लपेटा जाना चाहिए। यह आपको अप्रबंधित संसाधन के आरंभ के दौरान AppDomain को उतारने से बचाएगा।

और सुरक्षित आवरणों के माध्यम से अप्रबंधित संसाधनों का उपयोग करने वाले वर्गों को अंतिम रूप देने वालों की आवश्यकता नहीं है - आखिरकार, अंतिम रूप से पहले से ही इन आवरणों में हैं।

पुनश्च शब्दार्थ / वर्तनी / विराम चिह्न / वाक्य रचना / शब्दार्थ / रूपात्मक और अन्य त्रुटियों पर कोई भी टिप्पणी स्वीकार की जाती है।