系統架構設計師-軟件水平考試（高級）-論文-可靠性

前言

首先說一下為什麼這兩個月又沒消息了，因為這兩個月忙啊。

首先是接收上半年系統分析師的證書，並完成總結。其次是九月份PMP考試（4A通過，尚需努力），然後是十一月的軟考高項的考試。工作的事情就不談了，還好沒什麼私人事情需要處理。所以這兩個月沒什麼空寫博客，不過接下來應該會有一些時間來寫博客。

關於系統架構師這個分支，原本都打算完結了的。然後突然發現大家對系統架構師的論文比較感興趣，並且自從我上次透露了我有一個架構師/分析師的群后，陸陸續續不斷有人私信我加群。所以，就回過頭，再發一篇系統架構師的論文。並打算找時間，將自己系統分析師，PMP，項目管理師的知識整理出來。畢竟在過去的一年的時間，我連續通過系統架構師，系統分析師，PMP，並完成，參加了高項（雖然目前還不知道通過沒），我認為我的學習方法，知識體系等還是有一定作用的，希望對大家有所幫助。嘻嘻。

哦。差點忘了。由於我的架構師/分析師群是邀請制的，所以給你們群號，也是無法添加的。所以，如果有參加架構師/分析師的朋友，請私聊我。謝謝。

一，理論

（強調一下，圖片絕對清晰。如果看不清，請從新的頁面打開，或者下載下來）

論文

摘要：
本人於2015年11月參与浙江省某在線教育平台“外教一對一在線教育”項目，該項目為客戶提供了一對一歐美外教視頻教學，社交圈，公眾直播等功能提供全方位的軟件支撐，在該項目組中我擔任系統架構師崗位，主要負責整體架構設計與中間件選型。本文以該教育平台為例，主要討論了該系統有關可靠性方面的設計與應用，以及遇到的問題與解決方案。一方面通過負載均衡進行容錯技術中冗餘設計的實現，另一方面通過層次架構風格來明確系統結構體系，從而降低系統設計複雜度，提高系統可靠性。整個系統開發工作歷時18個月。目前，該系統已經穩定運行近一年半的時間。實踐證明，通過容錯設計，降低複雜度設計等，系統有效提高了可靠性，從而為公司業務提供持續穩定的服務支撐。

正文：
隨着國家對教育的越發重視，英語教育的市場份額逐步上升，其中用戶口語提升的需求越來越大。為此，一些公司開始提供與外國人聊天的平台。我所在公司決定從國際通訊領域進軍口語教育領域。為了這項戰略轉變，公司於2015年11月設計某在線教育平台系統（一下簡稱為“系統”）。該系統幫助人們與歐美外教進行面對面的口語交流和教學。其中隨意聊提供了一種類似QQ視頻通話，而正式課程還提供了H5互動課件與課後點評等，以提高教學質量。與此同時，還有公眾直播用於拉新，AI測試用於評定學院能力，降低成本。我參与了該項目的開發工作，擔任系統架構設計師職務，負責設計系統架構。本項目組全體成員共9人，我主要負責項目計劃制定，需求分析，整體架構設計與技術選型，以及部分底層設計。該項目的架構工作與次年2月完成，選擇了層次架構風格。整個項目耗時18個月，於2017年5月完成。
目前主流的可靠性設計技術有容錯設計，檢錯設計，降低複雜度設計等技術。容錯設計技術分為恢復塊設計，N版本程序設計和冗餘設計。其中恢復塊設計是選擇一組軟件操作作為容錯設計單元，將普通的程序塊編程恢復塊。N版本程序設計的核心是通過設計出多個模塊或不同版本，對於相同初始條件和相同輸入的操作結果，實現多數表決，防止其中某一軟件模塊/版本的故障提供錯誤的服務，以實現軟件容錯。冗餘設計是在一套完整的軟件系統之外，設計一種不同路徑，不同算法或不同實現方法的模塊或系統作為備份，在出現故障時可以使用冗餘的部分進行替換，從而維持軟件系統的正常運行。缺點是費用和資源的消耗會有所增加。檢錯技術是在軟件出現故障后能及時發現並報警。其缺點是不能自動解決故障。降低複雜度設計是因為軟件複雜性與軟件可靠性有着密切關係，是產生軟件缺陷的重要根源。在設計時考慮降低軟件的複雜性，是提高軟件可靠性的有效方法。

