.NET के पास सॉफ़्ट रेफरेंस के साथ-साथ वीक रेफरेंस, जावा की तरह क्यों नहीं है?

Question

मुझे वास्तव में वीक रेफरेंस पसंद है। लेकिन मेरी इच्छा है कि सीएलआर को बताने का एक तरीका था (कहें, 1 से 5 के पैमाने पर) आप संदर्भ को कितना कमजोर मानते हैं। वह शानदार होगा।

जावा में सॉफ़्ट रेफरेंस, वीक रेफरेंस है और मुझे एक तीसरा प्रकार भी माना जाता है जिसे "प्रेत संदर्भ" कहा जाता है। यह उस स्तर पर 3 स्तर है जहां जीसी के पास अलग-अलग व्यवहार एल्गोरिदम होता है जब यह तय होता है कि उस वस्तु को काट दिया जाता है या नहीं।

मैं एक छद्म-सॉफ़्ट रेफरेंस बनाने के लिए .NET की वीक रेफरेंस (सौभाग्य से और थोड़ा विचित्र रूप से इसे सील नहीं किया गया है) को उपclassing के बारे में सोच रहा हूं जो एक समाप्ति टाइमर या कुछ पर आधारित है।

Answer 1

को क्यों इस पहले से ही सादगी होगा नहीं है के रूप में मेरा अनुमान है। ज्यादातर लोग, मुझे लगता है, यह एक पुण्य कहलाएगा कि केवल एक ही प्रकार का संदर्भ है, चार नहीं।

Answer 2

'trackResurrection' विकल्प निर्माता शायद करने के लिए पारित कर दिया के लिए खोज रहे हैं?

जीसी वर्ग भी कुछ सहायता प्रदान करता है।

Answer 3

शायद ऐसी संपत्ति होनी चाहिए जहां आप निर्दिष्ट कर सकें कि ऑब्जेक्ट> = ऑब्जेक्ट> = इससे पहले कि वह एकत्र हो जाए। तो यदि आप 1 निर्दिष्ट करते हैं तो यह सबसे कमजोर संभावित संदर्भ है। लेकिन यदि आप 3 निर्दिष्ट करते हैं तो इसे संग्रह के लिए विचार करने से पहले कम से कम 3 पूर्व संग्रहों को जीवित रहने की आवश्यकता होगी।

मैंने सोचा कि ट्रैक पुनर्विक्रय ध्वज इसके लिए अच्छा नहीं था क्योंकि उस समय तक ऑब्जेक्ट को अंतिम रूप दिया गया है? गलत हालांकि हो सकता है ...

(पुनश्च: मैं ओ पी रहा हूँ, अभी साइन अप PITA है कि यह "अपंजीकृत" खातों से अपने इतिहास के वारिस नहीं है।।)

Answer 4

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

अतिरिक्त जटिलता से अधिक कुछ भी अधिक कुशल नहीं होगा क्योंकि सबसे प्रभावी तरीका पहले उपयोग किए जाने वाले वीक संदर्भों से छुटकारा पाने के लिए सबसे प्रभावी तरीका है। यदि आप प्राथमिकता सौंप सकते हैं, तो आप इसे कैसे करेंगे? यह एक समयपूर्व अनुकूलन की तरह गंध करता है: प्रोग्रामर वास्तव में ज्यादातर समय नहीं जानता है और अनुमान लगा रहा है; नतीजा एक धीमी जीसी संग्रह चक्र है जो शायद गलत वस्तुओं को पुनः प्राप्त कर रहा है।

हालांकि यह सवाल पूछता है कि यदि आप वीक रेफरेंस की परवाह करते हैं। लक्ष्य वस्तु को पुनः दावा किया जा रहा है, क्या यह वास्तव में वीक रेफरेंस का अच्छा उपयोग है?

यह एक कैश की तरह है। आप कैश में सामान फेंकते हैं और कैश से एक्स मिनट के बाद इसे बाँधने के लिए कहते हैं, लेकिन अधिकांश कैश इसे कभी भी आसपास रखने की गारंटी नहीं देते हैं। यह गारंटी देता है कि यदि ऐसा होता है, तो यह अनुरोधित नीति के अनुसार इसे समाप्त कर देगा।

Answer 5

क्यों नेट Softreferences नहीं है पता नहीं है। लेकिन जावा सॉफ़्ट्रेरेंस में आईएमएचओ अधिक उपयोग किया जाता है। इसका कारण यह है कि कम से कम एक एप्लिकेशन सर्वर में आप प्रति एप्लिकेशन को प्रभावित करने में सक्षम होना चाहते हैं कि आपका सॉफ़्ट्रेन्फ़ेन कितना समय तक रहता है। यह जावा में वर्तमान में संभव नहीं है।

