जावा

Question

में कमजोर संदर्भों का उपयोग करने की लागत क्या किसी ने जावा WeakReference ऑब्जेक्ट्स एकत्र करने और कचरा बनाने में शामिल रनटाइम लागतों का शोध किया है? क्या बहु-थ्रेडेड अनुप्रयोगों के लिए कोई प्रदर्शन समस्याएं (उदा। विवाद) हैं?

संपादित करें: स्पष्ट रूप से वास्तविक उत्तर JVM निर्भर होंगे, लेकिन सामान्य अवलोकनों का भी स्वागत है।

संपादित करें 2: यदि किसी ने प्रदर्शन के कुछ बेंचमार्किंग किए हैं, या कुछ बेंचमार्किंग परिणामों को इंगित कर सकते हैं, तो यह आदर्श होगा। (क्षमा करें, लेकिन बक्षीस की समयसीमा समाप्त हो गई है ...)

Answer 1

वीक रेफरेंस का सीएमएस कचरा कलेक्टर पर नकारात्मक प्रभाव पड़ता है। जहां तक ​​मैं अपने सर्वर के व्यवहार से देख सकता हूं, यह समांतर टिप्पणी चरण समय को प्रभावित करता है। इस चरण के दौरान सभी ऐप धागे बंद कर दिए गए हैं, इसलिए यह बेहद अवांछित चीज है। तो आपको वीक संदर्भों से सावधान रहना होगा।

Answer 2

कमजोर संदर्भों का उपयोग करके कैश आपके ऐप को काफी धीमा कर सकता है अगर यह मांग पर पुनर्निर्माण हो। टिककर खेल में:

1) अनुप्रयोग मेमोरी कम है

2) जी सी कमजोर संदर्भ साफ है, इस प्रकार कैश भी साफ कर दिया जाता

3) अनुप्रयोग जारी है:

public Object getSomethingExpensiveToFind() { 
    if(cache.contains(EXPENSIVE_OBJ_KEY)) { 
     return cache.get(EXPENSIVE_OBJ_KEY); 
    } 

    Object sth = obtainSomethingExpensiveToFind(); // computationally expensive 
    cache.put(EXPENSIVE_OBJ_KEY, sth); 
    return sth; 
} 

इस परिदृश्य की कल्पना , कई तरीकों जैसे getSomethingExpensiveToFind() को कैश किया जाता है और कैश का पुनर्निर्माण

4) ऐप फिर से स्मृति पर कम चल रहा है

5) जीसी साफ संदर्भ पहनते हैं, कैश को साफ करता है

6) अनुप्रयोग, जारी है() getSomethingExpensiveToFind तरह के तरीकों का एक बहुत लागू कर रहे हैं और कैश फिर

7) के पुनर्निर्माण और इतने पर ...

मैं ऐसी समस्या पर आया - ऐप को अक्सर जीसी द्वारा बाधित किया गया था और यह पूरी तरह से कैशिंग के पूरे बिंदु को हराया।

दूसरे शब्दों में, यदि अनुचित तरीके से प्रबंधित किया गया है, तो कमजोर संदर्भ आपके आवेदन को धीमा कर सकते हैं।

Answer 3

मैंने एक बार जावा कचरा कलेक्टर लागू किया, इसलिए जो कुछ भी मैं पूरा करने में सक्षम था वह एक (कमजोर :) संभव है कि कम संभव है।

मेरे कार्यान्वयन में, प्रत्येक कमजोर संदर्भ के लिए कचरा संग्रह के दौरान जाने पर अतिरिक्त ओवरहेड की अतिरिक्त स्थिरता होती है।

तो ऊपर की ओर है: मैं इसके बारे में चिंता नहीं करता, यह एक बड़ी समस्या नहीं है जब तक कि आप कमजोर संदर्भों के ज़िलियन का उपयोग नहीं कर रहे हों।

सबसे महत्वपूर्ण बात यह है कि लागत अस्तित्व में कमजोर संदर्भों की संख्या के समान है, समग्र ढेर का आकार नहीं।

हालांकि, यह कहना नहीं है कि एक कचरा कलेक्टर जो कमजोर संदर्भों का समर्थन करता है उतना तेज़ होगा जितना नहीं। यहां अनुमानित प्रश्न यह है कि जावा कमजोर संदर्भों का समर्थन करता है, इनका उपयोग करने की बढ़ती लागत क्या है?

मेरा एक सरल "दुनिया को रोकें" चिह्न/साफ़ कचरा कलेक्टर था।कचरा संग्रह के दौरान, यह प्रत्येक ऑब्जेक्ट के लिए दृढ़ संकल्प करता है कि वह ऑब्जेक्ट लाइव है या नहीं और ऑब्जेक्ट हेडर में LIVE बिट सेट करता है। फिर यह सभी गैर-जीवित वस्तुओं को पार करता है और मुक्त करता है।

कमजोर संदर्भ तुम सिर्फ निम्नलिखित जोड़ें संभाल करने के लिए:

• जब LIVE बिट (अर्थात, वे कारण नहीं है संदर्भित वस्तु पर LIVE बिट सेट करने के लिए) की स्थापना कमजोर संदर्भ पर ध्यान न दें। इस प्रकार
• झाडू चरण के दौरान, एक विशेष जांच जोड़ें: यदि वस्तु पर आप जा रहे LIVE है, और यह एक WeakReference है, तो वस्तु की जांच है कि यह कमजोर संदर्भ, और यदि उस वस्तु LIVE नहीं है, संदर्भ स्पष्ट ।

मुलायम और प्रेत संदर्भों के लिए इस तर्क कार्य के छोटे बदलाव।

कार्यान्वयन here है यदि आप वास्तव में उत्सुक हैं।