परमाणु बूलियन बनाम सिंक्रनाइज़ ब्लॉक

Question

मैं AtomicBoolean के साथ synchronized ब्लॉक को प्रतिस्थापित करके अपने कोड में थ्रेड विवाद को काटने की कोशिश कर रहा था।

public void toggleCondition() { 
    synchronized (this.mutex) { 
     if (this.toggled) { 
      return; 
     } 

     this.toggled = true; 
     // do other stuff 
    } 
} 

और AtomicBoolean के साथ वैकल्पिक:

public void toggleCondition() { 
    if (!this.condition.getAndSet(true)) { 
     // do other stuff 
    } 
} 

AtomicBoolean के कैस संपत्ति का लाभ उठाते हुए जिस तरह से तुल्यकालन पर भरोसा तो मैं एक भाग की तुलना में तेजी से किया जाना चाहिए

यहाँ synchronized साथ एक उदाहरण है little micro-benchmark।

10 समवर्ती धागे और 1000000 पुनरावृत्तियों के लिए, AtomicBooleansynchronized ब्लॉक से थोड़ा तेज में आता है।

(धागा प्रति)

औसत समय AtomicBoolean साथ toggleCondition() पर खर्च: 0.0338

(धागा प्रति)

औसत समय सिंक्रनाइज़ साथ toggleCondition() पर खर्च: 0,0357

मैं जानता हूँ कि सूक्ष्म मानक के लायक हैं क्या वे लायक हैं लेकिन अंतर अधिक नहीं होना चाहिए?

Answer 1

मुझे पता है कि माइक्रो-बेंचमार्क उनके लायक हैं, लेकिन क्या अंतर अधिक नहीं होना चाहिए?

मुझे लगता है कि समस्या आपके बेंचमार्क में है। ऐसा लगता है कि प्रत्येक धागा सिर्फ एक बार स्थिति टॉगल करने जा रहा है। बेंचमार्क अपने अधिकांश समय धागे बनाने और नष्ट करने में व्यतीत करेगा। मौका है कि किसी भी दिए गए धागे एक ही समय में एक शर्त को टॉगल कर रहे हैं क्योंकि किसी भी अन्य थ्रेड को टॉगल करना शून्य के करीब होगा।

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

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

संपादित

तो परिदृश्य आप परीक्षण करने का इरादा केवल धागा (और 10 धागे) प्रति एक टॉगल शामिल है, तो यह संभावना नहीं है कि आपके आवेदन विवाद का अनुभव होगा, और इसलिए यह है कि AtomicBoolean का उपयोग कर की संभावना कम है कोई फर्क पड़ता है।

इस बिंदु पर, मुझे यह पूछना चाहिए कि आप इस विशेष पहलू पर अपना ध्यान क्यों केंद्रित कर रहे हैं। क्या आपने अपना आवेदन प्रोफाइल किया है और यह निर्धारित किया है कि वास्तव में आपके पास लॉक विवाद समस्या है? या आप बस अनुमान लगा रहे हैं? क्या आपको अभी तक समयपूर्व अनुकूलन की बुराइयों पर मानक व्याख्यान दिया गया है ??

Answer 2

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

/** 
* Atomically sets to the given value and returns the previous value. 
* 
* @param newValue the new value 
* @return the previous value 
*/ 
public final boolean getAndSet(boolean newValue) { 
    for (;;) { 
     boolean current = get(); 
     if (compareAndSet(current, newValue)) 
      return current; 
    } 
} 

/** 
* Atomically sets the value to the given updated value 
* if the current value {@code ==} the expected value. 
* 
* @param expect the expected value 
* @param update the new value 
* @return true if successful. False return indicates that 
* the actual value was not equal to the expected value. 
*/ 
public final boolean compareAndSet(boolean expect, boolean update) { 
    int e = expect ? 1 : 0; 
    int u = update ? 1 : 0; 
    return unsafe.compareAndSwapInt(this, valueOffset, e, u); 
} 

और फिर इस com.sun.Unsafe.java

/** 
* Atomically update Java variable to <tt>x</tt> if it is currently 
* holding <tt>expected</tt>. 
* @return <tt>true</tt> if successful 
*/ 
public final native boolean compareAndSwapInt(Object o, long offset, 
               int expected, 
               int x); 

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