volatile असल में क्या गारंटी देता है, और कब यह काफी नहीं होता?

volatile visibility और ordering की गारंटी देता है: एक write उस हर थ्रेड को दिखता है जो बाद में उस field को पढ़े, और यह एक happens before किनारा बनाता है, इसलिए उससे पहले की गई writes भी दिख जाती हैं। यह atomicity नहीं देता, तो count plus plus अब भी एक race है क्योंकि वह एक read, एक add और एक write है। compound actions के लिए synchronized, कोई lock, या AtomicLong जैसी atomic class इस्तेमाल करें।

volatile का मतलब है कि read हमेशा सबसे ताजा write देखे, न कि किसी register या core के cache में पड़ा पुराना value, और यह उसके आसपास compiler और processor की reordering रोक देता है। memory model की भाषा में यह एक happens before किनारा बनाता है, तो लिखने वाले थ्रेड ने volatile write से पहले जो कुछ किया वह उस थ्रेड को दिखता है जो बाद में उसे पढ़ता है। जो यह नहीं देता वह है atomicity। counter increment तीन operations हैं, तो दो थ्रेड्स एक ही value पढ़ सकते हैं और एक update खो जाता है, चाहे field कितनी भी volatile हो। मेरा आम जायज इस्तेमाल एक boolean flag है जो किसी background loop को रुकने को कहता है, जहां एक write और एक read ही पूरा पैटर्न है। जहां भी read modify write है वहां मैं AtomicInteger लेता हूं, या LongAdder अगर इतना गर्म है कि contention मायने रखने लगे, या lock अगर कई fields एक साथ बदलनी हों। memory model पर मैं एक और जगह भरोसा करता हूं, safe publication में, क्योंकि final fields construction के बाद दिखने की गारंटी रखती हैं, और यह चीजों को immutable रखने की अच्छी वजह है।