在了解系統需求后，我們決定聽從公司技術顧問的建議，容錯設計主要應用在冗餘設計方面，通過負載均衡，雙機容錯等機制完成冗餘設計。檢錯設計則是通過對Java異常處理機制的設計與封裝處理完成。至於降低複雜度方面，採用層次架構風格，使得系統的結構明確，立體，從而提高系統可靠性。接下來，我將從系統的冗餘設計，複雜度降低設計介紹可靠性在系統中的設計與應用，以及應用過程中遇到的問題與解決方案。

1.冗餘設計：

首先說冗餘設計，冗餘包含邏輯冗餘，數據冗餘，應用冗餘等。這裏以應用冗餘為例。為了提高系統的性能，可靠性，可拓展性等，我們採用了負載均衡技術。常見的負載均衡技術有F5硬件，LVS軟件，Nginx服務器配置等。出於便捷與成本的考慮，我們採用了Nginx服務器配置負載均衡技術。通過對Nginx服務器中upstream模塊的配置，就可以實現在多台服務器的反向代理家在負載均衡。採用負載均衡后，應用服務器集群存在Session問題無法統一的問題。解決方法有Session Sticky，Session Replication，Session數據集中存儲，Cookie Based四個方案。Session Sticky是通過確保同一個會話的請求都在同一個Web服務器上處理實現。Session Replication是增加Web服務器間會話數據的同步來保證不同Web服務器間的Session數據的一致。Cookie Based就是通過Cookie傳遞Session數據完成。經過考慮，我們採用了Session數據集中存儲。Session數據集中存儲通過令每台服務器從專門的session服務器獲取session數據來解決問題。優點是可靠性，可移植性與可拓展性的大幅提高。缺點是一方面讀寫Session數據引入了網絡操作，對數據讀取存在時延和不穩定性，但對於使用內網通信的系統並沒有太大影響。另一方面，如果Session服務器或集群出現問題，將會影響整個應用。我們通過雙機容錯機制解決該問題。除此之外，還有心跳線，看門狗等技術。限於篇幅，不再贅述。

2.降低複雜度設計：

再者就是降低複雜度設計，由於系統的複雜性和綜合性，我們決定採用層次架構風格，將系統架構分為接入層，應用層，服務層，數據層四個層次。這裏以應用層與服務層為例。應用層分為視圖層與業務邏輯層，視圖層負責App與網站的表現效果，業務邏輯層負責業務層的邏輯處理。為了解決系統日益複雜，應用日益臃腫問題，我們將系統按照應用橫向劃分，將系統劃分為課件管理系統，課程管理系統等十餘個子系統。如課件管理系統負責學員上課所用課件，有課件編輯，課件預覽，課件交互等多個功能模塊。功能模塊需調用服務層的服務支撐，如課件交互模塊需要調用stomp通信服務，實現學生與老師間課件的交互功能。另外，課件交互模塊通過對賬戶服務的調用，確立課件雙方的身份，從而明確雙方在課件交互過程中對課件交互部分的交互權限。該劃分使得系統體系變得清晰明了，極大降低系統複雜度，提高系統可靠性。應用層採用基於J2ee的MVC框架-Structs框架，主要通過Servlet和JSP技術實現。另外還有動靜分離，動態資源靜態化等，這裏不再贅述。

服務層提供通用服務。系統在應用層中按照應用橫向劃分，有效降低系統複雜度。但系統代碼仍然存在冗餘，比如用戶信息的調用在諸多應用子系統中都有相關模塊。另外應用的大小依舊十分巨大，複雜，而過小的應用劃分會增加數據庫連接數負擔，故我們提出服務化解決方案。服務化方案就是提取出各個應用的通用服務，如賬戶服務，Session服務等。出於技術成熟度與技術支持等考慮，我們最終採用了阿里的dubbo服務框架，建立服務層。開發過程中，產生了服務框架部署問題與實現服務框架的jar包和應用自身依賴的jar包衝突的問題。前者，我們通過Tomcat作為Web容器，而服務框架作為容器的一部分來解決。後者，我們通過Java的ClassLoader將服務框架自身用的類與應用的類進行隔離。除此之外，我們通過服務線程池隔離，分佈請求合併，服務調用端的流程控制來降低系統複雜度，提高系統可靠性。詳情限於篇幅，不再贅述。

