PaylaşımMEMORY LEAK (BELLEK SIZINTISI) NEDIR? KAPSAMLI REHBER

Memory Leak (Bellek Sızıntısı) Nedir? Kapsamlı Rehber

Ne olduğu, neye yol açtığı, nasıl tespit edildiği ve nasıl önlendiği

• Manuel bellek yönetimli dillerde (C, C++) sorun: free() / delete çağrılmamıştır.
• Çöp toplayıcılı (GC) dillerde (Java, C#, JavaScript, Python, Go) sorun: nesneye giden bir referans hâlâ hayattadır. GC "buna hâlâ ulaşılabiliyor" der ve toplamaz.

"Java/JavaScript'te garbage collector var, orada memory leak olmaz." Bu yanlıştır. GC yalnızca ulaşılamayan nesneleri toplar. Yanlışlıkla tuttuğunuz bir referans, nesneyi sonsuza kadar "ulaşılabilir" yapar. GC'li dillerde sızıntı, unutulan referans şeklinde ortaya çıkar.

Genişletmek için tıkla ...

• GC'li dillerde: Çöp toplayıcı, dolmakta olan heap'i temizlemek için daha sık ve daha uzun çalışır. Her GC turunda uygulama duraklar ("stop-the-world"). Bu duraklamalar başta 10 ms iken 500 ms'ye çıkabilir. Kullanıcı bunu takılma / donma / lag olarak hisseder.
• Genel olarak: Fiziksel RAM dolunca işletim sistemi belleği diske taşımaya başlar (swap / paging). Disk RAM'den kat kat yavaştır; sistem geneli sürünmeye başlar.

• Aynı makinedeki diğer uygulamalar da bellek bulamaz hâle gelir.
• Cache'ler etkisizleşir, disk I/O patlar.
• Container ortamlarında (Docker/Kubernetes) bellek limiti aşılınca konteyner öldürülür ve yeniden başlatılır. Loglarda genellikle sadece OOMKilled yazar; uygulama tarafında hiçbir hata izi kalmayabilir.

• Java: java.lang.OutOfMemoryError: Java heap space
• C/C++: malloc NULL döner, new std::bad_alloc fırlatır, ya da doğrudan segfault
• Node.js: FATAL ERROR: Ineffective mark-compacts near heap limit — JavaScript heap out of memory
• Python: MemoryError
• Linux: Kernel'in OOM Killer'ı süreci sonlandırır; dmesg çıktısında "Out of memory: Killed process..." satırı görülür.

• Gece 03:00 alarmları ve "her sabah sunucuyu restart etme" alışkanlığı
• Sorunu gizlemek için sürekli RAM/donanım büyütülmesi (maliyet)
• Güvenlik boyutu: Uzaktan tetiklenebilen bir sızıntı, saldırgan için bir DoS (hizmet dışı bırakma) vektörüdür. Saldırgan tek yapması gerekeni tekrarlar ve servis kendi kendine çöker.

Kritik uyarı: "Her gece restart atıyoruz, sorun yok" bir çözüm değil, sızıntının varlığının kanıtıdır. Restart, semptomu bastırıp sorunu ölçülemez hâle getirir.

Genişletmek için tıkla ...

​

[/SIZE][/CENTER]
[SIZE=5][CENTER]void veri_isle() {
    char *buffer = malloc(1024);
    if (buffer == NULL) return;

    if (!dogrula(buffer)) {
        return;          // ✗ SIZINTI: erken çıkışta free yok
    }

    islem_yap(buffer);
    free(buffer);        // yalnızca "mutlu yol"da çalışıyor
}

• Erken return ve hata dalları
• Exception fırlatılması (C++'ta free/delete satırı atlanır)
• Yanlış operatör eşleşmesi: new[] ile ayırıp delete (köşeli parantezsiz) ile bırakmak
• Sahiplik belirsizliği: Belleği kimin bırakacağı tanımlı değildir; herkes "diğeri bırakır" varsayar

void veri_isle() {[/SIZE][/CENTER]
[SIZE=5][CENTER]    auto buffer = std::make_unique<char[]>(1024);   // sahiplik net

    if (!dogrula(buffer.get())) {
        return;          // ✓ unique_ptr yıkıcısı belleği otomatik bırakır
    }
    islem_yap(buffer.get());
}   // ✓ exception fırlasa bile bellek serbest kalır

[/SIZE][/CENTER]
[SIZE=5][CENTER]public class Kayit {
    // static = uygulama ömrü boyunca yaşar
    private static final List<Oturum> TUM_OTURUMLAR = new ArrayList<>();

    public static void oturumAc(Oturum o) {
        TUM_OTURUMLAR.add(o);    // ✗ ekleniyor...
    }
    // ...ama hiçbir yerde remove() yok. Liste sonsuza kadar büyür.
}

[/SIZE][/CENTER]
[SIZE=5][CENTER]// ✗ Sınır yok, süre yok, tahliye politikası yok
private final Map<String, Sonuc> cache = new HashMap<>();

// ✓ Boyut sınırı ve süre ile
private final Cache<String, Sonuc> cache = Caffeine.newBuilder()
        .maximumSize(10_000)
        .expireAfterWrite(Duration.ofMinutes(30))
        .build();

[/SIZE][/CENTER]
[SIZE=5][CENTER]// ✗ Sızdıran
function panelAc() {
  const agirVeri = new Array(1_000_000).fill('x');
  window.addEventListener('resize', () => console.log(agirVeri.length));
  // Panel kapansa bile listener window üzerinde kalır → agirVeri asla toplanmaz
}

// ✓ Temizlenen
function panelAc() {
  const agirVeri = new Array(1_000_000).fill('x');
  const handler = () => console.log(agirVeri.length);
  window.addEventListener('resize', handler);

  return function kapat() {
    window.removeEventListener('resize', handler);   // ✓ referans kopar
  };
}

[/SIZE][/CENTER]
[SIZE=5][CENTER]useEffect(() => {
  const id = setInterval(tick, 1000);
  return () => clearInterval(id);   // ✓ bu satır olmazsa interval + closure sızar
}, []);

[/SIZE][/CENTER]
[SIZE=5][CENTER]// ✓ try-with-resources: exception olsa bile kapatır
try (Connection conn = ds.getConnection();
     PreparedStatement ps = conn.prepareStatement(sql)) {
    ps.execute();
}

class Ekran {[/SIZE][/CENTER]
[SIZE=5][CENTER]    private byte[] tampon = new byte[50_000_000];

    void basla() {
        // ✗ Anonim Runnable, Ekran.this'i tutar → 50 MB planlayıcı yaşadıkça durur
        planlayici.scheduleAtFixedRate(new Runnable() {
            public void run() { tik(); }
        }, 0, 1, TimeUnit.SECONDS);
    }
}

• Python'un gc modülü döngüleri toplayabilir, ama __del__ içeren bazı eski senaryolarda takılabilir
• C++'ta std::shared_ptr döngüsü klasik örnektir; sayaç asla sıfıra inmez. Çözüm: döngüyü kıran tarafta std::weak_ptr kullanmak
• Eski tarayıcılarda DOM ↔ JavaScript arası döngüler

• Java'da DirectByteBuffer / JNI ile ayrılan bellek
• Node.js'te native modüllerin (Buffer dışı) ayırdığı bellek
• Python'da C uzantılarının ayırdığı bellek
• Metaspace/ClassLoader sızıntıları: uygulama sunucusunda tekrar tekrar deploy edildikçe eski sınıf yükleyicilerin bırakılmaması

İpucu: İşletim sistemi süreç belleği (RSS) sürekli artıyor ama heap grafiği düz duruyorsa, aradığınız şey büyük olasılıkla native bir sızıntıdır.

​

1. Uygulamayı ısıt, bir tam GC tetikle → Snapshot A
2. Şüpheli senaryoyu N kez çalıştır
3. Yeniden tam GC tetikle → Snapshot B
4. B − A farkında sayısı N ile orantılı artan nesne tipini ara

• Eclipse MAT: Path to GC Roots, Dominator Tree, Leak Suspects Report
• Chrome DevTools: Retainers paneli
• VisualVM / JProfiler: References / Nearest GC Root

• jcmd <pid> GC.heap_info — anlık heap durumu
• jstat -gcutil <pid> 1000 — saniyede bir GC istatistikleri; taban seviyesinin yükselişini görmenin en hızlı yolu
• GC logları: -Xlog:gc*:file=gc.log:time,uptime,level,tags
• JFR (Java Flight Recorder): -XX:StartFlightRecording=duration=300s,filename=kayit.jfr — düşük maliyetli, üretimde bile kullanılabilir

[/SIZE][/CENTER]
[SIZE=5][CENTER]jcmd <pid> GC.heap_dump /yol/dump.hprof
# veya
jmap -dump:live,format=b,file=dump.hprof <pid>

[/SIZE][/CENTER]
[SIZE=5][CENTER]-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/dumps

• Eclipse MAT — sızıntı analizinde standart araç. "Leak Suspects" raporu çoğu zaman doğrudan suçluyu gösterir
• VisualVM — ücretsiz, snapshot karşılaştırma yapabilir
• JProfiler / YourKit — ticari, ayrıntılı ve rahat kullanımlı
• Async-profiler — allocation profiling; "bu belleği hangi kod satırı ayırıyor" sorusunun cevabı

• Heap snapshot: Snapshot al, senaryoyu çalıştır, ikinci snapshot al, "Comparison" görünümüne geç ve Delta sütununa bak
• Allocation instrumentation on timeline: Zaman içinde ayrılan ve hayatta kalan nesneleri gösterir; mavi çubuklar hayatta kalanlardır — sızıntı bunlarda görünür
• Detached DOM nodes: Snapshot içinde Detached araması yapın. Bu, DOM'dan çıkarılmış ama JS tarafından hâlâ referans verilen elemanlardır ve web sızıntılarının en yaygın türüdür
• Performance monitor: JS heap size ve DOM node sayısını canlı izler; ikisi de sürekli tırmanıyorsa sorun kesindir

[/SIZE][/CENTER]
[SIZE=5][CENTER]node --inspect app.js          # Chrome DevTools ile bağlan
node --max-old-space-size=4096 app.js
node --heapsnapshot-signal=SIGUSR2 app.js   # sinyalle snapshot al

• process.memoryUsage() ile heapUsed ve rss değerlerini periyodik loglayın
• rss artıyor ama heapUsed sabitse: native/Buffer kaynaklı sızıntı
• clinic.js (özellikle clinic heapprofiler) teşhis için pratiktir

• Valgrind (Memcheck):

[/SIZE][/CENTER]
[SIZE=5][CENTER] valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes ./program

• AddressSanitizer (ASan) — modern tercih, çok daha hızlı:

[/SIZE][/CENTER]
[SIZE=5][CENTER]  g++ -fsanitize=address -g program.cpp -o program
  ./program        # çıkışta sızıntı raporu verir

• LeakSanitizer, Dr. Memory, Visual Studio CRT Debug Heap (Windows tarafında)
• En etkili önlem araç değil, disiplindir: RAII, std::unique_ptr / std::shared_ptr, çıplak new/delete'ten kaçınmak, döngüleri weak_ptr ile kırmak.

• tracemalloc (standart kütüphanede): iki anlık görüntü alıp compare_to() ile farkı listeler
• objgraph: objgraph.show_growth() — hangi tip nesnelerin sayısı artıyor
• memory_profiler: satır satır bellek kullanımı
• gc.set_debug(gc.DEBUG_LEAK) ve gc.garbage: toplanamayan döngüleri gösterir

• Linux: top/htop (RES sütunu), ps -o rss,vsz, smem, /proc/<pid>/status
• dmesg | grep -i "out of memory" — OOM Killer'ın süreci öldürüp öldürmediği
• pmap -x <pid> — süreç bellek haritası
• Windows: Task Manager, Resource Monitor, Performance Monitor, RAMMap
• macOS: Activity Monitor, leaks <pid>, Instruments (Leaks / Allocations enstrümanları)

• Prometheus + Grafana ile süreç ve heap belleği metrikleri
• Uyarı kuralı fikri: "Bellek kullanımı 6 saat boyunca monoton arttı" — mutlak eşikten çok daha erken uyarır
• Konteyner ortamlarında bellek limitini ölçüme dayalı belirleyin; sızıntıyı gizlemek için limiti büyütmek çözüm değil, ertelemedir

1. Sahipliği netleştirin. Her ayrılan kaynağın "sahibi" belli olsun: onu kim bırakacak, ne zaman bırakacak? Belirsizlik sızıntının ana kaynağıdır.
2. Dilin otomatik temizlik mekanizmalarını kullanın. C++'ta RAII ve akıllı işaretçiler; Java'da try-with-resources; Python'da with; C#'ta using; Go'da defer.
3. Her koleksiyona bir tavan koyun. Sınırsız büyüyebilen bir liste/map/cache, potansiyel bir sızıntıdır. Boyut sınırı ve/veya süre bazlı tahliye ekleyin.
4. Her addin bir removeu, her registerın bir unregisterı olsun. Bunu yazarken düşünün, sonradan değil.
5. Cache'i cache gibi kurun. HashMap bir cache değildir. Caffeine/Guava (Java), lru-cache (Node), functools.lru_cache (Python) gibi tahliye politikalı yapılar kullanın.
6. Uzun ömürlü nesnelerde ağır nesneleri tutmayın. Örneğin oyun sunucusunda Player nesnesi yerine UUID saklayın; gerektiğinde nesneyi yeniden çözümleyin.
7. Ömür (lifecycle) farkına dikkat edin. Kısa ömürlü bir nesneyi uzun ömürlü bir nesneye bağladığınız her yer, potansiyel bir sızıntı noktasıdır.
8. Zayıf referansları yerinde kullanın. WeakHashMap, WeakReference, weak_ptr, WeakMap — ama bunlar tasarım hatasını örtmek için değil, kasıtlı "sahiplenmeyen" ilişkiler için kullanılmalıdır.
9. Finalizer'lara güvenmeyin. Java'da finalize() kullanımdan kaldırıldı; ne zaman, hatta çalışıp çalışmayacağı belirsizdir. Temizlik açık ve deterministik olmalıdır.

• Kod incelemesinde sorulacak standart soru: "Bu nesnenin referansını kim, ne kadar süre tutuyor?"
• Dayanıklılık (soak) testi: Sürümden önce uygulamayı gerçekçi yükle 12–24 saat çalıştırıp bellek grafiğini inceleyin. Sızıntıların büyük kısmı bu tek adımla yakalanır.
• Otomatik regresyon kontrolü: CI'da bir senaryoyu N kez çalıştırıp bellek artışını eşikle karşılaştıran basit bir test bile çok işe yarar.
• Statik analiz: SpotBugs, Clang Static Analyzer, ESLint kuralları, sanitizer'lı derleme profilleri.
• Üretimde OOM dump'ı açık tutun. Çökme anındaki heap dump, sonradan üretilemeyen en değerli kanıttır.

1. Bellek grafiğini kaydet — sızıntı mı, yoksa sadece yüksek kullanım mı?
2. Tam GC sonrası taban seviyesi yükseliyor mu?
3. Sızıntıyı tekrar üretebilen bir senaryo bul
4. Öncesi/sonrası heap snapshot al ve farkı karşılaştır
5. Sayısı tekrar sayısıyla orantılı artan nesne tipini bul
6. O nesnenin GC root'a giden referans zincirini çıkar
7. Zincirdeki gereksiz referansı kopar (remove / unregister / close / clear)
8. Aynı senaryoyu tekrar çalıştır ve grafiğin düzleştiğini kanıtla
9. Aynı hatanın tekrar girmemesi için test veya izleme uyarısı ekle

1. Sızıntı bir bellek sorunu değil, bir sahiplik sorunudur. "Bu nesneyi kim, ne kadar süre tutuyor?" sorusunun cevabı yoksa, sızıntı adayınız var demektir.
2. Tahmin etmeyin, ölçün. Grafik ve heap snapshot olmadan yapılan her teşhis tahmindir.
3. Düzeltmeyi kanıtlayın. Ölçüm olmadan "düzeldi" demek, sorunu bir sonraki sürüme ertelemektir.