Garbage Collection — Üçlü Takas

En iyi çöp toplayıcı diye bir şey yok. Doğru soru: neyinden vazgeçmeye razısın?

Üçünü birden alamazsın

Üç şey birbiriyle yarışır ve hiçbir toplayıcı üçünü birden kazanmaz:

• Throughput — CPU’nun ne kadarı uygulamanın işini yapıyor
• Duraklama — en uzun stop-the-world?Terimin tanımını açstop-the-worldToplayıcının çalışabilmesi için tüm uygulama thread'lerinin durdurulduğu aralık. Gecikmeye duyarlı bir serviste p99'u bozan şey budur.Sözlükte gör → süresi
• Ayak izi — bellek ve CPU ek maliyeti

Bir toplayıcı seçmek, bu üçünden hangisinden vazgeçtiğini seçmektir.

Kendin gör

Alttaki karşılaştırma tablosuna bak — sıralama sütuna göre değişiyor:

1. Parallel, 8 GB, 500 MB/sn. En uzun duraklama 5.7 saniye. Ama throughput?Terimin tanımını açthroughputBirim zamanda yapılan iş miktarı. GC bağlamında: CPU'nun ne kadarı uygulamanın işini yapıyor, ne kadarı toplayıcıya gidiyor.Sözlükte gör → en yüksek: %93.3.
2. ZGC’ye geç. Duraklama 0.5 ms. Throughput ise %90 — daha düşük.
3. Heap’i 32 GB yap, Parallele dön. Duraklama 5.7 sn’den 22.9 sn’ye çıktı.
4. G1, 32 GB. Genç kuşağı 9830 MB’tan 2083 MB’a çekiyor ve 200 ms hedefini tutturuyor.
5. G1, 2 GB, 2000 MB/sn. Hedef gitti — G1 full GC’ye düştü.
6. Görevleri tamamla. Sonuncusu bir seçim sorusu: büyük heap ve yoğun ayırmada her duraklamayı 1 ms altında tutan toplayıcı hangisi, bedelini nerede ödüyor?

Üç toplayıcı, üç takas

 2 GB heap →  1.4 sn full GC
 8 GB heap →  5.7 sn full GC
32 GB heap → 22.9 sn full GC

Parallel — throughput kralı. Eşzamanlı hiçbir iş yapmaz, uygulamadan CPU çalmaz. Gece çalışan bir toplu iş için doğru tercih, kullanıcıya cevap veren bir servis için felakettir.

G1 — hedefi daha az toplayarak tutturur. -XX:MaxGCPauseMillis=200 verdiğinde genç kuşağı, hayatta kalanları kopyalamak hedefe sığacak kadar küçültür. Ayırma hızı artınca duraklama uzamaz, toplama sıklaşır.

Sınırı şu: promosyon hızı eşzamanlı işaretlemeyi geçerse G1 yetişemez ve full GC’ye düşer. Hedefi çok küçük vermek de işe yaramaz — toplama sıklığı fırlar, toplam maliyet artar.

Aşağıdaki örnek bir bankanın internet şubesinden ve kur ekranından: GC’nin toplayamadığı iki klasik sızıntı ve düzeltmesi, ardından GC’yi ayarlayıp ölçmek için bayraklar ve komutlar. Sayı yok; sayıyı kendi ölçümün verir.

1
public class SessionRegistry {
2

3
    // LEAK: every internet-banking session ever created stays reachable from a static
4
    // root, together with the account list and statement pages it loaded.
5
    private static final Map<String, Session> ALL = new ConcurrentHashMap<>();
6

7
    public static void register(Session session) {
8
        ALL.put(session.id(), session);
9
    }
10

11
    // FIX: bound it and let entries expire (or use Caffeine with expireAfterAccess).
12
    private static final Map<String, Session> RECENT = Collections.synchronizedMap(
13
            new LinkedHashMap<>(1_024, 0.75f, true) {
14
                @Override
15
                protected boolean removeEldestEntry(Map.Entry<String, Session> eldest) {
16
                    return size() > 10_000;
17
                }
18
            });
19

20
    public static void remember(Session session) {
21
        RECENT.put(session.id(), session);
22
    }
23
}

