Ana Sayfa/Java & Kurumsal Mimari
Java & Kurumsal Mimari·22 Ekim 2026·7 dk okuma

JDK 28’de Resmileşen JEP 543 (Structured Concurrency), JEP 546 Otonom ZGC Yığın Ölçekleme ve Spring AI Yerel Model Mimarisi

Inside.java’da JDK 28 için resmileşen JEP 543 (StructuredTaskScope ve Joiner<T, R, R_X>), manuel -Xmx ayarını ortadan kaldıran JEP 546 Adaptive ZGC, Spring Office Hours S5E26 yerel AI orkestrasyonu ve Mise ile geliştirici ortamı yönetiminin teknik analizi.

JDK 28’de Resmileşen JEP 543 (Structured Concurrency), JEP 546 Otonom ZGC Yığın Ölçekleme ve Spring AI Yerel Model Mimarisi

Project Loom ve ZGC’de Tam Olgunluk: Java ve Spring Ekosisteminde 22 Ekim Gündemi

Java Sanal Makinesi (JVM) ve Spring ekosistemi, Inside.java ve Spring.io resmi bültenlerinde yayınlanan 21–22 Ekim 2026 tarihli güncellemelerle kurumsal backend mimarisinin iki temel darboğazını kalıcı olarak çözüme kavuşturmaktadır: İlk olarak JDK 28 için resmileşen JEP 543 (Structured Concurrency), sekiz önizleme sürümünün ardından sanal iş parçacığı (virtual thread) koordinasyonunu --enable-preview bayrağı olmaksızın standartlaştırmaktadır. İkinci olarak JEP 546 (Adaptive Heap Sizing for ZGC) ve JEP 545, konteyner ortamlarında manuel -Xmx / -Xms bellek tahmini zorunluluğunu ortadan kaldırmaktadır. Uygulama katmanında ise Spring Office Hours S5E26 ve This Week in Spring seçkisi; 24 GB VRAM’li yerel iş istasyonlarında çalışan açık ağırlıklı modellerin (Muse Spark/Glimmer, DeepSeek V4.1 Flash) Spring AI ile orkestrasyonunu, JEP 540 Native JSON demolarını ve Mise ile deterministik geliştirici ortamı kurulumunu gündeme taşımaktadır.


1. JEP 543 JDK 28’de Resmileşti: StructuredTaskScope.open() ve Joiner<T, R, R_X> Mimarisi

Geleneksel ExecutorService ve Future<T> tabanlı eşzamanlılık modelinde, bir HTTP isteğini karşılamak için başlatılan üç paralel alt görevden biri hata fırlattığında diğer iki iş parçacığı arka planda çalışmaya devam ederek iş parçacığı sızıntısına (thread leak) ve gereksiz veritabanı/ağ tüketimine yol açar.

Inside.java üzerinde 21 Ekim 2026’da duyurulan JEP 543, JDK 19’daki kuluçka (JEP 428) ve JDK 21–27 arasındaki önizleme turlarını (JEP 453, 462, 480, 499, 505, 525, 533) tamamlayarak Yapılandırılmış Eşzamanlılığı (Structured Concurrency) JDK 28’de kalıcı standart haline getirmiştir. Temel tasarım ilkesi açıktır: Bir kod bloğu içinde çatallanan (forked) tüm eşzamanlı alt görevler, o sözdizimsel bloktan (try-with-resources) çıkılmadan önce tamamlanmak veya iptal edilmek zorundadır.

Nihai API Tasarımı: Joiner<T, R, R_X> ve Açık İstisna Tiplendirmesi

Son önizleme turlarında olgunlaşan ve JEP 543 ile mühürlenen API, alt sınıf türetme (subclassing) yerine bileşim (composition) desenini ve üç tip parametreli Joiner<T, R, R_X> arayüzünü kullanır:

  • T: Alt görevlerin (Subtask<T>) ürettiği sonuç tipi.
  • R: scope.join() çağrısının döndürdüğü birleşik sonuç tipi.
  • R_X: Tamamlanma politikasının fırlatabileceği açık istisna tipi (Explicit Exception Typing).
java
import java.time.Duration;
import java.util.concurrent.StructuredTaskScope;
import java.util.concurrent.StructuredTaskScope.Joiner;
import java.util.concurrent.StructuredTaskScope.Subtask;

public final class OrderAggregationService {

    public record CustomerProfile(String id, String tier) {}
    public record FraudScore(int riskIndex, boolean approved) {}
    public record AggregatedOrderContext(CustomerProfile profile, FraudScore fraud) {}

    public AggregatedOrderContext evaluateOrderParallel(String customerId, String txId)
            throws InterruptedException {

        // JEP 543 (JDK 28): --enable-preview gerektirmeyen nihai StructuredTaskScope.open() API'si
        try (var scope = StructuredTaskScope.open(
                Joiner.<Object>allSuccessfulOrThrow(),
                cfg -> cfg.withName("order-eval-scope")
                          .withTimeout(Duration.ofMillis(800)))) {

            Subtask<CustomerProfile> profileTask = scope.fork(() -> fetchCustomerProfile(customerId));
            Subtask<FraudScore> fraudTask = scope.fork(() -> evaluateFraudRisk(txId));

            // Herhangi biri hata fırlatırsa diğer sanal iş parçacığı anında iptal edilir (Short-Circuit)
            scope.join();

            return new AggregatedOrderContext(profileTask.get(), fraudTask.get());
        }
    }

