DataSet ve DataTable'ı Atmalı mıyım?

DataSet ve DataTable her ikisi de IDisposable uygular, bu nedenle, geleneksel en iyi uygulamalarla, onların Dispose () yöntemlerini çağırmalıyım.

Ancak, şimdiye kadar okuduğum kadarıyla, DataSet ve DataTable'ın aslında yönetilmeyen kaynakları yok, bu yüzden Dispose () aslında fazla bir şey yapmıyor.

Ayrıca, using(DataSet myDataSet...)DataSet'in DataTable koleksiyonu olduğu için kullanamıyorum .

Bu nedenle, güvenli olmak için, myDataSet.Table'ları yinelemem, DataTable'ların her birini atmam ve DataSet'i atmam gerekir.

Peki, tüm DataSets ve DataTable'larımda Dispose () öğesini çağırmanın zahmetine değer mi?

Zeyilname:

DataSet'in imha edilmesi gerektiğini düşünenler için: Genel olarak, imha etme deseni kullanmaktır usingveya try..finallyDispose () işlevinin çağrılmasını garanti etmek istediğiniz için.

Ancak, bu bir koleksiyon için çirkin gerçek hızlı olur. Örneğin, Dispose () çağrılarından biri bir istisna atarsa ​​ne yaparsınız? Bir sonraki elemanı atmaya devam edebilmeniz için onu yutuyor musunuz ("kötü")?

Veya, ben sadece myDataSet.Dispose () çağırmak ve myDataSet.Tables DataTableları atmayı unutmak öneririz?

Bir Veri Kümesi için neden Dispose'in gerekli olmadığını açıklayan birkaç tartışma.

Atmak mı, Atmamak mı? :

DataSet'teki Dispose yöntemi SADECE kalıtımın yan etkisi nedeniyle vardır - başka bir deyişle, sonlandırmada gerçekten yararlı bir şey yapmaz.

Dispose DataTable ve DataSet nesnelerinde çağrılmalı mıdır? MVP'den bazı açıklamalar içerir:

System.data ad alanı (ADONET) yönetilmeyen kaynaklar içermiyor. Bu nedenle, kendinize özel bir şey eklemediğiniz sürece bunlardan herhangi birini atmanıza gerek yoktur.

Dispose yöntemini ve veri kümelerini anlama? Scott Allen yetkilisinden bir yorumu var:

Pratikte, çok az fayda sağladığı için nadiren bir DataSet Kullanıyoruz "

Yani, fikir birliği şu anda bir DataSet üzerinde Dispose çağırmak için iyi bir neden yoktur.

Güncelleme (1 Aralık 2009):

Bu cevabı değiştirmek ve orijinal cevabın kusurlu olduğunu kabul etmek istiyorum.

Orijinal analiz , kesinleştirme gerektiren nesneler için geçerlidir ve doğru, derinlemesine bir anlayış olmadan uygulamaların yüzeyde kabul edilmemesi gerektiği nokta hala geçerlidir.

Ancak, DataSets, DataViews, DataTables'ın yapıcılarındaki sonlandırmayı bastırdığı ortaya çıkıyor - bu yüzden onlara Dispose () çağrılması açıkça hiçbir şey yapmıyor.

Muhtemelen bu, yönetilmeyen kaynaklara sahip olmadıkları için olur; bu nedenle MarshalByValueComponent'in yönetilmeyen kaynaklara izin vermesine rağmen , bu özel uygulamalara ihtiyaç yoktur ve bu nedenle sonlandırmayı bırakabilir.

(.NET yazarlarının normalde en fazla belleği işgal eden türlerde sonlandırmayı bastırmaya özen göstermeleri, bu uygulamanın genel olarak sonlandırılabilir türler için önemini ifade eder.)

