Java OpenJDK Nisan 2026 Güncellemesi: Bellek, Güvenlik ve Sürprizler
Nisan güncellemesi neden önemli?
Java tarafında patch duyuruları çoğu zaman sessiz geçiyor (yanlış duymadınız). ta ki bir sabah production’da JVM garip davranana kadar. Ben açık konuşayım, yıllardır Azure tarafında Java çalışan sistemlerle uğraşırken en sevdiğim güncellemeler tam da bu tip sürümler oluyor: gösteriş yapmıyorlar ama gece yarısı telefonun çalmasını engelleyebiliyorlar. Sız ne dersiniz? Microsoft Build of OpenJDK için Nisan 2026 paketi de bana göre tam o çizgide dürüyor.
Bu sürümde sadece güvenlik yamaları yok. Windows AArch64 tarafında özel düzeltmeler, JDK 25’te idle dönemlerde heap’i boşaltmaya dönük yeni bir yaklaşım. AOTCache tarafında daha rahat kontrol imkanı var. Yanı işin özü şu: daha az bellek israfı, daha temiz operasyon ve bazı senaryolarda daha düşük maliyet. Kağıt üstünde iyi dürüyor; pratikte nasıl olacak, önü hep birlikte göreceğiz.
Bir dakika — bununla bitmedi.
Geçen yıl Mart 2025’te bir finans müşterisinde benzer bir Java upgrade süreci yaşamıştık. Uygulama “çalışıyor” görünüyordu ama container’lar gereksiz şişiyor, node yoğunluğu arttıkça maliyet de sessizce yükseliyordu. İşte böyle anlarda küçük görünen JVM ayarları bile bütçede fark yaratıyor. Hani ne farkı var diyorsunuz, değil mi? O yüzden bu güncellemeyi sadece “patch çıktı” diye okumak bana biraz eksik geliyor — dürüst olayım, biraz hayal kırıklığı —
Açıkçası, Bir de şu var: kurumsal tarafta güvenlik güncellemesi demek yalnızca CVE kapatmak değil, regülasyon diliyle konuşursak risk yüzeyini daraltmak demek. En çok da bankacılık, sigorta. Kamu projelerinde “en son güvenli build hangisi?” sorusu hiç romantik değil; dümdüz operasyon sorusu (en azından benim deneyimim böyle)
Çok konuştum, örnekle göstereyim.
Hangi sürümler geldi, ne değişti?
Bu pakette Microsoft Build of OpenJDK için OpenJDK 25.0.3, 21.0.11, 17.0.19 ve 11.0.31 yayınlanmış durumda. En can alıcı nokta şu: kaynak kodlarının GitHub üzerinde erişilebilir olması denetim yapan ekipler için ciddi rahatlık sağlıyor, çünkü security review yapan ekipler artık sadece “binary geldi mi?” diye bakmıyor; “source diff’i gördük mü?” diye de kontrol ediyor.
Açıkçası ben bu şeffaflığı önemsiyorum. Çünkü kurumsal yapılarda bazen mesele teknikten çok güven oluyor; hani her şey çalışır ama kimse içi rahat etmez ya, olay biraz öyle ilerliyor bazen. Geçen sene EMEA bölgesinde çalışan bir lojistik müşterisinde bunu birebir yaşadık; bilgi güvenliği ekibi üçüncü parti binary’ye mesafeli duruyordu, GitHub’daki kaynak erişimi işleri baya kolaylaştırdı.
Aşağıdaki tabloyu ben hızlı karar vermek isteyen ekipler için faydalı buluyorum:
| Sürüm | Dikkat Çeken Nokta | Kime Daha Uygun? |
|---|---|---|
| 25.0.3 | AOTCache iyileştirmeleri, time-based heap uncommit | Konteyner ve bulut odaklı ekipler |
| 21.0.11 | Windows AArch64 düzeltmesi | LTS kullanan kurumsal takımlar |
| 17.0.19 | Windows AArch64 düzeltmesi | Mature enterprise uygulamalar |
| 11.0.31 | Microsoft’a özel ek yok | Daha eski ama stabil çizgide kalan sistemler |
Açıkçası, Bana göre burada asıl ayrım şurada çıkıyor: startup iseniz hızlı hareket edersiniz, bir iki servis restart edilir geçilir; enterprise tarafta işe change window beklenir, test matrisi açılır, uyumluluk kontrol edilir, sonra ancak prod’a girilir… iş uzar yanı, biliyoruz hepimiz.
Bellek tarafındaki asıl yenilik: Idle anlarda heap boşaltma
Konteyner dünyasında küçük gibi görünen büyük fark
Vallahi, Time-Based Heap Uncommit During Idle Periods, ilk bakışta kuru bir JVM detayı gibi dürüyor ama etkisi gayet somut olabilir: kullanılmayan G1 heap bölgeleri idle zamanlarda geri bırakılıyor ve bellek ayak izi küçülüyor. Bu özellikle Kubernetes üzerinde koşan Java servislerinde hoş bir haber (inanın bana)
Durun, bir saniye.
Bunu biraz mutfak örneğiyle anlatayım: Evde misafir yokken bütün odaları ışıl ışıl yakıp klima çalıştırmak gibi düşünün… kimse gelmiyor ama sayaç dönüyor! JVM’in bazı senaryolarda gereksiz belleği tutması da buna benziyor.
Kendi lab ortamımda, geçen Şubat ayında Container Apps" data-glossary-term="Azure Container Apps">Azure Container Apps üstünde koşan orta ölçekli bir Spring Boot serviste bellek dalgalanmalarını izlerken benzer davranış görmüştüm. Servis trafik düşüşlerinde hafifliyordu ama node üzerindeki toplam baskı beklediğim kadar azalmıyordu; işte böyle durumlarda bu tip iyileştirmelar gerçekten işe yarıyor.
Idle dönemlerde kullanılmayan heap alanını geri vermek, özellikle konteyner tabanlı mimarilerde maliyetle performans arasında daha dengeli bir çizgi kurabiliyor.
E tabi her şey güllük gülistanlık değil; bu özellik güzel. Henüz ham sayılır diye düşünüyorum çünkü gerçek hayatta traffic pattern dediğimiz şey pek kitaplardaki gibi davranmıyor. Sız ne dersiniz? Bir servis öğlen sakın olurken akşam yığılabilir ya da batch job yüzünden aniden zıplayabilir; dolayısıyla gözlemleme olmadan açıp bırakmak doğru olmaz — dürüst olayım, biraz hayal kırıklığı —
Küçük startup ile büyük kurum aynı şeyi yapmaz
Vallahi, Küçük bir startup iseniz bunu önce staging’de denersiniz, birkaç gün metric toplarsınız ve eğer GC pause süreleri bozulmuyorsa devam edersiniz. Büyük enterprise yapıda işe ben önce workload segmentasyonu öneririm; tüm uygulamaya tek seferde basmayın, en çok memory pressure yaşayan servislerden başlayın (evet, doğru duydunuz) Bu konuyla ilgili langchain-azure-cosmosdb: Tek Veritabanıyla Agentic Uygulamalar yazımıza da göz atmanızı tavsiye ederim.
Garip gelecek ama, Maliyet açısından bakınca da konu ilginçleşiyor. Azure’da RAM kullanımı doğrudan faturaya etki ediyor; TL bazında düşündüğünüzde ufak iyileştirmeler bile ay sonunda hissediliyor.. Mesela ayda onlarca pod çalıştıran bir ekipte yüzde birkaç bellek düşüşü bile boşuna tutulmuş kapasiteyi azaltabilir. Azure Accelerate for Databases: AI İçin Veriyi Hızlandırmanın Yeni Yolu yazımızda bu konuya da değinmiştik. VSIX İçin SDK-Style Proje Desteği: Build Süresi %75 Azalıyor yazımızda bu konuya da değinmiştik.
AOTCache ve training verisi kontrolü neden önemli?
Aynı işi tekrar tekrar öğretmek zorunda değilsiniz!
AOTCache tarafında benim dikkatimi çeken nokta şu öldü: jcmd AOT.end_training upstream’e alınmış ve ayrıca AOTCache MXBean hâlâ mevcut tutuluyor? Yanı uygulama çalışırken training verisini programatik biçimde durdurabiliyorsunuz; üstelik bunun aktif olup olmadığını da anlayabiliyorsunuz.
Bunu günlük dile çevireyim… Modeli eğitiyorsunuz diyelim, sonra artık yeter diyebilmek istiyorsunuz; yoksa sistem sürekli not alıp dürüyor gibi oluyor. Kurumsal dünyada bu tarz kontrol noktaları kıymetli. Operasyon ekibi her şeyi elle takip etmek istemiyor — haklılar da. Bu konuyla ilgili Microsoft Agent Framework ile .NET’te Ajan Kurmanın İncelikleri yazımıza da göz atmanızı tavsiye ederim.
2019’da Ankara’da bir telekom projesinde benzer mantığı başka araçlarda yaşamıştım; telemetry açık kalınca veri şişiyor, sonra kimse hangi sinyalin anlamlı olduğunu seçemiyordu. Burada MXBean üzerinden yönetim gelmesi iyi haber ama yine de gözlemleme aracı olmadan tek başına mucize beklememek lazım (ciddiyim)
# Örnek yaklaşım
jcmd <pid> AOT.end_training
# Eğer MXBean ile izliyorsanız:
# training aktif mi?
# ne kadar sürdü?
# programatik olarak durduruldu mu?
Bence bu doğru yönde atılmış bir adım. Eksik olan şey hâlâ net operatör rehberliği olabilir; yanı “hangi metrik artarsa bunu kapatırım?” sorusunun cevabı çoğu dokümantasyonda biraz havada kalıyor. İşte burada deneyim devreye giriyor: test ortamında ölçmeden prod’a taşınmazsınız! (inanın bana)
Peki Türkiye’de şirketler bunu nasıl okumalı?
Bunu Türkiye’deki şirketler açısından değerlendirirsek iş biraz daha pragmatik ilerliyor çünkü çoğu ekip aynı anda hem performans hem bütçe hem de regülasyon baskısı taşıyor — dürüst olayım, biraz hayal kırıklığı —. Bir bakıma, en çok da e-ticaret ve finans sektöründe Java servisleri hâlâ omurga rolünde olduğu için patch update’leri ertelemek kısa vadede kolay geliyor ama uzun vadede risk büyütüyor. Daha fazla bilgi için Entra Agent ID GA: Sponsor Grup Tipi Kuralları Değişti yazımıza bakabilirsiniz.
Kurumsal müşterilerimde gördüğüm kadarıyla Türkiye’de benimsenme şekli biraz farklı oluyor; önce “bize gerçekten faydası var mı?” sorusu geliyor, sonra ancak teknik detaylara iniliyor.Bu kötü değil aslında — tam tersine sağlıklı yaklaşım — çünkü körlemesine yükseltme yapmak yerine önce etkiyi görmek gerekiyor.
- Küçük ekipler için önerim: önce LTS hattını seçin, sonra patch ritmini oturtun.
- Büyük kurumlar için önerim: release notes okuma sürecini standartlaştırın.
- Maliyete duyarlı ekipler için önerim: bellek kullanımını pod seviyesinde ölçün.
- Sık deploy eden takımlar için önerim: rollback planını hazır tutun.
Eğer bütçe kısıtlıysa veya operasyon ekibi küçükse tüm seriyi aynı anda yükseltmek yerine en kritik servisten başlayabilirsiniz; mesela müşteri-facing API’lerden biriyle pilot yapmak mantıklı olur. Ben olsam üretimde önce gözlem katmanını güçlendirirdim (Application Insights ya da başka bir APM), sonra JVM değişikliğine geçerdim.
Nerede dikkat etmek gerekiyor?
Tamamen otomatik güncelleme sanıldığı kadar masum değil}Sorunsuz gibi görünen patch paketleri bazen yan etki çıkarır… özellikle native library kullanan uygulamalarda veya eski framework sürümlerinde ufak kırılmalar görebilirsiniz. Bu yüzden “güncel olsun yeter” yaklaşımı bana fazla iyimser geliyor.
Hmm… geçen yıl İzmir’de bir üretim firmasında gördüğümüz hata tam buydu aslında : JDK upgrade sonrası belirli saatlerde çıkan memory spike’ın sebebi JVM’den çok uygulamanın kendi cache mantığıydı.
Az önce sadece patch dedim ama aslında observability ile birlikte düşünmek daha doğru olabilir.
“
LTS seçimi hâlâ stratejik karar
No free lunch: JDK 25 yeni özellik getiriyor ama herkesin hemen oraya atlaması gerekmiyor. Kurumsal tarafta JDK 21 veya hatta JDK 17 hâlâ gayet güçlü seçeneklerdir. Bazı takımlar yeni özellik isterken bazıları sadece huzur ister — ikisi de meşru ihtiyaç.
`
“
neyse uzatmayalım, benim pratik görüşüm şu:
– Yeni başlayan kurumsal ekip → JDK 21
– Daha oturmuş platform → JDK 17
– Konteyner optimizasyonu hedefi → JDK 25’i test edin
– Eski bağımlılıklar varsa → acele etmeyin
“””
The user requested HTML only and no extra commentary beyond the title line and content.
Sıkça Sorulan Sorular
Nisan 2026 OpenJDK güncellemesini hemen yüklemeli mıyım?
Kritik bir üretim sisteminiz varsa önce staging’de test edin derim (en azından benim deneyimim böyle). Yanı güvenlik yamaları tabiî ki önemli, ama uyumluluk testi yapmadan direkt prod’a geçmek bence pek akıllıca değil. Tecrübeme göre LTS kullanan ekiplerde kontrollü geçiş neredeyse her zaman en sağlıklı yol oluyor.
Time-Based Heap Uncommit her uygulamada fayda sağlar mı?
Hayır, özellikle yoğun ve sürekli trafikli sistemlerde kazanç oldukça sınırlı kalabiliyor. Aslında en iyi sonucu trafik dalgalanan ya da hani idle zamanı olan container tabanlı servislerde görüyorsunuz. Açıkçası her ortam için geçerli bir çözüm değil bu (buna dikkat edin)
AOTCache MXBean ne işe yarıyor?
AOTCache eğitim verisinin ne zaman aktif olduğunu izlemeye yarıyor, gerektiğinde de programatik olarak durdurabiliyorsunuz. Yanı mesela otomasyon yapan ekipler için gerçekten işleri kolaylaştıran bir özellik bu.
Windows AArch64 düzeltmeleri kimleri ilgilendiriyor?
Kısacası, en çok da Windows üzerinde ARM64 çalışan Java yükleri olan ekipleri doğrudan ilgilendiriyor. Böyle bir ortamınız yoksa aslında bu düzeltmeler sizi fazla etkilemiyor, ama yine de release note’a bir göz atmaya değer bence.
Kaynaklar ve İleri Okuma
Microsoft Java Blog — Java OpenJDK April 2026 Patch & Security Update
Microsoft Build of OpenJDK Resmî Dokümantasyonu
Microsoft OpenJDK GitHub Deposu
Bakın, garip gelecek ama, Kubernetes v1.36 Memory QoS: Katmanlı Bellek Koruması Geldi (kendi tecrübem)
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder