सिंगलटन ऑब्जेक्ट्स की फैक्टरी: क्या यह कोड थ्रेड-सुरक्षित है?

Question

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

मुझे एक कारखाने की आवश्यकता है जो मांग पर कैश किए गए सिंगलटन कार्यान्वयन को वापस कर देगा, और आश्चर्य होगा कि निम्नलिखित दृष्टिकोण थ्रेड-सुरक्षित है या नहीं?

Update1: करें, कोई भी 3 आंशिक रूप से पुस्तकालयों का सुझाव नहीं है के रूप में यह संभव लाइसेंस के मुद्दों की वजह से कानूनी मंजूरी प्राप्त करने के लिए :-)

UPDATE2 की आवश्यकता होगी: इस कोड को होने की संभावना में इस्तेमाल किया जाएगा होगा ईजेबी पर्यावरण, इसलिए यह अतिरिक्त धागे को बढ़ाने या उस तरह की सामग्री का उपयोग करने के लिए पसंद नहीं है।

interface Singleton 
{ 
    void init() throws SingletonException; 
} 

public class SingletonFactory 
{ 
    private static ConcurrentMap<String, AtomicReference<? extends Singleton>> CACHE = 
     new ConcurrentHashMap<String, AtomicReference<? extends Singleton>>(); 

    public static <T extends Singleton> T getSingletonInstance(Class<T> clazz) 
     throws SingletonException 
    { 
     String key = clazz.getName(); 
     if (CACHE.containsKey(key)) 
     { 
      return readEventually(key); 
     } 

     AtomicReference<T> ref = new AtomicReference<T>(null); 
     if (CACHE.putIfAbsent(key, ref) == null) 
     { 
      try 
      { 
       T instance = clazz.newInstance(); 
       instance.init(); 
       ref.set(instance); // ----- (1) ----- 
       return instance; 
      } 
      catch (Exception e) 
      { 
       throw new SingletonException(e); 
      } 
     } 

     return readEventually(key); 
    } 

    @SuppressWarnings("unchecked") 
    private static <T extends Singleton> T readEventually(String key) 
    { 
     T instance = null; 
     AtomicReference<T> ref = (AtomicReference<T>) CACHE.get(key); 
     do 
     { 
      instance = ref.get(); // ----- (2) ----- 
     } 
     while (instance == null); 
     return instance; 
    } 
} 

मुझे लाइनों (1) और (2) के बारे में पूरी तरह से यकीन नहीं है। मुझे पता है कि संदर्भित ऑब्जेक्ट AtomicReference में अस्थिर क्षेत्र के रूप में घोषित किया गया है, और इसलिए रेखा (1) में किए गए परिवर्तन तुरंत लाइन (2) पर दिखाई दे सकते हैं - लेकिन अभी भी कुछ संदेह हैं ...

इसके अलावा - मुझे लगता है ConcurrentHashMap का उपयोग कैश में नई कुंजी डालने की परमाणुता को संबोधित करता है।

क्या आप इस दृष्टिकोण के साथ कोई चिंता देखते हैं? धन्यवाद!

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

Answer 1

गुवा के CacheBuilder का उपयोग करने पर विचार करें। उदाहरण के लिए:

private static Cache<Class<? extends Singleton>, Singleton> singletons = CacheBuilder.newBuilder() 
    .build(
     new CacheLoader<Class<? extends Singleton>, Singleton>() { 
     public Singleton load(Class<? extends Singleton> key) throws SingletonException { 
      try { 
      Singleton singleton = key.newInstance(); 
      singleton.init(); 
      return singleton; 
      } 
      catch (SingletonException se) { 
      throw se; 
      } 
      catch (Exception e) { 
      throw new SingletonException(e); 
      } 
     } 
     }); 

public static <T extends Singleton> T getSingletonInstance(Class<T> clazz) { 
    return (T)singletons.get(clazz); 
} 

नोट: यह उदाहरण अनचाहे और असम्बद्ध है।

अमरूद अंतर्निहित Cache कार्यान्वयन आपके लिए सभी कैशिंग और समवर्ती तर्क को संभालेगा।

