जावा - बेनामी इनर क्लास लाइफ साइकिल

Question

जब एक संपत्ति आंतरिक श्रेणी के रूप में अज्ञात आंतरिक वर्ग का उपयोग करते हैं तो ऑब्जेक्ट लाइफ चक्र में किस बिंदु पर कक्षा कचरा एकत्र किया जाता है? युक्त कक्षा (सेटिंग्स नोड) के बाद पुनः दावा किया गया है? क्या मुझे स्पष्ट श्रेणी (सेटिंग्स नोड) के अंतिमकर्ता में PropertyChangeListener को स्पष्ट रूप से हटा देना चाहिए?

public class SettingsNode extends AbstractNode 
{ 
    public SettingsNode(Project project, ProjectSettings projectSettings) 
     throws IntrospectionException 
    { 
     // use an anonymous inner class to listen for changes 
     projectSettings.addPropertyChangeListener(ProjectSettings.PROP_NAME, 
      new PropertyChangeListener() 
      { 
       @Override 
       public void propertyChange(PropertyChangeEvent evt) 
       { 
        // handle event 
       } 
      }); 
    } 
} 

Answer 1

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

इस विशेष मामले में, यह तब होगा जब projectSettings या तो removePropertyListener() करता है या स्वयं कचरा एकत्र होता है।

क्योंकि projectSettings गुमनाम आंतरिक वर्ग का संदर्भ देता है और क्योंकि आंतरिक वर्ग अपनी कक्षा का संदर्भ देता है, जिसका अर्थ है कि युक्त कक्षा कम से कम आंतरिक कक्षा के रूप में भी रहती है।

Answer 2

आप प्रोजेक्ट सेटिंग ऑब्जेक्ट में प्रॉपर्टी चेंज लिस्टनर क्लास जोड़ रहे हैं। जब तक ProjectSettings इसका संदर्भ देता है तब तक PropertyChangeListener को तब तक एकत्र नहीं किया जाएगा।

Answer 3

उदाहरण में आपने दोनों सेटिंग्स नोड दिखाए हैं और श्रोता को पुन: दावा नहीं किया जा सकता है जब तक कि परियोजना सेटिंग्स को पुनः दावा नहीं किया जाता है।

आपको श्रोता को स्पष्ट रूप से हटाने की आवश्यकता होगी लेकिन आपको शायद अंतिम रूप से कहीं अधिक विश्वसनीय दिखना चाहिए।

PropertyNangeListener हटा दिए जाने तक सेटिंग्स नोड पुनः प्राप्त नहीं किया जाएगा। श्रोताओं के लिए अज्ञात वर्गों का उपयोग करना यह स्मृति रिसाव का एक आम कारण है।

संपादित एलेक्स बी से सवाल follwing:

projectSettings आवेदन आप गुमनाम श्रोता नहीं निकाल सकते, जैसा कि आप इसे करने के लिए एक संदर्भ के बाद यह पंजीकृत है की जरूरत नहीं है की जीवन के लिए मौजूद है। एकाधिक सेटिंग्स नोड उदाहरण बनने के बाद वे अपने श्रोताओं को कन्स्ट्रक्टर में जोड़ देंगे लेकिन उन्हें कभी भी हटाया नहीं जाएगा क्योंकि किसी और के पास उनका कोई संदर्भ नहीं है। इसके बाद सेटिंग नोड्स को हटाए जाने से रोक दिया जाएगा साथ ही श्रोताओं के पास सेटिंग्स नोड्स

Answer 4

मेमोरी रिसाव के लिए एक सामान्य परिदृश्य होगा। अंतिम रूप देने की अनुशंसा नहीं करेंगे, क्योंकि यह जीसी में देरी कर सकती है। आप एक साफ अप फ़ंक्शन का पर्दाफाश कर सकते हैं या निपटान और अनधिकृत ओवरराइड कर सकते हैं।

वास्तव में आश्चर्यचकित क्यों कमजोर श्रोता पंजीकरण में स्विंग नहीं बनाया गया है। शायद आप स्रोत फोर्ज में कुछ ओपन सोर्स आज़मा सकते हैं?

Answer 5

यह प्रश्न काफी दिनांकित है।

हालांकि, मैं यहां अधिकांश उत्तरों से सहमत नहीं हूं।

श्रोता को स्पष्ट रूप से हटाने की आवश्यकता नहीं है। इस मामले में, आंतरिक वर्ग PropertyChangeListener ऑब्जेक्ट तब तक लाइव रहेगा जब तक कि युक्त इंस्टेंस सेटिंग्स नोड को एकत्रित किया जाता है।

आप वास्तव में PropertyChangeListener ऑब्जेक्ट को नहीं हटा सकते हैं क्योंकि इसके लिए कोई संदर्भ नहीं रखा गया है।

हालांकि यह सच है कि PropertyChangeListener ऑब्जेक्ट में इसके ऑब्जेक्ट सेटिंग्स नोड का संदर्भ है, जो उस ऑब्जेक्ट को डी-रेफरेंस और कचरा एकत्रित करने से नहीं रोकता है।

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