Finalizer'lar, özellikle C kütüphanelerine cgo aracılığıyla köprü kurarken dış kaynakları serbest bırakma için güvenlik ağı sunmak amacıyla Go'nun erken sürümlerinde tanıtılmıştır. Java'daki benzer mekanizmalardan esinlenerek, runtime.SetFinalizer, bir nesneye eklenen ve çöp toplayıcı bir referans olmadığını belirlendiğinde çalışan bir işlevdir. Ancak, Go ekibi, zamanlama belirsizliği ve çöp toplayıcının aşamalarıyla karmaşık etkileşimler nedeniyle kullanımlarını ısrarla discourage etmiştir.
Finalizer, yalnızca çöp toplayıcı bir nesneyi erişilemez olarak işaretlediğinde özel bir goroutine içinde asenkron olarak çalışır ve bu, kaynakların gerekli olandan daha uzun süre tahsis edileceği bir pencere oluşturur. Kritik bir sorun, bir finalizer'ın nesnesini global bir değişkende veya yaşayan bir nesnede referans tutarak tekrar erişilebilir hale getirmesidir. Sonsuz finalizasyon döngülerini ve kaynak tüketimini önlemek için çalışma zamanı, finalizer'ın zaten çalıştığını izlemeli ve herhangi bir sonraki finalizasyonun gerçekleşebilmesi için zorunlu bir "soğuma" süresi uygulamalıdır.
Go, nihai çöp toplama döngüsünden sonra finalizer'ın tam olarak bir kez çalışmasını garanti eder; bu koşul programın erken kapanmaması durumudur. Yeniden dirilme durumunda, çalışma zamanı internel süpürme tamponundan finalizer ilişkilendirmesini kaldırır, bu nedenle yeniden kaydetmek için runtime.SetFinalizer'a açık bir yeni çağrı gereklidir. Bu tasarım, yeniden diriltilmiş nesnelerin, bir sonraki finalizer'ın zamanlanabilmesi için gerçekten erişilemez olduklarını kanıtlamak amacıyla en az bir ek tam GC döngüsünden hayatta kalmalarını sağlayarak güvence altına alır.
type Resource struct { ptr unsafe.Pointer // C bellek } func NewResource() *Resource { r := &Resource{ptr: C.malloc(1024)} // Finalizer, r erişilemez hale geldiğinde çalışır runtime.SetFinalizer(r, (*Resource).Finalize) return r } func (r *Resource) Finalize() { C.free(r.ptr) // Eğer: global = r deseydik, r'yi yeniden diriltmiş oluruz // Finalizer artık ayrıldı; r'nin yeniden finalize edilmesi için bir GC döngüsüne ve yeni bir SetFinalizer çağrısına ihtiyaç vardır. }
Gerçek zamanlı bir analiz hattı oluştururken, ekibimiz cgo kullanarak donanım hızlandırmalı şifreleme için üçüncü taraf bir C kütüphanesini entegre etti ve C yığın belleğinde hassas anahtar tamponlarını tahsis ettik. Go sarmalayıcı yapılarında runtime.SetFinalizer'a güvenerek sarmalaycılar çöp toplandığında otomatik olarak C free() işlevini çağırdık. Sürekli yük testleri sırasında, Go kodunun, ilgili Go nesneleri hala istek işleyicilerinde aktif olmasına rağmen, serbest bırakılmış C belleğini erişmeye çalıştığı yerlerde kesik kesik segment hata bildirimleri gözlemledik.
Kök neden analizi, finalizer içinde çağrılan günlüğe alma çerçevemizin, hata bağlamı için Go sarmalayıcısının bir işaretçisini yakaladığını ve yanlışlıkla onu global bir halka tamponuna yeniden dirilttiğini ortaya çıkardı. Çünkü Go'nun finalizer'ı uygulama ile eşzamanlı çalıştığı için, nesne C belleği serbest bırakıldıktan sonra, ancak istek işleyicisi bunu kullanmayı bitirmeden yeniden dirildi. Bu yarış durumu, yeniden diriltilmiş nesnelerin sarkık C işaretçilerini bulundurmasıyla sonuçlanarak, yüksek eşzamanlılık altında hizmetin rastgele çökmesine yol açtı.
Açıkça Close() yöntemini io.Closer anlamları ile uygulamayı düşündük ve finalizer'ı sadece bir sızıntı tespiti güvenlik ağı olarak tutmayı planladık. Bu yaklaşım, belirleyici kaynak yönetimi sağlar ve Go en iyi uygulamalarına uygun olarak, istek tamamlandığında C belleğinin hemen serbest bırakılmasını sağlar. Ancak, hem Close() hem de finalizer eşzamanlı olarak çalıştığında çift serbest bırakma riski taşır ve geliştiricilerin Close() çağrısını unuttuğu durumlarda hala çökme yaşanabilir.
Bir başka seçenek, finalizer'ları uintptr adreslerini takip eden bir sync.Map ile özelleştirilmiş bir kayıt defteri ile değiştirmek oldu ve bu, çöp toplamayı engellemeden mevcut tahsisatları takip etmeyi sağladı. Bu yöntem, nesne yaşam döngüsü izlemesi üzerinde açık kontrol sağlar ve yeniden dirilme yan etkilerini tamamen ortadan kaldırır. Bununla birlikte, karmaşık manuel senkronizasyon gerektirir, harabe girişler için harita düzenli olarak taranmalı ve kayıt defteri titizlikle korunmadığı takdirde bellekte sızıntı riski taşır ve önemli bir operasyonel yük ekler.
Finalizer'ların, serbest bırakılan C belleğini serbest bırakmadan önce herhangi bir global önbellekte nesne işaretçisinin var olup olmadığını kontrol ederek yeniden dirilme tespiti yapmasını değerlendirdik, tespit edildiğinde panik vermesini sağladık. Bu yaklaşım, test sırasında hataları hemen açığa çıkarsa da, temel kaynak yönetimi problemini çözmemekte ve üretim kesintilerine yol açmaktadır. Ayrıca, nesne durumunu kontrol etmek için pahalı global kilitlere dayanmakta olup, yüksek performanslı hattımız için gereken verimliliği ciddi şekilde etkilemektedir.
Sonunda, finalizer'ları tamamen üretim kodundan kaldırdık ve tüm kod yollarında defer ifadeleri aracılığıyla zorunlu Close() çağrıları uyguladık. Son kullanım ile Close() çağrısı arasında erken GC'yi önlemek için, C belleği kullandığımız kritik bölümlerin ardından runtime.KeepAlive(obj) çağrılarını ekledik. Bu strateji, belirsiz davranışları ortadan kaldırdı, yeniden dirilme riskini azalttı ve Go'nun açık kaynak yönetim felsefesiyle uyumlu hale getirdi; ancak Close()'un her zaman erişilebilir olmasını sağlamak için kod tabanının önemli bölümlerinin yeniden yapılandırılmasını gerektirdi.
Göç sonrası, segmentasyon hataları tamamen ortadan kalktı ve GPU bellek kullanımı istek hacmi ile öngörülebilir ve doğrusal hale geldi. Bu nesneler üzerindeki Close() çağrılarını zorlamak için statik analiz linter'ları eklendi ve kaynak sızıntılarını derleme zamanında yakaladı. Sistem şu anda bellekle ilgili çöküş olmadan saniyede 100k+ isteği sürdürüyor, bu da açık yaşam döngüsü yönetiminin kritik görev Go hizmetlerinde finalizer tabanlı yaklaşımlardan daha iyi performans gösterdiğini kanıtlıyor.
Neden finalizasyonu devam eden bir nesne, finalizer'ı hala çalışırken GC tarafından geri alınabilir ve runtime.KeepAlive bunu nasıl önler?
Adaylar genellikle bir finalizer'ın hedef nesneyi finalizer tamamlanana kadar hayatta tuttuğunu varsayar. Gerçekte, bir nesnenin erişilemez olduğu belirlendiğinde, hemen geri alınabilir hale gelir ve finalizer ayrı bir goroutine içinde çalıştırılır; finalizer bitene kadar başka bir referans yoksa nesne geri alınabilir. Bunu önlemek için, nesnenin son kullanımı sonrası runtime.KeepAlive(obj) çağrısı yapılmalıdır ve bu da derleyici seviyesinde bir yaşam süresi uzantısı yaratarak, finalizer'ın çalışması boyunca C kaynaklarının veya diğer bağımlılıkların geçerli kalmasını sağlar.
Tek bir Go nesnesi üzerinden runtime.SetFinalizer'a ardışık çağrılar yoluyla birden fazla finalizer kaydedilebilir mi ve eğer finalizer işlevi nesneyi yakalayan bir kapama olursa ne olur?
Birçok aday, birden fazla finalizer'ın tek bir nesnede bir zincir veya kuyruk oluşturabileceğini yanlış bir şekilde düşünmektedir. Go, SetFinalizer çağrıldığında mevcut finalizer'ı açıkça geçersiz kılarak sadece en son işlev işaretçisini internel çalışma zamanı karma tablosunda saklar. Eğer finalizer bir kapama ise, nesneyi yakalamakta olup nesneyi daimi olarak erişilebilir kılar, finalizer'ın asla çalışmamasına ve yakalanan referansı bulunduğu kapama değişkenlerinden dosyaya gelmediğinden, bellek sızmalarına yol açar.
GC, A nesnesi B nesnesini referans alıyorsa ve ikisinin de finalizer'ları kaydedilmişse, finalizer'ların çalışma sırasını nasıl yönetir?
Adaylar genellikle çocukları-önce-ebeveyni veya LIFO yığın davranışından gelen belirleyici bir sıralama bekler. Go, belirleyici bir sıralama garantisi sağlamaz çünkü GC, erişilemez tüm nesneler için finalizer'ları paralel olarak birden fazla arka plan goroutine'i tarafından işlenecek bir global kuyrukta aynı anda sıraya alır. Eğer A'nın finalizer'i B'ye erişiyorsa ve B'nin finalizer'i zaten çalışmış ve kaynakları serbest bırakmışsa, A'nın finalizer'i bozulmuş bir durumu karşılayacak veya serbest bırakıldıktan sonra kullanmaya çalışarak hata alacaktır; bu nedenle finalizer'ların, diğer finalizer'ları olan nesnelere erişim sağlamaması veya tüm temizleme mantığının kök nesne için tek bir finalizer içinde merkezileşmesini gerektirdiğini unutmamak gerekir.