Yeni bir instance’ın JVM’i başlatması, sınıfları yüklemesi, framework context’ini oluşturması ve kodu optimize etmesi zaman alır. İstek trafiğinin olmadığı bir sürenin ardından fonksiyon yeniden oluşturuluyorsa kullanıcı bu maliyeti doğrudan “cold start” gecikmesi olarak hisseder.

GraalVM Native Image, Java uygulamasını dağıtım öncesinde makine koduna derleyerek bu denklemi değiştirir. Uygulama, çalışma anında JAR ve tam bir JVM başlatmak yerine işletim sistemi üzerinde doğrudan çalışan platforma özgü bir executable olarak açılır. GraalVM belgelerine göre native executable yalnızca erişilebilir uygulama ve JDK kodunu, gerekli çalışma zamanı bileşenlerini ve statik olarak bağlanan yerel kodu içerir; bunun sonucu milisaniyeler düzeyinde başlangıç, warm-up gerektirmeyen performans ve daha düşük kaynak tüketimidir. (GraalVM Native Image belgeleri)

Cold start neden oluşur?

Bir Java mikroservisinin ilk isteğe hazır hâle gelmeden önce tipik olarak şu işlemleri tamamlaması gerekir:

1. JVM süreci başlatılır.
2. Uygulama sınıfları ve bağımlılıklar yüklenir.
3. Bytecode doğrulanır ve yorumlanmaya başlanır.
4. Spring ApplicationContext oluşturulur.
5. Bean tanımları, koşullu konfigürasyonlar ve proxy’ler hazırlanır.
6. Sık çalışan kod yolları belirlenir ve JIT compiler tarafından optimize edilir.
7. Bağlantı havuzları ve harici servis istemcileri hazırlanır.

Uzun süre çalışan bir serviste bu maliyet yalnızca bir kez ödenir ve JIT optimizasyonları zaman içinde önemli throughput avantajı sağlar. Buna karşılık serverless platformlarda, scale-to-zero kullanan Kubernetes ortamlarında veya çok sık pod oluşturan sistemlerde başlangıç maliyeti tekrar tekrar ödenebilir.

Cold start yalnızca uygulamanın main metoduna ulaşma süresi değildir. Gerçek ölçüm, yeni instance’ın ilk isteğe doğru yanıt verebildiği ana kadar geçen süreyi kapsamalıdır.

JIT ve AOT arasındaki mimari fark

JIT: Çalışırken öğrenen optimizasyon

Geleneksel JVM modelinde Java kaynak kodu önce bytecode’a çevrilir:

Java kaynak kodu
        ↓
     Bytecode
        ↓
 JVM + Interpreter
        ↓
   JIT Compiler
        ↓
Optimize makine kodu

JIT, uygulamanın gerçek çalışma davranışını gözlemler. Hangi metotların sık çağrıldığını, dallanmaların hangi yönde ilerlediğini ve hangi kod yollarının “hot” olduğunu belirleyerek bu bölümleri çalışma sırasında optimize eder.

Bunun önemli bir avantajı vardır: Optimizasyon kararları gerçek trafik profilinden beslenir. Uzun süre çalışan ve CPU yoğun işlem yapan servislerde JVM, yeterli warm-up sonrasında çok yüksek tepe performansına ulaşabilir.

Bedeli ise JVM’in, derleyicinin, profil verilerinin ve sınıf metadata’sının bellekte bulunmasıdır. Uygulama ayrıca en iyi performansına hemen değil, belirli bir ısınma süresinden sonra ulaşır.

AOT: Çalışmadan önce tamamlanan derleme

GraalVM Native Image, bytecode’u build aşamasında analiz eder ve platforma özgü makine koduna dönüştürür:

Uygulama + bağımlılıklar + JDK sınıfları
                    ↓
      Erişilebilirlik analizi
                    ↓
       AOT optimizasyon ve derleme
                    ↓
 Kod + image heap + native runtime
                    ↓
        Native executable

Analiz main metodu gibi giriş noktalarından başlar. Erişilebilen sınıflar, metotlar ve alanlar tekrarlı biçimde bulunur; kullanılmadığı belirlenen parçalar native executable’a eklenmez. Derlemeden sonra yeni program elemanlarının çalışma anında sisteme eklenememesi “closed-world assumption”, yani kapalı dünya varsayımı olarak adlandırılır. (Native Image çalışma modeli)

Bazı sınıflar build sırasında initialize edilebilir. Oluşan nesneler ve statik durum “image heap” içerisine kaydedilir. Uygulama açıldığında bu işlerin yeniden yapılmaması startup süresini kısaltır.

AOT her durumda JIT’ten daha hızlı demek değildir. Native Image’ın temel avantajı başlangıç ve kaynak verimliliğidir. Uzun süre çalışan, CPU yoğun servislerde JIT’in çalışma zamanı profiline dayanan optimizasyonları daha yüksek throughput sağlayabilir. GraalVM’in Profile-Guided Optimization özelliği, temsilî trafikten profil toplayıp bunu AOT derlemeye taşıyarak aradaki farkı azaltabilir. (GraalVM optimizasyon belgeleri)

Startup süresi ve memory footprint üzerindeki etkisi

Native executable çalıştırılırken tam bir HotSpot JVM’in başlatılmasına ve uygulama kodunun JIT tarafından ısıtılmasına gerek kalmaz. Gereksiz sınıfların binary’ye alınmaması da class metadata, JIT code cache ve derleyici altyapısının çalışma zamanı maliyetlerini azaltır.

Cloud-native sistemlerde bu özellikler üç alanda değer üretir:

• Serverless fonksiyonlar ilk isteğe daha kısa sürede cevap verebilir.
• Kubernetes pod’ları daha hızlı hazır duruma gelerek scale-out gecikmesini azaltabilir.
• Aynı bellek bütçesi içerisinde daha fazla servis instance’ı çalıştırılabilir.

Ancak sonucu tek bir evrensel yüzdeyle ifade etmek doğru değildir. Kazanç; kullanılan framework’e, dependency sayısına, heap ayarlarına, GC seçimine, container limitlerine ve uygulamanın başlangıç sırasında yaptığı I/O işlemlerine bağlıdır.

Örneğin uygulama açılışta veritabanı migrasyonu çalıştırıyor veya uzak bir secret servisine bağlanıyorsa native executable bu ağ gecikmesini ortadan kaldırmaz. GraalVM kod başlatma maliyetini azaltır; dış sistemlerin gecikmesini sihirli biçimde çözmez.

Bu nedenle JVM ve native sürümleri aynı koşullarda karşılaştırın:

# JVM sürümü
/usr/bin/time -v java -jar target/cold-start-demo.jar

# Native sürüm
/usr/bin/time -v ./target/cold-start-demo

macOS üzerinde ayrıntılı süreç ölçümü için:

/usr/bin/time -l ./target/cold-start-demo

Yalnızca konsoldaki “Started” mesajını değil, aşağıdaki metrikleri kaydedin:

• Process başlangıcından readiness durumuna kadar geçen süre
• İlk isteğin p50, p95 ve p99 gecikmesi
• Warm request gecikmesi
• Peak RSS ve steady-state RSS
• CPU tüketimi
• Binary veya container image boyutu
• Native image build süresi
• Gerçek trafik altındaki throughput

GraalVM Native Image’ın zorlandığı alanlar

1. Reflection

Reflection kullanılan kodda çağrılacak sınıf veya metot adı çalışma anında bir konfigürasyondan gelebilir. Statik analiz bu ilişkiyi göremiyorsa ilgili sınıfın kullanılmadığını düşünerek onu binary dışında bırakabilir.

Sonuç olarak uygulama başarıyla derlense bile yalnızca belirli bir endpoint çağrıldığında hata verebilir. JSON serileştirme, ORM, dependency injection ve plugin tabanlı kütüphaneler bu açıdan özellikle test edilmelidir.

Spring Boot 3’ün AOT motoru controller dönüş tipleri, bean tanımları ve pek çok framework kullanımına ait hint’leri otomatik üretir. Otomatik çıkarımın yetmediği durumlarda @RegisterReflectionForBinding veya RuntimeHintsRegistrar kullanılabilir. (Spring Boot özel native hint rehberi)

