.NET में उपयोग के बाद वस्तुओं को शून्य / कुछ भी करने के लिए सेट करना

Question

एक बार जब आप उनके साथ समाप्त कर लें, तो क्या आपको null( NothingVB.NET में) सभी वस्तुओं को सेट करना चाहिए ?

मैं समझता हूं कि .NET में वस्तुओं के किसी भी उदाहरण का निपटान करना आवश्यक है जो IDisposableकुछ संसाधनों को जारी करने के लिए इंटरफ़ेस को लागू करता है, हालांकि वस्तु के निपटान के बाद भी वस्तु कुछ हो सकती है (इसलिए isDisposedरूपों में संपत्ति), इसलिए मुझे लगता है कि यह अभी भी निवास कर सकता है स्मृति में या कम से कम भाग में?

मुझे यह भी पता है कि जब कोई वस्तु स्कोप से बाहर जाती है तो उसे कचरा संग्रहकर्ता के पास के लिए तैयार संग्रह के लिए चिह्नित किया जाता है (हालांकि इसमें समय लग सकता है)।

तो इसके साथ दिमाग nullमें मेमोरी को जारी करने की प्रणाली को गति देने के लिए इसे स्थापित किया जाएगा क्योंकि यह काम नहीं करना है कि यह अब दायरे में नहीं है और क्या वे कोई बुरे दुष्प्रभाव हैं?

MSDN लेख कभी भी उदाहरणों में ऐसा नहीं करते हैं और वर्तमान में मैं ऐसा करता हूं क्योंकि मैं नुकसान नहीं देख सकता। हालाँकि मैं राय के मिश्रण में आया हूँ इसलिए कोई भी टिप्पणी उपयोगी है।

Comments

+1 महान प्रश्न। क्या कोई ऐसी परिस्थिति को जानता है जिसके तहत कंपाइलर असाइनमेंट को पूरी तरह से हटा देगा? यानी किसी ने भी एमएसआईएल को अलग-अलग परिस्थितियों में देखा है और आईएल को अशक्त (या उसके अभाव) वस्तु की स्थापना के लिए नोट किया है।

— टिम मेडोरा

Answer 1

कार्ल बिल्कुल सही है, उपयोग के बाद वस्तुओं को अशक्त करने की कोई आवश्यकता नहीं है। यदि कोई ऑब्जेक्ट लागू होता है IDisposable, तो सुनिश्चित करें कि IDisposable.Dispose()जब आप उस ऑब्जेक्ट के साथ काम कर रहे हों (एक try.. finally, या, using()ब्लॉक में लिपटे हुए )। लेकिन यहां तक ​​कि अगर आपको कॉल करना याद नहीं है Dispose(), तो ऑब्जेक्ट पर अंतिम विधि Dispose()आपके लिए कॉल करना चाहिए ।

मैंने सोचा कि यह एक अच्छा इलाज था:

आईडीसोपायरी में खुदाई

और इस

आईडिस्पोजल को समझना

जीसी और इसकी प्रबंधन रणनीतियों का अनुमान लगाने की कोशिश करने का कोई मतलब नहीं है क्योंकि यह स्वयं ट्यूनिंग और अपारदर्शी है। यहाँ जेफरी रिक्टर के साथ डॉट नेट रॉक्स पर आंतरिक कामकाज के बारे में अच्छी चर्चा थी: जेफ़री रिक्टर ने विंडोज मेमोरी मॉडल और रिचर्स पुस्तक सीएलआर पर सी # अध्याय 20 के माध्यम से एक महान उपचार किया है:

Comments

नल को सेट न करने के बारे में नियम "कठिन और तेज़" नहीं है ... यदि ऑब्जेक्ट बड़े ऑब्जेक्ट के ढेर पर रखा जाता है (आकार है> 85K) तो यह जीसी की मदद करेगा यदि आप ऑब्जेक्ट को शून्य करने के लिए सेट करते हैं जब आप काम करते हैं उसका इस्तेमाल कर रहे हैं।

— स्कॉट डोरमैन

मैं एक सीमित सीमा तक सहमत हूं, लेकिन जब तक आप स्मृति दबाव का अनुभव करना शुरू नहीं करते हैं तब मुझे उपयोग के बाद वस्तुओं को शून्य करने के लिए समय से पहले अनुकूलन करने की कोई आवश्यकता नहीं है।

— केव

