W Java concurrency in practice
Locking can guarantee both visibility and atomicity; volatile can only guarantee visibility.
A w Java notes 4 professionals:
volatile reads and writes are guaranteed to be atomic
W Java concurrency in practice
Locking can guarantee both visibility and atomicity; volatile can only guarantee visibility.
A w Java notes 4 professionals:
volatile reads and writes are guaranteed to be atomic
volatile nie jest atomicity przy operacjach np. counter++. jest to read-modify-write, więc nie zapewni niepodzielności. tak samo np. przy lazy loading, gdzie masz check-then-act.
zazwyczaj volatile stosuje się np. przy flagach booleanowych.
Wbrew ogólnie panującemu przekonaniu, volatile ma tak naprawdę mało wspólnego z atomowością - według JLS, wszystkie operacje read i write są atomowe bez konieczności użycia volatile (wyjątek to long i double i dla nich volatile robi różnicę jeśli chodzi o atomowość). Volatile zapewnia przede wszystkim visibility przez stworzenie relacji happens-before pomiędzy kolejnymi operacjami read / write na takim fragmencie pamięci. Lock ma tą przewagę, że pozwala zgrupować kilka operacji read/write jako jedną atomową operację z gwarancją visibility.