50/50 पढ़ने/लिखने के लिए समवर्ती संग्रह

Question

मुझे आपकी सलाह चाहिए। शुरुआत के लिए मैं पूर्व शर्त का वर्णन करना चाहता हूं।

1. मैं किसी तीसरे पक्ष जावा डिफ़ॉल्ट java.lang.Object के hashCode() और equals() कार्यान्वयन के साथ वस्तुओं की है। Comparable इंटरफ़ेस लागू नहीं किया गया है। आकार महत्वहीन है।
2. मुझे स्मृति में कुछ समय के लिए ऐसी वस्तुओं को स्टोर करने की आवश्यकता है। मैं 50/50 अनुपात में विभिन्न धागे से उन्हें पढ़ और लिखूंगा (लगभग 50% पढ़ता है और 50% लिखता है)।
3. वस्तुओं का क्रम महत्वपूर्ण नहीं है। मैं सिर्फ दुकान से कुछ वस्तु लेने की संभावना लेना चाहता हूं, बस इतना ही। के साथ मेरा मतलब है और एक ही समय में हटा दें।
4. निश्चित रूप से, मैं इसे सबसे कम मेमोरी खपत के साथ जितनी जल्दी हो सके काम करना चाहता हूं। मैं अपने कोड में किसी भी सिंक्रनाइज़ेशन से बचने की कोशिश कर रहा हूं।

सबसे पहले मैंने स्वयं को इस समस्या को हल करने का प्रयास किया है। मैंने उच्च स्मृति खपत के कारण तुरंत CopyOnWriteArray* संग्रह को खारिज कर दिया है। मैंने पढ़ा है कि दुर्लभ लिखने के मामले में उनका उपयोग करना बेहतर होता है। ConcurrentHashMap मेरी ज़रूरतों के लिए सामान्य स्वीट्स में मुझे बनाने के लिए रास्ता नहीं मिला ऑपरेशन परमाणु सिंक्रनाइज़ेशन के बिना। मैंने ConcurrentSkipListSet संग्रह पर अपनी जांच के साथ रोक दिया है। इसमें pollFirst विधि है जो पर बहुत अच्छा सूट ऑब्जेक्ट्स लेता है।

मैंने अपने समाधान को ConcurrentSkipListSet के आधार पर लागू किया है। मुझे एक छोटी सी जानकारी को छोड़कर सब कुछ ठीक काम करता है। जैसा कि मैंने उपरोक्त वस्तुओं का उल्लेख किया है, मैं Comparable लागू नहीं कर रहा हूं। तो चुने गए संग्रह का उपयोग करने के लिए मुझे किसी भी तरह Comparator लागू करना होगा। यहां इस इंटरफेस का मेरा कार्यान्वयन है। इस उदाहरण में मैंने अपने ऑब्जेक्ट प्रकार के बजाय सीधे java.lang.Object का उपयोग किया है। मैंने ऐसा किया है क्योंकि कारण कार्यान्वयन पूरी तरह से समान है, अंतर केवल कक्षा के सामान्य भाग में है।

import java.util.Comparator; 

public class ObjectComparator implements Comparator<Object> { 

    public int compare(Object o1, Object o2) { 
     return o1.hashCode() - o2.hashCode(); 
    } 
} 

इस कार्यान्वयन का विपक्ष स्पष्ट है। मैंने पाया है कि no guarantee है कि दो अलग-अलग ऑब्जेक्ट्स में अलग हैश कोड होंगे। ऐसे मामले में कुछ वस्तुओं को खोना संभव है जो स्वीकार्य नहीं है। मैंने अलग-अलग ऑब्जेक्ट्स के बराबर हैश कोड के मामले में कुछ यादृच्छिक संख्या वापस करने का विचार किया है, लेकिन मुझे यकीन नहीं है कि यह ConcurrentSkipListSet कार्यान्वयन को तोड़ नहीं देगा।

बताई गई स्थिति के बारे में मेरे दो सामान्य प्रश्न हैं।

1. यह इस तरह के रूप में जिस तरह से मेरी वस्तु के लिए Comparator लागू करने के लिए विभिन्न वस्तुओं के लिए 0 नहीं लौटते करने और ConcurrentSkipListSet संचालनीयता रखने संभव है?
2. क्या मेरे ऑब्जेक्ट्स को स्टोर करने का कोई और तरीका है?

आपके उत्तरों के लिए अग्रिम धन्यवाद।

Answer 1

शायद आप ConcurrentLinkedQueue की तलाश में हैं, यह FiFo (पहले बाहर में पहले) ऑर्डर के आधार पर आइटम संग्रहीत करेगा। इस वजह से hashcode और comparable आवश्यकताएं मौजूद हैं। किसी भी आंतरिक लॉकिंग के बिना, इस कतार का कार्यान्वयन बहुत ही कुशल है।

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

Answer 2

1: आप इस तरह के रूप में अपने तुलनित्र को लागू कर सकते हैं:

public int compare(Object o1, Object o2) { 
    if (o1 == o2) { 
     return 0; 
    } else { 
     int dif = o1.hashCode() - o2.hashCode(); 
     if (dif != 0) { 
      return dif; 
     } else { 
      return 1; //Might cause issues 
     } 
    } 
} 

2: आप किसी भी सामान्य संग्रह java.util का उपयोग कर सिंक्रनाइज़ कर सकते हैं।संग्रह। सिंक्रनाइज़ेशन चयन() (या कोई अन्य सिंक्रनाइज़ेशन-विधि)। उदाहरण के लिए, यदि आप एक लिंक्डलिस्ट को सिंक्रनाइज़ करते हैं, तो आप पर निकालें (इंडेक्स) का उपयोग ऑब्जेक्ट ले सकते हैं।

Answer 3

मेरी जरूरतों के लिए सामान्य सुइट में ConcurrentHashMap लेकिन मैं ले आपरेशन परमाणु

क्यों ConcurrentHashMap में remove का उपयोग नहीं करने के लिए रास्ता खोजने नहीं किया? ऐसा लगता है कि आपको क्या चाहिए।