क्यों की इस उदाहरण में अस्थिर प्रयोग किया जाता है डबल जाँच की

Question

हेड फर्स्ट डिजाइन पैटर्न पुस्तक से, डबल जाँच की लॉकिंग के साथ सिंगलटन पैटर्न नीचे के रूप में लागू किया गया है ताला लगा:

public class Singleton { 
    private volatile static Singleton instance; 
    private Singleton() {} 
    public static Singleton getInstance() { 
     if (instance == null) { 
      synchronized (Singleton.class) { 
       if (instance == null) { 
        instance = new Singleton(); 
       } 
      } 
     } 
     return instance; 
    } 
} 

मुझे समझ नहीं आता क्यों volatile किया जा रहा है उपयोग किया गया। volatile उपयोग डबल चेकिंग लॉकिंग i.e प्रदर्शन का उपयोग करने के उद्देश्य को हराने के लिए नहीं करता है?

Answer 1

volatile क्यों समझने के लिए एक अच्छा संसाधन JCIP पुस्तक से आता है। विकिपीडिया में उस सामग्री के decent explanation भी हैं।

असली समस्या यह है कि Thread Ainstance का निर्माण समाप्त होने से पहले instance के लिए मेमोरी स्पेस असाइन कर सकता है। Thread B उस असाइनमेंट को देखेगा और इसका उपयोग करने का प्रयास करेगा। इसके परिणामस्वरूप Thread B विफल हो रहा है क्योंकि यह instance का आंशिक रूप से निर्मित संस्करण का उपयोग कर रहा है।

Answer 2

यदि आपके पास यह नहीं है, तो दूसरा थ्रेड सिंक्रनाइज़ किए गए ब्लॉक में पहले सेट के बाद इसे सेट कर सकता है, और आपका स्थानीय कैश अभी भी लगता है कि यह शून्य था।

पहला व्यक्ति शुद्धता के लिए नहीं है (यदि आप सही थे तो यह स्वयं को पराजित करेगा) बल्कि अनुकूलन के लिए।

Answer 3

वैरिएबल को volatile के रूप में घोषित करने की गारंटी देता है कि सभी इसका उपयोग वास्तव में स्मृति से वर्तमान मूल्य को पढ़ता है।

volatile के बिना, कंपाइलर मेमोरी एक्सेस को ऑप्टिमाइज़ कर सकता है और इसके मान को रजिस्टर में रख सकता है, इसलिए केवल चर का पहला उपयोग वैरिएबल वाले वास्तविक मेमोरी लोकेशन को पढ़ता है। यह एक समस्या है यदि चर को पहले और दूसरी पहुंच के बीच किसी अन्य धागे द्वारा संशोधित किया गया है; पहले थ्रेड में पहले (पूर्व-संशोधित) मान की केवल एक प्रति है, इसलिए दूसरा if कथन वैरिएबल के मान की एक पुरानी प्रतिलिपि का परीक्षण करता है।

Answer 4

ठीक है, प्रदर्शन के लिए कोई डबल-चेक लॉकिंग नहीं है। यह टूटा पैटर्न है।

छोड़कर भावनाओं तरफ, volatile समय दूसरा धागा गुजरता instance == null द्वारा क्योंकि इसके बिना यहाँ है, पहले धागा अभी तक new Singleton() का निर्माण नहीं हो सकता है: कोई भी वादा करता है कि वस्तु के निर्माण के किसी भी थ्रेड के लिए होता है-पहले काम instance के लिए, लेकिन वास्तव में वस्तु बनाते हैं।

volatile बदले में होता है पढ़ने और लिखने के बीच संबंध, और टूटे पैटर्न को ठीक करता है।

यदि आप प्रदर्शन की तलाश में हैं, तो इसके बजाय धारक आंतरिक स्थिर वर्ग का उपयोग करें।

Answer 5

एक अस्थिर पढ़ना वास्तव में महंगा नहीं है।

आप एक अस्थिर पढ़ने के प्रभाव का निरीक्षण करने के लिए, एक तंग लूप में getInstance() पर कॉल करने के लिए एक परीक्षण तैयार कर सकते हैं; हालांकि यह परीक्षण यथार्थवादी नहीं है; ऐसी स्थिति में, प्रोग्रामर आमतौर पर getInstance() पर कॉल करेगा और उपयोग की अवधि के लिए उदाहरण कैश करेगा।

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

Answer 6

जैसा कि @irreputable द्वारा उद्धृत किया गया है, अस्थिर महंगा नहीं है। यहां तक ​​कि यदि यह महंगा है, तो प्रदर्शन पर स्थिरता को प्राथमिकता दी जानी चाहिए।

आलसी सिंगलेट्स के लिए एक और साफ सुरुचिपूर्ण तरीका है।

public final class Singleton { 
    private Singleton() {} 
    public static Singleton getInstance() { 
     return LazyHolder.INSTANCE; 
    } 
    private static class LazyHolder { 
     private static final Singleton INSTANCE = new Singleton(); 
    } 
} 

स्रोत लेख: Initialization-on-demand_holder_idiom विकिपीडिया

से सॉफ्टवेयर इंजीनियरिंग में, मांग धारक पर प्रारंभ (डिजाइन पैटर्न) मुहावरा एक आलसी-लोडेड सिंगलटन है। जावा के सभी संस्करणों में, मुहावरा अच्छा प्रदर्शन

के साथ एक सुरक्षित, अत्यधिक समवर्ती आलसी आरंभीकरण

के बाद से कक्षा प्रारंभ करने में किसी भी static चर नहीं है, प्रारंभ तुच्छता से पूरा करता है सक्षम बनाता है।

स्थिर श्रेणी परिभाषा LazyHolder इसके भीतर प्रारंभ नहीं की जाती है जब तक कि JVM निर्धारित करता है कि LazyHolder को निष्पादित किया जाना चाहिए।

स्थिर वर्ग LazyHolder केवल जब स्थिर विधि getInstance वर्ग सिंगलटन पर शुरू हो जाती है निष्पादित किया जाता है, और पहली बार ऐसा होता है JVM लोड और LazyHolder वर्ग प्रारंभ हो जाएगा।

यह समाधान विशेष भाषा संरचनाओं (यानी volatile या synchronized) की आवश्यकता के बिना थ्रेड-सुरक्षित है।