"समय से पहले अनुकूलन न करें" का यह पूरा कारोबार "धीमे को प्राथमिकता दें और चिंता न करें क्योंकि सीपीयू तेजी से हो रहा है और सीआरयूडी ऐप्स को वैसे भी गति की आवश्यकता नहीं है।" यह सिर्फ मुझे हालांकि हो सकता है। :)

— BobbySftftoe

इसका वास्तव में मतलब यह है कि "कचरा संग्रहकर्ता आपकी स्मृति से बेहतर है।" हालांकि यह सिर्फ मुझे हो सकता है। :)

— बॉब रोड्स

@ बॉबीशैफ्टो: यह कहना शायद उतना ही गलत है कि "समय से पहले अनुकूलन खराब होता है, हमेशा" जैसा लगता है कि '' धीमी गति पसंद है '' के विपरीत चरम पर कूदना है। कोई भी उचित प्रोग्रामर नहीं कहेगा। यह बारीकियों के बारे में है और आपके अनुकूलन के बारे में होशियार है। मैं व्यक्तिगत रूप से कोड स्पष्टता के बारे में चिंता करूँगा और कुछ हद तक परीक्षण प्रदर्शन करूँगा क्योंकि मैंने व्यक्तिगत रूप से बहुत सारे लोगों को देखा है (अपने आप को शामिल करते हुए जब मैं छोटा था) "सही" एल्गोरिथ्म बनाने में बहुत अधिक समय व्यतीत करते हैं, केवल इसे बचाने के लिए 0.1ms 100,000 पुनरावृत्तियों में, जबकि पठनीयता पूरी तरह से शूट की गई थी।

— ब्रेंट रिटेनहाउस

Answer 2

जब आप उनके साथ किए जाते हैं, तो वस्तुओं को अशक्त करने से बचने का एक और कारण यह है कि यह वास्तव में उन्हें लंबे समय तक जीवित रख सकता है।

जैसे

void foo()
{
    var someType = new SomeType();
    someType.DoSomething();
    // someType is now eligible for garbage collection         

    // ... rest of method not using 'someType' ...
}

किसी चीज़ द्वारा निर्दिष्ट वस्तु को "DoSomething" के लिए कॉल के बाद GC'd होने की अनुमति देगा, लेकिन

void foo()
{
    var someType = new SomeType();
    someType.DoSomething();
    // someType is NOT eligible for garbage collection yet
    // because that variable is used at the end of the method         

    // ... rest of method not using 'someType' ...
    someType = null;
}

कभी-कभी विधि के अंत तक वस्तु को जीवित रख सकते हैं। JIT आमतौर पर अशक्त करने के लिए काम दूर अनुकूलित करेंगे , तो ऊपर ही जा रहा है कोड अंत के दोनों बिट्स।

Comments

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

— गुरु जोश

सुनिश्चित करें कि वे जिंदा रहने के लिए पसंदीदा तरीका उपयोग करने के लिए है GC.KeepAlive(someType); देखें ericlippert.com/2013/06/10/construction-destruction

— NotMe

Answer 3

कोई भी अशक्त वस्तु नहीं। आप अधिक जानकारी के लिए http://codebetter.com/blogs/karlseguin/archive/2008/04/27/foundations-of-programming-pt-7-back-to-basics-memory.aspx देख सकते हैं, लेकिन चीजें सेट कर सकते हैं अपने कोड को गंदा करने के अलावा, कुछ भी करने के लिए अशक्त नहीं करेंगे।

Comments

साझा लिंक में स्मृति के बारे में अच्छा और विस्तार से विवरण

— user2323308

लिंक टूट गया। लिंक की गई सामग्री के बिना, यह उत्तर बल्कि useles है और इसे हटा दिया जाना चाहिए।

— इमरे पुवेल

Answer 4

इसके अलावा:

using(SomeObject object = new SomeObject()) 
{
  // do stuff with the object
}
// the object will be disposed of

Answer 5

सामान्य तौर पर, उपयोग के बाद वस्तुओं को शून्य करने की कोई आवश्यकता नहीं है, लेकिन कुछ मामलों में मुझे लगता है कि यह एक अच्छा अभ्यास है।

यदि कोई वस्तु IDis प्रयोज्य को लागू करती है और उसे किसी फ़ील्ड में संग्रहीत किया जाता है, तो मुझे लगता है कि इसे हटाने के लिए अच्छा है, बस विवादित वस्तु के उपयोग से बचने के लिए। निम्नलिखित प्रकार के कीड़े दर्दनाक हो सकते हैं:

this.myField.Dispose();
// ... at some later time
this.myField.DoSomething();