Answer 2

कोड आमतौर पर थ्रेड सुरक्षित नहीं है क्योंकि CACHE.containsKey(key) चेक और CACHE.putIfAbsent(key, ref) कॉल के बीच एक अंतर है। विधि में (विशेष रूप से मल्टी-कोर/प्रोसेसर सिस्टम पर) एक साथ कॉल करने के लिए दो धागे के लिए संभव है और दोनों containsKey() जांच करें, फिर दोनों रख-रखाव और निर्माण कार्य करने का प्रयास करें।

मैं लॉक या किसी प्रकार की मॉनीटर पर सिंक्रनाइज़ करके getSingletonInstnace() विधि के निष्पादन की रक्षा करता हूं।

Answer 3

इन समवर्ती/परमाणु चीजों के सभी के बाद सिर्फ गेटर आसपास

synchronized(clazz){} 

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

आप एक hashmap होने से इसे आगे का अनुकूलन कर सकता है, और केवल अगर वहाँ एक याद आती है, सिंक्रनाइज़ ब्लॉक का उपयोग करें:

public static <T> T get(Class<T> cls){ 
    // No lock try 
    T ref = cache.get(cls); 
    if(ref != null){ 
     return ref; 
    } 
    // Miss, so use create lock 
    synchronized(cls){ // singletons are double created 
     synchronized(cache){ // Prevent table rebuild/transfer contentions -- RARE 
      // Double check create if lock backed up 
      ref = cache.get(cls); 
      if(ref == null){ 
       ref = cls.newInstance(); 
       cache.put(cls,ref); 
      } 
      return ref; 
     } 
    } 
} 

Answer 4

यह लगता है कि यह हालांकि मैं अगर यहां तक ​​कि नींद में किसी प्रकार का विचार कर सकते हैं काम करेगा संदर्भ के लिए परीक्षण करते समय एक नैनोसेकंद या कुछ। स्पिन टेस्ट लूप बेहद महंगा होगा।

इसके अलावा, मैं AtomicReferencereadEventually() को गुजर ताकि आप containsKey() और फिर putIfAbsent() रेस स्थिति से बच सकते हैं द्वारा कोड में सुधार पर विचार करेंगे। तो कोड होगा:

AtomicReference<T> ref = (AtomicReference<T>) CACHE.get(key); 
if (ref != null) { 
    return readEventually(ref); 
} 

AtomicReference<T> newRef = new AtomicReference<T>(null); 
AtomicReference<T> oldRef = CACHE.putIfAbsent(key, newRef); 
if (oldRef != null) { 
    return readEventually(oldRef); 
} 
... 

Answer 5

आप तुल्यकालन से बचने के लिए बहुत काम करने के लिए चले गए हैं, और मुझे लगता है ऐसा करने के लिए कारण प्रदर्शन चिंताओं के लिए है। क्या आपने यह देखने के लिए परीक्षण किया है कि क्या यह वास्तव में एक सिंक्रनाइज़ समाधान बनाम प्रदर्शन में सुधार करता है?

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

इसके अतिरिक्त, मुझे लगता है कि जब आप सिंगलटन एक्सेप्शन को example.init() पर कॉल के दौरान फेंक दिया जाता है तो आप संभवतः एक अनंत लूप के साथ समाप्त हो सकते हैं। कारण यह है कि एक समवर्ती धागा पढ़ने में इंतजार कर रहा है, कभी भी इसके उदाहरण को कभी खत्म नहीं करेगा (क्योंकि एक अपवाद फेंक दिया गया था जबकि एक और धागा उदाहरण शुरू कर रहा था)। हो सकता है कि यह आपके मामले के लिए सही व्यवहार है, या हो सकता है कि आप प्रतीक्षा थ्रेड पर फेंकने के लिए अपवाद को ट्रिगर करने के लिए उदाहरण के लिए कुछ विशेष मान सेट करना चाहते हैं।

Answer 6

google "Memoizer"। मूल रूप से, AtomicReference के बजाय, Future का उपयोग करें।