Cevap.

Soru tarihi:

Java ilk ortaya çıktığında, bellek ve iş parçacıkları arasındaki etkileşimi tanımlayan resmi bir açıklama yoktu. Sonuç olarak, aynı programlar farklı JVM'lerde farklı davranabiliyordu, bu da tespit edilmesi zor hatalara yol açıyordu. 2004 yılında Java spesifikasyonuna Java Bellek Modeli (JMM) eklendi; iş parçacıklarının değişken güncellemelerini nasıl gördüğünü kesin olarak tanımlamak amacıyla.

Sorun:

Kesin bir bellek modelinin olmaması durumunda okuma ve yazma işlemleri, derleyici veya işlemci tarafından karıştırılabilir, bu da farklı iş parçacıklarından ortak değişkenlere erişirken beklenmedik davranışlara neden olabilir. Bu, yarış durumu, görünürlük sorunları ve hata ayıklaması zor senkronizasyon hatalarına yol açabilir.

Çözüm:

JMM, bir iş parçacığı tarafından yapılan değişikliklerin diğerlerine ne zaman görünür hale geleceğini tanımlayan kurallar belirler. Happens-before kavramlarını, senkronizatörleri (synchronized, volatile, final), iç kilitleri tanımlar ve çoklu iş parçacıklı ortamda talimatların yeniden düzenlenmesini sınırlar.

Kod örneği:

class Counter {
    private int count = 0;

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

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

Anahtar özellikler:

JMM, bir değişkenin değişikliklerinin diğer iş parçacıkları tarafından ne zaman görüleceğini tanımlar
Synchronized veya volatile kullanımı, değişikliklerin doğru bir şekilde yayımlanmasını garanti eder
Yanlış kullanım, belirgin hatalar olmaksızın yanlış çalışmaya yol açabilir

Sorularla birlikte zorluklar.

Neden volatile işlemleri atomik yapmaz, sadece görünürlük sağlar?

Volatile, iş parçacıkları arasındaki değişikliklerin görünürlüğünü garanti eder, ancak değişikliklerin atomik olmasını sağlamaz. Örneğin, bir volatile değişkeni arttırmak atomik bir işlem değildir çünkü bu işlem okuma, değiştirme ve yazma adımlarını içerir.

Kod örneği:

volatile int count = 0;
count++; // Atomik değil!

Synchronized blok, dışındaki değişikliklerin görünürlüğünü garanti eder mi?

Evet. Synchronized bloktan çıktıktan sonra, içindeki tüm değişiklikler, aynı nesne monitörüne girecek diğer iş parçacıkları tarafından görünür hale gelir.

Final alanların değişiklikleri diğer iş parçacıklarına ne zaman görünür?

Final alanlar, nesne tamamen diğer iş parçacıklarıyla bağlantı kurulmadan önce oluşturulduğunda doğru yayılmayı garanti eder; örneğin, immutable nesneler aracılığıyla. Aksi takdirde, başlatılmamış durumların görünürlüğü mümkündür.

Yaygın hatalar ve anti-patentler

İş parçacıkları arasında paylaşılan değişkenler üzerinde senkronizasyon olmadan çoklu iş parçacıklılığın kullanımı
Karmaşık işlemler için yalnızca volatile kullanmaya güvenmek
İş parçacıkları arasında biçimlenmemiş nesneleri yayımlamak

Gerçek hayattan bir örnek

Olumsuz durum

Geliştirici, birden fazla iş parçacığından basit volatile artırıcı kullanarak web sitesindeki giriş sayısını artırmaya karar verdi.

Artılar:

Daha basit, synchronized ile uğraşmaya gerek yok

Eksiler:

Atomiklik eksikliği nedeniyle yüksek yük altında gerçek artırımların kaybı
Yarış durumu ve yanlış istatistikler

Olumlu durum

Sayaç için AtomicInteger veya senkronize yöntemler kullanıldı.