फ़ील्ड को डिस्पोज़ करने के बाद उसे खाली करना अच्छा होता है, और उस लाइन पर NullPtrEx प्राप्त करें जहां फ़ील्ड का फिर से उपयोग किया जाता है। अन्यथा, आप लाइन के नीचे कुछ गुप्त बग में दौड़ सकते हैं (बिल्कुल DoSomething के आधार पर)।

Comments

यदि किसी वस्तु का पहले ही निस्तारण हो चुका हो, तो किसी निस्तारण योग्य वस्तु को ObjectDisposedException को फेंक देना चाहिए। यह, जहां तक ​​मुझे पता है, सभी जगह बॉयलरप्लेट कोड की आवश्यकता होती है, लेकिन फिर से, वैसे भी डिस्प्स्ड एक बुरी तरह से सोचा हुआ प्रतिमान है।

— निकोडेमस 13

Ctrl + F के लिए .Dispose()। यदि आप इसे ढूंढते हैं, तो आप सही तरीके से आईडीसिसोपयोगी उपयोग नहीं कर रहे हैं। डिस्पोजेबल ऑब्जेक्ट के लिए एकमात्र उपयोग एक ब्लॉक-ब्लॉक के परिसीमन में होना चाहिए। और उपयोग-ब्लॉक के बाद, आपके पास myFieldअब तक पहुंच भी नहीं है। और उपयोग करने वाले ब्लॉक के भीतर, सेटिंग की nullआवश्यकता नहीं है, उपयोग-ब्लॉक आपके लिए ऑब्जेक्ट का निपटान करेगा।

— सुमेरे

Answer 6

संभावना है कि यदि आप nullचर की आवश्यकता महसूस करते हैं तो आपका कोड पर्याप्त रूप से संरचित नहीं है ।

एक चर के दायरे को सीमित करने के कई तरीके हैं:

जैसा कि स्टीव ट्रैंबी ने उल्लेख किया है

using(SomeObject object = new SomeObject()) 
{
  // do stuff with the object
}
// the object will be disposed of

इसी तरह, आप बस घुंघराले कोष्ठक का उपयोग कर सकते हैं:

{
    // Declare the variable and use it
    SomeObject object = new SomeObject()
}
// The variable is no longer available

मुझे लगता है कि किसी भी "शीर्षक" के बिना घुंघराले कोष्ठक का उपयोग करना वास्तव में कोड को साफ करना और इसे और अधिक समझने में मदद करना है।

Comments

मैंने एक बार कस्टम लोकल स्कोप का उपयोग करने की कोशिश की (ज्यादातर एक स्मार्टए $ $)। कंपनी में विस्फोट हो गया।

— सुमेरे

दूसरे नोट पर: ऐसा इसलिए है क्योंकि c # संकलक को स्थानीय-स्कोप किए गए वैरिएबल मिलेंगे जो आईडीसिसोपायरी को लागू करते हैं, और कॉल करेंगे। अपने समय के समाप्त होने पर .Dispose (उस समय का MOST) करें। हालाँकि ... SQL कनेक्शन एक बड़ा समय होता है जब .Dispose () कभी भी अनुकूलित नहीं होता है। कुछ प्रकार हैं जिन पर स्पष्ट ध्यान देने की आवश्यकता होती है, इसलिए मैं व्यक्तिगत रूप से हमेशा चीजों को स्पष्ट रूप से करता हूं, इसलिए मुझे काट नहीं मिलता है।

— सुमेरे

Answer 7

केवल एक बार आपको एक चर को शून्य करने के लिए सेट करना चाहिए, जब चर दायरे से बाहर नहीं जाता है और आपको इसके साथ जुड़े डेटा की आवश्यकता नहीं है। अन्यथा कोई जरूरत नहीं है।

Comments

यह सच है, लेकिन इसका मतलब यह भी है कि आपको शायद अपने कोड को फिर से भरना चाहिए। मुझे नहीं लगता है कि मुझे कभी भी इसके इच्छित दायरे के बाहर एक चर घोषित करने की आवश्यकता है।

— कार्ल सेगिन

यदि "चर" को ऑब्जेक्ट फ़ील्ड शामिल करने के लिए समझा जाता है, तो यह उत्तर बहुत कुछ समझ में आता है। उस मामले में जहां "चर" का अर्थ केवल "स्थानीय चर" (एक विधि का) है, तो हम शायद यहां आला मामलों के बारे में बात कर रहे हैं (उदाहरण के लिए एक विधि जो बहुत लंबे समय तक चलने वाली सामान्य अवधि के लिए चलती है)।