Answer 6

यह न भूलें कि आपके पास अपने मानक संदर्भ भी हैं (जिन्हें आप दैनिक आधार पर उपयोग करते हैं)। यह आपको एक और स्तर देता है।

कमजोरियों का उपयोग तब किया जाना चाहिए जब आप वास्तव में परवाह नहीं करते हैं कि वस्तु दूर हो जाती है, जबकि सॉफ़्ट रेफरेंस वास्तव में केवल तब उपयोग किया जाना चाहिए जब आप सामान्य संदर्भ का उपयोग करेंगे, लेकिन आप अपने ऑब्जेक्ट को साफ़ करने के लिए साफ़ कर देंगे स्मृति की मुझे विनिर्देशों पर यकीन नहीं है, लेकिन मुझे संदेह है कि जीसी सामान्य रूप से सॉफ्ट रेफरेंस के माध्यम से पता लगाती है, लेकिन यह निर्धारित करते समय वीक रेफरेंस नहीं है कि कौन सी ऑब्जेक्ट्स लाइव हैं, लेकिन जब मेमोरी पर कम चलते हैं तो सॉफ़्ट रेफरेंस भी छोड़ देंगे।

मेरा अनुमान है कि नेट डिजाइनरों ने महसूस किया कि अंतर ज्यादातर लोगों को भ्रमित कर रहा था और या सॉफ़्ट रेफरेंस वास्तव में चाहते थे उससे अधिक जटिलता जोड़ते हैं और इसलिए उन्हें छोड़ने का फैसला किया जाता है।

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

Answer 7

शायद एएसपी.नेट कैश क्लास (System.Web.Caching.Cache) आप जो चाहते हैं उसे प्राप्त करने में मदद कर सकते हैं? स्मृति कम हो जाता है यह स्वचालित रूप से वस्तुओं को हटाने:

• ASP.NET Caching Overview

यहाँ एक लेख से पता चलता है कि कैसे एक खिड़कियों में कैश वर्ग का उपयोग करने के आवेदन रूपों।

उद्धृत से: Equivalent to SoftReference in .net?

Answer 8

मेरा मानना ​​है कि मौलिक कारण यह है कि नेट नरम संदर्भ नहीं है, क्योंकि यह आभासी स्मृति के साथ एक ऑपरेटिंग सिस्टम पर भरोसा कर सकते हैं। जावा प्रक्रिया को अपनी अधिकतम ओएस मेमोरी निर्दिष्ट करना चाहिए (उदा। -Xmx128M के साथ), और कभी उस से अधिक ओएस मेमोरी लेता है। जबकि एक नेट प्रक्रिया ओएस मेमोरी लेती रहती है जिसे इसकी आवश्यकता होती है, जो ओएस डिस्क-बैक वर्चुअल मेमोरी के साथ आपूर्ति करता है जब रैम समाप्त हो जाता है। यदि नेट ने मुलायम संदर्भों की अनुमति दी है, तो नेट रनटाइम उन्हें तब तक नहीं छोड़ेगा जब तक कि यह ओएस में गहराई से न देखे, यह देखने के लिए कि क्या इसकी मेमोरी वास्तव में डिस्क (एक बुरा ओएस/सीएलआर निर्भरता) पर पगड़ी है या फिर रनटाइम से अनुरोध किया गया है अधिकतम प्रक्रिया मेमोरी पदचिह्न निर्दिष्ट करें (उदाहरण के लिए -Xmx के बराबर)। मुझे लगता है कि माइक्रोसॉफ्ट -Xmx को नेट में नहीं जोड़ना चाहता क्योंकि उन्हें लगता है कि ओएस को यह तय करना चाहिए कि प्रत्येक प्रक्रिया कितनी रैम हो जाती है (यह चुनकर कि वर्चुअल मेमोरी पेज रैम या डिस्क पर हो), और प्रक्रिया ही नहीं।

Answer 9

जावा सॉफ़्ट संदर्भ का उपयोग स्मृति संवेदनशील कैश के निर्माण में किया जाता है (वे कोई अन्य उद्देश्य नहीं देते हैं)।

.NET 4 के रूप में, .NET की कक्षा System.Runtime.Caching.MemoryCache है जो शायद ऐसी किसी भी आवश्यकता को पूरा करेगी।