最終項目成功上線，正常運行了近一年半，收到各方好評。尤其是H5課件的良好互動性，使得大量業界同行爭相模仿，改用H5製作課件。還有我們的服務化方案架構被作為許多傳統互聯網企業系統重構的經典方案。在系統的架構設計中，我們引入了層次架構的設計思想，有效地降低了維護成本，提高了系統的開放性，可擴展性，可重用性以及可移植性。當然還是存在一些問題的。如H5課件採用http協議，易被非法劫持，嵌入廣告，可以將協議修改為https來解決。還有我們採用的負載均衡算法是加權輪轉算法，過於簡單，常常出現資源分配不合理的現象，可以將算法改為加權最小連接數算法來解決。這些都是我在今後的系統設計和開發中需要注意與改進的地方，也是日後我應該努力的方向。

三，總結

這篇論文的項目，依舊是之前那片論文的項目-在線教育系統。但是其中很多技術，其實在原有項目中是沒有涉及的。

另外這篇論文與之前論文存在一個結構上的不同之處，那就是這次的核心論點只有兩個分論點。不過，第二個論點-降低複雜度設計，是通過兩個方面進行闡述的。這也算是論文中核心論點的一種回答方式。往往論文的核心論點，推薦使用三個分論點進行論述，而部分論文的核心論點就只能拆分為兩個分論點（或者，三個論點的拆分維度，自己不熟悉）。這時候就需要靈活的轉變自己的思想，將核心論點的兩個分論點氛圍主次論點回答，實際體現就是主論點兩個段落，次論點一個段落。

既然說到這裏，也說一下，如果核心論點可以拆分出多個分論點。如架構風格的層次架構完全可以拆分為接入層，應用層，服務層（基礎服務層，通用服務層，業務服務層），數據接入層，數據源等。那麼這種情況，我們完全可以從中挑選三點自己熟悉的部分，進行闡述。如果擔心這樣寫，文章顯得比較僵硬，就在相關位置寫上“此處，我們以XXX,XXX,XXX為重點，進行論述”這樣的話語即可。

附錄

早期未修改的論文：

摘要：
本人於2015年11月參与浙江省某在線教育平台“外教一對一在線教育”項目，該項目為客戶提供了一對一歐美外教視頻教學，社交圈，公眾直播等功能提供全方位的軟件支撐，在該項目組中我擔任系統架構師崗位，主要負責整體架構設計與中間件選型。本文以該教育平台為例，主要討論了該系統有關可靠性方面的設計與應用。一方面通過負載均衡與應用服務器集群實現容錯技術中冗餘設計的實現，另一方面通過建立了接入層，應用層，服務層，數據層四層層次的架構來降低明確系統結構，從而系統設計複雜度，提高系統可靠性。整個系統開發工作歷時18個月。目前，該系統已經穩定運行近一年半的時間。實踐證明，通過容錯設計，降低複雜度設計等，系統有效提高了可靠性，從而為公司業務提供持續穩定的服務支撐。

正文：
隨着國家對教育的越發重視，英語教育的市場份額逐步上升，其中用戶口語提升的需求越來越大。為此，一些公司開始提供與外國人聊天的平台。我所在公司決定從國際通訊領域進軍口語教育領域。為了這項戰略轉變，公司於2015年11月設計某在線教育平台系統（一下簡稱為“系統”）。該系統幫助人們與歐美外教進行面對面的口語交流和教學。其中隨意聊提供了一種類似QQ視頻通話，而正式課程還提供了H5互動課件與課後點評等，以提高教學質量。與此同時，還有公眾直播用於拉新，AI測試用於評定學院能力，降低成本。我參与了該項目的開發工作，擔任系統架構設計師職務，負責設計系統架構。本項目組全體成員共9人，我主要負責項目計劃制定，需求分析，整體架構設計與技術選型，以及部分底層設計。該項目的架構工作與次年2月完成，選擇了層次架構風格。整個項目耗時18個月，於2017年5月完成。

目前主流的可靠性設計技術有容錯設計，檢錯設計，降低複雜度設計等技術。容錯設計技術分為恢復塊設計，N版本程序設計和冗餘設計。其中恢復塊設計是選擇一組軟件操作作為容錯設計單元，將普通的程序塊編程恢復塊。N版本程序設計的核心是通過設計出多個模塊或不同版本，對於相同初始條件和相同輸入的操作結果，實現多數表決，防止其中某一軟件模塊/版本的故障提供錯誤的服務，以實現軟件容錯。冗餘設計是在一套完整的軟件系統之外，設計一種不同路徑，不同算法或不同實現方法的模塊或系統作為備份，在出現故障時可以使用冗餘的部分進行替換，從而維持軟件系統的正常運行。缺點是費用和資源的消耗會有所增加。檢錯技術是在軟件出現故障后能及時發現並報警。其缺點是不能自動解決故障。降低複雜度設計是因為軟件複雜性與軟件可靠性有着密切關係，是產生軟件缺陷的重要根源。在設計時考慮降低軟件的複雜性，是提高軟件可靠性的有效方法。