Örneğin çalışma anında JSON’a dönüştürülecek bir sınıfı açıkça kaydetmek için:

import org.springframework.aot.hint.annotation.RegisterReflectionForBinding;
import org.springframework.context.annotation.Configuration;

@Configuration
@RegisterReflectionForBinding(PaymentRequest.class)
class NativeConfiguration {
}

2. Dynamic proxy

Spring AOP, declarative transaction yönetimi ve bazı HTTP client kütüphaneleri çalışma anında proxy oluşturabilir. JVM üzerinde ihtiyaç anında üretilebilen bu sınıfların native executable içinde önceden bilinmesi gerekir.

Spring AOT, kendi tanıyabildiği proxy’leri build sırasında üretir. Uygulamaya özgü bir JDK proxy için runtime hint eklenebilir:

import org.springframework.aot.hint.RuntimeHints;
import org.springframework.aot.hint.RuntimeHintsRegistrar;

class ApplicationRuntimeHints implements RuntimeHintsRegistrar {

    @Override
    public void registerHints(
            RuntimeHints hints,
            ClassLoader classLoader) {

        hints.proxies().registerJdkProxy(PaymentClient.class);
    }
}

Registrar’ı uygulamaya bağlayalım:

import org.springframework.context.annotation.ImportRuntimeHints;

@SpringBootApplication
@ImportRuntimeHints(ApplicationRuntimeHints.class)
public class PaymentApplication {

    public static void main(String[] args) {
        SpringApplication.run(PaymentApplication.class, args);
    }
}

Spring’in CGLIB tabanlı proxy’leri de JVM’de çalışma anında oluşturulurken native build sürecinde önceden üretilir. Oluşturulan proxy sınıfları Maven projelerinde target/spring-aot/main/classes altında incelenebilir. (Spring AOT proxy üretimi)

3. Classpath kaynakları

JSON şablonları, sertifikalar, SQL dosyaları, localization bundle’ları veya statik dosyalar Java kodu olmadığı için yalnızca erişilebilirlik analiziyle her zaman bulunamaz.

Bir kaynağı Spring runtime hints API ile eklemek mümkündür:

@Override
public void registerHints(
        RuntimeHints hints,
        ClassLoader classLoader) {

    hints.resources().registerPattern("templates/*.json");
    hints.resources().registerPattern("db/migration/**");
}

GraalVM ayrıca META-INF/native-image altındaki reachability-metadata.json dosyalarını okuyabilir:

{
  "resources": [
    {
      "glob": "templates/*.json"
    }
  ]
}

Native executable içine gömülen kaynaklar gerçek bir dosya sistemi yolu olmayabilir. Bu nedenle URL#getFile() yerine getResourceAsStream() veya URL#openStream() tercih edilmelidir. Gerekli metadata bulunmayan dinamik erişimler çalışma zamanı hatasına dönüşebilir. (GraalVM Reachability Metadata)

Spring Boot 3 ile native executable oluşturma

Aşağıdaki örnek Maven tabanlı bir Spring Boot 3 projesini temel alır.

Adım 1: Projeyi oluşturun

start.spring.io üzerinden şu seçimlerle bir proje oluşturabilirsiniz:

• Java 21 gibi desteklenen bir LTS sürümü
• Spring Boot 3.x
• Maven
• Spring Web
• GraalVM Native Support

Basit bir endpoint ekleyelim:

package com.example.coldstart;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
@SpringBootApplication
public class ColdStartApplication {

    @GetMapping("/hello")
    String hello() {
        return "Hello from GraalVM Native Image";
    }

    public static void main(String[] args) {
        SpringApplication.run(ColdStartApplication.class, args);
    }
}

Adım 2: Maven plugin’lerini kontrol edin

Spring Boot parent’ın sağladığı native profilinden yararlanmak için build bölümünde şu plugin’ler bulunmalıdır:

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
        </plugin>

        <plugin>
            <groupId>org.graalvm.buildtools</groupId>
            <artifactId>native-maven-plugin</artifactId>
        </plugin>
    </plugins>
</build>

Spring AOT işlemi ApplicationContext’i build aşamasında analiz eder; bean tanımlarına ve kapalı dünya varsayımına uygun optimize edilmiş kod ile GraalVM hint dosyaları üretir. Maven çıktıları target/spring-aot altında incelenebilir. (Spring Boot AOT belgeleri)

Adım 3: Yerel native executable üretin

Makinede kullandığınız Java sürümüyle uyumlu bir GraalVM dağıtımı ve gerekli native toolchain kurulu olmalıdır. Ardından:

./mvnw -Pnative native:compile

Executable varsayılan olarak target dizininde oluşur:

./target/cold-start-demo

Servisi doğrulayın:

curl http://localhost:8080/hello

Gradle kullanan projelerde GraalVM Native Build Tools plugin’i uygulandıktan sonra eşdeğer komutlar şunlardır:

./gradlew nativeCompile
./build/native/nativeCompile/cold-start-demo

Adım 4: Buildpack ile native container image oluşturun

Yerel GraalVM kurulumu yerine Docker ve Cloud Native Buildpacks kullanabilirsiniz:

./mvnw -Pnative spring-boot:build-image

Oluşan image’ı çalıştırın:

docker run --rm -p 8080:8080 \
  docker.io/library/cold-start-demo:0.0.1-SNAPSHOT

Gradle karşılığı:

./gradlew bootBuildImage

Spring Boot, Maven ve Gradle üzerinden Paketo buildpack ile JVM içermeyen native container image üretilmesini destekler. (Spring Boot native uygulama rehberi)

Native Image doğrudan cross-compilation yapmadığından executable hedef işletim sistemi ve CPU mimarisi için üretilmelidir. Örneğin Linux AMD64 ile Linux ARM64 artefact’larını ayrı runner’larda veya uygun multi-platform build altyapısında oluşturmak gerekir.

Adım 5: Native test çalıştırın

Normal JVM testleri hızlı geri bildirim sağlar; ancak kapalı dünya varsayımından kaynaklanan sorunları yakalamak için native test de CI sürecine eklenmelidir:

./mvnw -Pnative native:test

Gradle için:

./gradlew nativeTest

Özellikle şu yolları test edin:

• JSON serialization ve deserialization
• Reflection kullanan kod
• AOP ve transaction proxy’leri
• Dosya, template ve resource bundle erişimi
• SSL ve güvenlik sağlayıcıları
• ORM entity’leri
• Dinamik olarak seçilen implementasyonlar

Adım 6: Eksik metadata’yı tracing agent ile bulun

Spring’in otomatik hint üretiminin yetmediği eski veya uyumsuz bir kütüphanede uygulamayı önce JVM üzerinde tracing agent ile çalıştırabilirsiniz:

java -Dspring.aot.enabled=true \
  -agentlib:native-image-agent=config-output-dir=target/native-agent \
  -jar target/cold-start-demo.jar

Uygulamanın kritik akışlarını çalıştırdıktan sonra oluşan metadata’yı inceleyin. Gerekli dosyalar kontrollü biçimde src/main/resources/META-INF/native-image/ altına taşınabilir.

Tracing agent yalnızca çalıştırılan yolları görür. Eksiksiz test kapsamı yoksa gerekli metadata’nın bir kısmı yine atlanabilir; üretilen dosyaları körlemesine kabul etmek yerine sadeleştirmek ve doğrulamak gerekir. GraalVM’in agent’ı reflection, proxy, JNI ve resource erişimlerini kaydedebilir. (GraalVM tracing agent rehberi)

Üretim ortamı için mimari öneriler

GraalVM Native Image özellikle şu iş yüklerinde güçlü bir seçenektir:

• Trafiği düzensiz serverless fonksiyonlar
• Scale-to-zero kullanan servisler
• Çok hızlı yatay ölçeklenmesi gereken API’ler
• Düşük bellek limitli container’lar
• CLI uygulamaları ve kısa ömürlü batch işler
• Edge veya yoğun çoklu servis ortamları

