Java'da OutOfMemoryError Hatası: Nedenleri ve Çözüm Yolları

Java'da OutOfMemoryError hatası, JVM'in çalışan uygulama için gereken belleği ayıramadığını bildiren bir istisnadır; yani programınız bir noktada JVM'den yeni bellek istemiş, JVM de kendisine tanınan sınırlar içinde bu isteği karşılayamamıştır. Bu hata çoğu zaman heap alanının dolmasından, bazen metaspace'in yetersiz kalmasından, bazen de garbage collector'ın sürekli çalışıp bellek boşaltamamasından kaynaklanır. Hatanın hangi bellek bölgesinden geldiğini anlamak, çözüme giden yolun ilk ve en kritik adımıdır.

OutOfMemoryError Nedir? JVM Bellek Modelinde Heap ve Metaspace

JVM, bir Java programını çalıştırırken belleği farklı amaçlara hizmet eden bölgelere ayırır. Bu bölgelerden herhangi biri, kendisine ayrılan sınıra ulaştığında ve JVM daha fazla alan bulamadığında OutOfMemoryError fırlatılır. Bu istisna, "kodunuzda bir satır hatası var" demek değildir; daha çok "istediğiniz kadar bellek şu an mevcut değil" anlamına gelen bir sistem uyarısıdır. Dolayısıyla bu hatayı görmek, doğrudan kötü yazılmış bir kod anlamına gelmeyebilir, ama çoğu zaman altında bellek yönetimiyle ilgili bir sorun yatar.

Heap, JVM'in çalışma zamanında oluşturduğunuz nesnelerin (yeni bir sınıftan üretilen her obje, dizi, koleksiyon elemanı) yaşadığı bellek alanıdır. Programınız çalıştıkça heap'te sürekli yeni nesneler oluşur, garbage collector artık kullanılmayanları temizler, kullanılanlar ise yerinde kalır. Heap dolduğunda ve GC bir türlü yer açamadığında karşınıza çıkan hata genellikle "Java heap space" mesajıyla gelir.

Metaspace ise tamamen farklı bir amaca hizmet eder: burada nesneler değil, sınıfların kendisine ait metadata tutulur — yani bir sınıfın yapısı, metotları, alan tanımları gibi JVM'in sınıfı çalıştırabilmek için ihtiyaç duyduğu bilgiler. Uygulamanız çok sayıda sınıf dinamik olarak yüklüyorsa (örneğin bazı framework'lerin çalışma zamanında proxy sınıflar üretmesi gibi durumlarda) metaspace zamanla dolabilir ve ayrı bir OutOfMemoryError: Metaspace hatası ortaya çıkabilir.

Bu ikisinden ayrı olarak bir de stack bölgesi vardır; her thread'in kendi çağrı yığınını (method çağrıları, yerel değişkenler) tuttuğu alan budur. Stack ile ilgili sorunlarda karşınıza çıkan hata OutOfMemoryError değil, genellikle StackOverflowError'dır ve tipik sebebi sonsuz veya çok derin özyinelemeli (recursive) çağrılardır. Bu ayrımı net tutmak önemlidir: heap ve metaspace sorunları OutOfMemoryError ailesinde değerlendirilirken, stack taşmaları ayrı bir hata türüyle bildirilir.

Heap, Metaspace ve Stack: Kavramsal Karşılaştırma

Bir hatayla karşılaştığınızda önce hangi bellek bölgesinin sorumlu olduğunu anlamak, çözüm sürecini büyük ölçüde kısaltır. Aşağıdaki tablo, üç temel bellek alanının ne için var olduğunu ve doldurulduğunda hangi hatayla karşılaşacağınızı kavramsal düzeyde özetler.

Tablodan da görülebileceği gibi bu üç alan birbirinden bağımsız çalışır ve her biri farklı bir kullanım örüntüsüyle doldurulur. Bir geliştirici olarak hata mesajını gördüğünüz anda önce "hangi bölge?" sorusunu sormak, ardından "bu bölge neden dolmuş olabilir?" sorusuna geçmek, rastgele parametre değiştirmekten çok daha isabetli bir yaklaşımdır. Heap sorunları genellikle uygulamanın veri işleme mantığıyla, metaspace sorunları sınıf yükleme davranışıyla, stack sorunları ise özyineleme derinliğiyle ilgilidir.

OutOfMemoryError'a Yol Açan Yaygın Nedenler

Pratikte OutOfMemoryError hatalarının büyük çoğunluğu, birkaç tekrar eden kod örüntüsünden kaynaklanır. Bunları tanımak, hatayı görür görmez nereye bakmanız gerektiğini bilmenizi sağlar.

