Tarihçe: Erken Java derleyicileri, sabit ifadelerle başlatılan static final alanları gerçek adlandırılmış sabitler olarak ele aldı. JVM spesifikasyonu, bu değerlerin agresif optimizasyonuna izin verir ve HotSpot derleyicisinin alan erişim aşamasını ortadan kaldırarak değerleri doğrudan makine koduna yerleştirmesine olanak tanır. Bu sürekli katlama optimizasyonu, Java yüksek performanslı hesaplama için benimsendikçe daha da önemli hale geldi, çünkü dolaylı yönlerin ortadan kaldırılması önemli gecikme iyileştirmeleri sağlar.
Problem: Static final bir alan, bir derleme zamanı sabit ifade ile başlatıldığında (örneğin, bir literal (100), bir metin literal veya sabitlerin aritmetik kombinasyonu) javac derleyicisi, değeri istemci sınıfların bytecode'una ldc (sabit yükleme) talimatı kullanarak yerleştirir. Sonuç olarak, değer derleme zamanında arayanın sabitler havuzuna yerleştirilmiş olur; bu, çalışma zamanında getstatic ile alınmaz. Eğer yansıma daha sonra heap içinde alanın değerini değiştirirse, daha önce derlenmiş yöntemler yerleştirilen literali çalıştırmaya devam eder, böylece heap yeni değeri gösterirken çalışan kod orijinal sabiti gözlemler.
Çözüm: Yansıtıcı güncellemelerin görünür olmasını garanti etmek için, değişken yapılandırmalar için derleme zamanı sabit başlatmaktan kaçının. Çalışma zamanı hesaplamasını zorlayın — örneğin static final int MAX = Integer.valueOf(100); veya sistem özelliklerini okuyan bir static blok içinde başlatma — bu, derleyicinin getstatic talimatları yaymasını zorlayacaktır. Bu, alan dolaylılığını korur ve JVM'nin yansıtma işlemi alanın önbelleğini geçersiz kıldığında güncellenmiş değeri gözlemlemesine olanak tanır.
// Sorunlu: İstemci bytecode'una yerleştirilmiş literal 100 olarak public class Config { public static final int THRESHOLD = 100; } // Güvenli: getstatic aramasını zorlar public class Config { public static final int THRESHOLD = Integer.parseInt("100"); }
Problem tanımı: Yüksek frekanslı bir ticaret platformu kritik yolu optimize etmek için public static final int MAX_POSITION = 10000; olarak bir risk sınırı belirledi. Piyasa oynaklığı sırasında, risk yönetimi ekibi aşırı maruz kalmayı önlemek için bu eşiği dinamik olarak düşürmeye çalıştı. MBean, başarı bildirmiş ve yeni yüklenen sınıflar azaltılmış sınırı gözlemlemiş olmasına rağmen, mevcut işlem siparişi işleyen iş parçacıkları birkaç saat boyunca orijinal 10.000 limiti kabul etmeye devam etti ve bu da uygulamanın yeniden başlatılmasından önce düzenleyici bir ihlale neden oldu.
Çözüm 1: Final modifikatörünü kaldırın: Alanı static volatile int olarak değiştirmek, yansıtmanın hemen çalışmasına izin verecek ve görünürlük garantileri sağlayacaktır. Ancak, bu, ek senkronizasyon olmaksızın güvenli yayınlama için Java Bellek Modeli'nin öncelik garantilerini kaldırır ve derleyicinin alan erişimini ortadan kaldırmasını zorlaştırır, bu da kritik yol üzerindeki her risk kontrolünde nanosekondda gecikmeye neden olabilir.
Çözüm 2: Sarıcı dolaylılık: Primitifi, static final bir referans içinde tutulan AtomicInteger ile değiştirmek (static final AtomicInteger MAX_POSITION = new AtomicInteger(10000);). Bu, kilitsiz iş parçacığı güvenli güncellemeler ve tüm iş parçacıkları arasında tam görünürlük sağlar. Dezavantajı, bellek ayak izinde küçük bir artış ve çağrı yerlerini MAX_POSITION'dan MAX_POSITION.get()'e güncelleme ihtiyacı ile birlikte gelir, ancak bu, operasyonel yapılandırmanın değişken doğasını doğru bir şekilde modelleyebilir.
Çözüm 3: Yayın-abone ile yapılandırma hizmeti: Güncellemeleri uygulama olayları yoluyla yayınlayan özel bir ConfigurationService uygulamak. Yüzlerce parametreye sahip büyük sistemler için mimari olarak daha üstün olmasına rağmen, bu tek kritik eşik için gereğinden fazla olduğu düşünülmüştür ve binlerce çağrı noktasını yeniden yapılandırmayı gerektirmiştir, bu da gerileme riski taşımaktadır.
Seçilen çözüm: Çözüm 2 seçildi çünkü alan temelde sabit olarak maskelenen değişken bir operasyonel durumdu. AtomicInteger, sistemin yeniden başlatılmasını gerektirmeden gerekli görünürlük garantilerini sağladı. Risk yönetimi ekibi artık JMX üzerinden gerçek zamanlı olarak limitleri ayarlayabiliyordu ve sistem değişiklikten sonra tüm iş parçacıkları arasında yeni eşikleri hemen uyguluyordu.
Sonuç: Olay, sınırlara uymayan başka ticaretler olmadan çözüldü ve firma, operasyonel ayarlamaya tabi olan herhangi bir yapılandırma için derleme zamanı sabitlerini yasaklayan bir statik analiz kuralı uyguladı, böylece gelecekteki yansıtıcı güncellemeler ile çalışma zamanı davranışı arasındaki uyumsuzlukları önledi.
Bir derleme zamanı sabitini, bytecode düzeyinde sıradan bir static final alandan ne ayırır?
Bir derleme zamanı sabiti, yalnızca literaller, enum sabitleri veya diğer sabitler üzerindeki operatörlerden oluşan bir ifade olarak JLS 15.29 tarafından tanımlanır ve derleyici, bu tür alanlar için sınıf dosyasında ConstantValue niteliğini yayar. İstemci sınıflar, bu alanları ldc (sabit yükleme) yerine getstatic (statik alanı al) ile işler; bu, derleme sırasında arayanın sabitler havuzuna değerin kopyalanması anlamına gelir. Bu, gerçekten de derleme zamanı değerine sert bir bağımlılık yaratır ve alan konumuna çalışma zamanı bağlantısı bırakmadığı için, orijinal alan güncellenirse arayanları eski değere karşı derlenmiş durumda etkileyemez.
Yansıma, alanı başarılı bir şekilde değiştirmiş gibi görünüyorsa, bu değişiklik neden çalışan kodda görünmez?
Yansıma, Class meta verisindeki Field nesnesinin iç slotlarında çalışır. Field#setInt başarılı olduğunda, heap'teki statik alanın gerçek bellek konumunu günceller. Ancak, HotSpot'un C2 derleyicisi, JIT derlemesi sırasında sürekli katlama işlemi gerçekleştirmişse, doğrudan derlenen kodun içine hemen değeri yerleştirmiştir (örneğin, mov eax, 10000). Bu derlenmiş kod, tamamen bellek yüklemesini atlar. Yansıma güncellemesi heap'te gerçektir, ancak derlenmiş kod "eski" kalır, metod geri optimize edilip yeniden derlenmediği sürece, bu durum meydana gelebilir. Bu, alanı yansıma yoluyla kontrol eden birim testlerinin geçerliyken üretim kodunun eski değeri kullanmaya devam etmesine neden olur.
Sabit final referans türleri (String dışındaki) sürekli katlanabilir mi ve bu yansıma görünürlüğünü nasıl etkiler?
String ve primitive sabitler dışında yerleştirilmiş olan sabitler, javac tarafından yerleştirilmez. Diğer referans türleri için (örneğin, static final Object LOCK = new Object()), derleyici, referans kimliğinin sabitler havuzuna gömülememesi nedeniyle getstatic yayımlamak zorundadır. Ancak, JVM, kaçış analizi, referansın asla değişmeyeceğini kanıtladığında, JIT derlemesi sırasında çalışma zamanında sürekli propagasyon yapabilir. Bu şekilde, yansıma, derlenmiş kodun geçersizliğini zorlayabilir, ancak JVM'nin hemen geri optimize etme garantisi yoktur, bu da geçici görünürlük sorunlarına yol açar. Bu nedenle, referans türleri, yansıma görünmezliğine karşı bir miktar daha güvende olabilir, ancak optimizasyon artifaktlarına karşı bağışık değildir.