.NET Framework - संभावित मेमोरी-लीकी कक्षाएं?

Question

बस दूसरे दिन मैं एक मेमोरी रिसाव की जांच कर रहा था जो ऐप को ~ 50 एमबी से ~ 130 एमबी तक दो मिनट से कम कर रहा था। यह पता चला है कि समस्या ConcurrentQueue कक्षा के साथ थी। आंतरिक रूप से, कक्षा एरे की एक लिंक्ड सूची स्टोर करता है। जब किसी आइटम को ConcurrentQueue से हटा दिया जाता है, तो सरणी में अनुक्रमणिका बंप हो जाती है, लेकिन आइटम सरणी में रहता है (यानी यह शून्य पर सेट नहीं है)। पूरे सरणी नोड को पर्याप्त एनक्यूज/डेक्यू के बाद गिरा दिया जाता है, इसलिए यह तकनीकी रूप से लीक नहीं है, लेकिन यदि ConcurrentQueue में बड़ी ऑब्जेक्ट्स डालते हैं, तो यह हाथ से तेज़ हो सकता है। दस्तावेज इस खतरे का कोई ध्यान नहीं देता है।

मैं सोच रहा था कि बेस क्लास लाइब्रेरी में अन्य संभावित स्मृति समस्याएं क्या हैं? मुझे सबस्ट्रिंग एक के बारे में पता है (यानी, यदि आप सबस्ट्रिंग को कॉल करते हैं और केवल परिणाम पर पकड़ते हैं, तो पूरी स्ट्रिंग अभी भी स्मृति में होगी)। आप किसी अन्य का सामना करना पड़ा है?

Answer 1

हालांकि प्रत्यक्ष स्मृति रिसाव या .NET/BCL के लिए विशिष्ट नहीं है, स्ट्रिंग concatenation (+ = ऑपरेटर का उपयोग कर) मुद्दा है। भारी कचरा इकट्ठा करने के कारण यह लूप में सुंदर सीपीयू गहन है।

Answer 2

आप सही हैं। बग विधि System.Collections.Concurrent.ConcurrentQueue<T>+Segment.TryRemove(out T, ref ConcurrentQueue<T>.Segment) में स्थित है।

आप परावर्तक में इस विधि को देखें, तो आप निम्न पंक्ति देखेंगे:

result = this.m_array[low]; 

यह बाद निम्न पंक्ति होनी चाहिए:

this.m_array[low] = default(T); 

संदर्भ के लिए, आप देख सकते हैं विधि System.Collections.Generic.Queue<T>.Dequeue() विधि में यह सही ढंग से कार्यान्वित कैसे किया जाता है।

Answer 3

ConcurrentQueue केवल अधिकतम 31 अस्वीकृत वस्तुओं को रखेगा। यह एक बड़ी समस्या नहीं पेश करनी चाहिए जबतक कि आप वास्तव में बड़े ऑब्जेक्ट ग्राफ़ से निपट नहीं रहे हैं।

वैसे भी, यह भावना एक ConcurrentQueue का उपयोग कर आप 32 वस्तुओं के आवंटन के लिए enought स्थान नहीं है अगर नहीं है ...