कैश.एएसएपी() कैश.size() के साथ संगत क्यों नहीं है?

Question

गुवा लाइब्रेरी में, मैं उलझन में हूं कि क्यों Cache.asMap()Cache.size() के साथ संगत नहीं है, जब तक कि Cache.cleanUp() नहीं कहा जाता है।

Cache<Object, Object> cache = CacheBuilder.newBuilder() 
      .expireAfterWrite(1, TimeUnit.SECONDS) 
      .build(); 
cache.get(...); 
... 
//After some seconds, all entries are expired. 
//cache.asMap() is EMPTY Map, but cache.size() != 0 

तो मेरे सवाल: यह बग कि Cache.asMap()Cache.size() के अनुरूप नहीं है है? हालांकि मैं नोटिस Cache.size() की जावाडोक है:

/** 
    * Returns the **approximate** number of entries in this cache. 
    */ 

मैं सिर्फ अनुमान लगा सकते हैं कि यह एक समवर्ती पर्यावरण से संबंधित है। और Cache.cleanUp() क्या करता है वास्तव में?

Answer 1

गुवा का कैश लॉक एमोर्टाइजेशन के आसपास डिज़ाइन किया गया है और cleanUp विधि कैश को एक सतत स्थिति में आने के लिए मजबूर करती है। Map.size() विधि एक अनुमान है, लेकिन समाप्ति या संदर्भ निष्कासन के कारण हटाए गए प्रविष्टियों को लंबित कर सकता है। गुवा के कैश में अनुमानों की दृश्यता शायद ही कभी किसी एप्लिकेशन के लिए बहुत रूचि रखती है, जो एक कैश को एक क्षणिक डेटा स्टोर के रूप में सोचने लगता है। मानचित्र से कैश की विभिन्न अपेक्षाओं को कैश को मानचित्र के रूप में देखने की अनुमति देने के लिए asMap विधि का कारण बन गया, लेकिन अपवाद डेवलपर्स इसे इस तरह समझते हैं।

कैश के कार्यान्वयन विवरण StrangleLoop 2011 सम्मेलन slides में शामिल किया गया था। ConcurrentLinkedHashMap, जो गुवा का कैश से लिया गया था, भी ब्याज का हो सकता है लेकिन थोड़ा अलग दृष्टिकोण का वर्णन करता है।

Answer 2

बेन ने एक अच्छी उच्च स्तरीय प्रतिक्रिया दी। निम्न स्तर की प्रतिक्रिया है:

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

CacheBuilder javadocs विभिन्न स्थितियों (जैसे expireAfterWrite, आपके मामले में) में होने वाली सफाई के बारे में अधिक जानकारी में जाता है।