यह इस बात पर निर्भर करता है कि आपका ढेर कैसे व्यवस्थित किया जाता है। आपको यह देखना चाहिए कि कुल 0,1,2 में कितनी मेमोरी आवंटित की गई है और कुल उपयोग की गई स्मृति की तुलना में आपके पास कितनी मुफ्त मेमोरी है। यदि आपके पास 500 एमबी प्रबंधित ढेर का उपयोग किया गया है लेकिन 50 एमबी मुफ्त है तो आप बहुत अच्छी तरह से कर रहे हैं। यदि आप कई डब्ल्यूपीएफ नियंत्रण बनाने और उन्हें जारी करने जैसे स्मृति गहन संचालन करते हैं तो आपको थोड़े समय के लिए बहुत अधिक स्मृति की आवश्यकता होती है लेकिन .NET आपके द्वारा आवंटित किए जाने पर ओएस को स्मृति को वापस नहीं देता है। जीसी आवंटन पैटर्न को पहचानने की कोशिश करता है और आपकी मेमोरी पदचिह्न को उच्च रखने के लिए रहता है हालांकि आपका वर्तमान ढेर आकार बहुत बड़ा है जब तक कि आपकी मशीन भौतिक स्मृति पर कम न हो।
मैं इसे बहुत आसान .NET 3.5 जो ListNearObj जैसे कुछ शांत आदेशों जहां आप पता कर सकते जो वस्तुओं अपनी स्मृति छेद के आसपास हैं के लिए psscor2 उपयोग करने के लिए मिल गया (पिन की गई वस्तुओं?)। Psscor2 के आदेशों के साथ आपके पास वास्तव में आपके ढेर में क्या चल रहा है यह जानने के लिए बहुत बेहतर संभावनाएं हैं। अधिकांश आदेश भी .NET 4 में SOS.dll में उपलब्ध हैं।
अपने मूल प्रश्न का उत्तर देने के लिए: हाँ मुक्त ऑब्जेक्ट्स प्रबंधित ढेर पर अंतराल हैं जो जीसी सीमेंट पर आपके अंतिम आवंटित ऑब्जेक्ट के बाद बस फ्री मेमोरी ब्लॉक हो सकता है। या यदि आप करते हैं! जीसी सेगमेंट के प्रारंभ पते के साथ डंपहेप आप उस प्रबंधित हेप सेगमेंट में आवंटित ऑब्जेक्ट्स को अपनी फ्री ऑब्जेक्ट्स के साथ देखते हैं जो जीसी एकत्रित ऑब्जेक्ट्स हैं।
यह स्मृति छेद सामान्यतः जेन 2 में होता है। मुक्त वस्तु से पहले और बाद में ऑब्जेक्ट पते आपको बताता है कि संभावित रूप से पिन किए गए ऑब्जेक्ट्स आपके छेद के आसपास हैं। इससे आपको अपने आवंटन इतिहास को निर्धारित करने में सक्षम होना चाहिए और यदि आपको आवश्यकता हो तो इसे अनुकूलित करें। आप! DumpHeap 02aa1000 03836a30 साथ
0:021> !EEHeap -gc
Number of GC Heaps: 1
generation 0 starts at 0x101da9cc
generation 1 starts at 0x10061000
generation 2 starts at 0x02aa1000
ephemeral segment allocation context: none
segment begin allocated size
02aa0000 02aa1000** 03836a30 0xd95a30(14244400)
10060000 10061000** 103b8ff4 0x357ff4(3506164)
Large object heap starts at 0x03aa1000
segment begin allocated size
03aa0000 03aa1000 03b096f8 0x686f8(427768)
Total Size: Size: 0x115611c (18178332) bytes.
------------------------------
GC Heap Size: Size: 0x115611c (18178332) bytes.
वहाँ आप देख आप 02aa1000 पर ढेर है कि और 10061000. साथ जीसी ढेर के पते पा सकते हैं आप जीसी ढेर खंड डंप कर सकते हैं।
!DumpHeap 02aa1000 03836a30
Address MT Size
...
037b7b88 5b408350 56
037b7bc0 60876d60 32
037b7be0 5b40838c 20
037b7bf4 5b408350 56
037b7c2c 5b408728 20
037b7c40 5fe4506c 16
037b7c50 60876d60 32
037b7c70 5b408728 20
037b7c84 5fe4506c 16
037b7c94 00135de8 519112 Free
0383685c 5b408728 20
03836870 5fe4506c 16
03836880 608c55b4 96
....
वहां आपको अपनी निःशुल्क मेमोरी ब्लॉक मिलती है जो एक वस्तु थी जो पहले ही जीसीड थी। यह पता लगाने के लिए कि क्या वे पिन किए गए हैं या अन्य असामान्य गुण हैं, आप आस-पास की वस्तुओं को डंप कर सकते हैं (आउटपुट को क्रमबद्ध क्रमबद्ध किया गया है)।
स्रोत
2011-07-01 21:43:19
विखंडन ढेर कर सकते हैं (और अंत में आउटऑफमेमरी अपवाद) ** ** बिना पिन किए गए ऑब्जेक्ट्स के? मैं समझता हूं कि जीसी एक खंडित ढेर की सफाई है। पिन किए गए ऑब्जेक्ट्स के बिना, क्या जीसी अभी भी एक नए मेमोरी अनुरोध के लिए ढेर को साफ करने में असफल हो सकता है? पिन किए गए ऑब्जेक्ट को छोड़कर क्या एक खंडित ढेर हो सकता है जो सफाई (समय में) नहीं हो सकता है जब नए आवंटन की आवश्यकता होती है? – bitbonk
यदि आवंटन दर बहुत अधिक है तो आप स्मृति से बाहर हो सकते हैं। अगर आप जीसी को साफ करने का मौका देने के लिए एक तंग लूप में आवंटित कर रहे हैं तो क्लियर वास्तव में एक नींद (50) है जो आपके आवंटन अनुरोधों को थ्रॉटल कर रहा है लेकिन यह पर्याप्त नहीं हो सकता है। –