在了解系統需求后，我們決定聽從公司技術顧問的建議，在容錯設計，檢錯設計，降低複雜度設計三個主流方向分別作出相應處理和應用。容錯設計主要應用在冗餘設計方面，通過負載均衡，雙機容錯等機制完成冗餘設計。檢錯設計則是通過對Java異常處理機制的設計與封裝處理完成。至於降低複雜度，我們應用層次清晰的四層層次架構。通過將系統劃分為接入層，應用層，服務層，數據層，使得系統的結構明確，立體，從而降低系統複雜度。限於篇幅，接下來，我將從系統的冗餘設計，複雜度降低設計兩個方面介紹可靠性在系統中的設計與應用，以及應用過程中遇到的問題。

首先說冗餘設計，冗餘包含邏輯冗餘，數據冗餘，應用冗餘等。這裏以應用冗餘為例。一方面為了提高應用服務器性能，另一方面為了提高系統的可靠性，可拓展性等，我們採用了負載均衡技術。常見的負載均衡技術有F5硬件，LVS軟件，Nginx服務器配置等。出於便捷與成本的考慮，我們採用了Nginx服務器配置負載均衡技術。通過對Nginx服務器中upstream模塊的配置，就可以實現在多台服務器的反向代理家在負載均衡。為了提高負載均衡服務器可靠性，我們採用雙機熱備機制。但採用負載均衡后，應用服務器集群出現了Session問題無法統一的問題。解決方法有Session Sticky，Session Replication，Session數據集中存儲，Cookie Based四個方案。Session Sticky是通過確保同一個會話的請求都在同一個Web服務器上處理實現。Session Replication是增加Web服務器間會話數據的同步來保證不同Web服務器間的Session數據的一致。但一方面同步Session數據會造成網絡帶寬的開銷。另一方面，每台Web服務器都要保存所有Session數據，消耗大量內存。經過考慮，我們採用了第三種方案-Session數據集中存儲。Session數據集中存儲通過令每台服務器從專門的session服務器獲取session數據來解決問題。優點是可靠性，可移植性與可拓展性的大幅提高。缺點是一方面讀寫Session數據引入了網絡操作，對數據讀取存在時延和不穩定性，但對於使用內網通信的系統並沒有太大影響。另一方面，如果Session服務器或集群出現問題，將會影響整個應用。我們通過雙機容錯機制解決該問題。Cookie Based就是通過Cookie傳遞Session數據完成。實現簡單，但是存在如Cookie長度限制等問題。除此之外，還有心跳線，看門狗等諸多技術。限於篇幅，不再贅述。

再者就是降低複雜度設計，我們從架構風格選擇，技術選型等角度實現。由於系統的複雜性和綜合性，我們決定採用層次架構風格，將系統架構分為接入層，應用層，服務層，數據層四個層次。接入層負責多平台的接入，以及API網關，負載均衡等方面。API網關的使用使得對外資源與服務獲得統一，保持系統結構的明確，從而提高了系統可靠性。應用層分為視圖層與業務邏輯層，視圖層負責App與網站的表現效果，業務邏輯層負責業務層的邏輯處理。為了解決系統日益複雜，應用日益臃腫問題，我們將系統按照應用橫向劃分，將系統劃分為課件管理系統，課程管理系統等十餘個子系統。這樣的劃分使得系統體系變得清晰明了，極大降低系統複雜度，提高系統可靠性。應用層採用基於J2ee的MVC框架-Structs框架。服務層提供通用服務。系統在應用層中按照應用橫向劃分，有效降低系統複雜度。但系統代碼仍然存在冗餘，比如用戶信息的調用在諸多應用子系統中都有相關模塊。另外應用的大小依舊十分巨大，複雜，而過小的應用劃分會增加數據庫連接數負擔，故我們提出服務化解決方案。服務化方案就是提取出各個應用的通用服務，如賬戶服務，Session服務等。出於技術成熟度與技術支持等考慮，我們最終採用了阿里的dubbo服務框架，建立服務層。數據層涉及緩存，文件系統，數據庫，數據通知服務，搜索系統等模塊。由於用戶對數據訪問具有集中性，故我們基於Spring Cache與Redis實現緩存機制。數據訪問方面，Java已經有很多成熟技術，大致分為專用API方式，JDBC方式，給予ORM或類ORM接口方式三種。最終我們採用了成熟的ORM框架-Mybatis框架，再將框架包裝一層。這樣一方面提高系統開發效率，另一方面提高系統可移植性與可靠性。除此之外，還採用了solr作為數據層搜索引擎，數據訪問層物理部署採用Proxy方式。限於篇幅，不再贅述。