• Statik koleksiyonlarda referans tutmak: Bir static alan olarak tanımlanan liste veya map'e sürekli eleman ekleyip hiç temizlememek, bu koleksiyonun uygulamanın tüm yaşam döngüsü boyunca büyümesine yol açar. Statik referanslar garbage collector tarafından asla toplanmadığı için bu, klasik bir bellek sızıntısı senaryosudur.
• Döngü içinde kontrolsüz büyüyen koleksiyonlar: Bir döngüde her iterasyonda bir listeye eleman eklenip hiçbir sınır veya temizleme mekanizması konulmazsa, koleksiyon zamanla heap'in büyük bir kısmını işgal edebilir.
• Sonsuz veya hatalı döngüler: Bitiş koşulu hiç sağlanmayan bir döngü, her turda yeni nesneler üretiyorsa heap hızla dolar; döngünün mantık hatası burada asıl kök nedendir.
• Aşırı büyük veri yükleme: Büyük bir dosyayı veya veritabanı sonucunu satır satır işlemek yerine tamamını tek seferde belleğe almak, dosya boyutuyla orantılı bir heap kullanımına yol açar.
• Gereksiz nesne üretimi: Döngü içinde tekrar tekrar yeni nesne oluşturmak (örneğin string birleştirmelerini yanlış yöntemle yapmak) garbage collector üzerinde sürekli baskı yaratır ve heap'in verimsiz kullanılmasına neden olur.

Bu nedenlerin çoğu, kodun ilk bakışta "çalışıyor" görünmesine rağmen üretim ortamında saatler veya günler sonra patlak vermesiyle fark edilir. Nesnelerin yaşam döngüsünü, referansların ne zaman serbest kaldığını ve koleksiyonların nasıl büyüdüğünü kavramadan bu tür sorunları önceden görmek zordur; bu yüzden sağlam bir Java temeli kurmak, hatayı ortaya çıktıktan sonra kovalamaktan çok daha değerlidir. Java'da bellek yönetimini uygulamalı öğrenmeyi hedefleyen özel ders programı, tam olarak bu tür örüntüleri erken fark edebilme becerisini kazandırmayı amaçlar.

Hata Mesajı Türlerini Okumak: Heap Space, Metaspace, GC Overhead

Bir OutOfMemoryError fırlatıldığında panik yapmadan önce yapılması gereken ilk şey, hata mesajının tam metnini okumaktır. Çünkü JVM bu istisnayı fırlatırken hangi bellek bölgesinin doldurduğunu mesajın devamında belirtir ve bu ayrım, çözüm yolunu baştan belirler. Üç mesaj türünü birbirinden ayırt edemeyen bir geliştirici, aslında kod hatası olan bir sorunu JVM parametresiyle "çözmeye" çalışıp zaman kaybedebilir.

java.lang.OutOfMemoryError: Java heap space mesajı, uygulamanın çalışma zamanında oluşturduğu nesnelerin tutulduğu heap alanının doluluğa ulaştığını gösterir. Bu, genellikle referansı hâlâ canlı tutulan ama artık işe yaramayan nesnelerin birikmesinden, yani bellek sızıntısından ya da tek seferde işlenmesi gerekenden çok daha büyük veri kümesinin belleğe yüklenmesinden kaynaklanır.

Metaspace ile ilgili hata mesajı ise farklı bir katmana işaret eder. Bu bölge, sınıfların tanımlarını ve ilişkili metadata bilgilerini tutar. Metaspace dolduğunda sorun genellikle veri nesneleriyle değil, çalışma zamanında beklenenden çok fazla sınıfın yüklenmesiyle ilgilidir; örneğin dinamik proxy üreten kütüphanelerin veya sınıf yükleyicilerin (classloader) düzgün temizlenmediği senaryolarda bu tür hatalarla karşılaşılabilir.

GC overhead limit exceeded mesajı ise ayrı bir sinyal taşır: bu, JVM'in bellek boşaltmak için çöp toplayıcıyı (Garbage Collector) sürekli çalıştırdığı ama buna karşılık çok az bellek geri kazanabildiği durumu ifade eder. Başka bir deyişle sistem, işlemcisinin büyük kısmını bellek temizlemeye harcamasına rağmen anlamlı bir alan açamamaktadır; bu genellikle heap'in kronik olarak yetersiz kaldığının veya sızıntının ileri seviyede olduğunun işaretidir.

