NET'te kullanımdan sonra boş / Nothing Nesneleri ayarlama

oy
173

Eğer tüm nesneleri belirlesin null( Nothingonlarla bitirdikten sonra VB.NET olarak)?

Ben .NET o uygulamak nesnelerin herhangi örneklerini imha esastır anlıyoruz IDisposableo (dolayısıyla tanzim edildikten sonra nesne hala bir şey olabilir rağmen bazı kaynaklar serbest bırakmak için arayüz isDisposedformlarda özelliği), bu yüzden hala bulunabilir varsayalım bellekte ya da en azından kısmen?

Ben de bir nesne kapsam dışına çıktığında (bu zaman alabilir rağmen) daha sonra çöp toplayıcının bir sonraki geçişte hazır koleksiyonu için işaretlenmiş olduğunu biliyoruz.

Bu düşünceyle ayarlayarak olacak Yani için nullo artık kapsamında olduğuna işaret çalışmak zorunda olmadığı için belleği serbest sistemini hızlandırmak ve herhangi bir kötü yan etkileri nelerdir?

MSDN makaleleri örneklerde bunu asla ve ben zarar göremiyorum olarak şu anda bunu yapmak. herhangi bir yorum yararlıdır böylece Ancak görüşlerin karışımı rastlamak var.

Oluştur 05/08/2008 saat 21:14
kaynak kullanıcı
Diğer dillerde...                            


15 cevaplar

oy
66

Karl kullanımdan sonra boş nesneleri ayarlamak için gerek yoktur, kesinlikle doğru. Bir nesne uygularsa IDisposable, sadece aramak emin olun IDisposable.Dispose()(a sarılmış o nesneyle bitince try.. finallybir veya using()blok). Aramak hatırlamıyorum bile Ama Dispose(), nesne üzerinde finaliser yöntemi çağırarak gerektiğini Dispose()sizin için.

Bunun iyi bir tedavi olduğunu düşünmüş:

IDisposal içine Kazı

ve bu

IDisposable anlama

Kendini ayarlama ve opak çünkü ikinci GC ve yönetim stratejilerini tahmin etmeye çalışarak bir anlamı yoktur. Burada Nokta Net on the Rocks Jeffrey Richter ile iç işleyişi hakkında iyi bir tartışma vardı: Jeffrey Richter Windows Bellek Modeli üzerinde ve Richters kitap C # yoluyla CLR bölüm 20 büyük tedavi vardır:

Cevap 05/08/2008 saat 21:56
kaynak kullanıcı

oy
33

Onları aslında uzun süre hayatta tutmak olmasıdır ile işiniz bittiğinde diğer nedeni boş nesneleri ayarı önlemek için.

Örneğin

void foo()
{
    var someType = new SomeType();
    someType.DoSomething();
    // someType is now eligible for garbage collection         

    // ... rest of method not using 'someType' ...
}

sometype tarafından yönlendirilen nesne "DoSomething" çağrısının ardından GC'd ancak sağlayacak

void foo()
{
    var someType = new SomeType();
    someType.DoSomething();
    // someType is NOT eligible for garbage collection yet
    // because that variable is used at the end of the method         

    // ... rest of method not using 'someType' ...
    someType = null;
}

bazen yöntemin sonuna kadar canlı nesneyi tutabilir. Tam zamanında genellikle null atama eniyilenmesini olacak , bu yüzden kodunun iki bit aynı olma sonunda.

Cevap 15/08/2008 saat 15:43
kaynak kullanıcı

oy
15

Hayır değil boş nesneler yapmak. Dışarı kontrol edebilirsiniz http://codebetter.com/blogs/karlseguin/archive/2008/04/27/foundations-of-programming-pt-7-back-to-basics-memory.aspx fazla bilgi için, ama şeyler ayarı null olarak kirli kodunuzda dışında hiçbir şey yapmaz.

Cevap 05/08/2008 saat 21:23
kaynak kullanıcı

oy
7

Genel olarak, kullanımdan sonra nesneleri null gerek yoktur, ancak bazı durumlarda bunun iyi bir uygulamadır bulabilirsiniz.