最終項目成功上線，正常運行了近一年半，收到各方好評。尤其是H5課件的良好互動性，使得大量業界同行爭相模仿，改用H5製作課件。還有我們的服務化方案架構被作為許多傳統互聯網企業系統重構的經典方案。在系統的架構設計中，我們引入了層次架構的設計思想，有效地降低了維護成本，提高了系統的開放性，可擴展性，可重用性以及可移植性。當然還是存在一些問題的。如H5課件採用http協議，易被非法劫持，嵌入廣告，可以將協議修改為https來解決。還有我們採用的負載均衡算法是加權輪轉算法，過於簡單，常常出現資源分配不合理的現象，可以將算法改為加權最小連接數算法來解決。這些都是我在今後的系統設計和開發中需要注意與改進的地方，也是日後我應該努力的方向。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※為什麼 USB CONNECTOR 是電子產業重要的元件?

※網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司，幫您輕鬆架站!

※想要讓你的商品成為最夯、最多人討論的話題?網頁設計公司讓你強力曝光

※想知道最厲害的台北網頁設計公司推薦、台中網頁設計公司推薦專業設計師”嚨底家”!!

※新北清潔公司,居家、辦公、裝潢細清專業服務

該系列博文會告訴你如何從入門到進階，一步步地學習Java基礎知識，並上手進行實戰，接着了解每個Java知識點背後的實現原理，更完整地了解整個Java技術體系，形成自己的知識框架。

 

前言：

Java的基本理念是“結構不佳的代碼不能運行”。

“異常”這個詞有“我對此感到意外”的意思。問題出現了，你也許不清楚該如何處理，但你的確知道不應該置之不理；你要停下來，看看是不是有別人或在別的地方，能夠處理這個問題。只是在當前的環境中還沒有足夠的信息來解決這個問題，所以就把這個問題提交到一個更高級別的環境中，在這裏將作出正確的決定。

使用異常所帶來的另一個相當明顯的好處是，它往往能夠降低錯誤處理代碼的複雜度。如果不使用異常，那麼就必須檢查特定的錯誤，並在程序中的許多地方去處理它。而如果使用異常，那就不必在方法調用處進行檢查，因為異常機制將保證能夠捕獲這個錯誤。並且，只需在一個地方處理錯誤，即所謂的異常處理程序中。這種方式不僅節省代碼，而且把“描述在正常執行過程中做什麼事”的代碼和“出了問題怎麼辦”的代碼相分離。總之，與以前的錯誤處理方法相比，異常機制使代碼的閱讀、編寫和調試工作更加井井有條。

 

異常概述：

現在我們需要編寫一個五子棋程序，當用戶輸入下期坐標時，程序要判斷用戶輸入是否合法，如果保證程序有較好的容錯性，將會有如下的代碼（偽代碼）：

if(用戶輸入包含除逗號之外的其他非数字字符)
{
	alert 坐標只能是數值
	goto retry
}
else if(用戶輸入不包含逗號) {
	alert 應使用逗號分隔兩個坐標值
	goto retry
}

else if(用戶輸入坐標值超出了有效範圍) {
	alert 用戶輸入坐標應位於棋盤坐標之內
	goto retry
}

else if(用戶輸入的坐標已有棋子)
{
	alert 只能在沒有棋子的地方下棋
	goto retry
}
else {
	.....
}

　　

上面代碼還未涉及任何有效處理，只是考慮了4種可能的錯誤，代碼就已經急劇增加了。但實際上，上面考慮的4種情形還遠未考慮到所有的可能情形（事實上，世界上的意外是不可窮舉的），程序可能發生的異常情況總是大於程序員所能考慮的意外情況。

對於上面的錯誤處理機制，主要有以下兩個缺點：

• 無法窮舉所有的異常情況。因為人類知識的限制，異常情況總比可以考慮到的情況多，總有“漏網之魚”的異常情況，所以程序總是不夠健壯。
• 錯誤處理代碼和業務實現代碼混雜。這種錯誤處理和業務實現混雜的代碼嚴重影響程序的可讀性，會增加程序維護的難度。

我們希望有這樣一種處理機制：

if(用戶輸入的數據不合法){
    .....
}else{
   處理邏輯
   .....  
}

　　

