एक "स्मृति रिसाव" के एनाटॉमी

वोट
159

नेट परिप्रेक्ष्य में:

  • एक क्या है स्मृति रिसाव ?
  • आप कि आपका आवेदन लीक कैसे निर्धारित कर सकते हैं? प्रभाव क्या हैं?
  • आप एक स्मृति रिसाव कैसे रोक सकते हैं?
  • आपके आवेदन स्मृति रिसाव है, यह दूर जाना जब प्रक्रिया बाहर निकल जाता है या मार दिया जाता है करता है? या अपने आवेदन में मेमोरी लीक प्रक्रिया पूरी होने के बाद भी सिस्टम पर अन्य प्रक्रियाओं को प्रभावित करते हैं?
  • और COM इंटरॉप और / या पी के माध्यम से सुलभ अप्रबंधित कोड के बारे में क्या / आह्वान?
01/08/2008 को 16:12
का स्रोत उपयोगकर्ता
अन्य भाषाओं में...                            


15 जवाब

वोट
106

सबसे अच्छा विवरण मैंने देखा है मुफ्त के अध्याय 7 में है प्रोग्रामिंग ई-बुक की नींव

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

आपको पता चल जाएगा कि आप लीक है कि जब आप हो रही OutOfMemoryExceptions शुरू करने या अपने मेमोरी उपयोग आपकी आशा से परे चला जाता है ( परफ़ॉर्मेंस अच्छा स्मृति काउंटर है)।

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

बेशक, एक अच्छी याददाश्त प्रोफाइल आप अपनी वस्तु रेखांकन देखते हैं और देखने के लिए जहां संदर्भ से आ रहे हैं अपनी वस्तुओं के घोंसले / संदर्भित का पता लगाने और क्या जड़ वस्तु जिम्मेदार (है जाएगा लाल गेट चींटियों प्रोफ़ाइल , जेटब्रेन्स dotMemory, memprofiler वास्तव में अच्छा कर रहे हैं विकल्प हैं, या आप केवल-पाठ का उपयोग कर सकते WinDbg और एसओएस , लेकिन मैं दृढ़ता से एक व्यावसायिक / दृश्य उत्पाद की सलाह देते हैं जब तक आप एक असली गुरु हैं)।

मेरा मानना ​​है कि अप्रबंधित कोड अपने ठेठ मेमोरी लीक के अधीन है, सिवाय इसके कि साझा संदर्भ कचरा कलेक्टर द्वारा प्रबंधित कर रहे हैं। मैं इस अंतिम बिंदु के बारे में गलत हो सकता है।

01/08/2008 को 16:28
का स्रोत उपयोगकर्ता

वोट
32

सच पूछिये तो, एक स्मृति रिसाव स्मृति वह यह है कि इस कार्यक्रम के द्वारा "अब नहीं किया" लेने वाली है।

"अब नहीं किया" एक से अधिक अर्थ है, यह मतलब हो सकता है "यह करने के लिए कोई और अधिक संदर्भ", कि है, पूरी तरह से अप्राप्य है, या यह मतलब हो सकता है,, संदर्भित वसूली, अप्रयुक्त लेकिन कार्यक्रम के संदर्भ वैसे भी रहता है। केवल बाद के लिए .NET पर लागू होता है पूरी तरह से प्रबंधित वस्तुओं । हालांकि, सभी वर्गों एकदम सही हैं और कुछ बिंदु पर एक अंतर्निहित अप्रबंधित कार्यान्वयन है कि इस प्रक्रिया के लिए स्थायी रूप से संसाधन रिसाव हो सकता है।

सभी मामलों में, आवेदन अधिक स्मृति सख्ती से जरूरत से खपत करता है। पक्षों प्रभाव, राशि लीक पर निर्भर करता है, कोई नहीं से, अत्यधिक संग्रह की वजह से मंदी के लिए, स्मृति अपवाद की एक श्रृंखला है और अंत में एक घातक आरोपित प्रक्रिया समाप्ति के बाद त्रुटि के जा सकते हैं।

तुम्हें पता है कि एक आवेदन जब निगरानी से पता चलता है कि अधिक से अधिक स्मृति अपनी प्रक्रिया के लिए आवंटित किया जाता है एक स्मृति समस्या है प्रत्येक कचरा संग्रहण चक्र के बाद । ऐसे मामले में, आप या तो स्मृति में बहुत ज्यादा रख रहे हैं, या कुछ अंतर्निहित अप्रबंधित कार्यान्वयन लीक कर रहा है।