1
// Pushes every EUR/TRY, USD/TRY … tick to the screens that are open right now.
2
public class FxRateTicker {
3

4
    private final List<Consumer<Rate>> listeners = new CopyOnWriteArrayList<>();
5

6
    // Returning a handle makes "unsubscribe" impossible to forget in a try-with-resources.
7
    public AutoCloseable subscribe(Consumer<Rate> listener) {
8
        listeners.add(listener);
9
        return () -> listeners.remove(listener);
10
    }
11

12
    public void publish(Rate rate) {
13
        listeners.forEach(listener -> listener.accept(rate));
14
    }
15
}
16

17
// A customer's exchange screen, open for a few minutes. Without close(), the ticker keeps
18
// the lambda, the lambda keeps `this`, and `this` keeps its growing list alive forever.
19
class ExchangeScreen implements AutoCloseable {
20

21
    private final AutoCloseable subscription;
22
    private final List<Rate> seen = new ArrayList<>();
23

24
    ExchangeScreen(FxRateTicker ticker) {
25
        this.subscription = ticker.subscribe(seen::add);
26
    }
27

28
    @Override
29
    public void close() throws Exception {
30
        subscription.close();
31
    }
32
}

1
FROM eclipse-temurin:21-jre
2
COPY app.jar /app/app.jar
3
# G1 is the default; the flags below make the choices explicit and observable.
4
ENV JAVA_TOOL_OPTIONS="-XX:+UseG1GC \
5
  -XX:MaxRAMPercentage=75 \
6
  -XX:MaxGCPauseMillis=200 \
7
  -Xlog:gc*:file=/logs/gc.log:time,uptime,level,tags:filecount=5,filesize=20m \
8
  -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/dumps"
9
ENTRYPOINT ["java", "-jar", "/app/app.jar"]

PID=$(pgrep -f app.jar)

# Heap regions and occupancy right now
jcmd "$PID" GC.heap_info

# Which classes hold the most live memory (forces a full GC first: not on a busy production node)
jcmd "$PID" GC.class_histogram | head -25

# Two minutes of low-overhead recording: allocation, GC pauses, lock contention
jcmd "$PID" JFR.start name=gc duration=120s filename=/dumps/gc.jfr settings=profile

# Then open /dumps/gc.jfr in JDK Mission Control, and compare with /logs/gc.log.

ZGC — duraklamayı satın alır, throughput ile öder. İşaretleme ve yer değiştirme eşzamanlı olduğu için duraklama heap boyutundan bağımsızdır, 32 GB’ta da milisaniyenin altındadır.

Bedeli: her nesne okuması bir load barrier’dan geçer, düşük ayırma hızında throughput Parallel’den düşüktür. ZGC gecikmeye duyarlı servisler için doğru takastır, toplu işler için yanlış.

Çoğu nesne genç ölür

“Nesnelerin büyük çoğunluğu genç ölür.” Tüm generational GC tasarımı bu gözleme dayanır.

Genç toplamanın maliyeti çöple değil, hayatta kalanla orantılıdır. Eden’deki 2 GB çöpün hiçbiri yaşamıyorsa toplama neredeyse bedavadır — çöp kopyalanmaz.

Pratik sonucu: çok sayıda kısa ömürlü nesne üretmek GC için ucuzdur. Pahalı olan, uzun süre hayatta kalanlardır.

Tuzaklar

Java 9’dan beri varsayılan G1’dir ve çoğu servis için doğru cevap odur. Toplayıcıyı değiştirmeden önce ölç:

1. Ölç. GC logunu aç (-Xlog:gc*), duraklama dağılımına bak. p99 kaç ms?
2. Ayırma hızını düşür. Log string’leri, ara koleksiyonlar, kutulama — azaltmak her toplayıcıda kazandırır.
3. Live set’e bak. Sorun hayatta kalan veri miktarıysa bu bir önbellek ya da sızıntı sorunudur.
4. Sonra toplayıcı seç.

Heap’i büyütmek ilk refleks olmamalı: genç toplamanın işini değil sıklığını azaltır, Parallel ve G1’de full GC’yi uzatır.

Kendini sına