將方法引入任務以避免阻塞asp.net線程

我在想以下代碼是否有任何我在Web服務器上運行時不知道的問題。閱讀優秀系列http://reedcopsey.com/series/parallelism-in-net4/我無法找到任何與我的問題特別相關的內容，與msdn一樣，所以我想我會把它帶到這裏。將方法引入任務以避免阻塞asp.net線程

調用示例：

public ActionResult Index() { 
    ViewBag.Message = "Welcome to ASP.NET MVC!"; 

    Task.Factory.StartNew(() => { 
     //This is some long completing task that I don't care about 
     //Say logging to the database or updating certain information 
     System.Threading.Thread.Sleep(10000); 
    }); 

    return View(); 
}

來源

2011-05-02 Buildstarted

相關：http://stackoverflow.com/questions/3994085/are-there-any-non-obvious-dangers-in-using-threads-in-asp-net – 2011-05-02 20:16:37

感謝您的鏈接喬恩。我沒有考慮過的一條途徑，但現在對我來說顯而易見的是「由於AppPool被回收」，他們可能隨時死亡。絕對是我必須考慮的事情。雖然我不認爲這會影響那麼多，因爲我不關心他們* – Buildstarted 2011-05-02 20:26:16

ASP.Net支持異步頁，看到Asynchronous Pages in ASP.NET，但它是一個複雜的編程模型，並且不與MVC在所有綁定。話雖這麼說，從同步請求處理工作在一定程度上啓動異步任務：

如果在該請求添加新任務的速度超過處理您的過程最終會崩潰的平均速率。任務會佔用實時內存，最終他們將填滿內存中的內存隊列，並且您的註冊表將開始無法提交。
。由於它們缺乏持久性存儲，所以網絡固有地不可靠，因此所有提交異步的任務都必須作爲「放棄軟件」進行線程化，即。如果他們從未完成，則不會對應用程序或提出請求的用戶造成任何損失。如果任務很重要，那麼必須通過一個可靠的機制來提交，以保證在發生故障時執行，如Asynchronous procedure execution中所示。

來源

2011-05-02 20:02:28

ASP.NET MVC支持異步控制器（http://msdn.microsoft.com/zh-cn/library/ee728598.aspx ），但我認爲他們不適合這種即忘即忘式的任務。 – 2011-05-02 20:15:03

他們打算放棄呼叫。我並不是真的在意他們是否完成了，而是想合理地確信他們會這樣做。 – Buildstarted 2011-05-02 20:30:22

在這種情況下，一個重要的事情是確保包含在任務內的代碼包裝在try/catch塊中，否則在此線程中拋出的任何可能的異常都會傳播。您還應該確保在這個長時間運行的任務中，您不訪問任何Http Context成員，如請求，響應，會話...，因爲您訪問它們時可能不再提供它們。

來源

2011-05-02 20:06:39

我只是通過手動拋出異常來測試，並沒有看到它們冒泡。但是，當它不在asp.net中時，它確實會冒泡。 – Buildstarted 2011-05-02 20:27:18

使用new Thread而不是Task.Factory.StartNew。 Task.Factory.StartNew使用線程池中的線程，並且如果您將有許多後臺任務，則線程池將耗盡線程，並會降低您的Web應用程序。該請求將進行排隊，並最終你的Web App將死:)

您可以測試你的背景工作使用Thread.CurrentThread.IsThreadPoolThread線程池執行。如果您變爲True，則使用線程池。

來源

2012-11-09 08:09:20 Tomas

將方法引入任務以避免阻塞asp.net線程

回答

相關問題