सबसे लीक के लिए, संसाधनों जब प्रक्रिया समाप्त हो जाता है बरामद कर रहे हैं, फिर भी कुछ संसाधनों हमेशा कुछ सटीक मामलों में बरामद नहीं कर रहे हैं, GDI कर्सर हैंडल के लिए कुख्यात रहे हैं। बेशक, अगर आप एक interprocess संचार तंत्र है, अन्य प्रक्रिया में आबंटित स्मृति जब तक कि इस प्रक्रिया में यह मुक्त कर देते या समाप्त हो जाता है मुक्त नहीं किया जाएगा।

01/08/2008 को 18:52
का स्रोत उपयोगकर्ता

वोट
28

मुझे लगता है कि और "एक स्मृति रिसाव है क्या" "क्या प्रभाव कर रहे हैं" सवाल अच्छी तरह से पहले से ही उत्तर दिया गया है, लेकिन मैं अन्य प्रश्न पर कुछ और कार्य जोड़ना चाहते थे ...

कैसे कि आपका आवेदन लीक को समझने के लिए

एक दिलचस्प तरीके से खोलने के लिए है परफ़ॉर्मेंस और के लिए निशान जोड़ने सब ढेर में # बाइट और # जनरल 2 संग्रह सिर्फ अपने प्रक्रिया को देख, प्रत्येक मामले में। कोई विशेष सुविधा कसरत कुल बाइट्स में वृद्धि का कारण बनता है, और कहा कि स्मृति अगले जनरल 2 संग्रह के बाद आवंटित रहता है, तो आप कह सकते हैं कि सुविधा स्मृति लीक।

कैसे बचाना है

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

रिसाव चली प्रक्रिया बाहर निकलता है, और क्या COM इंटरॉप के बारे में है?

अपनी प्रक्रिया से बाहर निकलता है, सभी स्मृति इसका पता अंतरिक्ष में मैप किया गया ओएस द्वारा पुन: दावा किया जाता है, सहित किसी भी COM ऑब्जेक्ट DLLs से कार्य किया है। तुलनात्मक रूप से शायद ही कभी, COM ऑब्जेक्ट अलग प्रक्रियाओं से परोसा जा सकता है। इस मामले में, जब आपके प्रक्रिया बाहर निकल जाता है, तब भी आप किसी भी COM सर्वर प्रक्रियाओं है कि आप प्रयोग किया जाता में आबंटित स्मृति के लिए जिम्मेदार हो सकता है।

15/08/2008 को 17:11
का स्रोत उपयोगकर्ता

वोट
18

आप नेट में एक स्मृति रिसाव का निदान करने की जरूरत है, इन कड़ियों की जाँच करें:

http://msdn.microsoft.com/en-us/magazine/cc163833.aspx

http://msdn.microsoft.com/en-us/magazine/cc164138.aspx

उन लेखों अपने प्रक्रिया का एक स्मृति डम्प बनाने का तरीका है और यह कैसे विश्लेषण करने के लिए इतना है कि आप पहले यह तय कर सकते हैं अगर आपके रिसाव अप्रबंधित या प्रबंधित है का वर्णन है, और अगर यह किया जाता है, यह कैसे कहाँ से आ रहा है यह पता लगाने की।

माइक्रोसॉफ्ट भी पैदा दुर्घटना डंप के साथ सहायता करने ADPlus, DebugDiag कहा जाता है को बदलने के लिए एक नए उपकरण है।

http://www.microsoft.com/downloads/details.aspx?FamilyID=28bd5941-c458-46f1-b24d-f60151d875a3&displaylang=en

15/08/2008 को 00:16
का स्रोत उपयोगकर्ता

वोट
18

मैंने किसी चीज़ सभी स्मृति यह पूरा कर लिया है के बाद आवंटित को मुक्त नहीं के रूप में मेमोरी लीक को परिभाषित करेगा। मैं ने पाया है यह अपने आवेदन में तब होगा, जब Windows API और COM (यानी अप्रबंधित कोड है कि यह में एक बग है या सही ढंग से प्रबंधित नहीं किया जा रहा है) का उपयोग कर रहे हैं, ढांचे में और तीसरे पक्ष के घटकों में कर सकते हैं। मैं भी कलम की तरह कुछ वस्तुओं का उपयोग करके समस्या पैदा कर सकता है के बाद tiding नहीं मिली है।

