Odpowiedź.

Historia pytania:

Gdy Java pojawiła się po raz pierwszy, nie istniało formalne opisananie tego, jak pamięć i wątki współdziałają. W efekcie te same programy mogły zachowywać się różnie na różnych JVM, co prowadziło do trudnych do wykrycia błędów. W 2004 roku do specyfikacji Java dodano Java Memory Model (JMM), mający na celu ścisłe określenie, jak wątki widzą aktualizacje zmiennych.

Problem:

Bez jasnego modelu pamięci operacje zapisu i odczytu mogą być mieszane przez kompilator lub procesor, co prowadzi do nieoczekiwanego zachowania podczas dostępu do wspólnych zmiennych z różnych wątków. Może to spowodować race condition, problemy z widocznością i trudne do debugowania błędy synchronizacji.

Rozwiązanie:

JMM definiuje zasady: kiedy zmiany wprowadzone przez jeden wątek stają się widoczne dla innych. Wprowadza pojęcia happens-before, synchronizatorów (synchronized, volatile, final), wewnętrznych blokad i ogranicza reorganizację instrukcji w wielowątkowym środowisku.

Przykład kodu:

class Counter {
    private int count = 0;

    public synchronized void increment() {
        count++;
    }

    public synchronized int get() {
        return count;
    }
}

Kluczowe cechy:

JMM definiuje, kiedy zmiany jednej zmiennej są widoczne dla innych wątków
Użycie synchronized lub volatile gwarantuje prawidłową publikację zmian
Niewłaściwe użycie może prowadzić do niepoprawnego działania nawet przy braku jawnych błędów

Pytania z pułapką.

Dlaczego volatile nie czyni operacji atomowymi, a jedynie zapewnia widoczność?

Volatile gwarantuje tylko widoczność zmian między wątkami, ale nie atomowość zmiany. Na przykład inkrementacja zmiennej volatile nie jest operacją atomową, ponieważ samo działanie składa się z odczytu, zmiany i zapisu.

Przykład kodu:

volatile int count = 0;
count++; // Nie atomowo!

Czy blok synchronized może zagwarantować widoczność zmian poza jego zakresem?

Tak. Po opuszczeniu bloku synchronized wszystkie zmiany wprowadzone wewnątrz są widoczne dla innych wątków, które wejdą do bloku na ten sam obiekt-monitor.

Kiedy zmiany pól final stają się widoczne dla innych wątków?

Pola final gwarantują prawidłową publikację tylko wtedy, gdy obiekt jest w pełni skonstruowany przed przekazaniem referencji do niego innym wątkom, na przykład poprzez obiekty immutable. W przeciwnym razie może wystąpić widoczność niezainicjowanego stanu.

Typowe błędy i antywzorce

Używanie wielowątkowości bez synchronizacji na zmiennych współdzielonych między wątkami
Poleganie tylko na volatile dla skomplikowanych operacji
Publikowanie nieskonstruowanych obiektów między wątkami

Przykład z życia

Negatywny przypadek

Programista postanowił zwiększyć licznik wejść na stronę za pomocą prostego volatile inkrementu z kilku wątków.

Zalety:

Prostsze, nie trzeba się martwić o synchronized.

Wady:

Rzeczywista utrata inkrementów przy dużych obciążeniach z powodu braku atomowości
Race condition i błędna statystyka.

Pozytywny przypadek

Użyto AtomicInteger dla licznika lub metod synchronized.