上面偽碼提供了一個非常強大的“if塊”——程序不管輸入錯誤的原因是什麼，只要用戶輸入不滿足要求，程序就一次處理所有的錯誤。這種處理方法的好處是，使得錯誤處理代碼變得更有條理，只需在一個地方處理錯誤。

這就需要用到java異常了。

 

異常是程序中的一些錯誤，但並不是所有的錯誤都是異常，並且錯誤有時候是可以避免的。

比如說，你的代碼少了一個分號，那麼運行出來結果是提示是錯誤java.lang.Error；如果你用System.out.println(11/0)，那麼你是因為你用0做了除數，會拋出java.lang.ArithmeticException的異常。

異常發生的原因有很多，通常包含以下幾大類：

• 用戶輸入了非法數據。
• 要打開的文件不存在。
• 網絡通信時連接中斷，或者JVM內存溢出。

 

Java中的異常有以下三種類型：

檢查異常：最具代表的檢查性異常是用戶錯誤或問題引起的異常，這是程序員無法預見的。例如要打開一個不存在文件時，一個異常就發生了，這些異常在編譯時不能被簡單地忽略。

運行異常：運行時異常是可能被程序員避免的異常。與檢查性異常相反，運行時異常可以在編譯時被忽略。

錯誤：錯誤不是異常，而是脫離程序員控制的問題。錯誤在代碼中通常被忽略。例如，當棧溢出時，一個錯誤就發生了，它們在編譯也檢查不到的。

 

異常的體繫結構：

我們先來統觀以下Java的異常體繫結構圖：

 

 

Java的異常被分為兩大類：Checked異常和Runtime異常（運行時異常）。所有的RuntimeException類及其子類的實例被稱為Runtime異常；不是RuntimeException類及其子類的異常實例則被稱為Checked異常。

只有Java語言提供了Checked異常，其他語言都沒有提供Checked異常。Java認為Checked異常都是可以被處理（修復）的異常，所以Java程序必須顯式處理Checked異常。如果程序沒有處理Checked異常，該程序在編譯時就會發生錯誤，無法通過編譯。

 

Throwable：

Java異常的頂級類，所有的類都繼承自Throwable

Error：

Error錯誤，一般是指與虛擬機相關的問題，如系統崩潰、虛擬機錯誤、動態鏈接失敗等，這種錯誤無法恢復或不可能捕獲，將導致應用程序中斷。通常應用程序無法處理這些錯誤，因此應用程序不應該試圖使用catch 塊來捕獲Error對象。
在定義該方法時，也無須在其throws子句中聲明該方法可能拋出Error及其任何子類。

 

Exception：

Exception中異常主要分為兩大類，運行時異常和檢查異常。常見的運行時異常有ArrayIndexOutOfBoundsException（數組下標越界）、NullPointerException（空指針異常）、ArithmeticException（算術異常）、ClassNotFoundException（類型找不到），這些異常時非檢查異常，程序可以選擇處理，也可以不處理，編譯器編譯時期並不會報錯。這些異常一般是由於程序邏輯錯誤引起的，所以建議程序員還是處理一下。除運行時異常外的所有異常我們都稱為非運行時異常，也是必須處理的異常，如果不出來，程序編譯會報錯。

 

Error和Exception的區別：

Error和Exception的區別：Error通常是災難性的致命的錯誤，是程序無法控制和處理的，當出現這些異常時，Java虛擬機（JVM）一般會選擇終止線程；Exception通常情況下是可以被程序處理的，並且在程序中應該盡可能的去處理這些異常。

 

檢查異常：必須處理的異常

除了RuntimeException及其子類以外，其他的Exception類及其子類都屬於檢查異常，當程序中可能出現這類異常，要麼使用try-catch語句進行捕獲，要麼用throws子句拋出，否則編譯無法通過。

 

非檢查異常：可以不處理

包括RuntimeException及其子類和Error。

不受檢查異常為編譯器不要求強制處理的異常，檢查異常則是編譯器要求必須處置的異常。

 

異常處理機制：

Java的異常處理機制可以讓程序具有極好的容錯性，讓程序更加健壯。當程序運行出現意外情形時，系統會自動生成一個Exception對象來通知程序，從而實現將“業務功能實現代碼”和“錯誤處理代碼”分離，提供更好的可讀性。

java異常關鍵字：

