IP地址和端口號(hào)
1）IP地址
用來(lái)標(biāo)志網(wǎng)絡(luò)中的一個(gè)通信實(shí)體的地址。通信實(shí)體可以是計(jì)算機(jī)，路由器等。
2）IP地址分類(lèi)
IPV4：32位地址，以點(diǎn)分十進(jìn)制表示，如192.168.0.1
IPV6：128位（16個(gè)字節(jié)）寫(xiě)成8個(gè)16位的無(wú)符號(hào)整數(shù)，每個(gè)整數(shù)用四個(gè)十六進(jìn)制位表示，數(shù)之間用冒號(hào)（：）分開(kāi)，如：
3ffe:3201:1401:1280:c8ff:fe4d:db39:1984
3）特殊的IP地址
127.0.0.1 本機(jī)地址
192.168.0.0--192.168.255.255私有地址，屬于非注冊(cè)地址，專(zhuān)門(mén)為組織機(jī)構(gòu)內(nèi)部使用。
4）端口:port
IP地址用來(lái)標(biāo)志一臺(tái)計(jì)算機(jī)，但是一臺(tái)計(jì)算機(jī)上可能提供多種應(yīng)用程序，使用端口來(lái)區(qū)分這些應(yīng)用程序。 端口是虛擬的概念，并不是說(shuō)在主機(jī)上真的有若干個(gè)端口。通過(guò)端口，可以在一個(gè)主機(jī)上運(yùn)行多個(gè)網(wǎng)絡(luò)應(yīng)用程序。 端口范圍0---65535,16位整數(shù)
5）端口分類(lèi)
公認(rèn)端口 0—1023 比如80端口分配給WWW，21端口分配給FTP，22端口分配給SSH,23端口分配給te.NET，25端口分配給smtp
注冊(cè)端口 1024—49151 分配給用戶(hù)進(jìn)程或應(yīng)用程序
動(dòng)態(tài)/私有端口 49152--65535
6）理解IP和端口的關(guān)系
IP地址好比每個(gè)人的地址（門(mén)牌號(hào)），端口好比是房間號(hào)。必須同時(shí)指定IP地址和端口號(hào)才能夠正確的發(fā)送數(shù)據(jù)
IP地址好比為電話號(hào)碼，而端口號(hào)就好比為分機(jī)號(hào)。
介紹OSI七層模型和TCP/IP模型
OSI(Open System Interconnection)，開(kāi)放式系統(tǒng)互聯(lián)參考模型 。是一個(gè)邏輯上的定義，一個(gè)規(guī)范，它把網(wǎng)絡(luò)協(xié)議從邏輯上分為了7層。每一層都有相關(guān)、相對(duì)應(yīng)的物理設(shè)備，比如常規(guī)的路由器是三層交換設(shè)備，常規(guī)的交換機(jī)是二層交換設(shè)備。OSI七層模型是一種框架性的設(shè)計(jì)方法，建立七層模型的主要目的是為解決異種網(wǎng)絡(luò)互連時(shí)所遇到的兼容性問(wèn)題，其最主要的功能就是幫助不同類(lèi)型的主機(jī)實(shí)現(xiàn)數(shù)據(jù)傳輸。它的最大優(yōu)點(diǎn)是將服務(wù)、接口和協(xié)議這三個(gè)概念明確地區(qū)分開(kāi)來(lái)，通過(guò)七個(gè)層次化的結(jié)構(gòu)模型使不同的系統(tǒng)不同的網(wǎng)絡(luò)之間實(shí)現(xiàn)可靠的通訊。
TCP/IP協(xié)議是Internet最基本的協(xié)議、Internet國(guó)際互聯(lián)網(wǎng)絡(luò)的基礎(chǔ)，主要由網(wǎng)絡(luò)層的IP協(xié)議和傳輸層的TCP協(xié)議組成。TCP/IP 定義了電子設(shè)備如何連入因特網(wǎng)，以及數(shù)據(jù)如何在它們之間傳輸?shù)臉?biāo)準(zhǔn)。協(xié)議采用了4層的層級(jí)結(jié)構(gòu)，每一層都呼叫它的下一層所提供的協(xié)議來(lái)完成自己的需求。
ISO制定的OSI參考模型的過(guò)于龐大、復(fù)雜招致了許多批評(píng)。伴隨著互聯(lián)網(wǎng)的流行，其本身所采用的TCP/IP協(xié)議棧獲得了更為廣泛的應(yīng)用和認(rèn)可。在TCP/IP參考模型中，去掉了OSI參考模型中的會(huì)話層和表示層（這兩層的功能被合并到應(yīng)用層實(shí)現(xiàn)）。同時(shí)將OSI參考模型中的數(shù)據(jù)鏈路層和物理層合并為主機(jī)到網(wǎng)絡(luò)層。
TCP協(xié)議和UDP協(xié)議的比較
TCP和UDP是TCP/IP協(xié)議棧中傳輸層的兩個(gè)協(xié)議，它們使用IP路由功能把數(shù)據(jù)包發(fā)送到目的地，從而為應(yīng)用程序及應(yīng)用層協(xié)議（包括：HTTP、SMTP、SNMP、FTP和Telnet）提供網(wǎng)絡(luò)服務(wù)。
TCP的server和client之間通信就好比兩個(gè)人打電話，需要互相知道對(duì)方的電話號(hào)碼，然后開(kāi)始對(duì)話。所以在兩者的連接過(guò)程中間需要指定端口和地址。
UDP的server和client之間的通信就像兩個(gè)人互相發(fā)信。我只需要知道對(duì)方的地址，然后就發(fā)信過(guò)去。對(duì)方是否收到我不知道，也不需要專(zhuān)門(mén)對(duì)口令似的來(lái)建立連接。具體區(qū)別如下：
1）TCP是面向連接的傳輸。UDP是無(wú)連接的傳輸
2）TCP有流量控制、擁塞控制，檢驗(yàn)數(shù)據(jù)數(shù)據(jù)按序到達(dá)，而UDP則相反。
3）TCP的路由選擇只發(fā)生在建立連接的時(shí)候，而UDP的每個(gè)報(bào)文都要進(jìn)行路由選擇
4）TCP是可靠性傳輸，他的可靠性是由超時(shí)重發(fā)機(jī)制實(shí)現(xiàn)的，而UDP則是不可靠傳輸
5）UDP因?yàn)樯倭撕芏嗫刂菩畔ⅲ詡鬏斔俣缺萒CP速度快
6）TCP適合用于傳輸大量數(shù)據(jù)，UDP適合用于傳輸小量數(shù)據(jù)
什么是Socket編程
Socket編程的定義如下：
所謂socket通常也稱(chēng)作"套接字"，用于描述IP地址和端口，是一個(gè)通信鏈的句柄。應(yīng)用程序通常通過(guò)"套接字"向網(wǎng)絡(luò)發(fā)出請(qǐng)求或者應(yīng)答網(wǎng)絡(luò)請(qǐng)求。
我們開(kāi)發(fā)的網(wǎng)絡(luò)應(yīng)用程序位于應(yīng)用層，TCP和UDP屬于傳輸層協(xié)議，在應(yīng)用層如何使用傳輸層的服務(wù)呢？在應(yīng)用層和傳輸層之間，則是使用套接字來(lái)進(jìn)行分離。
套接字就像是傳輸層為應(yīng)用層開(kāi)的一個(gè)小口，應(yīng)用程序通過(guò)這個(gè)小口向遠(yuǎn)程發(fā)送數(shù)據(jù)，或者接收遠(yuǎn)程發(fā)來(lái)的數(shù)據(jù)；而這個(gè)小口以?xún)?nèi)，也就是數(shù)據(jù)進(jìn)入這個(gè)口之后，或者數(shù)據(jù)從這個(gè)口出來(lái)之前，是不知道也不需要知道的，也不會(huì)關(guān)心它如何傳輸，這屬于網(wǎng)絡(luò)其它層次的工作。
Socket實(shí)際是傳輸層供給應(yīng)用層的編程接口。傳輸層則在網(wǎng)絡(luò)層的基礎(chǔ)上提供進(jìn)程到進(jìn)程問(wèn)的邏輯通道，而應(yīng)用層的進(jìn)程則利用傳輸層向另一臺(tái)主機(jī)的某一進(jìn)程通信。Socket就是應(yīng)用層與傳輸層之間的橋梁
使用Socket編程可以開(kāi)發(fā)客戶(hù)機(jī)和服務(wù)器應(yīng)用程序，可以在本地網(wǎng)絡(luò)上進(jìn)行通信，也可通過(guò)Internet在全球范圍內(nèi)通信。
生活案例1如果你想寫(xiě)封郵件發(fā)給遠(yuǎn)方的朋友，如何寫(xiě)信、將信打包，屬于應(yīng)用層。信怎么寫(xiě)，怎么打包完全由我們做主；而當(dāng)我們將信投入郵筒時(shí)，郵筒的那個(gè)口就是套接字，在進(jìn)入套接字之后，就是傳輸層、網(wǎng)絡(luò)層等（郵局、公路交管或者航線等）其它層次的工作了。我們從來(lái)不會(huì)去關(guān)心信是如何從西安發(fā)往北京的，我們只知道寫(xiě)好了投入郵筒就OK了。
生活案例2：可以把Socket比作是一個(gè)港口碼頭，應(yīng)用程序只要將數(shù)據(jù)交給Socket，就算完成了數(shù)據(jù)的發(fā)送，具體細(xì)節(jié)由Socket來(lái)完成，細(xì)節(jié)不必了解。同理，對(duì)于接收方，應(yīng)用程序也要?jiǎng)?chuàng)建一個(gè)碼頭，等待數(shù)據(jù)的到達(dá)，并獲取數(shù)據(jù)。
簡(jiǎn)述基于TCP和UDP的Socket編程的主要步驟
JAVA分別為T(mén)CP和UDP 兩種通信協(xié)議提供了相應(yīng)的Socket編程類(lèi)，這些類(lèi)存放在java.net包中。與TCP對(duì)應(yīng)的是服務(wù)器的ServerSocket和客戶(hù)端的Socket，與UDP對(duì)應(yīng)的是DatagramSocket。
基于TCP創(chuàng)建的套接字可以叫做流套接字，服務(wù)器端相當(dāng)于一個(gè)監(jiān)聽(tīng)器，用來(lái)監(jiān)聽(tīng)端口。 服務(wù)器與客服端之間的通訊都是輸入輸出流來(lái)實(shí)現(xiàn)的。基于UDP的套接字就是數(shù)據(jù)報(bào)套接字，• 兩個(gè)都要先構(gòu)造好相應(yīng)的數(shù)據(jù)包。
基于TCP協(xié)議的Socket編程的主要步驟
服務(wù)器端（server）：
1. 構(gòu)建一個(gè)ServerSocket實(shí)例，指定本地的端口。這個(gè)socket就是用來(lái)監(jiān)聽(tīng)指定端口的連接請(qǐng)求的。
2. 重復(fù)如下幾個(gè)步驟：
a. 調(diào)用socket的accept()方法來(lái)獲得下面客戶(hù)端的連接請(qǐng)求。通過(guò)accept()方法返回的socket實(shí)例，建立了一個(gè)和客戶(hù)端的新連接。
b. 通過(guò)這個(gè)返回的socket實(shí)例獲取InputStream和OutputStream,可以通過(guò)這兩個(gè)stream來(lái)分別讀和寫(xiě)數(shù)據(jù)。
c. 結(jié)束的時(shí)候調(diào)用socket實(shí)例的close()方法關(guān)閉socket連接。
客戶(hù)端（client）：
1.構(gòu)建Socket實(shí)例，通過(guò)指定的遠(yuǎn)程服務(wù)器地址和端口來(lái)建立連接。
2.通過(guò)Socket實(shí)例包含的InputStream和OutputStream來(lái)進(jìn)行數(shù)據(jù)的讀寫(xiě)。
3.操作結(jié)束后調(diào)用socket實(shí)例的close方法，關(guān)閉。
UDP
服務(wù)器端（server）：
1. 構(gòu)造DatagramSocket實(shí)例，指定本地端口。
2. 通過(guò)DatagramSocket實(shí)例的receive方法接收
DatagramPacket.DatagramPacket中間就包含了通信的內(nèi)容。
3. 通過(guò)DatagramSocket的send和receive方法來(lái)收和發(fā)DatagramPacket.
客戶(hù)端（client）：
1. 構(gòu)造DatagramSocket實(shí)例。
2. 通過(guò)DatagramSocket實(shí)例的send和receive方法發(fā)送DatagramPacket報(bào)文。
3. 結(jié)束后，調(diào)用DatagramSocket的close方法關(guān)閉。
異常處理：
下列哪種異常是檢查型異常，需要在編寫(xiě)程序時(shí)聲明（）
A.NullPointerException
B.ClassCastException
C.FileNotFoundException
D.IndexOutOfBoundsException
答案：C
分析：NullPointerException空指針異常
ClassCastException類(lèi)型轉(zhuǎn)換異常
IndexOutOfBoundsException索引超出邊界的異常
以上這些異常都是程序在運(yùn)行時(shí)發(fā)生的異常，所以不需要在編寫(xiě)程序時(shí)聲明
Java出現(xiàn)OutOf MemoryError（OOM 錯(cuò)誤)的原因有哪些？出現(xiàn)OOM錯(cuò)誤后，怎么解決？
答:OutOf MemoryError這種錯(cuò)誤可以細(xì)分為多種不同的錯(cuò)誤，每種錯(cuò)誤都有自身的原因和解決辦法，如下所示：
java.lang.OutOfMemoryError: Java heap space
錯(cuò)誤原因：此OOM是由于JVM中heap的最大值不滿(mǎn)足需要。
解決方法：1) 調(diào)高h(yuǎn)eap的最大值，即-Xmx的值調(diào)大。2) 如果你的程序存在內(nèi)存泄漏，一味的增加heap空間也只是推遲該錯(cuò)誤出現(xiàn)的時(shí)間而已，所以要檢查程序是否存在內(nèi)存泄漏。
java.lang.OutOfMemoryError: GC overhead limit exceeded
錯(cuò)誤原因：此OOM是由于JVM在GC時(shí)，對(duì)象過(guò)多，導(dǎo)致內(nèi)存溢出，建議調(diào)整GC的策略，在一定比例下開(kāi)始GC而不要使用默認(rèn)的策略，或者將新代和老代設(shè)置合適的大小，需要進(jìn)行微調(diào)存活率。
解決方法：改變GC策略，在老代80%時(shí)就是開(kāi)始GC，并且將-XX:SurvivorRatio（-XX:SurvivorRatio=8）和-XX:NewRatio（-XX:NewRatio=4）設(shè)置的更合理。
java.lang.OutOfMemoryError: Java perm space
錯(cuò)誤原因：此OOM是由于JVM中perm的最大值不滿(mǎn)足需要。
解決方法：調(diào)高h(yuǎn)eap的最大值，即-XX:MaxPermSize的值調(diào)大。
另外，注意一點(diǎn)，Perm一般是在JVM啟動(dòng)時(shí)加載類(lèi)進(jìn)來(lái)，如果是JVM運(yùn)行較長(zhǎng)一段時(shí)間而不是剛啟動(dòng)后溢出的話，很有可能是由于運(yùn)行時(shí)有類(lèi)被動(dòng)態(tài)加載進(jìn)來(lái)，此時(shí)建議用CMS策略中的類(lèi)卸載配置。如：-XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled。
java.lang.OutOfMemoryError: unable to create new native thread
錯(cuò)誤原因：當(dāng)JVM向OS請(qǐng)求創(chuàng)建一個(gè)新線程時(shí)，而OS卻由于內(nèi)存不足無(wú)法創(chuàng)建新的native線程。
解決方法：如果JVM內(nèi)存調(diào)的過(guò)大或者可利用率小于20%，可以建議將heap及perm的最大值下調(diào)，并將線程棧調(diào)小，即-Xss調(diào)小，如：-Xss128k。
java.lang.OutOfMemoryError: Requested array size exceeds VM limit
錯(cuò)誤原因：此類(lèi)信息表明應(yīng)用程序（或者被應(yīng)用程序調(diào)用的APIs）試圖分配一個(gè)大于堆大小的數(shù)組。例如，如果應(yīng)用程序new一個(gè)數(shù)組對(duì)象，大小為512M，但是最大堆大小為256M，因此OutOfMemoryError會(huì)拋出，因?yàn)閿?shù)組的大小超過(guò)虛擬機(jī)的限制。
解決方法：1) 首先檢查heap的-Xmx是不是設(shè)置的過(guò)小。2) 如果heap的-Xmx已經(jīng)足夠大，那么請(qǐng)檢查應(yīng)用程序是不是存在bug，例如：應(yīng)用程序可能在計(jì)算數(shù)組的大小時(shí)，存在算法錯(cuò)誤，導(dǎo)致數(shù)組的size很大，從而導(dǎo)致巨大的數(shù)組被分配。
java.lang.OutOfMemoryError: request < size> bytes for < reason>. Out of swap space
錯(cuò)誤原因：拋出這類(lèi)錯(cuò)誤，是由于從native堆中分配內(nèi)存失敗，并且堆內(nèi)存可能接近耗盡。這類(lèi)錯(cuò)誤可能跟應(yīng)用程序沒(méi)有關(guān)系，例如下面兩種原因也會(huì)導(dǎo)致錯(cuò)誤的發(fā)生：1) 操作系統(tǒng)配置了較小的交換區(qū)。2)系統(tǒng)的另外一個(gè)進(jìn)程正在消耗所有的內(nèi)存。
解決辦法：1) 檢查os的swap是不是沒(méi)有設(shè)置或者設(shè)置的過(guò)小。2) 檢查是否有其他進(jìn)程在消耗大量的內(nèi)存，從而導(dǎo)致當(dāng)前的JVM內(nèi)存不夠分配。
注意：雖然有時(shí)< reason>部分顯示導(dǎo)致OOM的原因，但大多數(shù)情況下，< reason>顯示的是提示分配失敗的源模塊的名稱(chēng)，所以有必要查看日志文件，如crash時(shí)的hs文件。
列舉常見(jiàn)的運(yùn)行時(shí)異常
答:ClassCastException(類(lèi)轉(zhuǎn)換異常)
比如 Object obj=new Object(); String s=(String)obj;
IndexOutOfBoundsException(下標(biāo)越界異常)
NullPointerException(空指針異常)
ArrayStoreException(數(shù)據(jù)存儲(chǔ)異常，操作數(shù)組時(shí)類(lèi)型不一致)
BufferOverflowException(IO操作時(shí)出現(xiàn)的緩沖區(qū)上溢異常)
InputMismatchException(輸入類(lèi)型不匹配異常)
ArithmeticException(算術(shù)異常)
注意：運(yùn)行時(shí)異常都是RuntimeException子類(lèi)異常。
下面關(guān)于 Java.lang.Exception類(lèi)的說(shuō)法正確的是（）
A.繼承自 Throwable
B.不支持Serializable
C.繼承自 AbstractSet
D.繼承自FitelnputStream
答案：A
分析：Throwable是Exception和Error的父類(lèi)，Exception雖然沒(méi)有實(shí)現(xiàn)Serializable接口，但是其父類(lèi)Throwable已經(jīng)實(shí)現(xiàn)了該接口，因此Exception也支持Serializable。
Unsupported major.minor version 52是什么異常，怎么造成的，如何解決？
答：?jiǎn)栴}的根本原因是工程中某個(gè)jar包的版本（jar包編譯時(shí)的所用的jdk版本）高于工程build path中jdk的版本，這個(gè)是不兼容的! 編程中遇到此異常Unsupported major.minor version 52.0（根據(jù)版本號(hào)，這里可以為其他數(shù)值，52是1.8jdk jar包與 1.8以下低版本jdk不匹配），在將build path中jdk的版本調(diào)整與jar包匹配后，解決異常。
try{}里有一個(gè)return語(yǔ)句，那么緊跟在這個(gè)try后的finally{}里的code會(huì)不會(huì)被執(zhí)行，什么時(shí)候被執(zhí)行，在return前還是后?
答：會(huì)執(zhí)行，在方法返回調(diào)用者前執(zhí)行。Java允許在finally中改變返回值的做法是不好的，因?yàn)槿绻嬖趂inally代碼塊，try中的return語(yǔ)句不會(huì)立馬返回調(diào)用者，而是記錄下返回值待finally代碼塊執(zhí)行完畢之后再向調(diào)用者返回其值，然后如果在finally中修改了返回值，這會(huì)對(duì)程序造成很大的困擾，C#中就從語(yǔ)法上規(guī)定不能做這樣的事。
(也許你的答案是在return之前，但往更細(xì)地說(shuō)，我的答案是在return中間執(zhí)行，請(qǐng)看下面程序代碼的運(yùn)行結(jié)果：
public classTest {
/**
* @paramargs add by zxx ,Dec 9, 2008
*/
public static voidmain(String[] args) {
// TODO Auto-generated method stub
System.out.println(newTest().test());;
}
static int test()
{
int x = 1;
try
{
returnx;
}
finally
{
++x;
}
}
}
執(zhí)行結(jié)果
運(yùn)行結(jié)果是1，為什么呢？主函數(shù)調(diào)用子函數(shù)并得到結(jié)果的過(guò)程，好比主函數(shù)準(zhǔn)備一個(gè)空罐子，當(dāng)子函數(shù)要返回結(jié)果時(shí)，先把結(jié)果放在罐子里，然后再將程序邏輯返回到主函數(shù)。所謂返回，就是子函數(shù)說(shuō)，我不運(yùn)行了，你主函數(shù)繼續(xù)運(yùn)行吧，這沒(méi)什么結(jié)果可言，結(jié)果是在說(shuō)這話之前放進(jìn)罐子里的。
Java 語(yǔ)言如何進(jìn)行異常處理，關(guān)鍵字：throws、throw、try、catch、finally分別如何使用？
答：Java 通過(guò)面向?qū)ο蟮姆椒ㄟM(jìn)行異常處理，把各種不同的異常進(jìn)行分類(lèi)，并提供了良好的接口。在Java 中，每個(gè)異常都是一個(gè)對(duì)象，它是Throwable 類(lèi)或其子類(lèi)的實(shí)例。當(dāng)一個(gè)方法出現(xiàn)異常后便拋出一個(gè)異常對(duì)象，該對(duì)象中包含有異常信息，調(diào)用這個(gè)對(duì)象的方法可以捕獲到這個(gè)異常并進(jìn)行處理。Java 的異常處理是通過(guò)5 個(gè)關(guān)鍵詞來(lái)實(shí)現(xiàn)的：try、catch、throw、throws和finally。一般情況下是用try來(lái)執(zhí)行一段程序，如果出現(xiàn)異常，系統(tǒng)會(huì)拋出（throw）一個(gè)異常，這時(shí)候你可以通過(guò)它的類(lèi)型來(lái)捕捉（catch）它，或最后（finally）由缺省處理器來(lái)處理；try用來(lái)指定一塊預(yù)防所有“異常”的程序；catch 子句緊跟在try塊后面，用來(lái)指定你想要捕捉的“異常”的類(lèi)型；throw 語(yǔ)句用來(lái)明確地拋出一個(gè)“異常”；throws用來(lái)標(biāo)明一個(gè)成員函數(shù)可能拋出的各種“異常”；finally 為確保一段代碼不管發(fā)生什么“異常”都被執(zhí)行一段代碼；可以在一個(gè)成員函數(shù)調(diào)用的外面寫(xiě)一個(gè)try語(yǔ)句，在這個(gè)成員函數(shù)內(nèi)部寫(xiě)另一個(gè)try語(yǔ)句保護(hù)其他代碼。每當(dāng)遇到一個(gè)try 語(yǔ)句，“異常”的框架就放到棧上面，直到所有的try語(yǔ)句都完成。如果下一級(jí)的try語(yǔ)句沒(méi)有對(duì)某種“異常”進(jìn)行處理，棧就會(huì)展開(kāi)，直到遇到有處理這種“異常”的try 語(yǔ)句。
運(yùn)行時(shí)異常與受檢異常有何異同？
答：異常表示程序運(yùn)行過(guò)程中可能出現(xiàn)的非正常狀態(tài)，運(yùn)行時(shí)異常表示虛擬機(jī)的通常操作中可能遇到的異常，是一種常見(jiàn)運(yùn)行錯(cuò)誤，只要程序設(shè)計(jì)得沒(méi)有問(wèn)題通常就不會(huì)發(fā)生。受檢異常跟程序運(yùn)行的上下文環(huán)境有關(guān)，即使程序設(shè)計(jì)無(wú)誤，仍然可能因使用的問(wèn)題而引發(fā)。Java編譯器要求方法必須聲明拋出可能發(fā)生的受檢異常，但是并不要求必須聲明拋出未被捕獲的運(yùn)行時(shí)異常。異常和繼承一樣，是面向?qū)ο蟪绦蛟O(shè)計(jì)中經(jīng)常被濫用的東西，神作《Effective Java》中對(duì)異常的使用給出了以下指導(dǎo)原則：
不要將異常處理用于正常的控制流（設(shè)計(jì)良好的API不應(yīng)該強(qiáng)迫它的調(diào)用者為了正常的控制流而使用異常）
對(duì)可以恢復(fù)的情況使用受檢異常，對(duì)編程錯(cuò)誤使用運(yùn)行時(shí)異常
避免不必要的使用受檢異常（可以通過(guò)一些狀態(tài)檢測(cè)手段來(lái)避免異常發(fā)生）
優(yōu)先使用標(biāo)準(zhǔn)的異常
每個(gè)方法拋出的異常都要有文檔
保持異常的原子性
不要在catch中忽略掉捕獲到的異常
(異常表示程序運(yùn)行過(guò)程中可能出現(xiàn)的非正常狀態(tài)，運(yùn)行時(shí)異常表示虛擬機(jī)的通常操作中可能遇到的異常，是一種常見(jiàn)運(yùn)行錯(cuò)誤。java編譯器要求方法必須聲明拋出可能發(fā)生的非運(yùn)行時(shí)異常，但是并不要求必須聲明拋出未被捕獲的運(yùn)行時(shí)異常。)
類(lèi)ExampleA 繼承Exception，類(lèi)ExampleB 繼承ExampleA
有如下代碼片斷：
try{
throw new ExampleB("b")
}catch（ExampleA e）{
System.out.println("ExampleA");
}catch（Exception e）{
System.out.println("Exception");
}
}
請(qǐng)問(wèn)執(zhí)行此段代碼的輸出是什么？
答：輸出：ExampleA。（根據(jù)里氏代換原則[能使用父類(lèi)型的地方一定能使用子類(lèi)型]，抓取ExampleA類(lèi)型異常的catch塊能夠抓住try塊中拋出的ExampleB類(lèi)型的異常）
補(bǔ)充： 比此題略復(fù)雜的一道面試題如下所示（此題的出處是《Java編程思想》），說(shuō)出你的答案吧！
package com.bjsxt;
class Annoyance extends Exception {}
class Sneeze extends Annoyance {}
class Human {
public static void main(String[] args)
throws Exception {
try {
try {
throw new Sneeze();
}
catch ( Annoyance a ) {
System.out.println("Caught Annoyance");
throw a;
}
}
catch ( Sneeze s ) {
System.out.println("Caught Sneeze");
return ;
}
finally {
System.out.println("Hello World!");
}
}
}
輸出為：
Caught Annoyance
Caught Sneeze
Hello World!
Error和Exception的區(qū)別
Error類(lèi)，表示僅靠程序本身無(wú)法恢復(fù)的嚴(yán)重錯(cuò)誤，比如說(shuō)內(nèi)存溢出、動(dòng)態(tài)鏈接異常、虛擬機(jī)錯(cuò)誤。應(yīng)用程序不應(yīng)該拋出這種類(lèi)型的對(duì)象。假如出現(xiàn)這種錯(cuò)誤，除了盡力使程序安全退出外，在其他方面是無(wú)能為力的。所以在進(jìn)行程序設(shè)計(jì)時(shí)，應(yīng)該更關(guān)注Exception類(lèi)。
Exception類(lèi)，由Java應(yīng)用程序拋出和處理的非嚴(yán)重錯(cuò)誤，比如所需文件沒(méi)有找到、零作除數(shù)，數(shù)組下標(biāo)越界等。它的各種不同子類(lèi)分別對(duì)應(yīng)不同類(lèi)型異常。可分為兩類(lèi)：Checked異常和Runtime異常
Java異常處理try-catch-finally的執(zhí)行過(guò)程
try-catch-finally程序塊的執(zhí)行流程以及執(zhí)行結(jié)果比較復(fù)雜。
基本執(zhí)行過(guò)程如下：
1）程序首先執(zhí)行可能發(fā)生異常的try語(yǔ)句塊。
2）如果try語(yǔ)句沒(méi)有出現(xiàn)異常則執(zhí)行完后跳至finally語(yǔ)句塊執(zhí)行；
3）如果try語(yǔ)句出現(xiàn)異常，則中斷執(zhí)行并根據(jù)發(fā)生的異常類(lèi)型跳至相應(yīng)的catch語(yǔ)句塊執(zhí)行處理。
4）catch語(yǔ)句塊可以有多個(gè)，分別捕獲不同類(lèi)型的異常。
5）catch語(yǔ)句塊執(zhí)行完后程序會(huì)繼續(xù)執(zhí)行finally語(yǔ)句塊。
finally語(yǔ)句是可選的，如果有的話，則不管是否發(fā)生異常，finally語(yǔ)句都會(huì)被執(zhí)行。需要注意的是即使try和catch塊中存在return語(yǔ)句，finally語(yǔ)句也會(huì)執(zhí)行，是在執(zhí)行完finally語(yǔ)句后再通過(guò)return退出。
異常處理中throws和throw的區(qū)別
1）作用不同：
throw用于程序員自行產(chǎn)生并拋出異常；
throws用于聲明在該方法內(nèi)拋出了異常
2） 使用的位置不同：
throw位于方法體內(nèi)部，可以作為單獨(dú)語(yǔ)句使用；
throws必須跟在方法參數(shù)列表的后面，不能單獨(dú)使用。
3）內(nèi)容不同：
throw拋出一個(gè)異常對(duì)象，且只能是一個(gè)；
throws后面跟異常類(lèi)，而且可以有多個(gè)。