Bir nesne IDisposable uygulayan ve bir tarlada saklanıyorsa, ben, bunu boş olarak sadece bırakılmış nesneye kullanmaktan kaçının iyi olduğunu düşünüyorum. Aşağıdaki türden hatalar ağrılı olabilir:

this.myField.Dispose();
// ... at some later time
this.myField.DoSomething();

Bunu bertaraf sonra alanını boş ve tarla tekrar kullanılır çizgisinde bir NullPtrEx hakkını almak için iyidir. Aksi takdirde, (DoSomething ne yaptığını tam olarak bağlı olarak) satır aşağı bazı şifreli hata çalışabilir.

Cevap 09/08/2008 saat 12:16
kaynak kullanıcı

oy
7

Ayrıca:

using(SomeObject object = new SomeObject()) 
{
  // do stuff with the object
}
// the object will be disposed of
Cevap 05/08/2008 saat 21:37
kaynak kullanıcı

oy
6

Muhtemelen ihtiyacı hissediyorum eğer kod sıkıca yeterince yapılandırılmış olmadığını olan nulldeğişkenler.

Bir değişkenin kapsamını sınırlandırmak için çeşitli yolları vardır:

Tarafından belirtildiği gibi Steve Tranby

using(SomeObject object = new SomeObject()) 
{
  // do stuff with the object
}
// the object will be disposed of

Benzer şekilde, sadece süslü parantez kullanabilirsiniz:

{
    // Declare the variable and use it
    SomeObject object = new SomeObject()
}
// The variable is no longer available

Ben olmadan süslü parantez kullanılarak bulmak herhangi bir "başlığı" Gerçekten kodunu temizlemek ve onu daha anlaşılır hale getirmek için.

Cevap 09/08/2008 saat 13:13
kaynak kullanıcı

oy
5

Genel olarak gerek set null için. Ama sen sınıfında Sıfırlama özelliğe sahip varsayalım.

Eğer imhası bazı doğru bir şekilde uygulandığında olmayabilir çünkü iki kez elden ve System.ObjectDisposed istisna aramak istemiyorum çünkü O zaman, yapabilir.

private void Reset()
{
    if(_dataset != null)
    {
       _dataset.Dispose();
       _dataset = null;
    }
    //..More such member variables like oracle connection etc. _oraConnection
 }
Cevap 17/04/2012 saat 09:55
kaynak kullanıcı

oy
4

Değişken kapsamı dışına gitmez ve artık onunla ilişkili verileri gerektiğinde null bir değişken ayarlamak gereken tek zamandır. Aksi takdirde gerek yoktur.

Cevap 05/08/2008 saat 21:32
kaynak kullanıcı

oy
3

"Kullanımdan sonra boş nesneleri ayarlamak için gerek yoktur" bu tür tamamen doğru değildir. Bunu bertaraf sonra değişkeni NULL olarak gereken zamanlar vardır.

Evet, her zaman aramalısınız .Dispose()ya .Close()İşiniz bittiğinde o vardır bir şey üzerinde. O kolları, veritabanı bağlantıları veya tek kullanımlık nesneler dosya olun.

bundan ayrı LazyLoad çok pratik kalıptır.

Ben ve örneği Say ObjAarasında class A. Class Adenilen bir ortak özelliği vardır PropBve class B.

Dahili olarak, PropBözel değişkeni kullanır _Bnull varsayılan ve. Ne zaman PropB.Get()kullanılır, bu olmadığını kontrol eder _PropBnull ve eğer bir örneğini gerekli kaynak açılır BINTO _PropB. Daha sonra döner _PropB.

Tecrübelerime göre bu gerçekten yararlı bir hile.

Null ihtiyacı gelir sen içeriğinin olduğu bir şekilde değişim A sıfırlamak veya eğer olduğunda _PropBönceki değerlerinin çocuktun A, sen bertaraf VE sıfırlamamaktadır gerekecektir _PropBLazyLoad kodu IF doğru değeri almak için reset böylece bunu gerektirir.

Yalnızca yaparsanız _PropB.Dispose()ve kısa bir süre sonra LazyLoad başarılı olması için boş çek, boş olmayacak bekliyoruz ve bayat verilere bakarak olacağım. Sonuç olarak, size sonra boş gerekir Dispose()emin olmak için sadece.