    private CustomerProfile fetchCustomerProfile(String id) {
        return new CustomerProfile(id, "ENTERPRISE_GOLD");
    }

    private FraudScore evaluateFraudRisk(String txId) {
        return new FraudScore(12, true);
    }
}

Ayrıca StructuredTaskScope, Kapsamlı Değerler (ScopedValue — JEP 506) ile doğal entegrasyona sahiptir: Üst iş parçacığında bağlanan bir güvenlik bağlamı veya traceId, scope.fork(...) ile başlatılan tüm çocuk sanal iş parçacıklarına sıfır kopyalama maliyetiyle otomatik olarak miras kalır. jcmd <pid> Thread.dump_to_file -format=json komutu çalıştırıldığında ise iş parçacıkları düz bir liste yerine ebeveyn-çocuk ağaç hiyerarşisiyle görüntülenir.


2. JEP 546 ve JEP 545: ZGC’de Otonom Yığın Ölçekleme (Adaptive Heap Sizing) ve Hızlı Başlangıç

Bulut-yerel (cloud-native) Java mikroservislerinde en maliyetli operasyonel sorunlardan biri statik -Xmx tanımlamasıdır: Yığın çok küçük verilirse ani trafik artışlarında OutOfMemoryError yaşanır; çok büyük verilirse düşük trafik saatlerinde kullanılmayan RAM konteyner tarafından kilitlenir.

JDK 28’e hedeflenen JEP 546 (Adaptive Heap Sizing for ZGC) ve JEP 545 (Faster Startup and Warmup with ZGC), ZGC’nin bellek yönetimini tamamen otonom hale getirir:

  1. 2 MB Başlangıç Yığını ile Soğuk Başlatma (JEP 545): ZGC, başlangıçta yüzlerce megabaytlık fiziksel bellek sayfası sıfırlamak (page zeroing) yerine yalnızca 2 MB başlangıç yığınıyla uyanır ve ön ısıtılmış bellek önbelleğini kullanarak milisaniyeler içinde ilk isteği karşılar.
  2. Dinamik Genişleme ve Geri İade (JEP 546): ZGC çalışma zamanında nesne tahsis hızını (allocation rate), GC’nin harcadığı CPU yüzdesini ve işletim sistemindeki boş fiziksel RAM miktarını sürekli ölçer. İş yükü arttığında yığını otomatik büyütür, yük azaldığında veya aynı makinedeki komşu süreçler belleğe ihtiyaç duyduğunda kullanılmayan sayfaları işletim sistemine geri iade eder (uncommit).

3. Spring Office Hours S5E26 ve This Week in Spring: Yerel AI Modelleri, JEP 540 JSON ve Mise

Dan Vega ve DaShaun Carter’ın sunduğu Spring Office Hours S5E26 yayını ve Josh Long’un 20 Ekim This Week in Spring bülteni, modern Spring Boot 4.x geliştiricileri için üç pratik mimari deseni öne çıkarmaktadır:

A. 24 GB VRAM İş İstasyonlarında Yerel Modeller ve Spring AI

S5E26 bölümünde, Meta’nın açık ağırlıklı Muse Spark / Muse Glimmer modelleri, DeepSeek V4.1 Flash ve 24 GB VRAM’li tüketici/iş istasyonu GPU'larında yerel model çalıştırma teknikleri ele alındı. Spring AI, OpenAI uyumlu yerel çıkarım sunucularına (Ollama, vLLM, LM Studio) bağlanırken JEP 543 StructuredTaskScope ile birleştirildiğinde; birden fazla yerel modelden veya RAG kaynağından paralel çıkarım yapıp ilk/en doğru yanıtı milisaniyeler içinde birleştirebilmektedir:

java
import org.springframework.ai.chat.client.ChatClient;
import org.springframework.stereotype.Service;
import java.util.concurrent.StructuredTaskScope;
import java.util.concurrent.StructuredTaskScope.Joiner;

@Service
public class ParallelLocalAiOrchestrator {

    private final ChatClient localGlimmerClient;

    public ParallelLocalAiOrchestrator(ChatClient.Builder builder) {
        this.localGlimmerClient = builder.build();
    }

    public String synthesizeArchitectureReview(String codeSnippet) throws InterruptedException {
        // JDK 28 JEP 543 + Spring AI: İki paralel yerel ajan perspektifini tek kapsamda birleştirme
        try (var scope = StructuredTaskScope.open(Joiner.<String>allSuccessfulOrThrow())) {
            var securityAudit = scope.fork(() ->
                localGlimmerClient.prompt()
                    .system("Rol: Salt-okunur güvenlik denetçisi. Kod içindeki SSRF ve IDOR riskleri özetlenir.")
                    .user(codeSnippet)
                    .call()
                    .content()
            );
            var concurrencyAudit = scope.fork(() ->
                localGlimmerClient.prompt()
                    .system("Rol: JVM eşzamanlılık uzmanı. Sanal iş parçacığı blokaj (pinning) riskleri özetlenir.")
                    .user(codeSnippet)
                    .call()
                    .content()
            );

            scope.join();
            return "## Güvenlik Raporu\n" + securityAudit.get() + "\n\n## Eşzamanlılık Raporu\n" + concurrencyAudit.get();
        }
    }
}