— stakx - अब

Answer 8

सामान्य रूप से अशक्त करने की आवश्यकता नहीं है। लेकिन मान लीजिए कि आपके पास अपनी कक्षा में रीसेट कार्यक्षमता है।

तब आप ऐसा कर सकते हैं, क्योंकि आप दो बार डिस्पोजल को कॉल नहीं करना चाहते हैं, क्योंकि कुछ डिस्पोज को सही तरीके से लागू नहीं किया जा सकता है और System.ObjectDisposed अपवाद को फेंक दें।

private void Reset()
{
    if(_dataset != null)
    {
       _dataset.Dispose();
       _dataset = null;
    }
    //..More such member variables like oracle connection etc. _oraConnection
 }

Comments

एक अलग झंडे के साथ इसे ट्रैक करने के लिए सबसे अच्छा शायद।

— थुलानी चिवंडिक्वा

Answer 9

इस तरह के "उपयोग के बाद वस्तुओं को अशक्त करने की कोई आवश्यकता नहीं है" पूरी तरह से सही नहीं है। इसे निपटाने के बाद आपको कई बार चर को पूरा करने की आवश्यकता होती है।

हाँ, आपको हमेशा कॉल करना चाहिए .Dispose()या .Close()किसी भी चीज़ पर जब यह काम हो। यह फ़ाइल हैंडल, डेटाबेस कनेक्शन या डिस्पोजेबल ऑब्जेक्ट हो।

इससे अलग होना लेज़ीलाड का बहुत ही व्यावहारिक पैटर्न है।

मेरे पास है और instantiated कहो ObjAकी class A। Class Aकी सार्वजनिक संपत्ति PropBहोती है class B।

आंतरिक रूप से, रिक्त करने के लिए और डिफ़ॉल्ट PropBके निजी चर का उपयोग करता है _B। जब PropB.Get()प्रयोग किया जाता है, यह जांच करता है कि देखने के लिए _PropBहै बातिल और अगर ऐसा है, संसाधनों एक दृष्टांत के लिए आवश्यक खोलता Bमें _PropB। यह फिर लौटता है _PropB।

मेरे अनुभव के लिए, यह वास्तव में उपयोगी चाल है।

यदि शून्य करने की आवश्यकता है, तो यदि आप A को किसी तरह से रीसेट या बदल देते हैं, जो कि _PropBपिछले मानों का बच्चा था A, तो आपको निपटाने और शून्य करने की आवश्यकता होगी _PropBताकि LazyLoad सही मान प्राप्त करने के लिए रीसेट कर सके यदि कोड इसकी आवश्यकता है।

यदि आप केवल _PropB.Dispose()और बाद में लाजेल्लाड के सफल होने की उम्मीद करते हैं, तो यह अशक्त नहीं होगा, और आप बासी डेटा को देखेंगे। वास्तव में, आपको इसे Dispose()सुनिश्चित करने के बाद इसे शून्य करना होगा ।

मुझे यकीन है कि यह अन्यथा थे इच्छा है, लेकिन मैं कोड अभी एक के बाद इस व्यवहार का प्रदर्शन मिल गया है Dispose()एक पर _PropBहै, और बुला समारोह है कि निपटान किया के बाहर (और इस प्रकार लगभग क्षेत्र से बाहर), निजी प्रोप अभी भी रिक्त नहीं है और बासी डेटा अभी भी वहाँ है।

आखिरकार, निपटाई गई संपत्ति बाहर निकल जाएगी, लेकिन यह मेरे दृष्टिकोण से गैर-नियतात्मक है।

मुख्य कारण, जैसा कि dbkk अलाउड है कि पैरेंट कंटेनर (के ObjAसाथ PropB) का _PropBदायरा गुंजाइश बना रहा है, इसके बावजूद Dispose()।

Comments

अच्छा उदाहरण दिखा रहा है कि मैन्युअल रूप से नल की स्थापना का अर्थ है कॉलर के लिए अधिक घातक त्रुटि जो एक अच्छी बात है।

— रोल

Answer 10

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

लेकिन इस तरह की चीज केवल लंबे समय तक संग्रह में मायने रखती है। यदि यह जिस फ़ंक्शन में बनाया गया था, उसके अंत तक जीवित रहने वाली कतार नहीं है, तो यह पूरी तरह से बहुत कम मायने रखती है।