मैं व्यक्तिगत रूप से मेमोरी अपवाद जो कारण हो सकता है, लेकिन डॉट नेट अनुप्रयोगों में मेमोरी लीक करने के लिए अनन्य नहीं हैं में से नुकसान उठाना पड़ा है। (यह OOM भी pinning देखने से आ सकता है लगाए लेख )। आप यह OOM त्रुटियों नहीं मिल रहा है या अगर यह एक स्मृति रिसाव के कारण यह तो एक ही तरीका है आपके आवेदन प्रोफ़ाइल है की पुष्टि की आवश्यकता रहे हैं।

मैं भी कोशिश करते हैं और निम्नलिखित यह सुनिश्चित करना होगा:

क) सब कुछ है कि IDisposable लागू करता है या तो का उपयोग कर निपटान किया जाता है एक अंत में ब्लॉक या कथन का उपयोग इन ब्रश, कलम आदि (कुछ लोगों के अलावा कुछ भी नहीं करने के लिए सब कुछ स्थापित करने के लिए लोगों का तर्क है) शामिल हैं

ख) कुछ भी किसी करीबी विधि अंत में का उपयोग कर फिर से बंद कर दिया है या कथन का उपयोग (है कि हालांकि मैं अगर आप कथन का उपयोग बाहर वस्तु घोषित का उपयोग कर हमेशा पास आधार नहीं है पाया है)

ग) आप अप्रबंधित कोड का उपयोग कर रहे हैं, तो / खिड़कियों एपीआई है कि इन के साथ सही ढंग से करने के बाद निपटा रहे हैं। (कुछ संसाधनों को रिहा करने के तरीकों को साफ किया है)

उम्मीद है की यह मदद करेगा।

01/08/2008 को 18:57
का स्रोत उपयोगकर्ता

वोट
15

Microsoft से CLR प्रोफाइलर का उपयोग http://www.microsoft.com/downloads/details.aspx?familyid=86ce6052-d7f4-4aeb-9b7a-94635beebdda&displaylang=en एक शानदार तरीका है जो वस्तुओं पकड़े हुए हैं स्मृति, क्या निष्पादन प्रवाह होता है निर्धारित करने के लिए है इन वस्तुओं के निर्माण के लिए, और भी निगरानी जो जहां ढेर (विखंडन, LOH, आदि) पर लाइव वस्तुओं।

16/08/2008 को 20:54
का स्रोत उपयोगकर्ता

वोट
14

कैसे काम करता है कचरा कलेक्टर की सबसे अच्छा विवरण जेफ Richters में है सी # के माध्यम से CLR किताब, (अ। 20)। यह पढ़ कैसे समझ वस्तुओं जारी रहती है के लिए एक महान ग्राउंडिंग देता है।

वस्तुओं गलती से पक्ष के सबसे आम कारणों में से एक एक वर्ग outisde घटनाओं hooking द्वारा है। आप एक बाहरी घटना ऊपर हुक हैं

जैसे

SomeExternalClass.Changed += new EventHandler(HandleIt);

और यह करने के घृणाजनक करने के लिए जब आप निपटान, तो SomeExternalClass को अपनी कक्षा में एक रेफरी है भूल जाते हैं।

जैसा कि ऊपर उल्लेख, साइटेक स्मृति प्रोफाइलर आप वस्तुओं आपको संदेह लीक कर रहे हैं की जड़ों दिखा पर उत्कृष्ट है।

लेकिन वहाँ भी एक विशेष प्रकार की जाँच करने के लिए सिर्फ WnDBG का उपयोग किया जाता है (आप यहाँ तक कि जब संलग्न VS.NET तत्काल विंडो में इसका उपयोग कर सकते) एक बहुत ही त्वरित तरीका है:

.loadby sos mscorwks
!dumpheap -stat -type <TypeName>

अब कुछ आपको लगता है कि उस प्रकार की वस्तुओं (जैसे एक विंडो को बंद) निपटान होगा। यह यहाँ काम को चलाई जाने वाली एक डिबग बटन कहीं है करने के लिए है System.GC.Collect()एक दो बार।