Buna rağmen, .NET Framework'ün (neredeyse 8 yıl önce) başlaması oldukça şaşırtıcı olduğundan (parçaları birleştirmek için çelişkili, belirsiz bir malzemeyi elemek için esas olarak kendi cihazlarınıza bırakıldığınız için) bu ayrıntıların hala belgelenmediği zaman zaman sinir bozucu olmakla birlikte, her gün güvendiğimiz çerçevenin daha kapsamlı bir şekilde anlaşılmasını sağlar).

Çok fazla okumadan sonra, benim anlayışım:

Bir nesne tamamlanmasına gerektiriyorsa, o olabilir o ihtiyacı daha uzun bellek işgal - İşte sebebi: tanımlar bir yoketme) finalizable kabul edilir bir türünden bir yıkıcı tanımlar (veya devralır a) Her tür; b) Tahsis edildiğinde (kurucu çalışmadan önce), Sonlandırma kuyruğuna bir işaretçi yerleştirilir; c) Sonlandırılabilir bir nesne normalde 2 koleksiyonun geri kazanılmasını gerektirir (standart 1 yerine); d) Sonlandırmanın bastırılması, sonlandırma kuyruğundan bir nesneyi kaldırmaz (SOS'ta! FinalizeQueue tarafından bildirildiği gibi) Bu komut yanıltıcıdır; Sonlandırma kuyruğunda (kendi içinde) hangi nesnelerin olduğunu bilmek yardımcı olmaz; Sonlandırma kuyruğunda hangi nesnelerin bulunduğunu ve hala sonlandırma gerektirdiğini bilmek yardımcı olacaktır (bunun için bir komut var mı?)

Sonlandırmanın bastırılması, nesnenin başlığında, çalışma zamanına, Sonlandırıcının çağrılması gerekmediğini (Kırılabilir kuyruğu taşımasına gerek olmadığını) gösteren biraz kapanır; Sonuçlandırma kuyruğunda kalır (ve SOS'taki FinalizeQueue tarafından rapor edilmeye devam eder)

DataTable, DataSet, DataView sınıflarının tümü, yönetilemeyen kaynakları (potansiyel olarak) işleyebilen sonlandırılabilir bir nesne olan MarshalByValueComponent'e dayanır.

• DataTable, DataSet, DataView yönetilmeyen kaynaklar sunmadığından, kurucularında sonlandırmayı bastırırlar
• Bu alışılmadık bir desen olsa da, arayanı kullanımdan sonra imha etme konusunda endişelenmek zorunda kalmaz
• Bu ve DataTable'ların potansiyel olarak farklı DataSets arasında paylaşılabilmesi gerçeği, DataSets'in alt DataTable'ları atmayı umursamamasıdır.
• Bu aynı zamanda bu nesnelerin SOS'taki! FinalizeQueue altında görüneceği anlamına gelir
• Bununla birlikte, bu nesneler, tamamlanamayan benzerleri gibi, tek bir koleksiyondan sonra yine de geri kazanılabilir olmalıdır

4 (yeni referanslar):

• http://www.devnewsgroups.net/dotnetframework/t19821-finalize-queue-windbg-sos.aspx
• http://blogs.msdn.com/tom/archive/2008/04/28/asp-net-tips-looking-at-the-finalization-queue.aspx
• http://issuu.com/arifaat/docs/asp_net_3.5unleashed
• http://msdn.microsoft.com/en-us/magazine/bb985013.aspx
• http://blogs.msdn.com/tess/archive/2006/03/27/561715.aspx

Orijinal Yanıt:

Bu konuda birçok yanıltıcı ve genellikle çok kötü cevaplar var - buraya inen herkes gürültüyü görmezden gelmeli ve aşağıdaki referansları dikkatlice okumalıdır.

Hiç şüphesiz, imha edilmelidir herhangi finalizable nesneler çağırdı.

DataTable vardır finalizable.

Dispose çağrılması belleğin geri kazanımını önemli ölçüde hızlandırır.

MarshalByValueComponent , Dispose ( ) içinde GC.SuppressFinalize (this) öğesini çağırır - bu atlama, bellek geri kazanılmadan önce yüzlerce Gen0 koleksiyonu değilse düzinelerce beklemek zorunda kalır:

Bu temel sonuçlandırma anlayışıyla, çok önemli bazı şeyleri zaten çıkarabiliriz:

İlk olarak, sonlandırılması gereken nesneler yapmayan nesnelerden daha uzun yaşar. Aslında, çok daha uzun yaşayabilirler. Örneğin, gen2'deki bir nesnenin sonlandırılması gerektiğini varsayalım. Sonlandırma zamanlanacaktır ancak nesne hala gen2'de olduğundan, bir sonraki gen2 toplama gerçekleşinceye kadar yeniden toplanmayacaktır. Bu gerçekten çok uzun bir zaman olabilir ve aslında işler yolunda giderse uzun zaman alacaktır, çünkü gen2 koleksiyonları maliyetlidir ve bu nedenle bunların çok seyrek olmasını istiyoruz. Sonlandırılması gereken daha eski nesneler, alanları geri kazanılmadan önce yüzlerce gen0 koleksiyonu olmasa bile düzinelerce beklemek zorunda kalabilir.

İkincisi, sonlandırılması gereken nesneler teminat hasarına neden olur. Dahili nesne işaretçileri geçerli kalması gerektiğinden, yalnızca doğrudan sonlandırma gerektiren nesneler bellekte kalmayacak, aynı zamanda doğrudan ve dolaylı olarak nesnenin referans verdiği her şey de bellekte kalacaktır. Eğer sonlandırma gerektiren tek bir nesne tarafından devasa bir nesne ağacı tutturulmuş olsaydı, o zaman tartıştığımız gibi potansiyel olarak uzun süre tüm ağaç oyalanacaktı. Bu nedenle sonlandırıcıları az miktarda kullanmak ve mümkün olduğunca az dahili nesne işaretçisi olan nesnelere yerleştirmek önemlidir. Az önce verdiğim ağaç örneğinde, sonlandırma ihtiyacı olan kaynakları ayrı bir nesneye taşıyarak ve ağacın kökündeki o nesneye referans tutarak sorunu kolayca önleyebilirsiniz.

Son olarak, sonlandırma gerektiren nesneler sonlandırıcı iş parçacığı için iş oluşturur. Sonlandırma işleminiz karmaşık bir işlemse, tek ve sonlandırıcı iş parçacığı bu adımları gerçekleştirmek için çok zaman harcayacaktır, bu da bir iş birikmesine neden olabilir ve bu nedenle daha fazla nesnenin sonlandırmayı beklemeye devam etmesine neden olur. Bu nedenle, sonuçlandırıcıların mümkün olduğunca az iş yapması hayati önem taşımaktadır. Ayrıca, tüm nesne işaretçileri sonlandırma sırasında geçerli kalmasına rağmen, bu işaretçilerin zaten sonlandırılmış olan nesnelere yol açmış olabileceğini ve bu nedenle yararlı olmadıklarını unutmayın. İşaretçiler geçerli olsa bile, sonlandırma kodunda nesne işaretçileri izlemekten kaçınmak genellikle en güvenlidir. Güvenli, kısa bir sonlandırma kodu yolu en iyisidir.

Gen2'de 100'lerce MB referans edilmemiş DataTables gören birinden alın: Bu çok önemlidir ve bu konudaki cevaplar tarafından tamamen kaçırılmıştır.

Referanslar:

1 - http://msdn.microsoft.com/tr-tr/library/ms973837.aspx

2 - http://vineetgupta.spaces.live.com/blog/cns!8DE4BDC896BEE1AD!1104.entry http://www.dotnetfunda.com/articles/article524-net-best-practice-no-2-improve-garbage -collector performanslı-finalizedispose-pattern.aspx kullanılarak

3 - http://codeidol.com/csharp/net-framework/Inside-the-CLR/Automatic-Memory-Management/

Yararlı bir şey yaptığını varsaymalı ve mevcut hiçbir şey yapmasa bile Dispose olarak adlandırmalısınız. NET Framework enkarnasyonları, verimsiz kaynak kullanımına yol açan gelecekteki sürümlerde bu şekilde kalacağının garantisi yoktur.

Nesnenin yönetilmeyen kaynakları olmasa bile, imha, nesne grafiklerini kırarak GC'ye yardımcı olabilir. Genel olarak, nesne IDisposable uygularsa Dispose () çağrılmalıdır.

Dispose () öğesinin gerçekte bir şey yapıp yapmayacağı verilen sınıfa bağlıdır. DataSet durumunda, Dispose () uygulaması MarshalByValueComponent öğesinden devralınır. Kendini konteynerden kaldırır ve Disposed olayını çağırır. Kaynak kodu aşağıdadır (.NET Reflector ile sökülmüştür):

protected virtual void Dispose(bool disposing)
{
    if (disposing)
    {
        lock (this)
        {
            if ((this.site != null) && (this.site.Container != null))
            {
                this.site.Container.Remove(this);
            }
            if (this.events != null)
            {
                EventHandler handler = (EventHandler) this.events[EventDisposed];
                if (handler != null)
                {
                    handler(this, EventArgs.Empty);
                }
            }
        }
    }
}

DataTable'ları kendiniz mi oluşturuyorsunuz? Çünkü herhangi bir Nesnenin alt öğeleri üzerinden yineleme yapmak (DataSet.Table'larda olduğu gibi) genellikle gerekli değildir, çünkü tüm alt üyeleri atmak Ebeveynin görevidir.

Genel olarak kural şudur: Oluşturduysanız ve IDisposable uygularsa, atın. Eğer yaratmadıysanız, ATMAYIN, üst nesnenin işi budur. Ancak her nesnenin özel kuralları olabilir, Belgeleri kontrol edin.

Net 3.5 için, açıkça "Artık kullanmadığınızda imha et" yazıyor, ben de öyle yapardım.

Bir nesne IDisposeable uyguladığı zaman dispose diyorum. Orada bir sebep var.

Veri Kümeleri büyük bellek domuzları olabilir. Temizlik için ne kadar erken işaretlenirse o kadar iyidir.

Güncelleme

Bu soruyu cevaplamamın üzerinden 5 yıl geçti. Cevabımı hala kabul ediyorum. Bir atma yöntemi varsa, nesne ile işiniz bittiğinde çağrılmalıdır. IDispose arabirimi bir nedenle uygulanmıştır.

Niyetiniz veya bu sorunun içeriği gerçekten çöp toplama ise, veri kümelerini ve veri tablolarını açıkça null olarak ayarlayabilir veya anahtar kelimeyi kullanarak kullanabilir ve kapsam dışına çıkabilirsiniz. Tetraneutron'un daha önce söylediği gibi imha çok işe yaramaz. GC, artık referans verilmeyen veri kümesi nesnelerini ve kapsam dışı olanları da toplar.

Gerçekten SO'yu oy kullanma zorunluluğunu, cevabı indirmeden önce bir yorum yazmaya zorlamak istiyorum.

Veri kümeleri, IDisposable'ı uygulayan IDisposable eksiksiz MarshalByValueComponent uygular. Veri kümeleri yönetildiğinden, imha etme çağrısının gerçek bir yararı yoktur.

Clear () işlevini kullanmayı deneyin. Bertaraf etmek benim için harika çalışıyor.

DataTable dt = GetDataSchema();
//populate dt, do whatever...
dt.Clear();

DataSet, MarshalByValueComponent sınıfını ve MarshalByValueComponent IDisposable Arabirimini uyguladığı için Dispose () yöntemine gerek yoktur