2009-12-29 48 views
0

我的一位朋友告訴我,如果您想在運行時構建可以垃圾收集的代碼,動態方法是唯一的方法。如何使用反射垃圾回收來生成對象?

在我的腦海裏有一個問題,垃圾收集器如何垃圾對象使用反射生成?

+0

您正在使用什麼語言/運行? – johannes 2009-12-29 11:48:50

+0

咦?你可能想要包含你正在編程的語言。儘管我可以想象大多數語言的垃圾收集功能會比這更強大。 – 2009-12-29 11:49:34

+0

C#-DotNet .... – Pankaj 2009-12-29 11:51:12

回答

5

使用反射構造的對象將像任何其他類型的對象一樣被垃圾收集,例如,如果它是方法變量,它將離開方法的作用域。

+0

ok @@ Gerrie Schenck,但誰會決定代碼是管理還是非管理?是否由CRL決定? – Pankaj 2009-12-29 11:50:17

+1

反射被管理。而非託管資源永遠不會被垃圾收集器清理,因爲它們不在託管堆中。 – 2009-12-29 11:55:05

+0

謝謝@@ Gerrie Schenck,但我的問題是,誰決定代碼是管理還是損壞 – Pankaj 2009-12-29 11:57:54

1

反射創建的對象應該如何與正常創建的對象不同?

你有這個對象的實例變量......運行時確切地知道它是什麼類型的對象,也是GC。

只有創建對象的方式不同。該對象應該與使用new MyObject()

4

創建的對象完全相同垃圾收集將收集任何.NET對象。它們使用反射或不反射都沒有不同。

+0

真的非常2謝謝@@ Arjan ..如果我在我的管理代碼中使用一些第三方.dll,它由非託管代碼組成。在這種情況下,我的管理對象將調用unmanage dobject 。 CRL如何處理這種情況...... – Pankaj 2009-12-29 12:08:31

+0

要使用.NET反射和CLR,對象需要至少有一個.NET包裝器。 GC在封裝後清理完畢,但是封裝應該自行清理,也許在終結器中...我期望這是由.NET創建的COM封裝處理的... – 2009-12-29 19:15:06

+0

Thanks @@ Arjan。 .. – Pankaj 2009-12-30 06:12:01

0

任何在CLR控制下運行的代碼都是託管代碼,CLR負責管理和決定垃圾收集。 有些方法可以控制垃圾收集,但除非真的需要讓CLR來決定。

1

比這更復雜。 例如,搜索關於xml序列化程序泄漏內存的Tess(好MS員工)博客。 有些方法可以在代碼模式中解決這個問題。無論如何,這個xml序列化器內存泄漏問題不會被GC修復。事實上,這些類型的動態生成的dll只會在父應用程序被卸載(承載使用xml序列化程序的Web服務的IIS工作進程)時被刪除。底線:即使是.Net項目,也不要依賴所有情況下的GC。有泄漏需要解決方法代碼/代碼模式修復。

這個錯誤仍然在3.5我認爲。

更多鏈接: http://plainoldstan.blogspot.com/2011/04/wcf-memory-leak-with.html 閱讀苔絲鏈接的其它連接這裏面: Are there still known memory leaks with XMLSerialization in .Net 3.5?