再次探討企業(yè)級開發(fā)中的Try......Catch性能問題

2019-11-17 03:58:29

字體：大中小

供稿：網(wǎng)友

引言
之前寫過一篇文章《在企業(yè)級開發(fā)中使用Try...Catch...會(huì)影響效率嗎？》一文，得到了不少朋友的關(guān)注，自己也與大家私下交流了一些東西。

為了最快的讓大家明白本文的內(nèi)容，我先把本文的內(nèi)容列個(gè)提綱，提綱如下：

Try...Catch中大家普遍認(rèn)為的結(jié)論
盡可能的考慮真實(shí)環(huán)境的再次做測試并進(jìn)行分析
之前文章中有錯(cuò)誤的幾點(diǎn)內(nèi)容
總結(jié)

正文部分

第一部分

對于之前的文章，大家的主要意見有如下：

Try...Catch不會(huì)有性能問題
Try...Catch會(huì)對性能有一定的影響
對我的測試結(jié)果有爭議
測試沒有考慮所有環(huán)境，如預(yù)熱、網(wǎng)絡(luò)異常等等
不應(yīng)該用異常處理來作為邏輯處理
還是主觀上感覺try...catch還是會(huì)有性能影響，但是到底會(huì)有多大，不好說。
置疑“企業(yè)級開發(fā)”這個(gè)概念

第二部分

針對以上的一些問題，本著沒有困難，創(chuàng)造困難也要上的精神，筆者又做了一些測試，但是考慮到真實(shí)環(huán)境，及可能出現(xiàn)的問題，代碼或多或少有所改動(dòng)。考慮到的因素有：

throw new Exception("Kevin讓我異常了");這個(gè)異常拋出方法是拋出普通的異常方法，而實(shí)際開發(fā)中，可能出現(xiàn)的異常類的數(shù)量都非常的龐大，筆者粗略的估計(jì)了一下，可能至少得有上千種，而且還可以自定義異常類，如果按照這個(gè)來算的話，異常類的數(shù)量應(yīng)該是無窮的。
異常類有的處理起來時(shí)間會(huì)長，有的處理起來時(shí)間會(huì)短，有朋友認(rèn)為網(wǎng)絡(luò)處理方面的異常處理起來可能時(shí)間會(huì)稍長一些，一旦用try...catch的話，處理起來時(shí)間可能會(huì)長。
如果說一個(gè)函數(shù)的Try...Catch的性能損耗時(shí)間比較短，那么1000個(gè)函數(shù)的性能損耗會(huì)不會(huì)很長？比如，系統(tǒng)中有1000個(gè)函數(shù)，每個(gè)函數(shù)中都有一個(gè)try...catch,然后又一個(gè)方法調(diào)用了這1000個(gè)函數(shù)。針對這一點(diǎn)，就可以把try...catch...放在for循環(huán)里喜歡1000次來進(jìn)行測試。

測試中的預(yù)熱問題，盡可能的多考慮真實(shí)環(huán)境。
針對以上問題，筆者盡可能的換些異常類進(jìn)行測試，然后將try...catch...放到for循環(huán)中進(jìn)行測試。測試得到如下結(jié)論：

沒有使用try...catch不出現(xiàn)異常跟使用了try...catch不出現(xiàn)異常時(shí)間相當(dāng)。
try...catch...的時(shí)間=從執(zhí)行函數(shù)開始到出現(xiàn)異常的時(shí)間+異常捕獲的時(shí)間+異常處理的時(shí)間。而異常捕獲的時(shí)間通常微乎其微，如果是單次的話，可以忽略不計(jì)，也不會(huì)造成性能瓶頸。
如果只做異常捕獲，但是不做異常處理的話，循環(huán)1000次出現(xiàn)異常的時(shí)間約是使用了try...catch不出現(xiàn)異常的391.9倍。
因?yàn)楫惓Ｌ幚淼臅r(shí)間由多個(gè)部分組成，因?yàn)椴煌惓２东@到的時(shí)間可能不同，異常處理的時(shí)間也不盡相同，就會(huì)導(dǎo)致最后時(shí)間加起來結(jié)果跟我測試的會(huì)有差別。
在進(jìn)行以下的分析之前，筆者也請大家認(rèn)真的思考兩個(gè)問題：

什么問題算性能問題？
什么是性能瓶頸？

第三部分

糾正之前文章中的幾點(diǎn)錯(cuò)誤：

try...catch...會(huì)造成一定的性能損失，但并不是比不用try...catch...性能要高。
數(shù)據(jù)庫操作使用事務(wù)比不使用事務(wù)要速度快的問題。
關(guān)于數(shù)據(jù)庫操作使用事務(wù)比不使用事務(wù)快的問題，得分兩個(gè)方面來考慮：