Emin aksi olsaydı, ama ben şu an sonra bu davranışı sergileyen kodu var Dispose()bir üzerinde _PropBve Dispose yaptım (ve böylece neredeyse kapsam dışı), özel prop hala boş değil çağıran fonksiyonun dışında ve bayat veri hala orada.

Sonunda, elden çıkarılan mülk sıfırlamamaktadır olacak, ama bu benim bakış açısıyla olmayan deterministik oldu.

Temel nedeni, dbkk bahsettiği olarak (ana kap olmasıdır ObjAile PropB) örneğini tutmak _PropBrağmen kapsamına Dispose().

Cevap 11/04/2012 saat 02:12
kaynak kullanıcı

oy
1

De bu makaleye göz atın: http://www.codeproject.com/KB/cs/idisposable.aspx

Çoğunlukla, boş bir nesne ayarlayarak hiçbir etkisi olmaz. Eğer (bitmapler gibi) boyutunda 84K birden büyüktür "büyük nesne" ile çalışıyorsanız bunu yapmak için emin olmalıdır tek zamandır.

Cevap 17/08/2008 saat 05:46
kaynak kullanıcı

oy
1

o referansları boş mantıklı bazı durumlar vardır. Bir öncelik sırası gibi - - Bir koleksiyonu yazarken Örneğin, sözleşme ve istemci kuyruğundan onları kaldırılmış olma, müşteri için hayatta bu nesneleri tutmak gerekir.

Ama bu tür şeylerin sadece uzun ömürlü koleksiyonları içinde önemli. Sıra, oluşturulduğu fonksiyonun sonuna hayatta gitmiyor, o zaman daha az bir sürü önemli.

Bir bütün olarak bakıldığında, gerçekten rahatsız olmamalıdır. sıra sende böylece derleyici ve GC işlerini yapsın.

Cevap 05/08/2008 saat 21:46
kaynak kullanıcı

oy
0

Ben boş geri şey ayarlıyorum dağınık olduğunu düşünüyorum. öğe şimdi maruz kaldığı için ayarlanmış bir senaryo özelliği aracılığıyla söylemek düşünün. Şimdi bir şekilde bir kod bazı parçası yanlışlıkla öğe oluyor tam olarak ne olduğunu anlamaya bazı soruşturma gerektiren bir null başvuru özel alacak bertaraf edildikten sonra bu özelliğini kullanır.

Ben çerçeve tek kullanımlık verir daha anlamlı olan ObjectDisposedException atmak olacağına inanıyoruz. boş geri bu ayarlanmaması bu nedenle daha sonra daha iyi olurdu.

Cevap 13/09/2019 saat 12:52
kaynak kullanıcı

oy
0

Stephen Cleary bu yazı çok iyi açıklıyor: Ben Çöp Toplama Assist için null olarak Değişkenler Belirlemeli?

Diyor:

Kısa Cevap, sabırsız için Evet, değişken statik bir alandır, veya bir enumerable yöntemi (verim dönüşünü kullanarak) ya da asenkron yöntem yazıyorsanız eğer (uyumsuz kullanarak ve bekliyor) eğer. Yoksa yok.

Bu normal yöntemlerde (non-enumerable ve non-asenkron), null, yerel değişkenler, yöntem parametreleri veya oluşum alanlarını ayarlamak anlamına gelir.

(Eğer IDisposable.Dispose uygularken bile, yine de null değişkenleri set olmamalıdır).

Biz düşünmelisiniz önemli şeydir Statik alanlar .

Statik alanlar daima kök nesnelerdir , bu yüzden vardır hep “canlı” olarak kabul çöp toplayıcı tarafından. Statik bir alan artık ihtiyaç vardır bir nesneye başvurur, çöp toplayıcı toplama işlemi için uygun olarak muamele böylece null ayarlanmalıdır.

Tüm işlem kapatılıyor eğer null statik alanlar ayarlanması anlamsızdır. Tüm yığın tüm kök nesneleri de dahil olmak üzere bu noktada toplanan çöp olmak üzere.

blockquote

Sonuç:

Statik alanlar; hepsi bu. Başka bir şey bir zaman kaybıdır.

