Bellek sızıntılarını düzeltmek ne kadar önemlidir?

Valgring tarafından bazı GTK + programlarının bellek sızdırdığını buldum. Bu sızıntıları düzeltmek ne kadar önemli? Yani, genellikle bu programlar çok iyi çalışır, ancak diğer yandan, sızdıran kodun bir kısmını başka bir programa kopyalamak isteyip istemediğinden emin olamazsınız. Ve GTK + programlarının fikrinin hızlı çalışıp çalışmadığından emin değilim ve bu nedenle sızıntılar var.

Bu yüzden bazen açık kaynaklı bir programda bellek sızıntısı bulursam, düzeltmeli miyim yoksa örneğin verimlilik sorunları var mı?

Bellek sızıntılarını düzeltmenin ne kadar önemli olduğu, sorunun ciddiyetine ve bunun için başka ne yapmanız gerektiğine bağlıdır. Deneyimlerim, küçük bellek sızıntılarının çoğu uygulama için oldukça iyi olma eğiliminde olduğudur. Bir masaüstü uygulaması oturumunun ömrü genellikle küçük bir bellek sızıntısından kaynaklanan herhangi bir bozulmayı görecek kadar uzun değildir.

7/24 çalışan bir sunucu yazıyorsanız, küçük bellek sızıntıları zamanla toplanabilir ve büyük bir sorun haline gelebilir. Ancak bu nedenle birçok şirket sunucularını günlük veya haftalık olarak yeniden başlayacak şekilde zamanlar. Bellek sızıntılarını bulma çabası genellikle kazanılabilecek şeylere göre aşırıdır, bu nedenle sunucuları düzenli olarak yeniden başlatmak ve daha önemli şeylere geçmek daha kolaydır.

Kısa süren programlar için bellek sızıntıları o kadar önemli değildir; İşletim Sistemi fesih durumunda her şeyi geri alacaktır, ancak başka kaynakların serbest bırakılmamasına neden olabilir.

Kısa çalışma göreceli olsa da, bir sızıntı birkaç saat içinde kontrolden çıkabilir veya fark edilmeden haftalarca birikebilir.

Tavsiyem, izleyicide önerilen bir düzeltmeyle ilgili bir hata bildirmektir, eğer müşteri onu düzelteceğini umursa.

Sızıntı türü de önemlidir. Sızan tahsisin, geliştiricinin temizleme için işletim sistemine kasıtlı olarak güvendiği bir kerelik bir tahsis olması mümkündür. Bunlar valgrind'de yanlış bir pozitif verecektir.

Bu konuda itirafla dogmatik düşünceme göre, en azından yaygın olarak uygulanabilir olmayı amaçlayan herhangi bir kütüphanede fiziksel sızıntı için mazeret yoktur. Bu yüzden, GTK + geliştiricilerini kendileri düzeltene kadar bozmaya çalıştım.

Bir kütüphanenin, atexiten azından boşaltıldığında tahsis ettiği belleği boşaltması için geri çağrıları kaydetmesi yeterince önemsizdir . Eğer ufak ufacık tahsisatın bir yükünün masrafından kaçınmak istiyorsa, onları ilk etapta yapmamalıdır.

Bir kerede ufacık hafıza yığınlarını bir kerede tahsis etmek isteyen en tembel program bile, kapanıştaki tüm belleği temizleyen basit bir sıralı ayırıcı kullanabilir. Eğer ayırıcı hizalama ile uğraşmak istemiyorsa, sadece topladığı her parçayı maksimum hizalama sınırlarına kadar doldurabilir. Tüm bu ufacık bellek parçalarını ayrı ayrı serbest bırakmadan daha hızlı kapanma sürelerinden faydalanabiliyorsa, hafızayı düz sıralı bir şekilde havuzlayan böyle sıralı bir ayırıcı kullanarak önemsiz çaba karşılığında simetrik olarak büyük bir fayda sağlamak anlamına gelir. daha hızlı tahsislermallocve daha fazla önbellek dostu bellek desenleri, sadece kütüphane tamamlandığında ayırıcı tarafından birleştirilen tüm büyük bellek bloklarının serbest bırakılması. Tüm kitaplığın yapması gereken, mallocuğraşmadıkları çağrılarını freebenzer bir şeyle değiştirmektir seq_mallocve boşaltıldığında ayrılan tüm belleği boşaltmak için seq_purgebir atexitgeri çağrıyı çağırır .

Aksi takdirde, şimdi filtrelemek zorunda bellek sızıntısı algılama araçları mesajlar dağınıklık bu kötü kütüphane var. Daha da kötüsü, sistematik olarak filtrelemezseniz, kendi uygulamanızdaki sızıntıları gizleyebilirler ve meslektaşlarınız onları gözden geçirme alışkanlığını geliştirebilir, kaçak tespit araçlarının ilk olarak kendi takımınızın sızdıran kod. Bu iğrenç ve çirkin ve en önemlisi yukarıdaki çözümü kullanmanın ne kadar önemsiz olduğu göz önüne alındığında, bunu kasıtlı olarak zorlayıcı yapmak için lehte argümanlar bulamıyorum.

Mantıksal sızıntılar (çöp toplamanın bile koruyamayacağı daha karmaşık bir tür) daha karmaşık bir konudur ve orada, kısa ömürlü programların, tahsis ettikleri tüm belleği temizledikleri sürece mantıksal sızıntılara sahip oldukları için bazı gerekçeler bulabilirim. mantıksal sızıntıları önlemek için kaynak yönetimi hakkında büyük bir düşünce gerektirdiğinden (muhtemelen GC olan dillerde daha fazla). Ancak en tembel bağlamlarda bile kaçınmanın ne kadar önemsiz olduğu göz önüne alındığında, fiziksel sızıntılardan kaçınmak için makul bir bahane bulamıyorum.

Her neyse, en azından valgrind'deki sızıntıları filtreledim, böylece en azından ekibinizin kendi tespit etme yeteneğinizle uğraşmamaları.

FWIW, bir kullanıcı üzerinde çalıştığım bir uygulamada bir sızıntı bildirdiğinde, düzeltmeye çok eğilimli olurum (özellikle hata raporundaki düzeltmenin kodunu dahil ettiyse!). Bununla birlikte, sızıntının küçük olması ve diğer sorunların daha acil olması durumunda hemen gerçekleşmeyebilir (örneğin, sık sık meydana gelen çökme hatası). Ama kesinlikle takdir ediyorum ve sonunda düzeltmek için çalışacağım. Kesinlikle onlara bildirmelisin. Ya takdir edecekler ve düzeltmek için çalışacaklar (büyük olasılıkla), ya da umursamayacaklar ve size maliyeti olacak bir süre.