• try – 用於監聽。try后緊跟一個花括號括起來的代碼塊（花括號不可省略），簡稱try塊，它裏面放置可能引發異常的代碼，當try語句塊內發生異常時，異常就被拋出。【監控區域】
• catch – 用於捕獲異常。catch后對應異常類型和一個代碼塊，用於處理try塊發生對應類型的異常。【異常處理程序】
• finally – 用於清理資源，finally語句塊總是會被執行。 多個catch塊后還可以跟一個finally塊，finally塊用於回收在try塊里打開的物理資源（如數據庫連接、網絡連接和磁盤文件）。只有finally塊執行完成之後，才會回來執行try或者catch塊中的return或者throw語句，如果finally中使用了return或者throw等終止方法的語句，則就不會跳回執行，直接停止。【使用finally進行清理】
• throw – 用於拋出一個實際的異常。throw可以單獨作為語句使用，拋出一個具體的異常對象。【拋出異常】
• throws –用在方法簽名中，用於聲明該方法可能拋出的異常。【異常說明】

 

1、使用try…catch捕獲異常：

語法格式：

try{
   //業務實現代碼
   ...
}catch(Exception e){
  //異常處理代碼
  ...
}

　　

如果執行try塊里的業務邏輯代碼時出現異常，系統自動生成一個異常對象，該異常對象被提交給Java運行時環境，這個過程被稱為拋出（throw）異常。

當Java運行時環境收到異常對象時，會尋找能處理該異常對象的catch塊，如果找到合適的catch塊，則把該異常對象交給該catch塊處理，這個過程被稱為捕獲（catch）異常；如果Java運行時環境找不到捕獲異常的catch塊，則運行時環境終止Java程序也將退出。

下面看幾個簡單的異常捕獲的例子：

例1：

public class DivTest {
	
	public static void main(String[] args) {
		try {
			int a=Integer.parseInt(args[0]);
			int b=Integer.parseInt(args[1]);
			int c=a/b;
			System.out.println("您輸入的兩個數相除的結果是"+c);
		}catch(IndexOutOfBoundsException e) {
			System.out.println("數組越界，運行時參數不夠");
		}catch(NumberFormatException e) {
			System.out.println("数字格式異常");
		}catch(ArithmeticException e) {
			System.out.println("算術異常");
		}catch(Exception e) {
			System.out.println("未知異常");
		}
	}

}

　　

• 如果運行該程序時輸入的參數不夠，將會發生數組越界異常，Java運行時將調用IndexOutOfBoundsException對應的catch塊處理該異常。
• 如果運行該程序時輸入的參數不是数字，而是字母，將發生数字格式異常，Java運行時將調用NumberFormatException 對應的catch塊處理該異常。
• 如果運行該程序時輸入的第二個參數是0，將發生除0異常，Java運行時將調用ArithmeticException對應的catch塊處理該異常。
• 如果程序運行時出現其他異常，該異常對象總是Exception類或其子類的實例，Java運行時將調用Exception對應的catch塊處理該異常。

上面程序中的三種異常是我們在編程中經常遇見的，讀者應該掌握這些異常。

例2：

import java.util.Date;


public class Test {
	
	public static void main(String[] args) {
		Date d=null;
		try {
			System.out.println(d.after(new Date()));
		}catch(NullPointerException e) {
			System.out.println("空指針異常");
		}catch(Exception e) {
			System.out.println("未知異常");
		}
	}

}

　　

上面程序針對NullPointerException異常提供了專門的異常處理塊。上面程序調用一個null對象的after0方法，這將引發NullPointerException異常（當試圖調用一個null對象的實例方法或實例變量時，就會引發NullPointerException異常），Java 運行時將會調用NullPointerException對應的catch塊來處理該異常；如果程序遇到其他異常，Java運行時將會調用最後的catch塊來處理異常。

catch塊處理異常遵循着：先小后大，即先子類後父類。正如在前面程序所看到的，程序總是把對應Exception類的catch塊放在最後，這是為什麼呢？讀者可能明白原因：如果把Exception類對應的catch塊排在其他catch塊的前面，Java運行時將直接進入該catch塊（因為所有的異常對象都是Exception或其子類的實例），而排在它後面的catch塊將永遠也不會獲得執行的機會。

 

多異常捕獲：

在Java7之前，每個catch塊只能捕獲一個異常，Java7之後，每個catch塊可以捕獲多種類型的異常。

上面的例1可以改成如下代碼實現：

public class Test {
	
	public static void main(String[] args) {
		try {
			int a=Integer.parseInt(args[0]);
			int b=Integer.parseInt(args[1]);
			int c=a/b;
			System.out.println("您輸入的兩個數相除的結果是"+c);
		}catch(IndexOutOfBoundsException|NumberFormatException|ArithmeticException e) {
			System.out.println("數組越界，数字格式異常，算術異常");
		}catch(Exception e) {
			System.out.println("未知異常");
		}
	}

}

　　

