स्विंग श्रोता स्मृति रिसाव को कैसे हल करें?

Question

पृष्ठभूमि

तो मैंने पढ़ा है कि स्विंग अनुप्रयोगों के भीतर अक्सर मेमोरी लीक विभिन्न श्रोताओं (माउस, कुंजी, ध्यान, आदि) के उपयोग से उत्पन्न होते हैं। अनिवार्य रूप से, क्योंकि आप किसी ऑब्जेक्ट को श्रोता के रूप में पंजीकृत करते हैं और ऑब्जेक्ट को अपंजीकृत करना भूल जाते हैं, नोटिफ़ायर ऑब्जेक्ट के संदर्भ पर होल्डिंग समाप्त होता है, और कुछ स्मृति को रिसाव करता है।

मैं हमारे आवेदन श्रोताओं deregistering नहीं कर रहा था पता था और संभावित समाधानों पर अनुसंधान के एक बिट किया:

मैं इस समस्या से निपटने के लिए एक दृष्टिकोण पाया स्विंग के साथ दृष्टिकोण पर एक WeakReference का उपयोग करते हैं, पूरी जानकारी थी श्रोताओं को here मिल सकता है।

मैं तो कैसे NetBeans प्रपत्र संपादक कोड जनरेट किया गया था साफ करने के लिए के बारे में उत्सुक के बाद श्रोताओं रूप में जोड़ा और पाया कि NetBeans

argTypeComboBox.addItemListener(new java.awt.event.ItemListener() { 
    public void itemStateChanged(java.awt.event.ItemEvent evt) { 
     argTypeComboBoxItemStateChanged(evt); 
    } 
}); 

यानी एक रैपिंग वस्तु के माध्यम से श्रोताओं को पंजीकृत किया गया था लेकिन उत्पन्न कोड किया बन गया removeItemListener पर कॉल करके कभी भी साफ नहीं लगते हैं।

प्रश्न

रैपिंग वस्तु एक कमजोर संदर्भ की तरह कार्य कर रहा है? मेरे लिए ऐसा लगता है कि यह स्मृति की एक छोटी राशि (रैपिंग ऑब्जेक्ट का आकार) रिसाव कर सकता है?

क्या श्रोताओं से निपटने के दौरान आपके पास वैकल्पिक दृष्टिकोण हैं कि यह सुनिश्चित करने के लिए कि जब आप उनके साथ समाप्त हो जाते हैं तो वे हमेशा कचरा इकट्ठा होते हैं?

Answer 1

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

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

मैंने एक बार एक आवेदन के साथ निपटाया, हालांकि, यह एक अलग खिड़की के साथ खुली खिड़कियां पंजीकृत करने जैसे फैंसी चीजें करता था, इसलिए अगर खिड़की बंद हो गई, तो यह अभी भी पंजीकृत था - बड़ी समय मेमोरी रिसाव - ये खिड़कियां नहीं थीं छोटे।

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