ASP.NET多線程技術(shù)解析
前幾天遇到了一個問題，我在頁面邏輯里需要調(diào)用一個webservice，處理一個比較耗時的操作，但是我不需要知道其返回值。于是我希望ASP.NET能像winform一樣使用自動生成的webservice異步方法，通過ASP.NET多線程來解決這一問題。
你是不是想說：在頁面調(diào)用webservice的時候，直接調(diào)用其異步實現(xiàn)不就完了嗎？
這其實是行不通的，為了實現(xiàn)異步調(diào)用，我們需要對頁面進(jìn)行小小的改動，在Page元素里加上Async=true
我們很快就會發(fā)現(xiàn)這樣做的問題：
讓我們測試一下吧，現(xiàn)在我們在一個webservice的Helloworld方法中放入一個Thread。Sleep（10000），然后調(diào)用他的異步實現(xiàn)。通過調(diào)試，我們可以發(fā)現(xiàn)雖然程序運行至HelloworldAsync時，非?？焖俚姆祷夭⑼逻\行，但是當(dāng)所有邏輯處理完成后，頁面并不Response，而是硬生生等待我們的線程睡醒了才返回。
可是如果我希望真正做到調(diào)了不管怎么辦呢？
你可以使用ASP.NET多線程中的Thread，或者ThreadPool，自己來啟動一個線程，我推薦使用ThreadPool，這樣的話，這些線程都會被iis的線程池管理起來，不會造成崩潰
我們來分析一下ASP.NET多線程這兩種模式的運用有什么特點
WebService自帶的異步模式為下圖的模式
這種模式適合無返回的情況，這種情況下，對子線程的調(diào)用應(yīng)該越晚越好，我們可以看到，主、子線程共存的時間越短，我們的稀缺資源線程就越安全，請注意的是，也許總的執(zhí)行時間不會比同步的情況更少，但是我們很快就返回了用戶界面，所以用戶體驗?zāi)軌虻玫教岣?
使用web多線程的缺點 ：
看了上面的敘述,你也許會說,那干脆把我所有的調(diào)用都改成異步調(diào)用吧,你盡管去做吧,絕對是一場災(zāi)難,因為在異步的同時,一定一會產(chǎn)生一個新的線程等待調(diào)用的返回,即使你調(diào)用函數(shù)的返回值為void,所以異步調(diào)用的負(fù)面效果將是會產(chǎn)生許多子線程,所以注意當(dāng)你的調(diào)用非常耗時,這個子線程也將長期占用你的線程池,如果這樣的調(diào)用大量出現(xiàn),照樣會消耗掉所有的可用線程
那么什么情況下適合在web上使用哪種ASP.NET多線程模式呢
我們來看看這段偽代碼,他的用途是提交一個報告,方法傳入一個報告,并從一個WebService中獲得一些報告的內(nèi)容,接著插入數(shù)據(jù)庫,然后在文件服務(wù)器上生成一個報告文件,最后發(fā)出一個通知,讓我們逐條命令的過一下這個方法,看看什么地方適合改為異步調(diào)用？(記得我們的討論都是基于web的,關(guān)于桌面運用的多線程請參考 多線程總結(jié)一)
- public void CreateReport(Report report){
- //從webservice上取得報告的一些信息,
- 不取得這些信息報告,報告是不完整的,是不能提交的
- Report fullreport=CallWebService(report);
- //插入數(shù)據(jù)庫,很重要的工作
- InsertIntoDataBase(fullreport)
- try{
- //生成報告文件,這里是一個耗時而且容易出錯的操作
- WriteStaticFile(fullreport)
- }
- catch{//記錄錯誤日志。。。。}
- //這個只是通知郵件
- CallMailService2(fullreport)
- }
第一條語句CallWebService()從一個webservice里加載一些報告的內(nèi)容,這個是業(yè)務(wù)邏輯相關(guān)的,因為如果不加載的話報告內(nèi)容是不完整的,不能提交,顯然不能改為異步調(diào)了不管的模式,在這里你可以嘗試模式一,但是這個改動是沒有作用的，因為其他所有的過程，包括插入數(shù)據(jù)庫，生成報告都依賴于這個方法的返回，所以如果我們在這里使用異步的話，其他的所有操作都必須等待他的返回,所以采用異步除了多增加了線程以外，一點時間也不能節(jié)省
再來看插入數(shù)據(jù)庫,和上面一樣也沒有必要使用異步調(diào)用
生成報告這里比較有趣,確實他是一個和邏輯息息相關(guān)的操作,但是通過分析代碼,我們可以看出,雖然報告生成是一個重要業(yè)務(wù)步驟,但是并沒有嚴(yán)格到說"如果不能生成報告,就必須回滾上面的操作",并且如果操作失敗,在catch中也僅僅是記錄了日志,并沒有需要嘗試重寫的邏輯,(很有可能另外的某個程序或者某人,會定時查看日志,發(fā)現(xiàn)有錯誤就重新生成文件)也就是說,就這段代碼而言,生成也可以算一個額外邏輯,那么自然也可以去異步操作.可是:千萬注意!!
由于生成報告需要的時間較長,那么生成報告的子線程會長時間運行,長期無法返回線程池,如果請求量太大,頻率太快,那就會耗盡線程資源了.
平心而論,這個問題其實不是異步造成的,即使時同步調(diào)用,執(zhí)行此操作也需要化肥很長時間,調(diào)用量太大,頻率太快,也會造成排隊.而且由于返回時間太長,用戶體驗也不會好，所以我們的這個ASP.NET多線程的改造應(yīng)該是有益的。
【編輯推薦】