Bu üç mesaj türü arasındaki farkı doğru okumak, teşhis sürecinin en kritik adımıdır çünkü her biri farklı bir inceleme yönüne işaret eder: heap space nesne yaşam döngüsüne, metaspace sınıf yükleme davranışına, GC overhead ise genel bellek baskısına bakmayı gerektirir. Bu tür JVM davranışlarını örnekler üzerinden, kendi hızınızda tekrar tekrar izleyerek pekiştirmek isterseniz video eğitimler bu konuyu adım adım göstermek için uygun bir kaynak olabilir.

Hatalı Kod Örneği: Kontrolsüz Büyüyen Koleksiyon

Aşağıdaki örnek, sahada sıkça karşılaşılan bir kalıbı gösterir: bir listeye sürekli eleman eklenir ama hiçbir zaman temizlenmez veya boyutu sınırlanmaz.

import java.util.ArrayList;
import java.util.List;

public class SizintiOrnegi {
    private static final List ArrayList<>();

    public static void islemYap() {
        while (true) {
            byte[] veri = new byte[1024 * 1024]; // 1 MB büyüklüğünde veri
            onbellek.add(veri);
        }
    }

    public static void main(String[] args) {
        islemYap();
    }
}

Bu kodun neden zamanla belleği tükettiğini adım adım incelemek gerekirse: döngünün her turunda yeni bir byte[] nesnesi oluşturulur ve bu nesne onbellek adlı statik listeye eklenir. Normalde bir nesneye artık ihtiyaç kalmadığında ve ona ulaşan hiçbir referans kalmadığında GC bu nesneyi temizler. Ancak burada durum farklıdır: statik liste, uygulamanın tüm yaşam döngüsü boyunca canlı kalan bir referans zinciri oluşturur ve listeye eklenen her byte[] nesnesi bu zincir üzerinden erişilebilir durumda kalır.

Sonuç olarak GC, bu nesneleri "kullanımda" olarak işaretlemeye devam eder ve hiçbirini toplayamaz. Döngü tekrarlandıkça heap üzerindeki dolu alan sürekli büyür, boş alan giderek azalır ve bir noktada JVM yeni bir nesne için yer bulamaz hâle gelir. Bu, klasik bir bellek sızıntısı örneğidir: kod hatalı değildir çünkü derlenip çalışır, ama tasarım hatalıdır çünkü referanslar hiçbir zaman serbest bırakılmaz. Gerçek projelerde bu kalıp genellikle bir önbellek (cache), statik koleksiyon veya olay dinleyicisi (listener) listesi şeklinde, çok daha örtük biçimde karşımıza çıkar.

Düzeltilmiş Kod: Sınırlama ve Akışlı İşleme ile Bellek Yönetimi

Aynı senaryoyu, veriyi biriktirmek yerine parça parça işleyip anında serbest bırakan bir yaklaşımla yeniden yazalım:

import java.util.ArrayList;
import java.util.List;

public class AkisliIsleme {
    private static final int PARCA_BOYUTU = 100;

    public static void islemYap(int toplamAdet) {
        List geciciListe = new ArrayList<>(PARCA_BOYUTU);

        for (int i = 0; i < toplamAdet; i++) {
            byte[] veri = new byte[1024 * 1024];
            geciciListe.add(veri);

            if (geciciListe.size() == PARCA_BOYUTU) {
                isleGonder(geciciListe);
                geciciListe.clear(); // parça işlendikten sonra referanslar bırakılır
            }
        }
    }

    private static void isleGonder(List parca) {
        // veri burada işlenir, örneğin diske yazılır veya bir servise gönderilir
    }
}

Bu düzeltilmiş versiyonda bellek tüketiminin durmasını sağlayan noktalar şöyle sıralanabilir:

1. Veri artık kalıcı bir statik listede değil, sınırlı boyutlu geçici bir listede tutulur; bu liste her döngüde sınırsız büyümez.
2. Belirlenen parça boyutuna ulaşıldığında veri hemen işlenir, yani biriktirme değil akışlı (streaming) bir mantıkla anlık tüketim uygulanır.
3. clear() çağrısı, işlenmiş elemanlara tutulan referansları listeden koparır; bu sayede GC, artık erişilemeyen nesneleri bir sonraki toplama turunda güvenle geri kazanabilir.
4. Sonsuz döngü yerine sınırlı bir toplamAdet parametresi kullanılması, uygulamanın ne kadar veri işleyeceğinin baştan belli olmasını sağlar.

Buradaki temel prensip, verinin ömrünü olabildiğince kısa tutmaktır: bir nesneye ihtiyaç kalmadığı an, ona giden referans zincirinin de kırılması gerekir. Büyük veri kümeleriyle çalışırken tüm veriyi belleğe yüklemek yerine parça parça işlemek, hem heap üzerindeki baskıyı azaltır hem de GC'nin daha öngörülebilir çalışmasını sağlar.

