Python'un weakref modülü, weakref.proxy() fabrikası aracılığıyla proxy nesneleri oluşturur; bu, altındaki referansa güçlü bir referans tutmadan özellik erişimini ve yöntem çağrılarını ileten hafif bir sarmalayıcı döndürür. Dahili olarak, bu proxy'ler, hedefe işaret eden bir PyWeakReference işaretçisi içeren bir slot depolayan özel C yapılara (_ProxyType nesneler için, _CallableProxyType çağırılabilir nesneler için) olarak uygulanmıştır. Bir özellik erişildiğinde, proxy bu zayıf işaretçiyi dereferans eder; eğer nesne toplanmışsa, ReferenceError raise edilir. Ancak, proxy kendisi kendi türüne sahip olan ayrı bir nesne olduğundan, tam tür kimliği gerektiren işlemler -örneğin is karşılaştırmaları, id() çağrıları veya __copy__ ve __reduce_ex__ gibi dunder yöntemleri- ya proxy'ye özgü değerler döndürür ya da TypeError raise eder; çünkü C uygulaması, orijinal örneğin tam PyObject işaretçisini gerektiren düşük seviyeli tür denetimlerini karşılayamaz.
Gerçek zamanlı bir analiz platformu, yüksek frekanslı piyasa verilerini işlemek için pandas DataFrame'leri kullandı; her bir partition için birkaç gigabayt hafıza kaplıyordu. Uygulama, ticker sembollerinden hesaplanan teknik göstergelere kadar bir küresel önbellek tutuyordu, ancak önbellekteki güçlü referanslar, çöp toplayıcının düşük aktivite dönemlerinde hafızayı geri almasını engelledi. Bu, hizmetin mevcut RAM'i tüketmesine ve sistem genelinde swap fırtınalarına yol açtı.
Mühendislik ekibi, çöp toplayıcının hafızayı geri almasını sağlamak için ilk olarak weakref.ref nesnelerini kullanan bir önbellek uyguladı. Bu hafıza sızıntılarını önlese de, her tüketicinin referansı manuel olarak çağırmasını, None döndürme değerlerini kontrol etmesini ve eksik veriyi yeniden hesaplamak için yedek mantığınız uygulamasını gerektiriyordu. Bu, önemli miktarda kopyalama kodu ve varlık kontrolü ile gerçek veri kullanımı arasında potansiyel yarış koşulları oluşturdu.
Başka bir yaklaşım, zayıf referansı dahili olarak depolayan ve __getattr__ uygulayarak tüm özellik erişimlerini altındaki DataFrame'e ileten özel bir Python sarmalayıcı sınıfı oluşturmaktı. Bu, ham zayıf referanslardan daha temiz bir API sağladı, ancak her özellik erişiminde Python düzeyindeki yöntem çözümlemesi nedeniyle önemli bir performans yükü getirdi. Ayrıca, __getattr__ mekanizmasını tamamen atladıkları için __len__ veya __iter__ gibi özel yöntemleri desteklemekte başarısız olduk.
Ekip, sonunda, elle dereferanslama veya performans cezası olmadan altındaki DataFrame'lere şeffaf delegasyon sağlayan weakref.proxy nesnelerini önbellek değerleri olarak seçti. Bu seçim, çöp toplayıcının hafızayı otomatik olarak geri almasını sağlarken mevcut analiz kodlarına kesintisiz bir arayüz sundu. Ancak, kimlik kontrollerinin (is) ve serileştirme işlemlerinin proxy nesneleri ile başarısız olacağı veya beklenmedik şekilde davranacağına dair bir belgelemeyi gerektirdi.
Kullanım sonrası, platform, değişen yük desenleri altında sabit hafıza kullanımı sürdürdü ve saniyede milyonlarca olayı başarıyla işledi. Hafıza baskısı çöp toplamayı zorladığında, proxy'ler erişimde ReferenceError raise ederek, uygulamanın belirli göstergeleri talep üzerine yeniden hesaplama mantığını tetikledi ve hizmet kesintisi olmadan yeniden üretti. Performans ölçümleri, proxy'ler aracılığıyla özellik erişiminin doğrudan referanslara kıyasla ihmal edilebilir bir yük getirdiğini doğrulayarak mimari kararı onayladı.
Soru 1: Neden weakref.proxy, copy.deepcopy() ile geçirildiğinde TypeError raise eder ve bu davranış weakref.ref kullanmaktan nasıl farklıdır?
copy.deepcopy() bir proxy nesnesiyle karşılaştığında, nesneyi serileştirmek için __reduce_ex__ veya __getstate__ yöntemlerini çağırmaya çalışır, ancak proxy'ler zayıf referans sözleşmesini ihlal eden güçlü referansların oluşturulmasını önlemek için bu dunder yöntemleri açıkça engeller. weakref.ref ile, kopyalamadan önce nesneyi almak için referansı açıkça çağırırsınız, bu da gerçek örnekle çalışmanızı sağlar, şeffaf sarmalayıcı ile değil. Adaylar genellikle proxy'lerin tamamen şeffaf olduğunu varsayar, ancak tam C düzeyindeki tür kimliği gerektiren bazı düşük seviyeli protokol yöntemlerini proxy'lemediklerini gözden kaçırırlar; bu, serileştirme görevleri için weakref.ref aracılığıyla açık dereferanslama gerektirir.
Soru 2: Python'un döngüsel çöp toplayıcısı, referans döngülerini kırarken zayıf referanslarla nasıl etkileşir ve zayıf referans geri çağrısının anında mı yoksa ertelenerek mi çalıştırılacağını ne belirler?
Döngüsel GC, sonlandırıcılar (__del__) olmayan nesneleri içeren erişilemeyen bir döngüyü tespit ettiğinde, bu nesnelere olan zayıf referansları temizler ve toplama aşamasında geri çağrılarını hemen tetikler. Ancak, döngüdeki herhangi bir nesne __del__ yöntemi tanımlarasa, GC tüm döngüyü, tanımsız yok etme sıralamasını önlemek için gc.garbage listesine taşır ve hem nesne yok edilmesi hem de zayıf referans geri çağrılarının manuel müdahale olmadan ertelenmesine neden olur. Adaylar sıklıkla zayıf referans geri çağrılarının çöp toplayıcının bağlamında çalıştığını gözden kaçırır; bu durum, ek çöp toplama tetikleyebilecek veya yok edilen nesneleri yeniden oluşturacak işlemleri gerçekleştiremeyecekleri anlamına gelir.
Soru 3: Neden CPython'da int veya str örneklerine zayıf referanslar oluşturmak imkansızdır ve hangi bellek düzeni kısıtlaması bu türleri zayıf referansları destekleyecek şekilde genişletmeyi engeller?
CPython, her örneğin bellek üzerindeki yükünü azaltmak için zayıf referans slotunu C yapı tanımlarından çıkararak int ve str gibi değişmez yerleşik türleri optimize eder. Zayıf referanslar, bu örneğe işaret eden tüm zayıf referansları izlemek için nesne başlığında bir çift bağlı liste işaretçisi gerektirir; ancak küçük tam sayılar ve kısa dizeler genellikle içe alma ve önbellekleme mekanizmaları aracılığıyla yorumlayıcı genelinde paylaşılır. Zayıf referans desteği eklemek, her tam sayı veya dize nesnesini işaretçi içerecek şekilde birkaç bayt genişletmeyi gerektirecektir; bu, milyonlarca nesne kullanan programlar için bellek tüketimini önemli ölçüde artırır ve bu temel türler için bu tür bir takas kabul edilemez.