Cevap 27/03/2019 saat 00:50
kaynak kullanıcı

oy
0

Ben GC implementors tasarımı yaparak, olamaz inanıyoruz hızlandırmak geçersiz sayılması ile GC. Onlar GC çalıştırdığında nasıl / kendinizi endişe sizi tercih ediyorum eminim - Bu her yerde gibi davranın Varlık korunması ve sizin için tekrar dışarı izlerken ... (yay, gökyüzüne yumruk yükseltir baş aşağı) .. .

Ben kendini belgelerin biçimi olarak onlarla işim bittiğinde Şahsen ben genellikle açıkça null değişkenleri ayarlayın. Ben daha sonra boş olarak ayarlanır, kullanmak, beyan değil - Ben hemen boş onlar artık gerek konum sonra. Ben "... Ben resmen gitmiş ... seninle işim", açıkça söylüyorum

Bir GC'd dilinde gerekli nullifying mı? Hayır aksine çok GC için yararlı mı? Belki evet, belki hayır, tasarım gereği ben gerçekten kontrol edemez, kesin olarak bilmiyoruz, ve ne olursa olsun bu sürüme veya bununla günümüz cevabın gelecek GC uygulamaları Elimde olmayan cevabı değiştirebilir. Dışarı optimize edilmiştir sıfırlama zaman Artı eğer / o süslü biraz daha var comment eğer olacak.

Benim ayak izlerini takip sonraki yoksul aptal benim niyet net yaparsa ben anlamaya ve eğer "olabilir" potansiyel olarak bazen GC yardım, o zaman bana değer. Çoğunlukla bu beni derli toplu ve net hissettiren ve Mongo düzenli ve net hissetmeye seviyor. :)

Böyle bakmak: Programlama dilleri insanlar diğer insanlara niyet bir fikir ve bir derleyici ne yapacağını bir iş talebi vereyim için var - derleyici bir CPU için farklı bir dil (bazen birkaç) içine bu isteği dönüştürür - işlemci (ler) vb sekme ayarlarınızı, yorum, üslup vurguları, değişken adları, kullandığınız hangi dili bir yuh verebilir - bir işlemci tüm kaydeder ve işlem kodları ve hafıza yerleri twiddle ne söyler bit stream ilgili. biz belirtilen sırayla CPU tarafından tüketilen ne dönüşmeyen kodunda yazılı Birçok şeyi. Bizim C, C ++, C #, List, Babil, montajcı ya da her türlü işin bir ifadesi olarak yazılı teori ziyade gerçeklik vardır. Ne görüyorsanız onu bile assembler dilinde, evet, ne elde değil.

Ben (boş satır gibi) "gereksiz şeyler" zihniyet anlıyorum "gürültü ve karmakarışık hale getirmek kodu başka bir şey değildir." Yani daha önce kariyerimde bendim; Tamamen o olsun. Bu noktada ben kod daha net hale getiren bu düşkündürler. Benim programlara "gürültü" bile 50 satırları ekleyerek halim yok - burada ya da orada birkaç satır var.

herhangi kuralın istisnaları vardır. Uçucu bellek, statik bellek, yarış koşulları tekizler, "bayat" veri ve çürüme bütün bu tür kullanımı ile senaryolarda, bu farklı: Eğer bellek parçası değildir çünkü kilitleme ve gelmişken olarak sıfırlanmasını, kendi belleği yönetmek için İHTİYACINIZ GC'd Evren - umarım herkes anlar. GC'd dillerle zaman geri kalanı bu tarz ziyade zorunluluk veya garantili performans artışı meselesi.

Günün sonunda ne GC edilebilir, bu durumda ne değil anlıyorum emin olun; Kilidi elden ve uygun geçersiz; kapalı, balmumu mumu; nefes al nefes ver; ve her şey için diyorum: İyi gider, yap. Kilometre değişebilir ... olması gerektiği gibi ...

Cevap 10/05/2016 saat 13:07
kaynak kullanıcı

oy
-1

Bazı nesne varsayalım .dispose()bellek kaldırılacak kaynak zorlar yöntem.

Cevap 05/08/2008 saat 21:21
kaynak kullanıcı

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more