तब चलाने के !dumpheap -stat -type <TypeName>फिर से। नंबर नीचे जाना नहीं हुआ, तो या नीचे के रूप में ज्यादा के रूप में आप उम्मीद कर जाना नहीं था, तो आप आगे की जांच पड़ताल के लिए एक आधार है। (मैं एक सेमिनार द्वारा दिए गए इस टिप मिल गया इंगो बेलन )।

27/08/2008 को 15:12
का स्रोत उपयोगकर्ता

वोट
14

मुझे लगता है कि किसी प्रबंधित परिवेश में, एक रिसाव आप के आसपास स्मृति की एक बड़ी हिस्सा करने के लिए एक अनावश्यक संदर्भ रखते हुए किया जाएगा।

01/08/2008 को 16:19
का स्रोत उपयोगकर्ता

वोट
10

क्यों लोगों को लगता है कि नेट में एक स्मृति रिसाव किसी अन्य रिसाव के रूप में ही नहीं है?

एक स्मृति रिसाव जब आप एक संसाधन के लिए देते हैं और न दें यह जाना है। आप दोनों में कामयाब में और अप्रबंधित कोडिंग में ऐसा कर सकते हैं।

नेट के बारे में, और अन्य प्रोग्रामिंग उपकरण, वहाँ कचरा एकत्र करने के बारे में विचार, और स्थितियों है कि आपके आवेदन रिसाव कर देगा को कम करने के अन्य तरीकों किया गया है। लेकिन मेमोरी लीक को रोकने का सबसे अच्छा तरीका है कि आप अपने अंतर्निहित स्मृति मॉडल को समझने की जरूरत है, और कैसे चीजें काम करती है, मंच पर प्रयोग कर रहे हैं।

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

जब अप्रबंधित कोडिंग, आप सामान्य रूप से आप जानते हैं कि संसाधनों आप की पकड़ ले, साफ करने के लिए अपनी जिम्मेदारी है, न कि चौकीदार की हो जाएगा साफ करने के लिए सुनिश्चित करें,।

दूसरी ओर नेट में, बहुत से लोगों को लगता है कि जी सी सब कुछ साफ हो जाएगा। खैर, यह आप के लिए कुछ करता है, लेकिन आप यकीन है कि यह इतना है कि बनाने की जरूरत है। नेट चीजों के बहुत सारे लपेट करता है, ताकि आप हमेशा पता नहीं है अगर आप एक कामयाब रहे या अप्रबंधित संसाधन के साथ काम कर रहे हैं, और आप यकीन है कि क्या तुम क्या साथ काम कर रहे बनाने की जरूरत है। हैंडलिंग फोंट, GDI संसाधन, सक्रिय निर्देशिका, डेटाबेस आदि आम तौर पर चीजें आप के लिए बाहर देखने की जरूरत है।

कामयाब संदर्भ में मैं लाइन पर मेरी गर्दन डाल इसे दूर जाना है एक बार प्रक्रिया / मार दिया जाता है हटा दिया कहने के लिए होगा।

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

आप तो ब्राउज़र, कुछ साइट पर सर्फ में एक अन्य टैब खोलते हैं, तो टैब है कि अन्य पेज है कि ब्राउज़र रिसाव बनाया की मेजबानी बंद करते हैं, आपको लगता है ब्राउज़र स्मृति जारी करेंगे करते हैं? नहीं IE के साथ तो। अपने कंप्यूटर पर आईई आसानी से (लगभग 3-4 दिन) अगर मैं Google रीडर का उपयोग समय की एक छोटी राशि में स्मृति के 1 GiB खाएंगे। कुछ newspages भी बदतर हैं।

01/09/2008 को 13:19
का स्रोत उपयोगकर्ता

वोट
10

मुझे लगता है कि किसी प्रबंधित परिवेश में, एक रिसाव आप के आसपास स्मृति की एक बड़ी हिस्सा करने के लिए एक अनावश्यक संदर्भ रखते हुए किया जाएगा।

पूर्ण रूप से। इसके अलावा, डिस्पोजेबल वस्तुओं पर .Dispose () विधि का उपयोग नहीं जब उचित मेम लीक हो सकता है। क्योंकि यह स्वतः अंत में .Dispose () निष्पादित करता है यह करने के लिए सबसे आसान तरीका है एक का उपयोग कर ब्लॉक के साथ है:

