2009-10-19 16 views
11

सीएलआर प्रोफाइलर यह भी बता सकता है कि कौन सी विधियां आपके अपेक्षा से अधिक संग्रहण आवंटित करती हैं, और उन मामलों को उजागर कर सकती हैं जहां आप अनजाने में बेकार ऑब्जेक्ट ग्राफ़ के संदर्भ रखते हैं जिन्हें अन्यथा जीसी द्वारा पुनः दावा किया जा सकता है। (एक आम समस्या डिजाइन पैटर्न उन सॉफ़्टवेयर कैश या लुकअप टेबल है जिन्हें अब आवश्यकता नहीं है या बाद में पुनर्निर्माण के लिए सुरक्षित हैं। यह दुखद है जब कैश ऑब्जेक्ट ग्राफ़ को उनके उपयोगी जीवन से पहले जीवित रखता है। इसके बजाय, बाहर निकलना सुनिश्चित करें वस्तुओं के लिए संदर्भ तुम अब जरूरत है) -। Writing Faster Managed Codeसी #: आपको किस मामले में संदर्भों को रद्द करना चाहिए?

मुझे नहीं लगता कि मैं वास्तव में पहले कभी एक संदर्भ बाहर nulled गए हैं। मुझे लगता है कि आपको हमेशा ऐसा करने की ज़रूरत नहीं है, लेकिन मुझे लगता है कि ऐसा करने के लिए भी याद रखना महत्वपूर्ण है। लेकिन, वह क्या मामला है? आपको संदर्भों को कब हटा देना चाहिए?

उत्तर

11

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

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

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

+0

समझ में आता है। सोचो कि मैंने इस तरह से बहुत कुछ किया है, बस इसके बारे में सोचने के बिना। – Svish

4

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

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

+0

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

1

आपको उस ऑब्जेक्ट के संदर्भों को रद्द करना चाहिए जिनकी आपको आवश्यकता नहीं है, जब आपको पता चलेगा कि वे अन्यथा एकत्रित कचरा नहीं होंगे।

यदि आपके पास Effective Java पुस्तक है, तो आइटम 5 पर देखें, स्टैक कार्यान्वयन का एक उदाहरण है जिसमें स्मृति रिसाव है क्योंकि ऑब्जेक्ट संदर्भों को हटाया नहीं जाता है। अगर आपके पास वह पुस्तक नहीं है, तो आप उस पुस्तक को Google पुस्तकें here पर देख सकते हैं।

+0

उस पुस्तक में अच्छा उदाहरण :) – Svish

संबंधित मुद्दे