-Xmx, -Xms ve JVM Bellek Parametreleri: Teşhis Aracı, Çözüm Değil

Bir OutOfMemoryError ile karşılaşan çoğu geliştiricinin ilk refleksi JVM başlatma parametrelerine dokunmaktır. -Xmx parametresi JVM'in heap alanı için ayırabileceği üst sınırı belirler; uygulama bu sınıra ulaştığında ve çöp toplayıcı yeterli alanı boşaltamadığında hata fırlatılır. -Xms ise JVM başlarken heap için ayrılacak başlangıç boyutunu tanımlar. Uygulama çalışırken heap ihtiyacı büyüdükçe JVM, -Xms ile başlayıp -Xmx'e kadar genişleyebilir; bu genişleme sırasında da ek çöp toplama döngüleri devreye girer.

Bu iki parametreyi doğru ayarlamak gerçek bir mühendislik pratiğidir: uygulamanın tipik iş yüküne göre çok düşük bir -Xmx değeri gereksiz hatalara, çok yüksek bir değer ise sunucu kaynaklarının verimsiz kullanılmasına yol açar. Ancak burada kritik bir ayrım vardır. -Xmx değerini yükseltmek, bir bellek sızıntısı ya da kontrolsüz büyüyen bir koleksiyon karşısında sadece hatanın ortaya çıkma anını erteler; sızıntı devam ettiği sürece uygulama er ya da geç yeni, daha yüksek sınıra da ulaşacaktır. Bu yüzden -Xmx ve -Xms, üretim ortamında bir teşhis ve yumuşatma aracı olarak değerlidir, ama kök nedeni ortadan kaldıran bir çözüm değildir. Kalıcı çözüm her zaman kod ve mimari seviyesinde aranmalıdır: gereksiz referansların temizlenmesi, koleksiyonlara sınır konması, akışlı (streaming) veri işleme yaklaşımlarının benimsenmesi ve önbellekleme stratejilerinin gözden geçirilmesi gibi adımlar, parametre ayarından çok daha kalıcı sonuç verir.

Özellikle üretimde tekrarlayan ve kaynağı belirsiz OutOfMemoryError vakalarında, sorunu tek başına ayıklamak zaman alabilir; bu noktada kodun satır satır incelenip sızıntı noktalarının birlikte tespit edildiği 1-1 özel ders desteği, deneyimli bir gözün hızlı yönlendirmesiyle süreci kısaltabilir. Bir mentorla birlikte heap dump çıktısını okumak veya şüpheli bir servis sınıfını satır satır gözden geçirmek, çoğu zaman forum aramalarıyla geçen saatlerden çok daha verimlidir.

Teşhis Süreci: OutOfMemoryError'ı Adım Adım Analiz Etmek

Bir OutOfMemoryError ile karşılaşıldığında paniğe kapılıp rastgele kod değiştirmek, sorunu genellikle daha da karmaşık hale getirir. Bunun yerine sistematik bir teşhis sırası izlemek, hem zaman kazandırır hem de kalıcı bir çözüme ulaşma ihtimalini artırır.

1. Hata mesajını ve istisna türünü dikkatle okuyun. Stack trace'in en üstündeki satır, hatanın java.lang.OutOfMemoryError olduğunu doğrular; ancak asıl bilgi mesajın devamındaki ek metindedir. Bu metin, sorunun heap mi, metaspace mi yoksa çöp toplama verimliliği mi ile ilgili olduğunu ele verir.
2. Hatanın hangi bellek bölgesine işaret ettiğini belirleyin. Heap space, metaspace ve GC overhead mesajları farklı kök nedenlere işaret eder; bu ayrımı netleştirmeden yapılan her müdahale kör atış olur.
3. Heap dump alma fikrini değerlendirin. Heap dump, JVM'in çökme anındaki bellek içeriğinin bir anlık görüntüsüdür ve hangi nesne türlerinin belleği doldurduğunu, hangi referans zincirlerinin nesneleri canlı tuttuğunu görmeyi sağlar. Belirli araçlarla açılıp incelenebilen bu görüntü, "bellekte gerçekte ne birikiyor" sorusuna somut bir cevap verir.
4. Kod incelemesiyle şüpheli noktaları tarayın. Statik alanlarda tutulan koleksiyonlar, sınırsız büyüyen önbellekler, kapanmayan akışlar ve döngü içinde sürekli nesne üreten yapılar öncelikli inceleme noktalarıdır.
5. Küçük ölçekte test ederek doğrulayın. Şüphelenilen kod parçası izole edilip küçük bir veri kümesiyle veya sınırlı bir döngü sayısıyla test edilerek, belleğin gerçekten beklenmedik biçimde büyüyüp büyümediği gözlemlenir.