Buna karşılık aşağıdaki durumlarda geleneksel JVM seçeneğini ayrıca benchmark etmek gerekir:

• Günlerce çalışan CPU yoğun servisler
• Yoğun dinamik class loading veya plugin mimarisi
• Native desteği zayıf üçüncü taraf kütüphaneler
• Çok sık değişen runtime bean yapıları
• Derleme süresi ve CI kaynak maliyetinin kritik olduğu projeler

İyi bir cloud-native strateji bütün servisleri zorunlu olarak native’e çevirmek değildir. Cold start ve bellek baskısı yaşayan sınır servislerini native executable olarak çalıştırırken, uzun ömürlü ve throughput odaklı servisleri JVM üzerinde bırakmak daha dengeli olabilir.

Sonuç

GraalVM Native Image, Java’nın serverless ve mikroservis mimarilerindeki en görünür dezavantajlarından ikisini doğrudan hedefler: cold start gecikmesi ve yüksek memory footprint.

AOT derleme; erişilebilir kodu, gerekli runtime bileşenlerini ve belirli başlangıç durumlarını build aşamasında native executable içine taşır. Böylece uygulama hızlı açılır, warm-up ihtiyacı azalır ve daha küçük bir çalışma zamanı belleğiyle hizmet verebilir.

Bu kazanımın karşılığında closed-world assumption nedeniyle reflection, dynamic proxy, serialization ve classpath kaynaklarının daha bilinçli yönetilmesi gerekir. Spring Boot 3’ün AOT altyapısı bu işin büyük bölümünü otomatikleştirir; RuntimeHints, reachability metadata, tracing agent ve native testler ise kalan boşlukları kapatır.

Doğru karar için son adım her zaman aynıdır: JVM ve native sürümü gerçek trafik profiliniz, hedef container limitleriniz ve ölçeklenme modeliniz altında ölçün. Cold start kritikse GraalVM Native Image çoğu zaman yalnızca bir optimizasyon değil, doğrudan mimari bir avantajdır.

Sık Sorulan Sorular

GraalVM Native Image tamamen JVM’siz mi çalışır?

Üretilen executable’ın yanında ayrı bir HotSpot JVM bulunmaz. Ancak binary; garbage collector, thread desteği ve gerekli çalışma zamanı servisleri gibi Native Image runtime bileşenlerini içerir.

Native Image her Java uygulamasında daha hızlı mıdır?

Hayır. Başlangıç süresi genellikle çok daha iyidir; fakat uzun süre çalışan ve CPU yoğun uygulamalarda JIT daha yüksek tepe throughput sağlayabilir. Karar benchmark sonucuna göre verilmelidir.

Spring Boot 3 reflection sorunlarını otomatik çözer mi?

Spring AOT birçok yaygın kullanım için gerekli hint’leri otomatik üretir. Uygulamaya özel reflection, dinamik proxy veya üçüncü taraf kütüphane kullanımlarında ek runtime hint gerekebilir.

Native executable bir kez üretilip her platformda çalıştırılabilir mi?

Hayır. Binary hedef işletim sistemi ve CPU mimarisine özeldir. Linux, macOS, AMD64 ve ARM64 hedefleri için uygun ortamlarda ayrı build alınmalıdır.

GraalVM Native Image serverless maliyetini azaltır mı?

Daha hızlı startup ve düşük bellek tüketimi, platformun fiyatlandırma modeline bağlı olarak süre ve kaynak maliyetini azaltabilir. Kesin kazanç ancak gerçek provider, trafik ve bellek ayarlarıyla yapılan ölçüm sonucunda belirlenebilir.

GraalVM Native Image ile Serverless ve Mikroservislerde Cold Start Sorununu Çözmek yazısı ilk önce Ali Karahisar üzerinde ortaya çıktı.

Özellikle onlarca veya yüzlerce gigabaytlık heap kullanan sistemlerde ortalama GC süresine bakmak yeterli değildir. Kullanıcı deneyimini ve servis seviyesi hedeflerini çoğunlukla p99, p99.9 ve p99.99 gecikmeleri belirler. Bu nedenle doğru soru “Hangi GC daha hızlı?” değil, “Bu iş yükünün gecikme, throughput ve kaynak tüketimi hedefleri için hangi GC daha uygun?” olmalıdır.

G1 GC, dengeli throughput ve öngörülebilir duraklamalar sağlamayı amaçlayan genel kullanıma yönelik bir collector’dır. ZGC ise daha fazla işi uygulamayla eş zamanlı yürüterek çok büyük heap’lerde dahi ultra düşük duraklama sürelerini hedefler.

Oracle’ın güncel sınıflandırmasına göre G1 “mostly concurrent”, ZGC ise “fully concurrent” bir collector’dır. Oracle, yanıt süresinin en yüksek öncelik olduğu sistemlerde ZGC’yi başlangıç seçeneği olarak önermektedir. Bununla birlikte ZGC’nin düşük duraklama avantajı, iş yüküne bağlı CPU ve bellek maliyetleriyle birlikte değerlendirilmelidir. Oracle Java 25 GC seçim rehberi

Kısa cevap: G1 GC mi, ZGC mi?

Aşağıdaki yaklaşım pratik bir başlangıç noktasıdır:

• Dengeli throughput, makul bellek tüketimi ve yüzlerce milisaniyenin altında tutulmak istenen GC duraklamaları için G1 GC güçlü bir varsayılan seçimdir.
• Onlarca ya da yüzlerce gigabaytlık heap, yüksek canlı veri miktarı ve tek haneli milisaniyelik uçtan uca gecikme hedefleri varsa ZGC öncelikli adaydır.
• CPU kapasitesi sınırlıysa veya en önemli hedef maksimum işlem hacmiyse, ZGC’nin concurrent çalışma maliyeti mutlaka ölçülmelidir.
• GC değişikliği sentetik mikro benchmark sonucuyla değil, üretime benzeyen yük, veri dağılımı ve allocation profiliyle doğrulanmalıdır.

ZGC düşük gecikme için güçlü bir mimari avantaj sağlar; fakat gerçek zamanlı bir collector değildir ve uygulama için kesin bir SLA garantisi vermez. İşletim sistemi zamanlaması, safepoint işlemleri, JIT derlemesi, disk erişimi, sayfa hataları, kilit rekabeti ve dış servisler de tail latency üretebilir.

G1 GC nasıl çalışır?

Garbage-First Garbage Collector, heap’i eşit büyüklükte bölgelere ayırır. Bu bölgeler sabit biçimde Eden, Survivor veya Old olarak ayrılmış değildir; ihtiyaç oldukça farklı roller üstlenebilir.

G1; generational, bölge tabanlı, evacuating ve çoğunlukla eş zamanlı çalışan bir collector’dır. Global canlılık analizi gibi pahalı işlerin bir bölümünü uygulama thread’leri çalışırken gerçekleştirir. Buna karşılık canlı nesnelerin seçilmiş bölgelerden başka bölgelere kopyalanması ağırlıklı olarak Stop-The-World duraklamaları içinde yapılır.

Oracle’ın tanımına göre G1, belirlenen pause-time hedefine yüksek olasılıkla ulaşmaya çalışır; ancak bu hedef her GC duraklaması için kesin bir üst sınır değildir. Oracle G1 GC mimarisi

G1 GC döngüsü

G1’in çalışma modeli iki ana dönem halinde düşünülebilir.

1. Young-only dönemi

Yeni nesilde biriken nesneler young collection ile toplanır. Yaşamaya devam eden nesneler Survivor bölgelerine veya yaşlarına göre Old Generation’a taşınır.

Young collection sırasında uygulama thread’leri durdurulur. G1, bir sonraki young generation boyutunu geçmiş duraklama sürelerinden ve kopyalanan canlı nesne miktarından yararlanarak hesaplar.

2. Concurrent marking ve space-reclamation dönemi

Old Generation doluluğu Initiating Heap Occupancy eşiğine ulaştığında G1 concurrent marking döngüsünü başlatır:

1. Bir Concurrent Start young collection yapılır.
2. Old Generation içindeki erişilebilir nesneler uygulamayla eş zamanlı işaretlenir.
3. Remark duraklamasında işaretleme sonuçlandırılır.
4. Cleanup aşamasında bölgelerin canlılık oranları hesaplanır.
5. Mixed collection’larda young bölgelerle birlikte seçilmiş old bölgeler de boşaltılır.

“Garbage-First” adı, collector’ın önce en fazla çöp içeren ve en verimli biçimde geri kazanılabilecek bölgeleri seçmesinden gelir.

G1’in pause-time modeli

-XX:MaxGCPauseMillis bir zaman sınırı değil, ergonomik bir hedeftir. G1, collection set’e eklenecek bölgelerin sayısını ve young generation büyüklüğünü bu hedefe göre ayarlamaya çalışır.

Örneğin 100 milisaniyelik hedef vermek, hiçbir GC duraklamasının 100 milisaniyeyi geçmeyeceği anlamına gelmez. Çok yüksek canlı nesne oranı, ani allocation artışı, reference processing, remembered set taraması veya humongous object yoğunluğu hedefin aşılmasına neden olabilir.

Remembered set ve card table maliyeti

G1, bölgeler arasındaki referansları bulabilmek için card table ve remembered set yapılarından yararlanır. Uygulama bir referans alanını değiştirdiğinde write barrier ilgili kartı işaretler. Böylece young collection sırasında bütün Old Generation’ın taranması gerekmez.

Bu mekanizma toplama işini sınırlar; ancak uygulama thread’lerine barrier maliyeti, ek metadata tüketimi ve remembered set bakım yükü getirir. Nesne grafiğinde çok yoğun bölge geçişleri bulunan sistemlerde bu maliyet görünür hale gelebilir.

Evacuation ve Full GC riski

G1, canlı nesneleri seçilmiş bölgelerden boş alanlara taşıyarak belleği sıkıştırır. Taşıma için yeterli boş bölge kalmazsa evacuation failure oluşabilir.

Concurrent marking allocation hızına yetişemez ve yeterli alan geri kazanılamazsa G1, son çare olarak Stop-The-World Full GC gerçekleştirebilir. Büyük heap’lerde bu durum saniyelere ulaşabilen ciddi latency sıçramaları oluşturabilir.

Humongous object davranışı

Boyutu bir G1 bölgesinin yarısından büyük olan nesneler “humongous” olarak değerlendirilir ve ardışık bölgelerde tutulur. Büyük byte dizileri, sıkıştırılmış mesajlar, cache blokları ve büyük JSON payload’ları bu kategoriye girebilir.

Humongous allocation:

• Heap parçalanmasını artırabilir.
• Concurrent marking döngüsünü erken başlatabilir.
• Ardışık boş bölge ihtiyacı doğurabilir.
• Full GC ve hatta OutOfMemoryError riskini yükseltebilir.

GC loglarında humongous region sayısı yüksekse ilk çözüm JVM bayrağı eklemek değil, büyük allocation kaynaklarını uygulama seviyesinde incelemek olmalıdır.

ZGC nasıl çalışır?

ZGC, ölçeklenebilir ve düşük gecikme odaklı, concurrent bir collector’dır. Marking, reference processing ve nesne relocation gibi pahalı işlerin büyük bölümünü uygulama thread’leri çalışırken gerçekleştirir.

Oracle’ın güncel rehberine göre ZGC’nin duraklama süreleri kullanılan heap boyutundan bağımsızdır ve collector birkaç yüz megabayttan 16 TB’a kadar heap’lerde çalışabilir. JDK 25 dokümantasyonu maksimum duraklamaları bir milisaniyenin altında hedefleyen çalışma modelini açıklamaktadır. Oracle ZGC rehberi

Buradaki kritik ifade “heap boyutundan bağımsız” olmasıdır. Bu, heap büyüdükçe concurrent toplam iş miktarının hiç artmadığı anlamına gelmez. Artan canlı veri daha fazla CPU zamanı ve daha uzun concurrent cycle gerektirebilir. Mimari avantaj, pahalı işin Stop-The-World penceresine taşınmamasıdır.

Generational ZGC ve JDK sürümü

ZGC’nin nesilleri kullanan sürümü JDK 21 ile kullanıma sunuldu. Generational ZGC, çoğu nesnenin genç yaşta öldüğü gözleminden yararlanarak young ve old nesilleri farklı sıklıklarda toplar.

Sürüm davranışı önemlidir:

• JDK 21 ve 22’de generational mod -XX:+ZGenerational ile etkinleştirilir.
• JDK 23’te generational mod varsayılan hale gelmiştir.
• JDK 24 itibarıyla non-generational ZGC kaldırılmış ve ZGenerational seçeneğine ihtiyaç kalmamıştır.

Dolayısıyla internetten kopyalanan eski bir JVM başlangıç satırı yeni JDK’da geçersiz olabilir. Bayraklar hedef JDK dağıtımı ve sürümü üzerinde doğrulanmalıdır. Oracle JDK 21 değişiklikleri ve Oracle JDK 24 değişiklikleri

Colored pointers

ZGC’nin temel yapı taşlarından biri colored pointer yaklaşımıdır. Nesne referansları yalnızca bellek adresi taşımaz; marking ve relocation durumuyla ilgili metadata da içerir.

Bu bilgi sayesinde JVM bir referansın:

• Geçerli GC görünümüne ait olup olmadığını,
• İşaretleme işlemi gerektirip gerektirmediğini,
• Nesnenin taşınmış olup olmadığını,
• Referansın güncellenmesi gerekip gerekmediğini

kontrol edebilir.

Colored pointer yaklaşımı, ZGC’nin nesneleri uygulama thread’leri çalışırken taşıyabilmesinin önemli nedenlerinden biridir.

Load ve store barrier’lar

Uygulama bir nesne referansını okuduğunda veya güncellediğinde JIT tarafından üretilen barrier kodu devreye girebilir. Barrier, referansın GC açısından güvenli ve güncel olmasını sağlar.

Bir nesne concurrent relocation sırasında başka bir konuma taşınmışsa barrier doğru konumu bulabilir ve referansı düzeltebilir. Bu nedenle bütün uygulama thread’lerini durdurup heap genelindeki tüm referansları tek seferde güncellemek gerekmez.

Generational ZGC ayrıca young ve old nesiller arasındaki referansları verimli biçimde izlemek için optimize edilmiş barrier mekanizmaları kullanır. Bunun karşılığı, uygulamanın normal nesne erişim yollarında belirli bir CPU maliyetidir.

Concurrent marking

ZGC, erişilebilir nesneleri uygulama çalışırken işaretler. Kısa Stop-The-World evreleri temel olarak kök durumunu güvenli biçimde yakalamak ve bazı faz geçişlerini koordine etmek için kullanılır.

Duraklamalarda bütün canlı nesne kümesini dolaşmak yerine sınırlı ve heap boyutuna doğrudan bağlı olmayan işler yapılması, large heap sistemlerde ZGC’nin en önemli avantajıdır.

Concurrent relocation

ZGC, seçilen bölgelerdeki canlı nesneleri uygulama çalışırken taşıyabilir. Uygulama eski konumu gösteren bir referansla karşılaştığında barrier mekanizması erişimi doğru adrese yönlendirir.

Böylece:

• Heap concurrent biçimde sıkıştırılabilir.
• Uzun bir Stop-The-World compaction aşaması önlenebilir.
• Büyük canlı veri kümelerinde pause süresinin heap boyutuyla büyümesi engellenebilir.
• Ayrı ve uzun süren klasik Full GC ihtiyacı ortadan kaldırılabilir.

Large heap sistemlerde ZGC’nin mimari avantajları

1. Duraklama süresi heap boyutuyla ölçeklenmez

G1’de concurrent marking heap genelinde çalışsa da canlı nesnelerin tahliyesi ve collection set işleme gibi önemli işler Stop-The-World aşamalarında yapılır. Heap ve canlı veri büyüdükçe bu aşamaların kuyruk gecikmesine etkisi artabilir.

