您是否需要在ASP.NET webforms中「unwire」事件處理程序

鑑於WebForm中的所有控件都在每次回髮結束時被銷燬（通過我的瞭解），您是否需要「取消」任何可能具有的事件處理程序有線嗎？（假設你要停止處理事件，並允許GC）所以您是否需要在ASP.NET webforms中「unwire」事件處理程序

例如：

public partial class WebForm1 : System.Web.UI.Page 
{ 
    protected void Page_Load(object sender, EventArgs e) 
    { 
     //Do I need to remove this handler? 
     btnSubmit.ServerClick += btnSubmit_ServerClick; 
    } 
}

來源

2011-06-20 Maxim Gershkovich

不太可能。如果我記得正確，您的WebForm1實例的生命週期就在Unload事件之後結束。在提供頁面和清理完成之後，並不像持續提及WebForm1類。

來源

2011-06-20 19:18:56 Andrew

不，你不必。他們將被垃圾收集。

來源

2011-06-20 19:18:40 ulrichb

我設法使用動態控件創建一個Web應用程序（WebForm），我不得不「斷開」我的事件，否則頁面變得越來越慢。我認爲GC已經關注的「舊」頁面仍然存在。當我在Page_Unload中取消綁定事件時，我的應用程序不再繼續爲不存在的頁面引發事件。

這隻發生在我身上一次，而這可能是由於應用程序的動態性質。

只是回味無窮:)

來源

2011-11-24 16:51:11 thmsn

這太簡單化假設一個WebForm是短暫的 - 在這個例子中，你看起來很好，但一般而言，您應該謹慎。

就在今天，我遇到了一個很好的例子，類似於@thmsn，在ASP.NET WebForms應用程序中未能解除事件處理程序導致令人討厭的內存泄漏。

在這種情況下，幾乎所有頁面中使用的母版頁都訂閱了其Page_Init中的對象事件。所討論的對象是長期存在的，並且在ASP.NET會話中持久化，並且該站點被配置爲使用InProc會話存儲並且超時60分鐘。如果無法斷開事件處理程序，則意味着該對象只要存活（至少每小時一個小時），就會阻止在會話期間訪問的所有頁面的GC被訪問。

快速修復方法是取消Page_Unload中的事件處理程序 - 此示例顯示頁面的生命週期很容易被無意間擴展到超過其有效生命週期。我不會在這裏使用Session，儘管它遠非理想 - 我也看到類似的錯誤引入了來自對象的反向引用，這些對象的頁面生存期比適當的長。

來源

2017-02-22 21:29:15

事件處理程序不以任何方式延長事件對象的生命週期，只要具有事件的對象處於活動狀態，它就會延長具有處理程序的對象的生命週期，因此您描述的情況是不可能的。你擁有的對象必須既是引用頁面（而不是其他方式）。 – Servy

簡單的錯字 - 訂閱對象的事件（而非處理程序）。糾正。相信我，我已經有了！dumpheap來證明泄漏！乾杯:)在會話中訂閱對象上的事件意味着該對象將引用返回到頁面，並保持活動狀態。 –

爲事件訂閱事件處理程序不會導致處理程序具有對定義事件的對象的引用的對象。你可以在你的情況下明確地創建這樣的參考;這很容易做到，但事件訂閱並不一定會發生，這意味着取消訂閱事件處理程序也不會消除您的問題。現在，如果您的頁面實例爲長期存在的其他對象訂閱了一個事件處理程序，那麼只要該另一個對象在附近，* that *就會保留該頁面，但這是一種不同的情況。 – Servy

您是否需要在ASP.NET webforms中「unwire」事件處理程序

回答

相關問題