2、使用throws聲明拋出異常：

使用throws聲明拋出異常的思路是，當前方法不知道如何處理這種類型的異常，該異常應該由上一級調用者處理；如果main方法也不知道如何處理這種類型的異常，也可以使用throws聲明拋出異常，該異常將交給JVM處理。JVM對異常的處理方法是，打印異常的跟蹤棧信息，並中止程序運行，這就是前面程序在遇到異常后自動結束的原因。

import java.io.FileInputStream;
import java.io.FileNotFoundException;

public class Test {
	
	public static void main(String[] args) throws FileNotFoundException {
		FileInputStream fis=new FileInputStream("a.txt");
	}

}

　　

上面程序聲明不處理IOException異常，將該異常交給JVM處理，所以程序一旦遇到該異常，JVM就會打印該異常的跟蹤棧信息，並結束程序。運行上面程序，會看到如下圖所示的運行結果。

 

 

3、使用throw拋出異常：

public class Test {
	
	public static void main(String[] args) throws Exception {
		try {
			int a=Integer.parseInt(args[0]);
			int b=Integer.parseInt(args[1]);
			int c=a/b;
			if(b==0) {
				throw new Exception("除數不能為0");
			}
			System.out.println("您輸入的兩個數相除的結果是"+c);
		}catch(Exception e) {
			System.out.println("未知異常");
		}
	}

}

　　

上面程序中粗體字代碼使用throw語句來自行拋出異常。當Java運行時接收到開發者自行拋出的異常時，同樣會中止當前的執行流，跳到該異常對應的catch塊，由該catch塊來處理該異常。也就是說，不管是系統自動拋出的異常，還是程序員手動拋出的異常，Java運行時環境對異常的處理沒有任何差別。

 

4、訪問異常信息：

如果程序需要在catch塊中訪問異常對象的相關信息，則可以通過訪問catch塊的后異常形參來獲得。當Java運行時決定調用某個catch塊來處理該異常對象時，會將異常對象賦給catch塊后的異常參數，程序即可通過該參數來獲得異常的相關信息。

所有的異常對象都包括如下幾個常用的方法：

getMessage()：返回該異常信息的跟蹤棧信息輸出到標準錯誤輸出

printStackTrace()：將該異常的跟蹤棧信息輸出到標準錯誤輸出。

printStackTrace(PrintStream s)：將該異常的跟蹤棧信息輸出到指定輸出流。

getStackTrace()：返回該異常的跟蹤棧信息。

 

5、使用finally回收資源：

有些時候，程序在try塊里打開了一些物理資源（例如數據庫連接、網絡連接和磁盤文件），這些物理資源都必須显示回收。

在哪裡回收這些物理資源呢？在try塊里回收？還是在catch塊中進行回收？假設程序在try塊里進行資源回收，根據圖10.1所示的異常捕獲流程—一如果try塊的某條語句引起了異常，該語句后的其他語句通常不會獲得執行的機會，這將導致位於該語句之後的資源回收語句得不到執行。如果在catch塊里進行資源回收，但catch塊完全有可能得不到執行，這將導致不能及時回收這些物理資源。

為了保證一定能回收try塊中打開的物理資源，異常處理機制提供了finally塊。不管try塊中的代碼是否出現異常，也不管哪一個catch塊被執行，甚至在try塊或catch塊中執行了return語句，finally塊總會被執行。完整的Java異常處理語法結構如下：

try{
  //業務實現代碼
  ...
}catch(SubException e){
  //異常處理塊
  ...
}catch(SubException e2){
   //異常處理塊
   ...
}finally{
   //資源回收
   ...
}

　　

例如：

public class Test {
	
	public static void main(String[] args) throws Exception {
		try {
			int a=10;
			int b=0;
			int c=a/b;
		}catch(Exception e) {
			System.out.println("未知異常");
		}finally {
			System.out.println("資源回收");
		}
	}

}

　　

結果：

未知異常
資源回收

　　

 

總結：

 

 

 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※為什麼 USB CONNECTOR 是電子產業重要的元件?

※網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司，幫您輕鬆架站!

※想要讓你的商品成為最夯、最多人討論的話題?網頁設計公司讓你強力曝光

※想知道最厲害的台北網頁設計公司推薦、台中網頁設計公司推薦專業設計師”嚨底家”!!