lipkerson napisał(a)
Mam klase "Flagi" w której znajdują się same pola typu public static. Różne wątki korzystają z tych pól i mogą je również zmieniać.
To ryzykowne i odradzają tego autorzy wszystkich książek o współbieżności w Javie jakie znam. No chyba, że te pola są z rodziny klas Atomic. Dla pól innego typu istnieją krótkie, celowo spreparowane przykłady w Javie, które udowadniają, że taka konstrukcja spowoduje awarię danych.
Czy jest sens aby wzbogacić takie pole volatile? Wydaje mi się, ze nie bardzo.
Volatile powoduje, że pomijane będą optymalizacje odczytu (rejestry CPU, inne stosy wątków) oraz cache. Jest sens używać tego głównie wtedy kiedy pole może zostać zmodyfikowane przez kod/sprzęt spoza JVM lub kiedy pole jest używane między wątkami bez osobnej synchronizacji między wątkami (a taki przypadek właśnie tutaj zachodzi). Modyfikatora tego można używać właściwie tylko od wersji 1.5 Javy bo wcześniej był źle zaimplementowany.
Lub inaczej - w klasie dziedziczącej po Thread mam pole public static i wg mnie takie pole powinno być volatile (przy czym w tej klasie zmianę pola może wykonać tylko wątek tej klasy lub wątek główny).
Powinno. A poza tym czy ta klasa jest singletonem?
Moim zdaniem aby udostępniać między wątkami jakąkolwiek zmienną niesynchronizowaną, to zmienna ta powinna być volatile oraz klasy np. AtomicInteger. W innym wypadku łamie się odkryte już reguły współbieżności.