सी #: स्मार्ट कैश को कैसे कार्यान्वित करें

Question

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

पिछले एक के एक साधारण उदाहरण:

public static class Cache 
{ 
    private static Dictionary<string, PropertyChangedEventArgs> cache; 
    static Cache() 
    { 
     cache = new Dictionary<string, PropertyChangedEventArgs>(); 
    } 
    public static PropertyChangedEventArgs GetPropertyChangedEventArgs(
     string propertyName) 
    { 
     if (cache.ContainsKey(propertyName)) 
      return cache[propertyName]; 

     return cache[propertyName] = new PropertyChangedEventArgs(propertyName); 
    } 
} 

लेकिन, यह काम होगा अच्छी तरह से? उदाहरण के लिए यदि हमारे पास अलग-अलग संपत्ति नामों का पूरा भार था, तो इसका मतलब यह होगा कि हम एक विशाल कैश के साथ खत्म हो जाएंगे, वहां कभी भी कचरा इकट्ठा या कुछ भी नहीं होगा। मैं कल्पना कर रहा हूं कि कैश किया गया क्या बड़ा मूल्य है और यदि एप्लिकेशन एक लंबे समय से चल रहा है, तो यह किसी प्रकार की समस्या के रूप में समाप्त हो सकता है ... या आप क्या सोचते हैं? एक अच्छा कैश कैसे लागू किया जाना चाहिए? क्या यह ज्यादातर उद्देश्यों के लिए पर्याप्त है? कुछ अच्छे कैश कार्यान्वयन के किसी भी उदाहरण जो समझने में बहुत मुश्किल नहीं हैं या लागू करने के लिए बहुत जटिल हैं?

Answer 1

आप अपने प्रत्येक कैश किए गए आइटम को WeakReference में लपेट सकते हैं। यह जीसी को वस्तुओं को पुनः प्राप्त करने की इजाजत देता है, और जब आवश्यक हो, हालांकि यह आपको कैश से आइटम गायब होने पर कोई दानेदार नियंत्रण नहीं देता है, या आपको स्पष्ट समाप्ति नीतियों आदि को लागू करने की अनुमति देता है।

(Ha मैंने अभी देखा है कि MSDN page पर दिया गया उदाहरण एक साधारण कैशिंग कक्षा है।)

Answer 2

यह है करने के लिए एक अच्छा बहस है, लेकिन अपने आवेदन के आधार है, यहां कुछ युक्तियां है:

आप कैश का अधिकतम आकार, क्या पुराने आइटम के साथ क्या करना है, तो अपने कैश भरा हुआ है परिभाषित करना चाहिए, एक सफाई है रणनीति, कैश में ऑब्जेक्ट के रहने का समय निर्धारित करें, क्या आपके कैश को कहीं और जारी रखा जाना चाहिए, स्मृति असामान्य समाप्ति के मामले में, ...

Answer 3

यह एक बड़ी समस्या है, आपको इसकी आवश्यकता है समस्या का डोमेन निर्धारित करें और सही तकनीक लागू करें। उदाहरण के लिए, आप वस्तुओं की समाप्ति का वर्णन कैसे करेंगे? क्या वे समय के एक निश्चित अंतराल पर बाँध बन जाते हैं? क्या वे बाहरी घटना से निकल जाते हैं? यह कितनी बार होता है? इसके अतिरिक्त, आपके पास कितनी ऑब्जेक्ट्स हैं? अंत में, वस्तु उत्पन्न करने के लिए कितना खर्च होता है?

सबसे सरल रणनीति सीधे ऊपर की तरह, जैसा कि आप ऊपर है, करना होगा। यह मानता है कि ऑब्जेक्ट्स कभी समाप्त नहीं होते हैं, और आपके मेमोरी को और चलाने के लिए इतने सारे नहीं हैं कि आपको लगता है कि इन ऑब्जेक्ट्स को बनाने की लागत शुरू करने के लिए कैश के उपयोग की गारंटी देती है।

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

अगला, आपको समय पर या कुछ बाहरी उत्तेजना के आधार पर स्पष्ट समाप्ति को लागू करने की आवश्यकता हो सकती है। इसके लिए आपको किसी प्रकार की समाप्ति घटना की आवश्यकता होगी जिसे बुलाया जा सके।

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

पीएस कृपया अपनी कक्षा को परिभाषित करते समय जेनेरिक का उपयोग करने पर विचार करें ताकि कई प्रकार की वस्तुओं को संग्रहीत किया जा सके, इस प्रकार आपके कैशिंग कोड को पुन: उपयोग किया जा सके।

Answer 4

यह एक आम समस्या है जिसमें आपके आवेदन की आवश्यकता के आधार पर कई समाधान हैं। यह इतना आम है कि माइक्रोसॉफ्ट ने इसे संबोधित करने के लिए एक संपूर्ण पुस्तकालय जारी किया। आपको अपना खुद का कैश रोल करने से पहले माइक्रोसॉफ्ट वेग की जांच करनी चाहिए। http://msdn.microsoft.com/en-us/data/cc655792.aspx इस सहायता की आशा करें।

Answer 5

आप WeakReference का उपयोग कर सकते हैं, लेकिन यदि आपका ऑब्जेक्ट इतना बड़ा नहीं है क्योंकि WeakReference ऑब्जेक्ट की तुलना में अधिक मेमोरी ले रहा है जो एक अच्छी तकनीक नहीं है। साथ ही, यदि ऑब्जेक्ट एक शॉर्ट-टाइम उपयोग है, जहां यह जीसी पर पीढ़ी 0 से पीढ़ी 1 तक कभी नहीं बनायेगा, तो WeakReference की आवश्यकता नहीं है लेकिन ऑब्जेक्ट पर आईडीस्पोजेबल इंटरफ़ेस SuppressFinalize पर रिलीज़ के साथ होगा।

यदि आप जीवनकाल को नियंत्रित करना चाहते हैं तो आपको अपने कैश में ऑब्जेक्ट पर वांछित एक्स्पिरेशनटाइम को फिर से टाइमटाइम/टाइमपैन अपडेट करने के लिए टाइमर चाहिए।

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

Answer 6

ऐसा लगता है कि .NET 4.0 अब System.Runtime.Caching को कई प्रकार की चीज़ों को कैशिंग के लिए समर्थन देता है। पहिया को फिर से आविष्कार करने के बजाय, आपको पहले उसमें देखना चाहिए। अधिक विवरण:

http://msdn.microsoft.com/en-us/library/system.runtime.caching%28VS.100%29.aspx