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ı.