कुल मिलाकर, आपको वास्तव में परेशान नहीं करना चाहिए। संकलक और जीसी अपने काम करते हैं ताकि आप अपना कर सकें।

Answer 11

इस लेख पर भी नज़र डालें: http://www.codeproject.com/KB/cs/idisposable.aspx

अधिकांश भाग के लिए, ऑब्जेक्ट को अशक्त करने के लिए कोई प्रभाव नहीं पड़ता है। ऐसा करने के लिए आपको केवल इतना ही सुनिश्चित करना चाहिए कि क्या आप "बड़ी वस्तु" के साथ काम कर रहे हैं, जो आकार में 84K से बड़ा है (जैसे कि बिटमैप्स)।

Answer 12

स्टीफन क्लीरी इस पोस्ट में बहुत अच्छी तरह से समझाते हैं: क्या मुझे वेरिएबल्स को अशक्त करने के लिए कचरा संग्रह में सहायता करना चाहिए?

कहते हैं

इंप्रेशर हाँ के लिए लघु उत्तर, यदि चर एक स्थिर क्षेत्र है, या यदि आप एक एन्यूमरेबल विधि (उपज वापसी का उपयोग कर) या एक एसिंक्रोनस विधि (async और प्रतीक्षा का उपयोग करके) लिख रहे हैं। नहीं तो नहीं।

इसका मतलब यह है कि नियमित तरीकों (गैर-गणना योग्य और गैर-एसिंक्रोनस) में, आप स्थानीय चर, विधि पैरामीटर, या उदाहरण फ़ील्ड को शून्य करने के लिए सेट नहीं करते हैं।

(यहां तक ​​कि अगर आप आईडीसिसोप्लॉट लागू कर रहे हैं। फिर भी, आपको अभी भी चर सेट नहीं करना चाहिए)।

हमें जिस महत्वपूर्ण चीज पर विचार करना चाहिए वह है स्टेटिक फील्ड्स ।

स्थैतिक क्षेत्र हमेशा रूट ऑब्जेक्ट होते हैं , इसलिए उन्हें कचरा कलेक्टर द्वारा हमेशा "जीवित" माना जाता है । यदि कोई स्थिर फ़ील्ड किसी ऐसी ऑब्जेक्ट को संदर्भित करता है जिसकी अब आवश्यकता नहीं है, तो इसे शून्य पर सेट किया जाना चाहिए ताकि कचरा संग्रहकर्ता संग्रह के लिए योग्य समझे।

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

निष्कर्ष:

स्थैतिक क्षेत्र ; यह इसके बारे में। और कुछ भी समय की बर्बादी है ।

Answer 13

मेरा मानना ​​है कि जीसी कार्यान्वयनकर्ताओं के डिजाइन से, आप nulification के साथ GC को गति नहीं दे सकते । मुझे यकीन है कि वे पसंद करते हैं आप कैसे / जब जीसी चलाता है के साथ खुद को चिंता नहीं कर रहा हूँ - इस तरह हर जगह का इलाज यह होने के नाते की रक्षा करने और अधिक देख रहे हैं और आप के लिए बाहर ... (धनुष सिर नीचे, मुट्ठी आकाश को जन्म देती है) .. ।

निजी तौर पर, मैं अक्सर स्पष्ट रूप से चर सेट करता हूं जब मैं उनके साथ स्व-प्रलेखन के रूप में काम करता हूं। मैं घोषणा नहीं करता, उपयोग करते हैं, तो बाद में शून्य करने के लिए सेट करें - मैं तुरंत शून्य कर देता हूं क्योंकि उन्हें अब आवश्यकता नहीं है। मैं स्पष्ट रूप से कह रहा हूं, "मैं आधिकारिक तौर पर आपके साथ कर रहा हूं ... चले गए ..."

क्या एक GC'd भाषा में अशक्त करना आवश्यक है? जीसी के लिए यह मददगार है? शायद हां, शायद नहीं, कुछ के लिए नहीं जानता, डिजाइन से मैं वास्तव में इसे नियंत्रित नहीं कर सकता, और इस संस्करण के साथ आज के जवाब की परवाह किए बिना या, भविष्य के जीसी कार्यान्वयन मेरे नियंत्रण से परे जवाब बदल सकते हैं। साथ ही अगर / जब nulling अनुकूलित किया गया है, तो यह एक फैंसी टिप्पणी की तुलना में थोड़ा अधिक है यदि आप करेंगे।

