Sorunun tarihi
Bu konu, Python'ın saf referans sayımından Python 2.0'da tanıtılan hibrit çöp toplama modeline evriminden kaynaklanmaktadır. Temel sorun, geliştiricilerin dosya tanıtıcıları veya ağ soketleri gibi harici kaynakları yönetmek için sonlandırıcı yöntemleri (__del__) kullanmasıyla ortaya çıkmıştır. Sonlandırıcı olan nesnelerin döngüsel referanslar oluşturması durumunda, Python güvenli bir yok etme sırasını belirleyememekte ve bu da çökmesine veya kaynak sızıntılarına yol açabilmektedir. Bu sınırlama, döngüsel çöp toplayıcı modülünün (gc) uygulanmasına ve "toplanamaz" çöpün özel işlenmesine yol açtı.
Sorun
Bir grup nesne bir referans döngüsü oluşturduğunda ve en az bir tanesi özel bir __del__ yöntemi tanımladığında, Python belirleyici bir yok etme ikilemiyle karşılaşır. Yorumlayıcı hangi nesneyi önce sonlandıracağını karar veremez çünkü döngü karşılıklı bağımlılığı ifade eder ve birini yok etmek diğerlerini geçersiz bir duruma getirebilir. Sonuç olarak, Python bu nesneleri belleklerini serbest bırakmak yerine gc.garbage listesine taşır. Bu davranış, sonlandırıcılar güvenli toplanmayı engellediğinde modern sürümlerde de devam eder ve uzun süreli uygulamalarda yavaş yavaş bellek sızıntılarına yol açar.
Çözüm
Kesin çözüm, kaynak temizliği için tamamen __del__ yöntemlerinden kaçınmak ve bağlam yöneticileri (with ifadeleri) veya weakref geri çağırmaları kullanmaktır. Eğer sonlandırıcılar kaçınılmazsa, nesneler ulaşılamaz hale gelmeden önce referans döngülerini açıkça kırmak için temizleme yöntemlerinde örnek değişkenlerini None olarak ayarlamak gereklidir. Python 3.4 ile birlikte, çöp toplayıcı birçok durumda sonlandırıcılarla döngüleri toplayabilir ve sonlandırmayı dikkatli bir şekilde sıralayabilir, ancak açık kaynak yönetimi en güvenilir desen olmaya devam eder.
import gc class Resource: def __init__(self, name): self.name = name self.peer = None def __del__(self): print(f"Temizleniyor {self.name}") # Sonlandırıcılar ile bir döngü oluşturma a = Resource("A") b = Resource("B") a.peer = b b.peer = a # Harici referansları kaldırma del a, b gc.collect() print(f"Toplanamaz: {gc.garbage}") # Karmaşık senaryolar içerebilir
Yüksek hacimli veri işleme hattı üzerinde çalıştık, burada Node nesneleri bir grafikte hesaplama adımlarını temsil ediyordu. Her düğüm, komşularına referanslar tutuyordu ve GPU bellek tutucularını serbest bırakmak için bir __del__ yöntemini barındırıyordu. Yoğun işler sırasında, profil oluşturmasında belirgin bir bellek sızıntısı olmamasına rağmen, monolitik bellek büyümesini gözlemledik. Araştırma, karmaşık grafik topolojilerinin düğümler arasında referans döngüleri oluşturduğunu ve __del__ yöntemlerinin döngüsel GC'nin bu nesneleri yeniden almasını engellediğini ortaya çıkardı, bu da onların gc.garbage içinde birikmesine neden oldu ve süreç sona erene kadar devam etti.
Çözüm 1: Bağlam yöneticilerine yeniden yapılandırma
__del__'yi açıkça acquire() ve release() yöntemleri ile bağlam yöneticileri aracılığıyla değiştirmeyi düşündük. Bu yaklaşım, çöp toplama için sonlandırıcı engelini tamamen ortadan kaldırır ve belirleyici kaynak temizliği sağlar. Ancak, bu, binlerce satırlık grafik inşa kodunun değiştirilmesini gerektirdi ve geliştiricilerin düğüm kullanımını with blokları ile sarmayı unutmaları durumunda kaynak sızıntıları riski taşıyordu, özellikle de eski geri çağrmalı bileşenlerde.
Çözüm 2: Grafik kenarları için zayıf referanslar uygulaması
Tüm komşu referanslarını weakref.ref nesneleri olarak değiştirmeyi araştırdık, bu da düğümlerin, grafik bağlantılılığına bakılmaksızın, harici referans kalmadığında hemen toplanmasını sağlar. Ancak, bu karmaşık bir yapı sunarak, grafik geçiş algoritmalarının sürekli olarak ölü zayıf referansları kontrol etmesi ve yinelemeler sırasında geçici "hayalet" düğümleri yönetmesi gerektiğinden önemli bir karmaşıklık getirdi. Bu yaklaşım, kullanım senaryomuz için performansı önemli ölçüde düşürdü ve grafik geçiş mantığının kapsamlı bir şekilde yeniden yapılandırılmasını gerektirdi.
Çözüm 3: Temizleme protokolü aracılığıyla açık döngü kırma
Düğümleri grafikten kaldırmadan önce self.neighbors = [] ve self.gpu_handle = None değerlerini açıkça ayarlayan bir destroy() metodu uyguladık. Bu, mevcut API yüzeyini korurken döngüleri belirleyici bir şekilde kırdı. Bu çözümü seçtik çünkü değişiklikleri düğüm kaldırma mantığına lokalize ederken, endişeleri tüm kod tabanında yaymayı önledi ve mevcut grafik algoritmaları ile geriye dönük uyumluluğu korudu.
Sonuç
Açık temizleme protokolünü uyguladıktan ve gc.garbage'ın CI testleri sırasında boş kaldığını doğrulamak için kesinlikler ekledikten sonra, bellek kullanımı sabit bir temel seviyede stabil hale geldi. Hizmet, önceki yavaş bellek birikimi olmadan haftalarca çalıştı. Ayrıca, geliştirme ekiplerinin sonlandırıcılar ile döngüsel referanslar arasındaki etkileşimi anlamalarını sağlamak için bu deseni belgelerle kaydettik.
Python 3.4+’te gc.garbage hala nesneleri içeriyorsa bu neden kaynaklanıyor?
Python 3.4, döngüsel GC'yi sonlandırıcıları güvenli bir sırayla çağırarak ve referansları temizleyerek işlemek için önemli ölçüde geliştirmiştir. Ancak, belirli koşullarda nesneler hala gc.garbage içinde gözükebilir. Eğer bir __del__ yöntemi, nesneyi global bir değişkende saklayarak diriltiyorsa, GC döngüyü güvenli bir şekilde toplayamaz ve sürekli döngüleri önlemek için onu gc.garbage'ya taşır. Ayrıca, döngüsel GC protokolünü doğru bir şekilde desteklemeyen özel tp_dealloc slotlarına sahip C genişletme nesneleri, yerel kodda çöküşleri önlemek için toplanamaz olarak değerlendirilir.
Zayıf referans weakref.ref ile geri çağırma döngüsel çöp toplayıcıyla nasıl etkileşimde bulunuyor?
Adaylar, bir nesne ulaşılmaz hale geldiğinde zayıf referans geri çağırmalarının hemen tetiklendiğini yanlış varsayıyor. Gerçekte, geri çağırma nesne gerçekten yok edildiğinde ve belleği serbest bırakıldığında tetiklenir. Eğer bir nesne, GC'nin kıramadığı sonlandırıcıların bulunduğu bir referans döngüsüne katılıyorsa, nesne gc.garbage içinde saklanır ve zayıf referans geri çağırması asla yürütülmez. Bu ayrım, kaynak temizleme sistemlerini zayıf referans geri çağırmalarına dayanan nesne yok etme bildirimleri tasarlarken çok önemlidir.
__del__ yöntemlerinde "dirilme" sorunu nedir ve bu, döngüsel referansların çöp toplamasını nasıl engeller?
Dirilme, bir sonlandırıcı yönteminin ölen örneği bir global değişkene atadığı veya onu kalıcı bir konteynere ekleyerek, GC tarafından yok edilmesi için işaretlendiğinden etkili bir şekilde canlandırdığı durumu ifade eder. Bir döngüsel referans senaryosunda, eğer bir nesnenin __del__'si döngüdeki herhangi bir nesneyi diriltirse, tüm döngü tekrar ulaşılabilir hale gelir. Python'ın çöp toplayıcısı bu anomaliyi tespit eder ve sonsuz yok etme ve dirilme döngüsünü çözmeye çalışmak yerine tüm döngüyü gc.garbage'ye taşır, bellek işlem sonlanana kadar geri alınamaz halde kalır.