Bu adımları teorik olarak bilmek ile gerçek bir hata anında hızlıca uygulayabilmek arasında ciddi bir fark vardır; bu farkı kapatmanın pratik bir yolu, bellek yönetimi ve istisna senaryolarını içeren sorularla kendinizi sınamaktır. Java bilgi testi ile bu tür pratik senaryolara ne kadar hazır olduğunuzu kısa sürede görebilirsiniz.

Sık Sorulan Sorular

OutOfMemoryError ile StackOverflowError arasındaki fark nedir?

OutOfMemoryError genellikle heap veya metaspace gibi geniş bellek bölgelerinin dolmasından kaynaklanır ve çoğunlukla büyüyen koleksiyonlar veya sızıntılarla ilişkilidir. StackOverflowError ise her thread'e ayrılan sınırlı çağrı yığınının, genellikle sonsuz veya çok derin özyinelemeli (recursive) çağrılar nedeniyle taşmasından doğar; ikisi farklı bellek bölgelerini ve farklı kod hatalarını işaret eder.

Metaspace hatası neden heap hatasından farklı bir şekilde çözülür?

Heap hatası genellikle uygulamanın çalışma zamanında ürettiği nesnelerle ilgiliyken, metaspace hatası sınıf tanımlarının kendisiyle ilgilidir. Bu yüzden metaspace sorunlarında odak noktası nesne yönetimi değil, dinamik sınıf üretiminin (örneğin aşırı proxy veya class loader kullanımı) kontrol altına alınmasıdır.

-Xmx değerini artırmak OutOfMemoryError'ı kalıcı olarak çözer mi?

Hayır. -Xmx değerini artırmak, uygulamanın hata vermeden önce kullanabileceği bellek alanını genişletir ve hatanın ortaya çıkışını geciktirebilir; ancak altta yatan bir bellek sızıntısı veya kötü tasarım varsa, uygulama zamanla yeni sınıra da ulaşır. Kalıcı çözüm kod ve mimari düzeyinde aranmalıdır.

GC overhead limit exceeded hatası ne anlama gelir?

Bu hata, çöp toplayıcının çok fazla zaman harcamasına rağmen çok az bellek boşaltabildiği durumlarda ortaya çıkar. Pratikte JVM'in belleği "geri kazanmaya çalışıyor ama başaramıyor" durumunu ifade eder ve çoğunlukla ciddi bir bellek sızıntısının veya aşırı düşük heap boyutunun işaretidir.

Bellek sızıntısını fark etmek için hangi ilk işaretlere bakılmalı?

Uygulamanın zamanla, özellikle uzun süre çalıştıkça yavaşlaması, çöp toplama duraklamalarının sıklaşması ve bellek kullanımının hiç düşmeden sürekli yükselen bir eğri izlemesi, sızıntının erken işaretleri arasındadır. Statik koleksiyonlarda veya önbelleklerde sürekli artan eleman sayısı da önemli bir ipucudur.

Heap dump almak gerçekten gerekli mi, yoksa kod incelemesi yeterli mi?

Basit ve açık hatalarda dikkatli bir kod incelemesi sorunu bulmak için yeterli olabilir. Ancak sızıntının kaynağı belirsizse veya çok sayıda bileşen etkileşim halindeyse, heap dump'ın sunduğu somut nesne ve referans bilgisi, tahmine dayalı incelemeden çok daha güvenilir bir teşhis sağlar.

Küçük ölçekli bir projede de OutOfMemoryError görülebilir mi?

Evet. Hatanın büyüklüğü projenin ölçeğiyle değil, kodun bellek yönetim disiplinigiyle ilgilidir. Küçük bir öğrenim projesinde bile sınırsız büyüyen bir liste veya kapatılmayan bir kaynak, aynı hatayı tetikleyebilir; bu da erken aşamada doğru alışkanlıkları öğrenmenin değerini gösterir.

OutOfMemoryError, panik gerektiren değil sistematik bir okuma ve inceleme süreci gerektiren bir hatadır; hata mesajını doğru yorumlamak, bellek bölgesini belirlemek ve kod seviyesinde kalıcı çözümler üretmek bu sürecin temelidir. Bu tür JVM davranışlarını ve genel Java pratiklerini daha sağlam bir zeminde öğrenmek isteyenler, Java yazılım kursu sayfasından eğitmenimiz Berk Keskin'in hazırladığı içeriklere göz atabilir.