ZGC’de pahalı marking ve relocation işleri concurrent yürütüldüğü için 32 GB’tan 256 GB’a geçiş, GC pause süresini aynı oranda büyütmez. Büyük in-memory cache, risk hesaplama motoru, fiyatlama sistemi, oyun sunucusu veya gerçek zamanlı analitik platformlarında bu özellik belirleyicidir.

2. Concurrent compaction

Low-pause collector’ların yalnızca erişilemeyen nesneleri bulması yetmez; fragmentation sorununu da uzun duraklama üretmeden çözmesi gerekir. ZGC’nin concurrent relocation yaklaşımı bellek sıkıştırmayı uygulama çalışırken gerçekleştirebilir.

3. Daha düşük tail-latency riski

Ortalama yanıt süresi iyi olsa bile uzun bir Full GC p99.9 değerini bozabilir. ZGC’nin tasarımı bu tür büyük GC kaynaklı sıçramaları azaltmaya yöneliktir.

Bununla birlikte “GC pause düştü” sonucu, uçtan uca latency’nin otomatik olarak düştüğü anlamına gelmez. Concurrent GC thread’leri CPU üzerinde uygulamayla rekabet ederse servis süresi artabilir. Bu nedenle GC pause, CPU utilization ve request latency birlikte izlenmelidir.

4. Allocation spike’larına karşı heap headroom

ZGC concurrent çalıştığı için GC bir cycle’ı tamamlayana kadar uygulama yeni nesne ayırmaya devam eder. Maksimum heap; canlı veri kümesini, cycle boyunca yapılacak allocation’ları ve trafik sıçramalarını karşılayacak boşluğu içermelidir.

Örneğin canlı veri kümesi 40 GB olan bir servise yalnızca 42 GB heap vermek, teorik olarak yeterli görünse de yüksek allocation rate altında allocation stall yaratabilir. ZGC tuning’in en önemli parametresi çoğu zaman karmaşık bir bayrak değil, doğru -Xmx ve yeterli headroom’dur.

5. Adaptif generational yönetim

Modern ZGC, generational yapıda nesil boyutlarını, GC thread sayısını ve tenuring eşiklerini iş yüküne göre dinamik biçimde ayarlar. Bu nedenle başlangıç yaklaşımı az sayıda bayrak kullanmak ve yalnızca ölçüm sonucunda müdahale etmek olmalıdır.

G1 GC ve ZGC çalışma mekanizmalarının karşılaştırması

Prod ortamında GC seçim kriterleri

Temel JVM bayrakları ve tuning örnekleri

Aşağıdaki değerler doğrudan üretime kopyalanacak reçeteler değildir. Heap büyüklüğü, CPU sayısı, NUMA yapısı, container limitleri ve allocation profili test edilmeden kesinleştirilmemelidir.

G1 GC için güvenli başlangıç profili

java \
  -XX:+UseG1GC \
  -Xms32g \
  -Xmx32g \
  -XX:MaxGCPauseMillis=100 \
  -XX:+AlwaysPreTouch \
  -Xlog:gc*,safepoint:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=10,filesize=100M \
  -jar application.jar

Bayrakların amacı:

• -XX:+UseG1GC: G1 collector’ı etkinleştirir.
• -Xms32g -Xmx32g: Heap resizing ve çalışma anındaki sayfa tahsis sürprizlerini azaltır.
• -XX:MaxGCPauseMillis=100: G1’e 100 ms’lik ergonomik pause hedefi verir.
• -XX:+AlwaysPreTouch: Heap sayfalarını başlangıçta fiziksel belleğe dokundurur; açılışı uzatabilir fakat runtime latency varyansını azaltabilir.
• -Xlog:gc*,safepoint: GC ve safepoint davranışını analiz etmeyi sağlar.

G1 için young generation’ı -Xmn ile sabitlemek genellikle önerilmez. G1, pause hedefine ulaşmak için young generation boyutunu adaptif biçimde kullanır; sabit young generation bu kontrol mekanizmasını zayıflatabilir. Oracle’ın önerisi, önce yalnızca heap boyutu ve gerekiyorsa pause hedefiyle başlamaktır. Oracle G1 tuning rehberi

G1’de Full GC riski görülüyorsa

GC loglarında Pause Full (G1 Compaction Pause) veya evacuation failure görülmesi durumunda aşağıdaki seçenekler kontrollü olarak değerlendirilebilir:

-XX:G1ReservePercent=20
-XX:ConcGCThreads=8

G1ReservePercent, allocation ve evacuation için daha fazla güvenlik alanı bırakabilir. ConcGCThreads, marking’in allocation hızına yetişemediği doğrulandıysa artırılabilir. Her ikisi de maliyetsiz değildir: kullanılabilir heap alanını veya uygulamaya kalan CPU’yu azaltabilir.

Adaptive IHOP tahminleri iş yükündeki ani değişikliklere yetişemiyorsa, son çare olarak işaretlemenin daha erken başlatılması denenebilir:

-XX:-G1UseAdaptiveIHOP
-XX:InitiatingHeapOccupancyPercent=30

Bu ayar statik davranış üretir. Sezonsal veya burst karakterli iş yüklerinde adaptif mekanizmadan daha kötü sonuç verebileceği için uzun süreli karşılaştırmalı test gerektirir.

Çok sayıda yinelenen String için

Heap dump ve profiler, yüksek miktarda yinelenen String bulunduğunu gösteriyorsa:

-XX:+UseStringDeduplication

Bu seçenek bellek tüketimini azaltabilir; ancak concurrent deduplication işleminin CPU maliyeti vardır. Kanıt olmadan varsayılan tuning listesine eklenmemelidir.

JDK 24+ ZGC düşük gecikme profili

java \
  -XX:+UseZGC \
  -Xms64g \
  -Xmx64g \
  -XX:+AlwaysPreTouch \
  -Xlog:gc*,safepoint:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=10,filesize=100M \
  -jar application.jar

-Xms ile -Xmx değerlerinin eşitlenmesi:

• Heap’in çalışma sırasında büyüme ihtiyacını azaltır.
• ZGC’nin belleği işletim sistemine iade etmesini fiilen sınırlar.
• Commit/uncommit ve page fault kaynaklı latency varyansını azaltabilir.
• Başlangıç süresini ve kalıcı bellek tüketimini artırır.

Ultra düşük gecikme hedeflerinde bu değiş tokuş çoğu zaman anlamlıdır; bellek yoğunluğu öncelikli ortamlarda ise esnek heap daha uygun olabilir.

Esnek bellek kullanan ZGC profili

java \
  -XX:+UseZGC \
  -Xms16g \
  -Xmx64g \
  -XX:SoftMaxHeapSize=48g \
  -XX:ZUncommitDelay=300 \
  -Xlog:gc*,safepoint:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=10,filesize=100M \
  -jar application.jar

SoftMaxHeapSize, ZGC’nin normal koşullarda altında kalmaya çalışacağı yumuşak sınırdır. Collector, allocation stall riskini azaltmak için gerekirse -Xmx değerine kadar büyüyebilir.

Örnekte ZGC 48 GB altında kalmaya çalışır; ancak trafik sıçramasında 64 GB’a kadar çıkabilir. Bu, bellek maliyetiyle burst dayanıklılığı arasında kullanışlı bir denge sağlar.

JDK 21 ve 22’de Generational ZGC

java \
  -XX:+UseZGC \
  -XX:+ZGenerational \
  -Xms64g \
  -Xmx64g \
  -XX:+AlwaysPreTouch \
  -jar application.jar

Bu örnekteki -XX:+ZGenerational yalnızca ilgili eski sürüm davranışı için kullanılmalıdır. JDK 24 ve sonrasında bu seçenek kaldırılmıştır.

ZGC’de thread sayısını değiştirmek

ZGC, GC thread sayısını adaptif olarak ayarlayabilir. Bu nedenle -XX:ConcGCThreads başlangıç profilinde sabitlenmemelidir.

GC allocation hızına yetişemiyor, allocation stall oluşuyor ve sistemde boş CPU bulunuyorsa kontrollü bir deney yapılabilir:

-XX:ConcGCThreads=12