मुझे लगता है कि अगर यह मेरे इरादे को अगले गरीब मूर्ख को स्पष्ट कर देता है जो मेरे नक्शेकदम पर चलता है, और अगर यह " जीसी " को कभी-कभी " मदद " कर सकता है , तो यह मेरे लिए इसके लायक है। अधिकतर यह मुझे चुस्त और स्पष्ट महसूस कराता है और मोंगो को चुस्त और स्पष्ट महसूस करना पसंद है। :)

मैं इसे इस तरह से देखता हूं: प्रोग्रामिंग भाषाएं मौजूद हैं जो लोगों को दूसरे लोगों को इरादे का एहसास दिलाती हैं और एक कंपाइलर नौकरी के लिए क्या करना चाहिए - कंपाइलर एक सीपीयू के लिए उस अनुरोध को एक अलग भाषा (कभी-कभी कई) में परिवर्तित करता है - CPU (s) आपको एक हूट दे सकता है कि आप किस भाषा का प्रयोग करते हैं, आपकी टैब सेटिंग, टिप्पणियां, शैलीगत आकृतियाँ, चर नाम इत्यादि - एक CPU की बिट स्ट्रीम के बारे में जो यह बताती है कि रजिस्टर और opcodes और मेमोरी लोकेशन को ट्वीड करने के लिए क्या है। कोड में लिखी गई कई चीजें सीपीयू द्वारा हमारे द्वारा निर्दिष्ट अनुक्रम में खपत नहीं होती हैं। हमारे सी, सी ++, सी #, लिस्प, बेबेल, असेंबलर या जो कुछ भी वास्तविकता के बजाय सिद्धांत है, काम के बयान के रूप में लिखा गया है। जो आप देख रहे हैं वह आपको नहीं मिलता, हां, यहां तक ​​कि असेंबलर भाषा में भी।

मैं "अनावश्यक चीजों" (जैसे रिक्त रेखाएं) की मानसिकता को समझता हूं "कुछ भी नहीं बल्कि शोर और अव्यवस्था है।" मेरे करियर में यह पहले था; मैं पूरी तरह से मिलता है। इस मोड़ पर मैं उस ओर झुक गया जो कोड को स्पष्ट करता है। ऐसा नहीं है कि मैं अपने कार्यक्रमों में "शोर" की 50 लाइनें भी जोड़ रहा हूं - यह यहां या वहां कुछ लाइनें हैं।

किसी भी नियम के अपवाद हैं। वाष्पशील स्मृति, स्थिर स्मृति, दौड़ की स्थिति, एकल, "बासी" डेटा के उपयोग और सभी प्रकार के सड़ांध के साथ परिदृश्यों में, यह अलग है: आप अपनी खुद की स्मृति, लॉकिंग और नलिका को एप्रोपोस के रूप में प्रबंधित करने की आवश्यकता है क्योंकि स्मृति का हिस्सा नहीं है GC'd यूनिवर्स - उम्मीद है कि हर कोई समझता है। GC'd भाषाओं के साथ बाकी समय यह आवश्यकता या गारंटी प्रदर्शन को बढ़ावा देने के बजाय स्टाइल की बात है।

दिन के अंत में सुनिश्चित करें कि आप समझते हैं कि जीसी के लिए क्या योग्य है और क्या नहीं; ताला, निपटान और उचित रूप से शून्य करना; वैक्स ऑन वैक्स ऑफ़; सांस अंदर सांस बाहर; और बाकी सब कुछ के लिए मैं कहता हूं: अगर यह अच्छा लगता है, तो करो। आपका माइलेज भिन्न हो सकता है ... जैसा कि यह होना चाहिए ...

Answer 14

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

मेरा मानना ​​है कि फ्रेमवर्क डिस्पोज़ेबल्स ObjectDisposedException को फेंकने की अनुमति देगा जो अधिक सार्थक है। इन कारणों को वापस शून्य पर सेट करना बेहतर नहीं होगा।

Answer 15

कुछ ऑब्जेक्ट मान .dispose()लेते हैं जो संसाधन को स्मृति से निकालने के लिए मजबूर करता है।

Comments

नहीं, यह नहीं है; डिस्पोज़ () ऑब्जेक्ट एकत्र नहीं करता है - इसका उपयोग निर्धारक सफाई को करने के लिए किया जाता है, आमतौर पर अप्रबंधित संसाधनों को जारी करना।

— मार्क Gravell

यह ध्यान में रखते हुए कि नियतत्ववाद केवल प्रबंधित संसाधनों पर लागू होता है, न कि अप्रबंधित (यानी स्मृति) पर

— निकोडेमस 13