Java Bellek Yönetimi, yerleşik çöp toplama ile dilin en iyi başarılarından biridir. Geliştiricilerin, bellek ayırma ve ayrılma hakkında açıkça endişelenmeden yeni nesneler oluşturmalarına olanak tanır; çünküçöp toplayıcı otomatik olarak yeniden kullanım için belleği geri alır. Bu, bellek sızıntılarını ve diğer bellekle ilgili sorunları ortadan kaldırırken, daha basit kalıp kodu ile daha hızlı geliştirmeyi sağlar. En azından teorik olarak.
İronik olarak, Java çöp toplama çok fazla nesne oluşturup kaldırarak çok iyi çalışıyor gibi görünüyor. Çoğu bellek yönetimi sorunu çözülür, ancak genellikle ciddi performans sorunları yaratma pahasına. Çöp toplama her türlü duruma uyarlanabilir hale getirmek, karmaşık ve optimize edilmesi zor bir sisteme neden olmuştur. Başınızı çöp toplama etrafında sarmak için önce bellek yönetiminin bir Java Sanal Makinesi'nde (JVM) nasıl çalıştığını anlamanız gerekir.
Çöp Koleksiyonu Gerçekten Nasıl Çalışır?
Birçok kişi çöp toplamanın ölü nesneleri toplayıp attığını düşünüyor. Gerçekte, Java çöp toplama tersini yapıyor! Canlı nesneler izlenir ve her şey çöp tayin edilir. Gördüğünüz gibi, bu temel yanlış anlama birçok performans problemine neden olabilir.
Dinamik ayırma için kullanılan bellek alanı olan yığın ile başlayalım. Çoğu yapılandırmada, işletim sistemi, yığın yığını, program çalışırken JVM tarafından yönetilmek üzere önceden tahsis eder. Bu birkaç önemli etkiye sahiptir:
1)Nesne oluşturma daha hızlıdır, çünkü her bir nesne için işletim sistemi ile küresel senkronizasyon gerekli değildir. Bir tahsis basitçe bir bellek dizisinin bir kısmını talep eder ve ofset işaretçisini ileriye taşır. Bir sonraki tahsisat bu ofsette başlar ve dizinin sonraki bölümünü talep eder.
2)Bir nesne artık kullanılmadığında, çöp toplayıcı altta yatan belleği geri alır ve onu gelecek nesne ayırma için yeniden kullanır. Bu, açık bir silinme olmadığı ve işletim sistemine geri verilen hiçbir bellek olmadığı anlamına gelir.
Tüm nesneler JVM tarafından yönetilen yığın alanında tahsis edilir. Geliştiricinin kullandığı her öğe, sınıf nesneleri, statik değişkenler ve hatta kodun kendisi de dahil olmak üzere bu şekilde değerlendirilir. Bir nesne atıfta bulunduğu sürece JVM canlı olarak değerlendirir. Bir nesne artık atıfta bulunulmadığı ve bu nedenle uygulama kodu tarafından erişilemediğinde, çöp toplayıcı onu kaldırır ve kullanılmayan belgeyi geri alır. Bu kadar basit, bir soru ortaya çıkarıyor: Ağacın ilk referansı nedir?
.
.
Burdan sonrasını anlamak için biraz java bilmek gerekiyor. (Şahsen bilmiyorum :)) Yazı yabancı bir siteden alıntıdır. Çeviri ve düzenleme bana ait. (Google amcayada teşekkür etmek lazım.)[DOUBLEPOST=1494176486,1494176144][/DOUBLEPOST]Özet geçmek gerekirse anladığım kadarıyla gc yani garbage collector birçok bellek yönetim sorunu yani RAM ile ilgili sorunu çözerken aslında daha çok performans kaybına yol açıyor. Yanlışım varsa düzeltin.
İronik olarak, Java çöp toplama çok fazla nesne oluşturup kaldırarak çok iyi çalışıyor gibi görünüyor. Çoğu bellek yönetimi sorunu çözülür, ancak genellikle ciddi performans sorunları yaratma pahasına. Çöp toplama her türlü duruma uyarlanabilir hale getirmek, karmaşık ve optimize edilmesi zor bir sisteme neden olmuştur. Başınızı çöp toplama etrafında sarmak için önce bellek yönetiminin bir Java Sanal Makinesi'nde (JVM) nasıl çalıştığını anlamanız gerekir.
Çöp Koleksiyonu Gerçekten Nasıl Çalışır?
Birçok kişi çöp toplamanın ölü nesneleri toplayıp attığını düşünüyor. Gerçekte, Java çöp toplama tersini yapıyor! Canlı nesneler izlenir ve her şey çöp tayin edilir. Gördüğünüz gibi, bu temel yanlış anlama birçok performans problemine neden olabilir.
Dinamik ayırma için kullanılan bellek alanı olan yığın ile başlayalım. Çoğu yapılandırmada, işletim sistemi, yığın yığını, program çalışırken JVM tarafından yönetilmek üzere önceden tahsis eder. Bu birkaç önemli etkiye sahiptir:
1)Nesne oluşturma daha hızlıdır, çünkü her bir nesne için işletim sistemi ile küresel senkronizasyon gerekli değildir. Bir tahsis basitçe bir bellek dizisinin bir kısmını talep eder ve ofset işaretçisini ileriye taşır. Bir sonraki tahsisat bu ofsette başlar ve dizinin sonraki bölümünü talep eder.
2)Bir nesne artık kullanılmadığında, çöp toplayıcı altta yatan belleği geri alır ve onu gelecek nesne ayırma için yeniden kullanır. Bu, açık bir silinme olmadığı ve işletim sistemine geri verilen hiçbir bellek olmadığı anlamına gelir.
Tüm nesneler JVM tarafından yönetilen yığın alanında tahsis edilir. Geliştiricinin kullandığı her öğe, sınıf nesneleri, statik değişkenler ve hatta kodun kendisi de dahil olmak üzere bu şekilde değerlendirilir. Bir nesne atıfta bulunduğu sürece JVM canlı olarak değerlendirir. Bir nesne artık atıfta bulunulmadığı ve bu nedenle uygulama kodu tarafından erişilemediğinde, çöp toplayıcı onu kaldırır ve kullanılmayan belgeyi geri alır. Bu kadar basit, bir soru ortaya çıkarıyor: Ağacın ilk referansı nedir?
.
.
Burdan sonrasını anlamak için biraz java bilmek gerekiyor. (Şahsen bilmiyorum :)) Yazı yabancı bir siteden alıntıdır. Çeviri ve düzenleme bana ait. (Google amcayada teşekkür etmek lazım.)[DOUBLEPOST=1494176486,1494176144][/DOUBLEPOST]Özet geçmek gerekirse anladığım kadarıyla gc yani garbage collector birçok bellek yönetim sorunu yani RAM ile ilgili sorunu çözerken aslında daha çok performans kaybına yol açıyor. Yanlışım varsa düzeltin.