Değer çok düşükse collector geride kalabilir. Çok yüksekse GC, uygulama thread’lerinin CPU’sunu tüketerek request latency ve throughput’u bozabilir.

Explicit large pages

Büyük ve sabit heap’lerde, işletim sistemi önceden doğru biçimde hazırlanmışsa:

-XX:+UseLargePages

Large pages, TLB baskısını azaltarak throughput ve latency’ye yardımcı olabilir. Ancak host üzerinde yeterli sayıda sayfa ayrılmadan yalnızca JVM bayrağını eklemek yeterli değildir.

Transparent Huge Pages ile explicit large pages aynı şey değildir. Oracle, latency-sensitive ZGC sistemlerinde Transparent Huge Pages kullanımının istenmeyen latency sıçramaları oluşturabileceğini belirtmektedir. Bu nedenle kernel ayarı, JVM konfigürasyonu ve gerçek workload birlikte test edilmelidir. Oracle ZGC large pages açıklaması

GC loglarında hangi sinyaller izlenmeli?

Collector seçiminden bağımsız olarak aşağıdaki metrikler birlikte değerlendirilmelidir:

• GC pause p50, p95, p99 ve maksimum değerleri
• Young, mixed, old ve full collection sayısı
• GC cycle süresi ve cycle sıklığı
• Allocation rate
• Promotion rate
• Collection sonrası heap occupancy
• Canlı veri kümesi büyüklüğü
• Allocation stall sayısı ve süresi
• Application throughput
• CPU kullanımı ve CPU throttling
• Container memory limiti ile toplam RSS farkı
• Safepoint süresi ve safepoint’e ulaşma gecikmesi
• Reference processing süresi
• G1 humongous region ve evacuation failure sayısı

Yalnızca “GC toplam süresi” metriğini izlemek yanıltıcıdır. ZGC’de kısa duraklamalara rağmen concurrent GC CPU maliyeti artabilir. G1’de toplam GC süresi makul görünürken tek bir Full GC tail-latency SLO’sunu ihlal edebilir.

Üretime geçiş için önerilen test yöntemi

GC değişimi kontrollü bir performans mühendisliği çalışması olarak ele alınmalıdır:

1. Mevcut collector ile temel ölçüm alın.
2. Aynı JDK dağıtımı, heap ve CPU limitleriyle ikinci collector’ı test edin.
3. Gerçekçi canlı veri kümesini test başlamadan önce oluşturun.
4. JVM ısınması ve JIT derlemesi tamamlandıktan sonra ölçüm alın.
5. Ortalama yükün yanı sıra trafik sıçraması ve uzun süreli soak test uygulayın.
6. p99.9 latency, throughput, CPU ve RSS değerlerini birlikte karşılaştırın.
7. Heap dump, JFR ve GC loglarını allocation kaynakları açısından inceleyin.
8. Canary deployment ile sınırlı üretim trafiğinde doğrulayın.
9. Otomatik rollback eşiğini GC pause yerine uçtan uca servis SLO’suna bağlayın.

Konteyner ortamında yalnızca -Xmx değerini pod bellek limitine eşitlemeyin. Metaspace, code cache, thread stack’leri, direct buffer’lar, JNI kütüphaneleri ve JVM’nin native yapıları da RSS tüketir. Heap dışında yeterli güvenlik payı bırakılmalıdır.

Hangi senaryoda hangi GC seçilmeli?

G1 GC tercih edin:

• Gecikme hedefi yüzlerce milisaniye ölçeğindeyse,
• Throughput, ultra düşük pause süresinden daha önemliyse,
• CPU limiti sıkıysa,
• Heap orta veya büyük olsa da canlı veri kümesi yönetilebiliyorsa,
• Operasyon ekibi yerleşik ve yaygın bir collector istiyorsa,
• Gerçek workload altında G1 Full GC veya evacuation problemi üretmiyorsa.

ZGC tercih edin:

• p99.9 ve üzeri tail-latency kritikse,
• Tek haneli milisaniyelik servis hedefleri bulunuyorsa,
• Heap onlarca veya yüzlerce gigabaytsa,
• Canlı veri kümesi büyükse,
• Uzun G1 evacuation ya da Full GC duraklamaları görülüyorsa,
• Concurrent GC için CPU kapasitesi ayrılabiliyorsa,
• Heap’e yeterli allocation headroom verilebiliyorsa.

Sonuç

G1 GC ve ZGC arasında evrensel bir kazanan yoktur. G1 GC, yüksek throughput ile nispeten kısa ve tahmin edilebilir duraklamalar arasında güçlü bir denge sağlar. Bu nedenle çoğu kurumsal Java servisi için hâlâ iyi bir başlangıç noktasıdır.

ZGC’nin ayrıştığı alan, büyük heap ve katı tail-latency hedefleridir. Colored pointers, barrier mekanizmaları, concurrent marking ve concurrent relocation sayesinde pahalı GC işlemlerinin büyük bölümünü uygulamayı durdurmadan gerçekleştirir. Böylece heap büyüklüğünün Stop-The-World süresine etkisini önemli ölçüde azaltır.

Bunun karşılığında ZGC’ye yeterli CPU ve heap headroom sağlanmalıdır. Collector seçimi yalnızca maksimum GC pause karşılaştırmasına indirgenmemeli; throughput, p99.9 yanıt süresi, allocation rate, CPU tüketimi, RSS ve altyapı maliyeti birlikte değerlendirilmelidir.

Kurumsal üretim ortamı için en güvenilir yaklaşım şudur: Önce sade bir JVM konfigürasyonu kurun, ölçüm alın, üretime benzeyen yük altında G1 ve ZGC’yi karşılaştırın ve yalnızca gözlemlenmiş bir problemi çözen bayrağı ekleyin.

Garbage Collector Seçimi ve Akort Edilmesi: G1 GC vs. ZGC yazısı ilk önce Ali Karahisar üzerinde ortaya çıktı.

Java 21 ile kalıcı hâle gelen Virtual Threads, bu denklemi değiştiriyor. Amaç, bloklayan kodu ortadan kaldırmak değil; bloklayan bir işin bekleme süresince pahalı bir işletim sistemi thread’ini işgal etmesini önlemek.

Bu nedenle Virtual Threads’i yalnızca “daha hafif thread” şeklinde tanımlamak eksik kalır. Asıl mimari değişiklik şudur:

Uygulamanın eşzamanlılık birimi yeniden Thread ile temsil edilebilir; fakat her Java thread’i için ayrı bir işletim sistemi thread’i ayırmak gerekmez.

Platform Thread ve Virtual Thread arasındaki fark

Geleneksel Java thread’leri, yani platform thread’leri, işletim sistemi thread’leri üzerine kuruludur. Basitleştirilmiş olarak ilişki 1:1’dir:

Java Platform Thread ─── OS Thread

Bir platform thread ağdan veri, veritabanından yanıt veya dosya sisteminden sonuç beklerken işletim sistemi thread’i de ona bağlı kalır. Thread pool kullanmak thread oluşturma maliyetini azaltır; fakat aynı anda çalışabilecek iş sayısını havuz büyüklüğüyle sınırlar.

Virtual Thread mimarisinde ise ilişki M biçimindedir:

Çok sayıda Virtual Thread
            │
            ▼
Az sayıda Carrier Platform Thread
            │
            ▼
       OS Thread’leri

Virtual thread çalışacağı zaman JVM tarafından bir platform thread’e, yani carrier thread’e bağlanır. Desteklenen bir bloklayan I/O çağrısına geldiğinde virtual thread askıya alınabilir ve carrier serbest bırakılabilir. Aynı carrier bu sırada başka bir virtual thread’i çalıştırır.

I/O tamamlandığında virtual thread yeniden çalıştırılabilir; üstelik daha önce kullandığı carrier’a dönmek zorunda değildir. Uygulama açısından ise bu geçiş görünmezdir:

var response = httpClient.send(request, BodyHandlers.ofString());

Kod hâlâ senkron görünür. Metot sonucu bekler, normal try/catch kullanılabilir ve stack trace istek akışını korur. Fakat bekleyen virtual thread uygun durumda carrier’ı işgal etmez.