如果是一個(gè)人操作的話，使用事務(wù)會(huì)比不使用事務(wù)要快。
如果是多個(gè)人操作，使用事務(wù)就不一定快了，道理很簡單，使用事務(wù)的話，是利用鎖來進(jìn)行并發(fā)控制的，如果盲目的認(rèn)為使用事務(wù)快，而濫用事務(wù)，那么就可能導(dǎo)致很嚴(yán)重的性能問題，多個(gè)用戶進(jìn)行并發(fā)操作的時(shí)候，全部被一個(gè)人鎖住了，得一個(gè)一個(gè)的來，可想而知，極有可能會(huì)因?yàn)闉E用事務(wù)而造成性能瓶頸。筆者之前沒有考慮到第二點(diǎn)，不過值得慶幸的是，我也從來沒有濫用過事務(wù)。

第四部分

總結(jié)：

Try...Catch...會(huì)損耗一定的性能，但不會(huì)造成性能瓶頸。
建議使用try...catch。
盡可能的考慮到可能存在的異常并進(jìn)行處理，盡可能的少出現(xiàn)異常或不出現(xiàn)異常。
不要濫用數(shù)據(jù)庫事務(wù)提高性能，這樣可能會(huì)造成并發(fā)訪問的性能問題或性能瓶頸。
不要使用try...catch進(jìn)行流程處理。
如果可能的話，盡量要把循環(huán)寫在try...catch內(nèi)部，而不要把try...catch放到循環(huán)內(nèi)部。
如果是try...catch中套著try...catch，異常處理機(jī)制是從內(nèi)部的try...catch...往外部拋的，最先是在內(nèi)部進(jìn)行捕獲、處理。

關(guān)于測試。雖然測試還是不能完全的達(dá)到真實(shí)環(huán)境，實(shí)際上真實(shí)的環(huán)境也是錯(cuò)綜復(fù)雜的，很難完全兼顧，但至少目前的測試來說，筆者認(rèn)為，還是達(dá)到了我想要的目的。
關(guān)于什么是企業(yè)級開發(fā)？筆者也只是有個(gè)模糊的概念，從Google上搜索到了一下一段，與大家分享下吧：

企業(yè)級開發(fā)主要是針對企業(yè)級應(yīng)用的開發(fā)。
那么什么是企業(yè)級應(yīng)用呢？
企業(yè)級應(yīng)用是指那些為商業(yè)組織、大型企業(yè)而創(chuàng)建并部署的解決方案及應(yīng)用。這些大型企業(yè)級應(yīng)用的結(jié)構(gòu)復(fù)雜，涉及的外部資源眾多、事務(wù)密集、數(shù)據(jù)量大、用戶數(shù)多，有較強(qiáng)的安全性考慮。
當(dāng)代的企業(yè)級應(yīng)用決不可能是一個(gè)個(gè)相互獨(dú)立的系統(tǒng)。在企業(yè)中，一般都會(huì)部署多個(gè)彼此連接的、相互通過不同集成層次進(jìn)行交互的企業(yè)級應(yīng)用，同時(shí)這些應(yīng)用又都有可能與其它企業(yè)的相關(guān)應(yīng)用連接，從而構(gòu)成一個(gè)結(jié)構(gòu)復(fù)雜的、跨越Intranet和Internet的分布式企業(yè)應(yīng)用群集。
此外，作為企業(yè)級應(yīng)用，其不但要有強(qiáng)大的功能，還要能夠滿足未來業(yè)務(wù)需求的變化，易于升級和維護(hù)。

實(shí)際上看到這里，大家可能對企業(yè)級開發(fā)有一個(gè)粗略的認(rèn)識了，雖然概念已經(jīng)給出，可是對于理解什么是企業(yè)級開發(fā)，還是有一些困難。可能有的人也會(huì)問，概念都給你了，為什么還這么難理解？實(shí)際上筆者認(rèn)為，看待某個(gè)問題，得從多個(gè)方面來看，才理解的深刻，如當(dāng)你問什么是唯心主義，實(shí)際上唯心主義是針對唯物主義來進(jìn)行定義的，當(dāng)你不明白唯心主義的時(shí)候，恐怕也是很難區(qū)分清楚唯物主義的。

就像企業(yè)級應(yīng)用是按照什么分類的？難道還有個(gè)人級開發(fā)......？

最近博客園流行幾個(gè)新詞：”吉日風(fēng)格“、”吉日風(fēng)格的水貼“，可是究竟什么是吉日風(fēng)格，滿足什么條件才算吉日風(fēng)格？滿足什么條件又算是水貼？

其實(shí)這些都是非常主觀的的概念，既然很主觀，就沒必要去深究了。

上一篇： ASP.net 頁面被關(guān)閉后，服務(wù)器端是否仍然執(zhí)行中？

下一篇：EULA：微軟的法寶