B. JDK 28 Native JSON API (JEP 540) ve Mise ile Deterministik Ortam Kurulumu

  • JEP 540 (java.util.json): Harici Jackson veya Gson bağımlılığı eklemeden doğrudan JDK çekirdeğinde değişmez (immutable) JsonValue, JsonObject ve JsonArray ayrıştırma ve desen eşleme (pattern matching) yeteneği sunar.
  • Mise ve .env Yönetimi: Josh Long ve SivaLabs tarafından paylaşılan rehberler, sdkman ve nvm gibi dağınık araçlar yerine Rust tabanlı Mise (mise.toml) aracıyla proje dizinine girildiği anda doğru OpenJDK sürümünün, Maven/Gradle araçlarının ve .env ortam değişkenlerinin deterministik olarak yüklenmesini standartlaştırır.

4. Günün Java ve Spring Gelişmeleri — Mimari Karşılaştırma Matrisi

Teknoloji / JEP Kaynak / Durum Çekirdek Bileşenler Üretim Mimarisindeki Temel Kazanım
JEP 543: Structured Concurrency Inside.java / JDK 28 Nihai StructuredTaskScope.open(), Joiner<T, R, R_X> --enable-preview olmadan sızıntısız sanal iş parçacığı orkestrasyonu
JEP 546 & 545: Adaptive ZGC Inside.java / JDK 28 Hedefli Otonom Yığın Ölçekleme + 2 MB İlk Yığın Manuel -Xmx/-Xms ayarına son verme ve hızlı mikroservis başlangıcı
Inside Java Podcast #72 Inside.java / Nicolai Parlog OpenJDK Bug Triage, JDK 28, JavaOne Sürüm adayı fazında kritik JVM/C2 hatalarının giderilme metodolojisi
Spring Office Hours S5E26 Spring.io / Dan Vega & DaShaun Yerel LLM (24 GB VRAM), JEP 540 JSON, Kiln Spring AI ile yerel açık kaynak modelleri sıfır bulut maliyetiyle çalıştırma
Mise & Modüler Monolitler This Week in Spring / Josh Long mise.toml, .env, Spring Modulith Deterministik çoklu JDK yönetimi ve temiz sınırlarla modüler monolit tasarımı

Mimari Değerlendirme

22 Ekim 2026 Java ve Spring gündemi, platformun geliştirici üzerindeki bilişsel yükü nasıl sistematik olarak azalttığını göstermektedir: JEP 543 karmaşık eşzamanlı hata yönetimini basit bir try-with-resources bloğuna indirgerken, JEP 546 GC bellek ayarını otonomlaştırmakta; Spring AI ve JEP 540 ise yerel yapay zeka modellerini kurumsal Java servislerine minimum bağımlılıkla entegre etmektedir.

Konu Etiketleri
#Structured Concurrency#JEP 543#JDK 28#Spring AI#ZGC JEP 546
Emre Taştutan
Emre TaştutanGeliştirici & AI Meraklısı

Yazılım mimarisi, mikroservis ekosistemleri ve üretken yapay zeka uygulamaları üzerine çalışıyorum. TastutanLabs çatısı altında geliştirici araçları ve SaaS ürünleri inşa ediyorum.

@tastutanlabs • Instagram Mini-Blog

Bu analizin 6 kartlık görsel özetini Instagram'da inceleyin ve kaydedin

Her gün yazılım mimarisi, Java/JVM ve yapay zeka gelişmelerini kendi başına okunabilen 6 slaytlık Mini-Blog serileri halinde paylaşıyoruz.

Instagram'da Takip Et →
Bu Yazıyı Paylaş:

Yorumlar (0)

Düşüncelerinizi Paylaşın

Henüz yorum yapılmamış. İlk yorumu siz yapın!

Bu Kategorideki Diğer İncelemeler

Java & Kurumsal Mimari

Spring Batch 6.1.0-RC1 (@JobParameter ve JdbcClient), Oracle JVM İlk Hata Teşhis Mimarisi (JFR/NMT) ve JetBrains PSI Tabanlı AI Ajanları

Spring Batch 6.1.0-RC1 ile gelen @JobParameter anotasyonu, MessageChannelPartitionHandler bellek optimizasyonu ve JdbcClient geçişi; Oracle JVM Area Lead Sandra Payne'in %1 altı ek yükle ilk üretim çöküşünü yakalayan JFR/NMT teşhis mimarisi ve Anton Arhipov'un açıkladığı JetBrains PSI semantik ajan altyapısı incelenmektedir.

Emre TaştutanEmre Taştutan
7 dk