Platform ve virtual thread’leri şöyle karşılaştırabiliriz:

Virtual Threads Java 21’de JEP 444 ile kalıcı özellik hâline gelmiştir. OpenJDK’nın temel hedefi de thread-per-request biçimindeki sunucu uygulamalarının daha verimli ölçeklenmesini sağlamaktır. JEP 444: Virtual Threads

Thread-Per-Request modeline neden geri dönüyoruz?

Thread-per-request yaklaşımında her istek başından sonuna kadar tek bir mantıksal thread üzerinde ilerler:

HTTP isteği
   → kimlik doğrulama
   → veritabanı sorgusu
   → uzak servis çağrısı
   → yanıt üretimi

Bu modelin güçlü tarafı yapısal sadeliğidir:

• Kontrol akışı yukarıdan aşağı okunur.
• Yerel değişkenler istek durumunu doğal biçimde taşır.
• Hatalar try/catch/finally ile yönetilir.
• Transaction ve güvenlik sınırları daha kolay görülür.
• Debugger ile adım adım ilerlenebilir.
• Stack trace, iş çağrı zincirini doğrudan gösterir.

Sorun modelin kendisi değil, modelin platform thread’leriyle uygulanmasıydı.

Little Yasası’na göre sistemde aynı anda bulunan ortalama iş sayısı yaklaşık olarak throughput ile ortalama gecikmenin çarpımıdır:

Concurrency ≈ Throughput × Latency

Örneğin ortalama 200 ms süren bir işlemde saniyede 5.000 istek karşılamak istiyorsak sistemin yaklaşık 1.000 isteği eşzamanlı taşıması gerekir. Her istek bir platform thread tüketiyorsa thread sayısı kısa sürede temel darboğaza dönüşebilir.

Reactive ve callback tabanlı sistemler bu problemi, bekleme sırasında thread’i serbest bırakarak çözdü. Bunun karşılığında uygulamanın mantıksal çağrı zinciri callback, Mono, Flux veya CompletableFuture aşamalarına bölündü.

Virtual Threads aynı kaynak sorununa farklı bir katmanda çözüm getirir:

• Reactive yaklaşım, thread paylaşımını uygulama programlama modeline taşır.
• Virtual Threads ise thread paylaşımını JVM zamanlayıcısının sorumluluğuna bırakır.

Böylece “bir istek, bir thread” modeli yeniden ekonomik hâle gelir. Buradaki thread artık pahalı bir OS kaynağı değil, uygulamadaki bir görevi temsil eden hafif bir Java nesnesidir.

Önemli bir sonuç da şudur: Virtual Threads tek bir isteği kendiliğinden hızlandırmaz. Esas fayda, çok sayıda bekleyen işi daha az platform thread ile taşıyarak toplam throughput’u artırmaktır. I/O gecikmesi yine aynı gecikmedir.

Reactive programming artık gereksiz mi?

Kısa cevap: Hayır. Fakat reactive programlamanın seçim gerekçesi değişmiştir.

Reactive stack’lerin yaygınlaşmasındaki önemli nedenlerden biri, çok sayıda bloklayan isteği sınırlı platform thread havuzuyla taşımanın zor olmasıydı. Virtual Threads bu teknik zorunluluğu önemli ölçüde azaltır.

Tipik bir servis aşağıdaki özelliklere sahipse Spring MVC ve Virtual Threads güçlü bir seçenek olabilir:

• Request/response ağırlıklı çalışma
• JDBC gibi bloklayan istemciler
• Senkron HTTP çağrıları
• Kısa veya orta uzunlukta iş akışları
• Ekibin imperative Java konusunda daha deneyimli olması
• Kolay debugging ve okunabilir stack trace beklentisi

Spring Boot 3.2’den itibaren Java 21 üzerinde virtual thread desteği şu ayarla etkinleştirilebilir:

spring.threads.virtual.enabled=true

Spring ekibi de Spring MVC ile Virtual Threads kombinasyonunu geleneksel web uygulamaları için yalın bir seçenek olarak konumlandırmaktadır. Kaynak: Spring: Runtime Efficiency with Spring

Bununla birlikte WebFlux ve Reactive Streams hâlâ belirgin avantajlara sahiptir:

• Sonsuz veya uzun süreli veri akışları
• Backpressure’ın uçtan uca ifade edilmesi
• Server-Sent Events ve streaming response’lar
• Çok aşamalı event pipeline’ları
• Deklaratif dönüşüm ve birleştirme operasyonları
• Reactive sürücüler üzerine kurulmuş mevcut sistemler
• Akışın talep, iptal ve hata sinyallerinin bir protokol olarak modellenmesi

Virtual Threads bir zamanlama mekanizmasıdır; backpressure protokolü değildir. Tüketici üreticiden yavaşsa virtual thread kullanmak tek başına kuyruk büyümesini veya bellek baskısını önlemez.

Dolayısıyla doğru soru “WebFlux mü, Virtual Threads mü?” değildir. Daha doğru karar çerçevesi şöyledir:

• Yüksek sayıda bağımsız, bloklayan request/response işi için imperative kod ve Virtual Threads genellikle daha basittir.
• Akış semantiği, backpressure veya yoğun reaktif kompozisyon gerekiyorsa WebFlux değerini korur.
• Mevcut reactive sistem yalnızca virtual thread geldi diye yeniden yazılmamalıdır.
• Yeni bir CRUD servisi de sırf yüksek eşzamanlılık ihtimali var diye otomatik olarak reactive tasarlanmamalıdır.

I/O yoğunluklu bir örnek

Aşağıdaki servis, çok sayıda sipariş için iki uzak sistemden bloklayan HTTP çağrıları yapıyor. Her sipariş ayrı bir virtual thread üzerinde işleniyor.

import java.io.IOException;
import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
import java.time.Duration;
import java.util.List;
import java.util.concurrent.Callable;
import java.util.concurrent.Executors;
import java.util.concurrent.Semaphore;

public final class OrderAggregator {

    private static final HttpClient HTTP_CLIENT = HttpClient.newBuilder()
            .connectTimeout(Duration.ofSeconds(2))
            .build();

    /*
     * Virtual thread sayısını değil, kapasitesi sınırlı olan uzak servise
     * yapılan eşzamanlı çağrı sayısını sınırlandırıyoruz.
     */
    private static final Semaphore REMOTE_SERVICE_LIMIT =
            new Semaphore(100);

    public static void main(String[] args) throws Exception {
        List<Long> orderIds = java.util.stream.LongStream
                .rangeClosed(1, 1_000)
                .boxed()
                .toList();

        try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
            List<Callable<OrderView>> tasks = orderIds.stream()
                    .<Callable<OrderView>>map(orderId ->
                            () -> loadOrderView(orderId))
                    .toList();

            var futures = executor.invokeAll(tasks);

            for (var future : futures) {
                OrderView view = future.get();
                System.out.println(view);
            }
        }
    }

    private static OrderView loadOrderView(long orderId)
            throws IOException, InterruptedException {

        String orderJson = get(
                "https://orders.example.com/orders/" + orderId);

        String shipmentJson = get(
                "https://shipping.example.com/shipments/" + orderId);

        return new OrderView(orderId, orderJson, shipmentJson);
    }

    private static String get(String url)
            throws IOException, InterruptedException {

        REMOTE_SERVICE_LIMIT.acquire();
        try {
            HttpRequest request = HttpRequest.newBuilder(URI.create(url))
                    .timeout(Duration.ofSeconds(3))
                    .GET()
                    .build();

            return HTTP_CLIENT.send(
                    request,
                    HttpResponse.BodyHandlers.ofString()
            ).body();
        } finally {
            REMOTE_SERVICE_LIMIT.release();
        }
    }

    record OrderView(
            long orderId,
            String orderJson,
            String shipmentJson
    ) {}
}

Kodun önemli tarafı, çağrıların bloklayan HttpClient.send() kullanmasına rağmen her görev için ayrı bir virtual thread oluşturulabilmesidir. I/O bekleyen görevler uygun olduğunda carrier thread’i serbest bırakır.