StreamReader sr;
using(sr = new StreamReader("somefile.txt"))
{
    //do some stuff
}

और अगर आप एक वर्ग है कि अप्रबंधित वस्तुओं उपयोग कर रहा है बनाने के लिए, अगर आप IDisposable सही ढंग से लागू नहीं कर रहे हैं, तो आप अपने वर्ग के उपयोगकर्ताओं के लिए मेमोरी लीक के कारण हो सकता है।

05/08/2008 को 23:47
का स्रोत उपयोगकर्ता

वोट
9

सभी मेमोरी लीक कार्यक्रम समाप्ति के द्वारा हल कर रहे हैं।

पर्याप्त स्मृति रिसाव और ऑपरेटिंग सिस्टम को अपनी ओर से समस्या को हल करने का फैसला कर सकते।

04/08/2008 को 15:09
का स्रोत उपयोगकर्ता

वोट
9

मैं .net क्या एक सदस्य रिसाव हो सकता है में करने के लिए के रूप में बर्नार्ड से सहमत होगा।

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

कामयाब संदर्भ में मैं लाइन पर मेरी गर्दन डाल इसे दूर जाना है एक बार प्रक्रिया / मार दिया जाता है हटा दिया कहने के लिए होगा।

अप्रबंधित कोड का अपना जानवर है और एक रिसाव यह के भीतर मौजूद है, तो यह एक मानक मेम का पालन करेंगे। परिभाषा रिसाव।

01/08/2008 को 16:23
का स्रोत उपयोगकर्ता

वोट
7

यह भी ध्यान नेट दो ढेर, एक बड़ी वस्तु ढेर किया जा रहा है कि में रहते हैं। मेरा मानना ​​है कि मोटे तौर पर 85k या बड़ा की वस्तुओं इस ढेर पर डाल रहे हैं। यह ढेर नियमित ढेर से एक अलग जीवन के नियम हैं।

आप बड़े स्मृति ढांचे (शब्दकोश की या सूची के) बना रहे हैं यह विवेकपूर्ण देखने क्या सटीक नियम हैं जाने के लिए होगा।

जहाँ तक, प्रक्रिया समाप्त होने पर स्मृति सुधारने जब तक आपके Win98 चल रहे हैं या यह समकक्ष के रूप में, सब कुछ समाप्त होने पर ओएस के लिए वापस जारी किया गया है। केवल अपवाद चीजें हैं जो पार प्रक्रिया खुले हुए हैं और किसी अन्य प्रक्रिया अभी भी संसाधन खुला है।

COM ऑब्जेक्ट मुश्किल यद्यपि हो सकता है। आप हमेशा का उपयोग करते हैं IDisposeपैटर्न, आप सुरक्षित हो जाएगा। लेकिन मैं कुछ इंटरॉप असेंबलियों कि लागू पार चला गया है IDispose। कुंजी यहाँ कॉल करने के लिए है Marshal.ReleaseCOMObjectजब आप इसे पूरा कर चुके हैं। COM ऑब्जेक्ट अभी भी मानक COM संदर्भ गिनती का उपयोग करें।

07/08/2008 को 14:17
का स्रोत उपयोगकर्ता

वोट
6

मैंने पाया नेट मेमोरी प्रोफाइलर जब नेट में मेमोरी लीक ढूँढने एक बहुत अच्छा मदद करते हैं। यह माइक्रोसॉफ्ट CLR प्रोफाइलर तरह मुक्त नहीं है, लेकिन तेजी से और अधिक मेरी राय में बात करने के लिए है। ए

20/08/2008 को 19:39
का स्रोत उपयोगकर्ता

वोट
1

एक परिभाषा है: नहीं पहुंचा जा सकता स्मृति, जिस पर अब प्रक्रिया आवंटन के निष्पादन के दौरान नई प्रक्रिया के लिए आवंटित किया जा सकता है छोड़ने में असमर्थ। यह ज्यादातर जीसी तकनीकों का उपयोग करके ठीक हो या स्वचालित उपकरणों द्वारा पता लगाया जा सकता है।

अधिक जानकारी के लिए, कृपया देखें http://all-about-java-and-weblogic-server.blogspot.in/2014/01/what-is-memory-leak-in-java.html

27/08/2014 को 16:22
का स्रोत उपयोगकर्ता

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more