Burada executor bir virtual thread havuzu değildir. newVirtualThreadPerTaskExecutor() her görev için yeni bir virtual thread oluşturur. Virtual thread’ler ucuz olduğundan yeniden kullanılmaları veya sabit boyutlu bir havuzda tutulmaları amaçlanmaz.

Buna karşılık uzak servis bağlantıları sınırsız değildir. Bu nedenle Semaphore, iş parçacığı sayısını değil kıt kaynağa erişimi sınırlar. OpenJDK da virtual thread’lerin havuzlanmamasını ve sınırlı kaynakların semaphore gibi mekanizmalarla korunmasını önerir. Oracle Virtual Threads Adoption Guide

Üretim kodunda ayrıca timeout, retry bütçesi, circuit breaker, rate limit ve iptal davranışı açık biçimde tasarlanmalıdır. Bir milyon virtual thread oluşturabilmek, veritabanının bir milyon bağlantıyı veya uzak servisin bir milyon eşzamanlı isteği kaldırabileceği anlamına gelmez.

Kaçınılması gereken antipattern’ler

1. Virtual thread’leri sabit boyutlu havuzda toplamak

Yanlış yaklaşım:

var executor = Executors.newFixedThreadPool(
        100,
        Thread.ofVirtual().factory()
);

Bu tasarım virtual thread’in temel avantajını yapay olarak sınırlar. Bir göreve bir virtual thread oluşturulmalıdır:

var executor = Executors.newVirtualThreadPerTaskExecutor();

Eşzamanlılık sınırı gerekiyorsa thread sayısı yerine veritabanı, haricî API veya başka bir kıt kaynak doğrudan sınırlandırılmalıdır.

2. Uzun süren CPU işlerini sınırsız virtual thread’e dağıtmak

Virtual Threads CPU kapasitesini artırmaz. Binlerce CPU-bound görevi virtual thread üzerinde başlatmak çekirdek sayısını değiştirmez; yalnızca zamanlama baskısı ve kuyruk oluşturur.

CPU-bound işlerde çekirdek sayısına göre boyutlandırılmış executor, ForkJoinPool veya uygun paralel algoritma çoğu zaman daha doğrudur.

I/O-bound görev  → Virtual Threads için güçlü aday
CPU-bound görev  → Sınırlı paralellik gerekir

3. JDK 21–23 üzerinde bloklayan I/O’yu synchronized içinde yapmak

Java 21–23’te virtual thread, synchronized bir bölüm içinde bloklandığında carrier thread’e pinlenebilir:

synchronized (lock) {
    callSlowRemoteService();
}

Bu durum programı hatalı yapmaz; fakat uzun ve sık gerçekleşiyorsa ölçeklenebilirliği düşürür. Bu JDK sürümlerinde gerekli noktalarda ReentrantLock kullanılabilir veya I/O kritik bölümün dışına taşınabilir:

lock.lock();
try {
    updateSharedInMemoryState();
} finally {
    lock.unlock();
}

callSlowRemoteService();

Ancak bu tavsiye sürüme bağlıdır. JDK 24’te gelen JEP 491 ile synchronized altında bekleyen virtual thread’lerin carrier’ı serbest bırakabilmesi sağlandı. Dolayısıyla JDK 24+ üzerinde sırf virtual thread kullanılıyor diye bütün synchronized bloklarını mekanik olarak ReentrantLock ile değiştirmek doğru değildir. Oracle JDK 24 değişiklikleri

Yine de sürümden bağımsız tasarım ilkesi geçerlidir: Ağ veya veritabanı çağrısı boyunca lock tutmak contention, uzun kuyruklar ve deadlock riski yaratabilir. Ayrıca native veya foreign-function çağrıları güncel JDK’larda hâlâ pinning oluşturabilir.

4. ThreadLocal içinde pahalı nesne cache’lemek

Virtual thread’ler ThreadLocal destekler. Sorun API’nin çalışmaması değil, thread sayısının artık çok büyük olabilmesidir:

private static final ThreadLocal<ExpensiveParser> PARSER =
        ThreadLocal.withInitial(ExpensiveParser::new);

On binlerce veya yüz binlerce virtual thread, aynı sayıda pahalı nesne örneği oluşturabilir. Platform thread havuzunda makul görünen “thread başına cache” yaklaşımı virtual thread mimarisinde ciddi bellek tüketimine dönüşebilir.

Daha güvenli seçenekler şunlardır:

• Immutable ve thread-safe nesneleri paylaşmak
• Gerçekten sınırlı kaynaklar için açık bir pool kullanmak
• Request context’i mümkünse metot parametreleriyle taşımak
• Kullanılan JDK sürümünün durumuna göre ScopedValue değerlendirmek
• Framework’lerin context propagation davranışını test etmek

Correlation ID veya güvenlik bağlamı gibi küçük request-scoped veriler ThreadLocal ile çalışabilir. Ancak bellek maliyeti, yaşam süresi, temizleme davranışı ve InheritableThreadLocal ile istemsiz veri aktarımı özellikle incelenmelidir.

5. Sınırsız dış kaynak tüketimini ölçeklenebilirlik sanmak

Virtual thread sayısı arttığında darboğaz ortadan kalkmaz; başka bir katmana taşınır:

• JDBC connection pool
• HTTP connection pool
• Uzak servis kapasitesi
• Rate limit
• Heap
• Dosya tanıtıcıları
• CPU
• Kuyruklar

Bu nedenle virtual thread geçişi mutlaka bulkhead, timeout ve yük testi stratejisiyle birlikte ele alınmalıdır.

6. Yalnızca ortalama latency’ye bakmak

Virtual Threads’e geçiş değerlendirilirken şu metrikler birlikte izlenmelidir:

• Throughput
• p95 ve p99 latency
• Carrier thread kullanımı
• CPU ve heap tüketimi
• GC davranışı
• Bağlantı havuzu bekleme süreleri
• Uzak servis hata oranları
• Virtual thread pinning olayları
• Kuyruk uzunlukları

Java Flight Recorder, özellikle pinning ve virtual thread yaşam döngüsüyle ilgili olayları gözlemlemek için kullanılabilir. Java 21 dokümantasyonu jdk.VirtualThreadPinned olayını ve jdk.tracePinnedThreads seçeneğini açıklar. JDK 24+ değerlendirmelerinde ise monitor pinning davranışının değiştiği unutulmamalıdır.

Mimari karar özeti

Virtual Threads, reactive programlamanın yerini alan evrensel bir teknoloji değildir. Daha çok, reactive programlamanın zorunlu hâle gelmesine neden olan thread kıtlığını JVM seviyesinde azaltır.

İyi bir başlangıç matrisi şöyledir:

Sonuç

Project Loom’un en önemli katkısı “milyonlarca thread oluşturabilmek” değildir. Daha temel katkısı, Java’daki mantıksal görev ile işletim sistemi thread’i arasındaki zorunlu 1:1 ilişkiyi kaldırmasıdır.

Bu değişiklik sayesinde:

• Thread-per-request modeli yeniden ölçeklenebilir hâle gelir.
• Bloklayan ve okunabilir Java kodu yüksek I/O eşzamanlılığı taşıyabilir.
• Stack trace, debugging ve hata yönetimi doğal yapısını korur.
• Reactive programlama teknik bir zorunluluk olmaktan çıkarak bilinçli bir mimari seçeneğe dönüşür.

Fakat fiziksel kaynak sınırları ortadan kalkmaz. Virtual thread’ler sınırsız veritabanı bağlantısı, sınırsız CPU veya sınırsız uzak servis kapasitesi sağlamaz. Başarılı bir geçiş; thread sayısını büyütmekten çok, darboğazları doğru yerde sınırlandırmayı, kullanılan kütüphaneleri doğrulamayı ve sistemi gerçek yük altında ölçmeyi gerektirir.

Doğru zihinsel model şudur:

Virtual Threads, bloklamayı ucuzlatır; kaynakları sınırsızlaştırmaz.

Java Virtual Threads: Daha Fazla Thread Değil, Daha Doğru Bir Eşzamanlılık Modeli yazısı ilk önce Ali Karahisar üzerinde ortaya çıktı.