2.Java的四個(gè)基本特性（抽象、封裝、繼承，多態(tài)）

抽象：就是把現(xiàn)實(shí)生活中的某一類東西提取出來，用程序代碼表示，我們通常叫做類或者接口。抽象包括兩個(gè)方面：一個(gè)是數(shù)據(jù)抽象，一個(gè)是過程抽象。數(shù)據(jù)抽象也就是對象的屬性。過程抽象是對象的行為特征。
封裝：把客觀事物封裝成抽象的類，并且類可以把自己的數(shù)據(jù)和方法只讓可信的類或者對象操作，對不可信的進(jìn)行封裝隱藏。封裝分為屬性的封裝和方法的封裝。
繼承：是對有著共同特性的多類事物，進(jìn)行再抽象成一個(gè)類。這個(gè)類就是多類事物的父類。父類的意義在于抽取多類事物的共性。
多態(tài)：允許不同類的對象對同一消息做出響應(yīng)。方法的重載、類的覆蓋正體現(xiàn)了多態(tài)。

3.重載和重寫的區(qū)別

重載：發(fā)生在同一個(gè)類中，方法名必須相同，參數(shù)類型不同、個(gè)數(shù)不同、順序不同，方法返回值和訪問修飾符可以不同，發(fā)生在編譯時(shí)。
重寫：發(fā)生在父子類中，方法名、參數(shù)列表必須相同，返回值小于等于父類，拋出的異常小于等于父類，訪問修飾符大于等于父類；如果父類方法訪問修飾符為private則子類中就不是重寫。

4.構(gòu)造器Constructor是否可被override

構(gòu)造器不能被重寫，不能用static修飾構(gòu)造器，只能用public
private protected這三個(gè)權(quán)限修飾符，且不能有返回語句。

5.訪問控制符public,protected,private,以及默認(rèn)的區(qū)別

private只有在本類中才能訪問；
public在任何地方都能訪問；
protected在同包內(nèi)的類及包外的子類能訪問；
默認(rèn)不寫在同包內(nèi)能訪問。
6是否可以繼承String類#
String類是final類故不可以繼承，一切由final修飾過的都不能繼承。

7.String和StringBuffer、StringBuilder的區(qū)別#

可變性
String類中使用字符數(shù)組保存字符串，private
final char value[]，所以string對象是不可變的。StringBuilder與StringBuffer都繼承自AbstractStringBuilder類，在AbstractStringBuilder中也是使用字符數(shù)組保存字符串，char[]
value，這兩種對象都是可變的。
線程安全性
String中的對象是不可變的，也就可以理解為常量，線程安全。AbstractStringBuilder是StringBuilder與StringBuffer的公共父類，定義了一些字符串的基本操作，如expandCapacity、append、insert、indexOf等公共方法。StringBuffer對方法加了同步鎖或者對調(diào)用的方法加了同步鎖，所以是線程安全的。StringBuilder并沒有對方法進(jìn)行加同步鎖，所以是非線程安全的。
性能
每次對String 類型進(jìn)行改變的時(shí)候，都會(huì)生成一個(gè)新的String 對象，然后將指針指向新的String 對象。StringBuffer每次都會(huì)對
StringBuffer 對象本身進(jìn)行操作，而不是生成新的對象并改變對象引用。相同情況下使用
StirngBuilder 相比使用
StringBuffer 僅能獲得10%~15% 左右的性能提升，但卻要冒多線程不安全的風(fēng)險(xiǎn)。

8.hashCode和equals方法的關(guān)系#

equals相等，hashcode必相等；hashcode相等，equals可能不相等。

9.抽象類和接口的區(qū)別#

語法層次
抽象類和接口分別給出了不同的語法定義。
設(shè)計(jì)層次
抽象層次不同，抽象類是對類抽象，而接口是對行為的抽象。抽象類是對整個(gè)類整體進(jìn)行抽象，包括屬性、行為，但是接口卻是對類局部（行為）進(jìn)行抽象。抽象類是自底向上抽象而來的，接口是自頂向下設(shè)計(jì)出來的。
跨域不同
抽象類所體現(xiàn)的是一種繼承關(guān)系，要想使得繼承關(guān)系合理，父類和派生類之間必須存在"is-a"
關(guān)系，即父類和派生類在概念本質(zhì)上應(yīng)該是相同的。對于接口則不然，并不要求接口的實(shí)現(xiàn)者和接口定義在概念本質(zhì)上是一致的，僅僅是實(shí)現(xiàn)了接口定義的契約而已，"like-a"的關(guān)系。

10.自動(dòng)裝箱與拆箱#

裝箱：將基本類型用它們對應(yīng)的引用類型包裝起來；
拆箱：將包裝類型轉(zhuǎn)換為基本數(shù)據(jù)類型；
Java使用自動(dòng)裝箱和拆箱機(jī)制，節(jié)省了常用數(shù)值的內(nèi)存開銷和創(chuàng)建對象的開銷，提高了效率，由編譯器來完成，編譯器會(huì)在編譯期根據(jù)語法決定是否進(jìn)行裝箱和拆箱動(dòng)作。

11.什么是泛型、為什么要使用以及泛型擦除#

泛型，即“參數(shù)化類型”。
創(chuàng)建集合時(shí)就指定集合元素的類型，該集合只能保存其指定類型的元素，避免使用強(qiáng)制類型轉(zhuǎn)換。
Java編譯器生成的字節(jié)碼是不包涵泛型信息的，泛型類型信息將在編譯處理是被擦除，這個(gè)過程即類型擦除。泛型擦除可以簡單的理解為將泛型java代碼轉(zhuǎn)換為普通java代碼，只不過編譯器更直接點(diǎn)，將泛型java代碼直接轉(zhuǎn)換成普通java字節(jié)碼。
類型擦除的主要過程如下：
1）.將所有的泛型參數(shù)用其最左邊界（最頂級的父類型）類型替換。
2）.移除所有的類型參數(shù)。

12.Java中的集合類及關(guān)系圖#

List和Set繼承自Collection接口。
Set無序不允許元素重復(fù)。HashSet和TreeSet是兩個(gè)主要的實(shí)現(xiàn)類。
List有序且允許元素重復(fù)。ArrayList、LinkedList和Vector是三個(gè)主要的實(shí)現(xiàn)類。
Map也屬于集合系統(tǒng)，但和Collection接口沒關(guān)系。Map是key對value的映射集合，其中key列就是一個(gè)集合。key不能重復(fù)，但是value可以重復(fù)。HashMap、TreeMap和Hashtable是三個(gè)主要的實(shí)現(xiàn)類。
SortedSet和SortedMap接口對元素按指定規(guī)則排序，SortedMap是對key列進(jìn)行排序。

13.HashMap實(shí)現(xiàn)原理#

具體原理參考文章：
http://zhangshixi.iteye.com/blog/672697
http://www.admin10000.com/document/3322.html

14.HashTable實(shí)現(xiàn)原理#

具體原理參考文章：
http://www.cnblogs.com/skywang12345/p/3310887.html
http://blog.csdn.net/chdjj/article/details/38581035

15.HashMap和HashTable區(qū)別#

1）.HashTable的方法前面都有synchronized來同步，是線程安全的；HashMap未經(jīng)同步，是非線程安全的。
2）.HashTable不允許null值(key和value都不可以) ；HashMap允許null值(key和value都可以)。
3）.HashTable有一個(gè)contains(Object
value)功能和containsValue(Object
value)功能一樣。
4）.HashTable使用Enumeration進(jìn)行遍歷；HashMap使用Iterator進(jìn)行遍歷。
5）.HashTable中hash數(shù)組默認(rèn)大小是11，增加的方式是old*2+1；HashMap中hash數(shù)組的默認(rèn)大小是16，而且一定是2的指數(shù)。
6）.哈希值的使用不同，HashTable直接使用對象的hashCode； HashMap重新計(jì)算hash值，而且用與代替求模。

16.ArrayList和vector區(qū)別#

ArrayList和Vector都實(shí)現(xiàn)了List接口，都是通過數(shù)組實(shí)現(xiàn)的。
Vector是線程安全的，而ArrayList是非線程安全的。
List第一次創(chuàng)建的時(shí)候，會(huì)有一個(gè)初始大小，隨著不斷向List中增加元素，當(dāng)List 認(rèn)為容量不夠的時(shí)候就會(huì)進(jìn)行擴(kuò)容。Vector缺省情況下自動(dòng)增長原來一倍的數(shù)組長度，ArrayList增長原來的50%。

17.ArrayList和LinkedList區(qū)別及使用場景#

區(qū)別
ArrayList底層是用數(shù)組實(shí)現(xiàn)的，可以認(rèn)為ArrayList是一個(gè)可改變大小的數(shù)組。隨著越來越多的元素被添加到ArrayList中，其規(guī)模是動(dòng)態(tài)增加的。
LinkedList底層是通過雙向鏈表實(shí)現(xiàn)的， LinkedList和ArrayList相比，增刪的速度較快。但是查詢和修改值的速度較慢。同時(shí)，LinkedList還實(shí)現(xiàn)了Queue接口，所以他還提供了offer(),
peek(), poll()等方法。
使用場景
LinkedList更適合從中間插入或者刪除（鏈表的特性）。
ArrayList更適合檢索和在末尾插入或刪除（數(shù)組的特性）。

18.Collection和Collections的區(qū)別#

java.util.Collection 是一個(gè)集合接口。它提供了對集合對象進(jìn)行基本操作的通用接口方法。Collection接口在Java 類庫中有很多具體的實(shí)現(xiàn)。Collection接口的意義是為各種具體的集合提供了最大化的統(tǒng)一操作方式。
java.util.Collections 是一個(gè)包裝類。它包含有各種有關(guān)集合操作的靜態(tài)多態(tài)方法。此類不能實(shí)例化，就像一個(gè)工具類，服務(wù)于Java的Collection框架。

19.Concurrenthashmap實(shí)現(xiàn)原理#

具體原理參考文章：
http://www.cnblogs.com/ITtangtang/p/3948786.html
http://ifeve.com/concurrenthashmap/

20.Error、Exception區(qū)別#

Error類和Exception類的父類都是throwable類，他們的區(qū)別是：
Error類一般是指與虛擬機(jī)相關(guān)的問題，如系統(tǒng)崩潰，虛擬機(jī)錯(cuò)誤，內(nèi)存空間不足，方法調(diào)用棧溢等。對于這類錯(cuò)誤的導(dǎo)致的應(yīng)用程序中斷，僅靠程序本身無法恢復(fù)和和預(yù)防，遇到這樣的錯(cuò)誤，建議讓程序終止。
Exception類表示程序可以處理的異常，可以捕獲且可能恢復(fù)。遇到這類異常，應(yīng)該盡可能處理異常，使程序恢復(fù)運(yùn)行，而不應(yīng)該隨意終止異常。

21.Unchecked

Exception和Checked Exception，各列舉幾個(gè)#
Unchecked Exception:
a. 指的是程序的瑕疵或邏輯錯(cuò)誤，并且在運(yùn)行時(shí)無法恢復(fù)。
b. 包括Error與RuntimeException及其子類，如：OutOfMemoryError,
UndeclaredThrowableException, IllegalArgumentException,
IllegalMonitorStateException, NullPointerException, IllegalStateException,
IndexOutOfBoundsException等。
c. 語法上不需要聲明拋出異常。

Checked Exception:
a. 代表程序不能直接控制的無效外界情況（如用戶輸入，數(shù)據(jù)庫問題，網(wǎng)絡(luò)異常，文件丟失等）
b. 除了Error和RuntimeException及其子類之外，如：ClassNotFoundException,
NamingException, ServletException, SQLException, IOException等。
c. 需要try catch處理或throws聲明拋出異常。

22.Java中如何實(shí)現(xiàn)代理機(jī)制(JDK、CGLIB)#

JDK動(dòng)態(tài)代理：代理類和目標(biāo)類實(shí)現(xiàn)了共同的接口，用到InvocationHandler接口。
CGLIB動(dòng)態(tài)代理：代理類是目標(biāo)類的子類，用到MethodInterceptor接口。

23.多線程的實(shí)現(xiàn)方式#

繼承Thread類、實(shí)現(xiàn)Runnable接口、使用ExecutorService、Callable、Future實(shí)現(xiàn)有返回結(jié)果的多線程。

24.線程的狀態(tài)轉(zhuǎn)換#

20140828202610671.jpg

25.如何停止一個(gè)線程#

參考文章：
http://www.cnblogs.com/greta/p/5624839.html

26.什么是線程安全#

線程安全就是多線程訪問同一代碼，不會(huì)產(chǎn)生不確定的結(jié)果。

27.如何保證線程安全#

對非安全的代碼進(jìn)行加鎖控制；
使用線程安全的類；
多線程并發(fā)情況下，線程共享的變量改為方法級的局部變量。

28.synchronized如何使用#

synchronized是Java中的關(guān)鍵字，是一種同步鎖。它修飾的對象有以下幾種：
1). 修飾一個(gè)代碼塊，被修飾的代碼塊稱為同步語句塊，其作用的范圍是大括號(hào){}括起來的代碼，作用的對象是調(diào)用這個(gè)代碼塊的對象；
2). 修飾一個(gè)方法，被修飾的方法稱為同步方法，其作用的范圍是整個(gè)方法，作用的對象是調(diào)用這個(gè)方法的對象；
3). 修改一個(gè)靜態(tài)的方法，其作用的范圍是整個(gè)靜態(tài)方法，作用的對象是這個(gè)類的所有對象；
4). 修改一個(gè)類，其作用的范圍是synchronized后面括號(hào)括起來的部分，作用主的對象是這個(gè)類的所有對象。

29.synchronized和Lock的區(qū)別#

主要相同點(diǎn)：Lock能完成synchronized所實(shí)現(xiàn)的所有功能
主要不同點(diǎn)：Lock有比synchronized更精確的線程語義和更好的性能。Lock的鎖定是通過代碼實(shí)現(xiàn)的，而synchronized是在JVM層面上實(shí)現(xiàn)的，synchronized會(huì)自動(dòng)釋放鎖，而Lock一定要求程序員手工釋放，并且必須在finally從句中釋放。Lock還有更強(qiáng)大的功能，例如，它的tryLock方法可以非阻塞方式去拿鎖。Lock鎖的范圍有局限性，塊范圍，而synchronized可以鎖住塊、對象、類。

30.多線程如何進(jìn)行信息交互#

void notify() 喚醒在此對象監(jiān)視器上等待的單個(gè)線程。
void notifyAll() 喚醒在此對象監(jiān)視器上等待的所有線程。
void wait() 導(dǎo)致當(dāng)前的線程等待，直到其他線程調(diào)用此對象的notify()方法或notifyAll()方法。
void wait(long timeout) 導(dǎo)致當(dāng)前的線程等待，直到其他線程調(diào)用此對象的notify()方法或notifyAll()方法，或者超過指定的時(shí)間量。
void wait(long timeout, int nanos) 導(dǎo)致當(dāng)前的線程等待，直到其他線程調(diào)用此對象的notify()方法或notifyAll()方法，或者其他某個(gè)線程中斷當(dāng)前線程，或者已超過某個(gè)實(shí)際時(shí)間量。

31.sleep和wait的區(qū)別(考察的方向是是否會(huì)釋放鎖)#

sleep()方法是Thread類中方法，而wait()方法是Object類中的方法。
sleep()方法導(dǎo)致了程序暫停執(zhí)行指定的時(shí)間，讓出cpu該其他線程，但是他的監(jiān)控狀態(tài)依然保持者，當(dāng)指定的時(shí)間到了又會(huì)自動(dòng)恢復(fù)運(yùn)行狀態(tài)，在調(diào)用sleep()方法的過程中，線程不會(huì)釋放對象鎖。而當(dāng)調(diào)用wait()方法的時(shí)候，線程會(huì)放棄對象鎖，進(jìn)入等待此對象的等待鎖定池，只有針對此對象調(diào)用notify()方法后本線程才進(jìn)入對象鎖定池準(zhǔn)備。

32.多線程與死鎖#

死鎖是指兩個(gè)或兩個(gè)以上的進(jìn)程在執(zhí)行過程中，因爭奪資源而造成的一種互相等待的現(xiàn)象，若無外力作用，它們都將無法推進(jìn)下去。
產(chǎn)生死鎖的原因：
一.因?yàn)橄到y(tǒng)資源不足。
二.進(jìn)程運(yùn)行推進(jìn)的順序不合適。
三.資源分配不當(dāng)。

33.如何才能產(chǎn)生死鎖#

產(chǎn)生死鎖的四個(gè)必要條件：
一.互斥條件：所謂互斥就是進(jìn)程在某一時(shí)間內(nèi)獨(dú)占資源。
二.請求與保持條件：一個(gè)進(jìn)程因請求資源而阻塞時(shí)，對已獲得的資源保持不放。
三.不剝奪條件:進(jìn)程已獲得資源，在末使用完之前，不能強(qiáng)行剝奪。
四.循環(huán)等待條件:若干進(jìn)程之間形成一種頭尾相接的循環(huán)等待資源關(guān)系。

34.死鎖的預(yù)防#

打破產(chǎn)生死鎖的四個(gè)必要條件中的一個(gè)或幾個(gè)，保證系統(tǒng)不會(huì)進(jìn)入死鎖狀態(tài)。
一.打破互斥條件。即允許進(jìn)程同時(shí)訪問某些資源。但是，有的資源是不允許被同時(shí)訪問的，像打印機(jī)等等，這是由資源本身的屬性所決定的。所以，這種辦法并無實(shí)用價(jià)值。
二.打破不可搶占條件。即允許進(jìn)程強(qiáng)行從占有者那里奪取某些資源。就是說，當(dāng)一個(gè)進(jìn)程已占有了某些資源，它又申請新的資源，但不能立即被滿足時(shí)，它必須釋放所占有的全部資源，以后再重新申請。它所釋放的資源可以分配給其它進(jìn)程。這就相當(dāng)于該進(jìn)程占有的資源被隱蔽地強(qiáng)占了。這種預(yù)防死鎖的方法實(shí)現(xiàn)起來困難，會(huì)降低系統(tǒng)性能。
三.打破占有且申請條件?？梢詫?shí)行資源預(yù)先分配策略。即進(jìn)程在運(yùn)行前一次性地向系統(tǒng)申請它所需要的全部資源。如果某個(gè)進(jìn)程所需的全部資源得不到滿足，則不分配任何資源，此進(jìn)程暫不運(yùn)行。只有當(dāng)系統(tǒng)能夠滿足當(dāng)前進(jìn)程的全部資源需求時(shí)，才一次性地將所申請的資源全部分配給該進(jìn)程。由于運(yùn)行的進(jìn)程已占有了它所需的全部資源，所以不會(huì)發(fā)生占有資源又申請資源的現(xiàn)象，因此不會(huì)發(fā)生死鎖。
四.打破循環(huán)等待條件，實(shí)行資源有序分配策略。采用這種策略，即把資源事先分類編號(hào)，按號(hào)分配，使進(jìn)程在申請，占用資源時(shí)不會(huì)形成環(huán)路。所有進(jìn)程對資源的請求必須嚴(yán)格按資源序號(hào)遞增的順序提出。進(jìn)程占用了小號(hào)資源，才能申請大號(hào)資源，就不會(huì)產(chǎn)生環(huán)路，從而預(yù)防了死鎖。

35.什么叫守護(hù)線程，用什么方法實(shí)現(xiàn)守護(hù)線程#

守護(hù)線程是為其他線程的運(yùn)行提供服務(wù)的線程。
setDaemon(boolean on)方法可以方便的設(shè)置線程的Daemon模式，true為守護(hù)模式，false為用戶模式。

36.Java線程池技術(shù)及原理#

參考文章：
http://www.importnew.com/19011.html
http://www.cnblogs.com/dolphin0520/p/3932921.html

37.java并發(fā)包c(diǎn)oncurrent及常用的類#

這個(gè)內(nèi)容有點(diǎn)多，參考文章：
并發(fā)包諸類概覽：http://www.raychase.net/1912
線程池：http://www.cnblogs.com/dolphin0520/p/3932921.html
鎖：http://www.cnblogs.com/dolphin0520/p/3923167.html
集合：http://www.cnblogs.com/huangfox/archive/2012/08/16/2642666.html

38.volatile關(guān)鍵字#

用volatile修飾的變量，線程在每次使用變量的時(shí)候，都會(huì)讀取變量修改后的最的值。volatile很容易被誤用，用來進(jìn)行原子性操作。
Java語言中的volatile變量可以被看作是一種“程度較輕的
synchronized”；與
synchronized 塊相比，volatile 變量所需的編碼較少，并且運(yùn)行時(shí)開銷也較少，但是它所能實(shí)現(xiàn)的功能也僅是synchronized的一部分。鎖提供了兩種主要特性：互斥（mutual
exclusion）和可見性（visibility）。互斥即一次只允許一個(gè)線程持有某個(gè)特定的鎖，因此可使用該特性實(shí)現(xiàn)對共享數(shù)據(jù)的協(xié)調(diào)訪問協(xié)議，這樣，一次就只有一個(gè)線程能夠使用該共享數(shù)據(jù)?？梢娦员仨毚_保釋放鎖之前對共享數(shù)據(jù)做出的更改對于隨后獲得該鎖的另一個(gè)線程是可見的，如果沒有同步機(jī)制提供的這種可見性保證，線程看到的共享變量可能是修改前的值或不一致的值，這將引發(fā)許多嚴(yán)重問題。Volatile變量具有synchronized的可見性特性，但是不具備原子特性。這就是說線程能夠自動(dòng)發(fā)現(xiàn)volatile
變量的最新值。
要使volatile變量提供理想的線程安全，必須同時(shí)滿足下面兩個(gè)條件：對變量的寫操作不依賴于當(dāng)前值；該變量沒有包含在具有其他變量的不變式中。
第一個(gè)條件的限制使volatile變量不能用作線程安全計(jì)數(shù)器。雖然增量操作（x++）看上去類似一個(gè)單獨(dú)操作，實(shí)際上它是一個(gè)由讀?。薷模瓕懭氩僮餍蛄薪M成的組合操作，必須以原子方式執(zhí)行，而volatile不能提供必須的原子特性。實(shí)現(xiàn)正確的操作需要使x 的值在操作期間保持不變，而volatile
變量無法實(shí)現(xiàn)這點(diǎn)。
每一個(gè)線程運(yùn)行時(shí)都有一個(gè)線程棧，線程棧保存了線程運(yùn)行時(shí)候變量值信息。當(dāng)線程訪問某一個(gè)對象時(shí)候值的時(shí)候，首先通過對象的引用找到對應(yīng)在堆內(nèi)存的變量的值，然后把堆內(nèi)存變量的具體值load到線程本地內(nèi)存中，建立一個(gè)變量副本，之后線程就不再和對象在堆內(nèi)存變量值有任何關(guān)系，而是直接修改副本變量的值，在修改完之后的某一個(gè)時(shí)刻（線程退出之前），自動(dòng)把線程變量副本的值回寫到對象在堆中變量。這樣在堆中的對象的值就產(chǎn)生變化了。

read and load 從主存復(fù)制變量到當(dāng)前工作內(nèi)存
use and assign 執(zhí)行代碼，改變共享變量值
store and write 用工作內(nèi)存數(shù)據(jù)刷新主存相關(guān)內(nèi)容
其中use and
assign 可以多次出現(xiàn)，但是這一些操作并不是原子性，也就是在read load之后，如果主內(nèi)存count變量發(fā)生修改之后，線程工作內(nèi)存中的值由于已經(jīng)加載，不會(huì)產(chǎn)生對應(yīng)的變化，所以計(jì)算出來的結(jié)果會(huì)和預(yù)期不一樣。

39.Java中的NIO，BIO，AIO分別是什么#

BIO:同步并阻塞，服務(wù)器實(shí)現(xiàn)模式為一個(gè)連接一個(gè)線程，即客戶端有連接請求時(shí)服務(wù)器端就需要啟動(dòng)一個(gè)線程進(jìn)行處理，如果這個(gè)連接不做任何事情會(huì)造成不必要的線程開銷，當(dāng)然可以通過線程池機(jī)制改善。BIO方式適用于連接數(shù)目比較小且固定的架構(gòu)，這種方式對服務(wù)器資源要求比較高，并發(fā)局限于應(yīng)用中，JDK1.4以前的唯一選擇，但程序直觀簡單易理解。
NIO:同步非阻塞，服務(wù)器實(shí)現(xiàn)模式為一個(gè)請求一個(gè)線程，即客戶端發(fā)送的連接請求都會(huì)注冊到多路復(fù)用器上，多路復(fù)用器輪詢到連接有I/O請求時(shí)才啟動(dòng)一個(gè)線程進(jìn)行處理。NIO方式適用于連接數(shù)目多且連接比較短（輕操作）的架構(gòu)，比如聊天服務(wù)器，并發(fā)局限于應(yīng)用中，編程比較復(fù)雜，JDK1.4開始支持。
AIO:異步非阻塞，服務(wù)器實(shí)現(xiàn)模式為一個(gè)有效請求一個(gè)線程，客戶端的I/O請求都是由OS先完成了再通知服務(wù)器應(yīng)用去啟動(dòng)線程進(jìn)行處理.AIO方式使用于連接數(shù)目多且連接比較長（重操作）的架構(gòu)，比如相冊服務(wù)器，充分調(diào)用OS參與并發(fā)操作，編程比較復(fù)雜，JDK7開始支持。

40.IO和NIO區(qū)別#

一.IO是面向流的，NIO是面向緩沖區(qū)的。
二.IO的各種流是阻塞的，NIO是非阻塞模式。
三.Java NIO的選擇器允許一個(gè)單獨(dú)的線程來監(jiān)視多個(gè)輸入通道，你可以注冊多個(gè)通道使用一個(gè)選擇器，然后使用一個(gè)單獨(dú)的線程來“選擇”通道：這些通道里已經(jīng)有可以處理的輸入，或者選擇已準(zhǔn)備寫入的通道。這種選擇機(jī)制，使得一個(gè)單獨(dú)的線程很容易來管理多個(gè)通道。

41.序列化與反序列化#

把對象轉(zhuǎn)換為字節(jié)序列的過程稱為對象的序列化。
把字節(jié)序列恢復(fù)為對象的過程稱為對象的反序列化。
對象的序列化主要有兩種用途：
一.把對象的字節(jié)序列永久地保存到硬盤上，通常存放在一個(gè)文件中；
二.在網(wǎng)絡(luò)上傳送對象的字節(jié)序列。
當(dāng)兩個(gè)進(jìn)程在進(jìn)行遠(yuǎn)程通信時(shí)，彼此可以發(fā)送各種類型的數(shù)據(jù)。無論是何種類型的數(shù)據(jù)，都會(huì)以二進(jìn)制序列的形式在網(wǎng)絡(luò)上傳送。發(fā)送方需要把這個(gè)Java對象轉(zhuǎn)換為字節(jié)序列，才能在網(wǎng)絡(luò)上傳送；接收方則需要把字節(jié)序列再恢復(fù)為Java對象。

42.常見的序列化協(xié)議有哪些#

Protobuf, Thrift, Hessian, Kryo

43.內(nèi)存溢出和內(nèi)存泄漏的區(qū)別#

內(nèi)存溢出是指程序在申請內(nèi)存時(shí)，沒有足夠的內(nèi)存空間供其使用，出現(xiàn)out of
memory。
內(nèi)存泄漏是指分配出去的內(nèi)存不再使用，但是無法回收。

44.Java內(nèi)存模型及各個(gè)區(qū)域的OOM，如何重現(xiàn)OOM#

這部分內(nèi)容很重要，詳細(xì)閱讀《深入理解Java虛擬機(jī)》，也可以詳細(xì)閱讀這篇文章http://hllvm.group.iteye.com/group/wiki/2857-JVM

45.出現(xiàn)OOM如何解決#

一. 可通過命令定期抓取heap dump或者啟動(dòng)參數(shù)OOM時(shí)自動(dòng)抓取heap dump文件。
二. 通過對比多個(gè)heap dump，以及heap dump的內(nèi)容，分析代碼找出內(nèi)存占用最多的地方。
三. 分析占用的內(nèi)存對象，是否是因?yàn)殄e(cuò)誤導(dǎo)致的內(nèi)存未及時(shí)釋放，或者數(shù)據(jù)過多導(dǎo)致的內(nèi)存溢出。

46.用什么工具可以查出內(nèi)存泄漏#

一. Memory
Analyzer－是一款開源的JAVA內(nèi)存分析軟件，查找內(nèi)存泄漏，能容易找到大塊內(nèi)存并驗(yàn)證誰在一直占用它，它是基于Eclipse
RCP(Rich Client Platform)，可以下載RCP的獨(dú)立版本或者Eclipse的插件。
二. JProbe－分析Java的內(nèi)存泄漏。
三.JProfiler－一個(gè)全功能的Java剖析工具，專用于分析J2SE和J2EE應(yīng)用程序。它把CPU、執(zhí)行緒和內(nèi)存的剖析組合在一個(gè)強(qiáng)大的應(yīng)用中，GUI可以找到效能瓶頸、抓出內(nèi)存泄漏、并解決執(zhí)行緒的問題。
四. JRockit－用來診斷Java內(nèi)存泄漏并指出根本原因，專門針對Intel平臺(tái)并得到優(yōu)化，能在Intel硬件上獲得最高的性能。
五. YourKit-.NET & Java Profiling業(yè)界領(lǐng)先的Java和.NET程序性能分析工具。
六.AutomatedQA －AutomatedQA的獲獎(jiǎng)產(chǎn)品performance profiling和memory debugging工具集的下一代替換產(chǎn)品，支持Microsoft,Borland, Intel, Compaq 和 GNU編譯器。可以為.NET和Windows程序生成全面細(xì)致的報(bào)告，從而幫助您輕松隔離并排除代碼中含有的性能問題和內(nèi)存/資源泄露問題。支持.Net 1.0,1.1,2.0,3.0和Windows 32/64位應(yīng)用程序。
七.Compuware DevPartner Java Edition－包含Java內(nèi)存檢測,代碼覆蓋率測試,代碼性能測試,線程死鎖,分布式應(yīng)用等幾大功能模塊

47.Java內(nèi)存管理及回收算法#

閱讀這篇文章：http://www.cnblogs.com/hnrainll/archive/2013/11/06/3410042.html

48.Java類加載器及如何加載類(雙親委派)#

閱讀文章：
https://www.ibm.com/developerworks/cn/java/j-lo-classloader/（推薦）
http://blog.csdn.net/zhoudaxia/article/details/35824249

49.xml解析方式#

一.DOM(JAXP
Crimson解析器)
二.SAX
三.JDOM
四.DOM4J
區(qū)別：
一.DOM4J性能最好，連Sun的JAXM也在用DOM4J。目前許多開源項(xiàng)目中大量采用DOM4J，例如大名鼎鼎的hibernate也用DOM4J來讀取XML配置文件。如果不考慮可移植性，那就采用DOM4J.
二.JDOM和DOM在性能測試時(shí)表現(xiàn)不佳，在測試10M
文檔時(shí)內(nèi)存溢出。在小文檔情況下還值得考慮使用DOM和JDOM。雖然JDOM的開發(fā)者已經(jīng)說明他們期望在正式發(fā)行版前專注性能問題，但是從性能觀點(diǎn)來看，它確實(shí)沒有值得推薦之處。另外，DOM仍是一個(gè)非常好的選擇。DOM實(shí)現(xiàn)廣泛應(yīng)用于多種編程語言。它還是許多其它與XML相關(guān)的標(biāo)準(zhǔn)的基礎(chǔ)，因?yàn)樗将@得W3C
推薦(與基于非標(biāo)準(zhǔn)的Java模型相對)，所以在某些類型的項(xiàng)目中可能也需要它(如在JavaScript中使用DOM)。
三.SAX表現(xiàn)較好，這要依賴于它特定的解析方式－事件驅(qū)動(dòng)。一個(gè)SAX檢測即將到來的XML流，但并沒有載入到內(nèi)存(當(dāng)然當(dāng)XML流被讀入時(shí)，會(huì)有部分文檔暫時(shí)隱藏在內(nèi)存中)。

50.Statement和PreparedStatement之間的區(qū)別#

一.PreparedStatement是預(yù)編譯的,對于批量處理可以大大提高效率. 也叫JDBC存儲(chǔ)過程
二.使用
Statement 對象。在對數(shù)據(jù)庫只執(zhí)行一次性存取的時(shí)侯，用
Statement 對象進(jìn)行處理。PreparedStatement
對象的開銷比Statement大，對于一次性操作并不會(huì)帶來額外的好處。
三.statement每次執(zhí)行sql語句，相關(guān)數(shù)據(jù)庫都要執(zhí)行sql語句的編譯，preparedstatement是預(yù)編譯得,
preparedstatement支持批處理
四.
代碼片段1:
String updateString = "UPDATE COFFEES SET SALES = 75 " + "WHERE
COF_NAME LIKE ′Colombian′";
stmt.executeUpdate(updateString);
代碼片段2:
PreparedStatement updateSales = con.prepareStatement("UPDATE COFFEES SET
SALES = ? WHERE COF_NAME LIKE ? ");
updateSales.setInt(1, 75);
updateSales.setString(2, "Colombian");
updateSales.executeUpdate();
片斷2和片斷1的區(qū)別在于，后者使用了PreparedStatement對象，而前者是普通的Statement對象。PreparedStatement對象不僅包含了SQL語句，而且大多數(shù)情況下這個(gè)語句已經(jīng)被預(yù)編譯過，因而當(dāng)其執(zhí)行時(shí)，只需DBMS運(yùn)行SQL語句，而不必先編譯。當(dāng)你需要執(zhí)行Statement對象多次的時(shí)候，PreparedStatement對象將會(huì)大大降低運(yùn)行時(shí)間，當(dāng)然也加快了訪問數(shù)據(jù)庫的速度。
這種轉(zhuǎn)換也給你帶來很大的便利，不必重復(fù)SQL語句的句法，而只需更改其中變量的值，便可重新執(zhí)行SQL語句。選擇PreparedStatement對象與否，在于相同句法的SQL語句是否執(zhí)行了多次，而且兩次之間的差別僅僅是變量的不同。如果僅僅執(zhí)行了一次的話，它應(yīng)該和普通的對象毫無差異，體現(xiàn)不出它預(yù)編譯的優(yōu)越性。
五.執(zhí)行許多SQL語句的JDBC程序產(chǎn)生大量的Statement和PreparedStatement對象。通常認(rèn)為PreparedStatement對象比Statement對象更有效,特別是如果帶有不同參數(shù)的同一SQL語句被多次執(zhí)行的時(shí)候。PreparedStatement對象允許數(shù)據(jù)庫預(yù)編譯SQL語句，這樣在隨后的運(yùn)行中可以節(jié)省時(shí)間并增加代碼的可讀性。
然而，在Oracle環(huán)境中，開發(fā)人員實(shí)際上有更大的靈活性。當(dāng)使用Statement或PreparedStatement對象時(shí)，Oracle數(shù)據(jù)庫會(huì)緩存SQL語句以便以后使用。在一些情況下,由于驅(qū)動(dòng)器自身需要額外的處理和在Java應(yīng)用程序和Oracle服務(wù)器間增加的網(wǎng)絡(luò)活動(dòng)，執(zhí)行PreparedStatement對象實(shí)際上會(huì)花更長的時(shí)間。
然而，除了緩沖的問題之外，至少還有一個(gè)更好的原因使我們在企業(yè)應(yīng)用程序中更喜歡使用PreparedStatement對象,那就是安全性。傳遞給PreparedStatement對象的參數(shù)可以被強(qiáng)制進(jìn)行類型轉(zhuǎn)換，使開發(fā)人員可以確保在插入或查詢數(shù)據(jù)時(shí)與底層的數(shù)據(jù)庫格式匹配。
當(dāng)處理公共Web站點(diǎn)上的用戶傳來的數(shù)據(jù)的時(shí)候，安全性的問題就變得極為重要。傳遞給PreparedStatement的字符串參數(shù)會(huì)自動(dòng)被驅(qū)動(dòng)器忽略。最簡單的情況下，這就意味著當(dāng)你的程序試著將字符串“D'Angelo”插入到VARCHAR2中時(shí)，該語句將不會(huì)識(shí)別第一個(gè)“，”，從而導(dǎo)致悲慘的失敗。幾乎很少有必要?jiǎng)?chuàng)建你自己的字符串忽略代碼。
在Web環(huán)境中，有惡意的用戶會(huì)利用那些設(shè)計(jì)不完善的、不能正確處理字符串的應(yīng)用程序。特別是在公共Web站點(diǎn)上,在沒有首先通過PreparedStatement對象處理的情況下，所有的用戶輸入都不應(yīng)該傳遞給SQL語句。此外，在用戶有機(jī)會(huì)修改SQL語句的地方，如HTML的隱藏區(qū)域或一個(gè)查詢字符串上，SQL語句都不應(yīng)該被顯示出來。

51.servlet生命周期及各個(gè)方法#

參考文章http://www.cnblogs.com/xuekyo/archive/2013/02/24/2924072.html

52.servlet中如何自定義filter#

參考文章http://www.cnblogs.com/javawebsoa/archive/2013/07/31/3228858.html

53.JSP原理#

參考文章http://blog.csdn.net/hanxuemin12345/article/details/23831645

54.JSP和Servlet的區(qū)別#

(1)JSP經(jīng)編譯后就變成了“類servlet”。
(2)JSP由HTML代碼和JSP標(biāo)簽構(gòu)成，更擅長頁面顯示；Servlet更擅長流程控制。
(3)JSP中嵌入JAVA代碼，而Servlet中嵌入HTML代碼。

55.JSP的動(dòng)態(tài)include和靜態(tài)include#

(1)動(dòng)態(tài)include用jsp:include動(dòng)作實(shí)現(xiàn)，如<jsp:include
page="abc.jsp" flush="true" />，它總是會(huì)檢查所含文件中的變化，適合用于包含動(dòng)態(tài)頁面，并且可以帶參數(shù)。會(huì)先解析所要包含的頁面，解析后和主頁面合并一起顯示，即先編譯后包含。
(2)靜態(tài)include用include偽碼實(shí)現(xiàn)，不會(huì)檢查所含文件的變化，適用于包含靜態(tài)頁面，如<%@
include file="qq.htm" %>，不會(huì)提前解析所要包含的頁面，先把要顯示的頁面包含進(jìn)來，然后統(tǒng)一編譯，即先包含后編譯。

56.Struts中請求處理過程#

參考文章http://www.cnblogs.com/liuling/p/2013-8-10-01.html

57.MVC概念#

參考文章http://www.cnblogs.com/scwyh/articles/1436802.html

58.Springmvc與Struts區(qū)別#

參考文章：
http://blog.csdn.net/tch918/article/details/38305395
http://blog.csdn.net/chenleixing/article/details/44570681

59.Hibernate/Ibatis兩者的區(qū)別#

參考文章http://blog.csdn.net/firejuly/article/details/8190229

60.Hibernate一級和二級緩存#

參考文章http://blog.csdn.net/windrui/article/details/23165845

61.簡述Hibernate常見優(yōu)化策略#

參考文章http://blog.csdn.net/shimiso/article/details/8819114

62.Springbean的加載過程(推薦看Spring的源碼)#

參考文章http://geeekr.com/read-spring-source-1-how-to-load-bean/

63.Springbean的實(shí)例化(推薦看Spring的源碼)#

參考文章http://geeekr.com/read-spring-source-two-beans-initialization/

64.Spring如何實(shí)現(xiàn)AOP和IOC(推薦看Spring的源碼)#

參考文章http://www.360doc.com/content/15/0116/21/12385684_441408260.shtml

65.Springbean注入方式#

參考文章http://blessht.iteye.com/blog/1162131

66.Spring的事務(wù)管理#

這個(gè)主題的參考文章沒找到特別好的，http://blog.csdn.net/trigl/article/details/50968079這個(gè)還可以。

67.Spring事務(wù)的傳播特性#

參考文章http://blog.csdn.net/lfsf802/article/details/9417095

68.springmvc原理

參考文章http://blog.sina.com.cn/s/blog_7ef0a3fb0101po57.html

69.springmvc用過哪些注解#

參考文章http://aijuans.iteye.com/blog/2160141

70.Restful有幾種請求#

參考文章，http://www.infoq.com/cn/articles/designing-restful-http-apps-roth，該篇寫的比較全。

71.Restful好處#

(1)客戶-服務(wù)器：客戶-服務(wù)器約束背后的原則是分離關(guān)注點(diǎn)。通過分離用戶接口和數(shù)據(jù)存儲(chǔ)這兩個(gè)關(guān)注點(diǎn)，改善了用戶接口跨多個(gè)平臺(tái)的可移植性；同時(shí)通過簡化服務(wù)器組件，改善了系統(tǒng)的可伸縮性。
(2)無狀態(tài)：通信在本質(zhì)上是無狀態(tài)的，改善了可見性、可靠性、可伸縮性.
(3)緩存：改善了網(wǎng)絡(luò)效率減少一系列交互的平均延遲時(shí)間，來提高效率、可伸縮性和用戶可覺察的性能。
(4)統(tǒng)一接口：REST架構(gòu)風(fēng)格區(qū)別于其他基于網(wǎng)絡(luò)的架構(gòu)風(fēng)格的核心特征是，它強(qiáng)調(diào)組件之間要有一個(gè)統(tǒng)一的接口。

72.Tomcat，Apache，JBoss的區(qū)別#

Apache:HTTP服務(wù)器(WEB服務(wù)器)，類似IIS，可以用于建立虛擬站點(diǎn)，編譯處理靜態(tài)頁面，可以支持SSL技術(shù)，支持多個(gè)虛擬主機(jī)等功能。
Tomcat:Servlet容器，用于解析jsp，Servlet的Servlet容器，是高效，輕量級的容器。缺點(diǎn)是不支持EJB，只能用于java應(yīng)用。
Jboss:應(yīng)用服務(wù)器，運(yùn)行EJB的J2EE應(yīng)用服務(wù)器，遵循J2EE規(guī)范，能夠提供更多平臺(tái)的支持和更多集成功能，如數(shù)據(jù)庫連接，JCA等，其對Servlet的支持是通過集成其他Servlet容器來實(shí)現(xiàn)的，如tomcat和jetty。

73.memcached和redis的區(qū)別#

(1)性能對比：由于Redis只使用單核，而Memcached可以使用多核，所以平均每一個(gè)核上Redis在存儲(chǔ)小數(shù)據(jù)時(shí)比Memcached性能更高。而在100k以上的數(shù)據(jù)中，Memcached性能要高于Redis，雖然Redis最近也在存儲(chǔ)大數(shù)據(jù)的性能上進(jìn)行優(yōu)化，但是比起Memcached，還是稍有遜色。
(2)內(nèi)存使用效率對比：使用簡單的key-value存儲(chǔ)的話，Memcached的內(nèi)存利用率更高，而如果Redis采用hash結(jié)構(gòu)來做key-value存儲(chǔ)，由于其組合式的壓縮，其內(nèi)存利用率會(huì)高于Memcached。
(3)Redis支持服務(wù)器端的數(shù)據(jù)操作：Redis相比Memcached來說，擁有更多的數(shù)據(jù)結(jié)構(gòu)和并支持更豐富的數(shù)據(jù)操作，通常在Memcached里，你需要將數(shù)據(jù)拿到客戶端來進(jìn)行類似的修改再set回去。這大大增加了網(wǎng)絡(luò)IO的次數(shù)和數(shù)據(jù)體積。在Redis中，這些復(fù)雜的操作通常和一般的GET/SET一樣高效。所以，如果需要緩存能夠支持更復(fù)雜的結(jié)構(gòu)和操作，那么Redis會(huì)是不錯(cuò)的選擇。

74.如何理解分布式鎖#

參考文章：
http://blog.csdn.net/zheng0518/article/details/51607063
http://blog.csdn.net/nicewuranran/article/details/51730131。

75.你知道的開源協(xié)議有哪些#

常見的開源協(xié)議有GPL、LGPL、BSD、Apache Licence
vesion 2.0、MIT，詳細(xì)內(nèi)容參考文章:
http://blog.jobbole.com/44175/、http://www.ruanyifeng.com/blog/2011/05/how_to_choose_free_software_licenses.html。

76.json和xml區(qū)別#

XML:
(1)應(yīng)用廣泛，可擴(kuò)展性強(qiáng)，被廣泛應(yīng)用各種場合；
(2)讀取、解析沒有JSON快；
(3)可讀性強(qiáng)，可描述復(fù)雜結(jié)構(gòu)。
JSON:
(1)結(jié)構(gòu)簡單，都是鍵值對；
(2)讀取、解析速度快，很多語言支持；
(3)傳輸數(shù)據(jù)量小，傳輸速率大大提高；
(4)描述復(fù)雜結(jié)構(gòu)能力較弱。

77.設(shè)計(jì)模式#

參考文章：http://www.cnblogs.com/beijiguangyong/archive/2010/11/15/2302807.html#_Toc281750445。

78.設(shè)計(jì)模式的六大原則#

參考文章http://www.uml.org.cn/sjms/201211023.asp。

79.用一個(gè)設(shè)計(jì)模式寫一段代碼或畫出一個(gè)設(shè)計(jì)模式的UML#

參考文章http://www.cnblogs.com/beijiguangyong/archive/2010/11/15/2302807.html#_Toc281750445

80.高內(nèi)聚，低耦合方面的理解#

參考文章http://my.oschina.net/heweipo/blog/423235。

81.深度優(yōu)先和廣度優(yōu)先算法#

推薦看書籍復(fù)習(xí)！可參考文章：
http://blog.163.com/zhoumhan_0351/blog/static/3995422720098342257387/
http://blog.163.com/zhoumhan_0351/blog/static/3995422720098711040303/
http://blog.csdn.net/andyelvis/article/details/1728378
http://driftcloudy.iteye.com/blog/782873

82.排序算法及對應(yīng)的時(shí)間復(fù)雜度和空間復(fù)雜度#

推薦看書籍復(fù)習(xí)！可參考文章：
http://www.cnblogs.com/liuling/p/2013-7-24-01.html
http://blog.csdn.net/cyuyanenen/article/details/51514443
http://blog.csdn.net/whuslei/article/details/6442755

83.排序算法編碼實(shí)現(xiàn)#

參考http://www.cnblogs.com/liuling/p/2013-7-24-01.html

84.查找算法#

參考http://sanwen8.cn/p/142Wbu5.html

85.B+樹#

參考http://www.cnblogs.com/syxchina/archive/2011/03/02/2197251.html

86.KMP算法#

推薦閱讀數(shù)據(jù)復(fù)習(xí)！參考http://www.cnblogs.com/c-cloud/p/3224788.html

87.hash算法及常用的hash算法#

參考http://www.360doc.com/content/13/0409/14/10384031_277138819.shtml

88.如何判斷一個(gè)單鏈表是否有環(huán)#

參考文章：
http://www.itdecent.cn/p/0e28d31600dd
http://my.oschina.net/u/2391658/blog/693277?p={{totalPage}}

89.隊(duì)列、棧、鏈表、樹、堆、圖#

推薦閱讀數(shù)據(jù)復(fù)習(xí)！

90.linux常用命令#

參考http://www.itdecent.cn/p/03cfc1a721b8

91.如何查看內(nèi)存使用情況#

參考http://blog.csdn.net/windrui/article/details/40046413

92.Linux下如何進(jìn)行進(jìn)程調(diào)度#

推薦閱讀書籍復(fù)習(xí)，參考文章：
http://www.cnblogs.com/zhaoyl/archive/2012/09/04/2671156.html
http://blog.csdn.net/rainharder/article/details/7975387

93.產(chǎn)生死鎖的必要條件#

參考http://blog.sina.com.cn/s/blog_5e3604840100ddgq.html

94.死鎖預(yù)防#

參考http://blog.sina.com.cn/s/blog_5e3604840100ddgq.html

95.數(shù)據(jù)庫范式#

參考http://www.360doc.com/content/12/0712/20/5287961_223855037.shtml

96.數(shù)據(jù)庫事務(wù)隔離級別#

參考http://blog.csdn.net/fg2006/article/details/6937413

97.數(shù)據(jù)庫連接池的原理#

參考http://blog.csdn.net/shuaihj/article/details/14223015

98.樂觀鎖和悲觀鎖#

參考http://www.open-open.com/lib/view/open1452046967245.html

99.如何實(shí)現(xiàn)不同數(shù)據(jù)庫的數(shù)據(jù)查詢分頁#

參考http://blog.csdn.net/yztezhl/article/details/20489387

100.SQL注入的原理，如何預(yù)防#

參考https://www.aliyun.com/zixun/content/3_15_245099.html

101.數(shù)據(jù)庫索引的實(shí)現(xiàn)(B+樹介紹、和B樹、R樹區(qū)別)#

參考文章：
http://blog.csdn.net/kennyrose/article/details/7532032
http://www.xuebuyuan.com/2216918.html

102.SQL性能優(yōu)化#

參考文章：
http://database.51cto.com/art/200904/118526.htm
http://www.cnblogs.com/rootq/archive/2008/11/17/1334727.html

103.數(shù)據(jù)庫索引的優(yōu)缺點(diǎn)以及什么時(shí)候數(shù)據(jù)庫索引失效#

參考文章：
http://www.cnblogs.com/mxmbk/articles/5226344.html
http://www.cnblogs.com/simplefrog/archive/2012/07/15/2592527.html
http://www.open-open.com/lib/view/open1418476492792.html
http://blog.csdn.net/colin_liu2009/article/details/7301089
http://www.cnblogs.com/hongfei/archive/2012/10/20/2732589.html

104.Redis的數(shù)據(jù)類型#

參考http://blog.csdn.net/hechurui/article/details/49508735

105.OSI七層模型以及TCP/IP四層模型#

參考文章：
http://blog.csdn.net/sprintfwater/article/details/8751453
http://www.cnblogs.com/commanderzhu/p/4821555.html
http://blog.csdn.net/superjunjin/article/details/7841099

106.HTTP和HTTPS區(qū)別#

參考：
http://blog.csdn.net/mingli198611/article/details/8055261
http://www.mahaixiang.cn/internet/1233.html

107.HTTP報(bào)文內(nèi)容#

參考文章：
https://yq.aliyun.com/articles/44675
http://www.cnblogs.com/klguang/p/4618526.html
http://my.oschina.net/orgsky/blog/387759

108.get提交和post提交的區(qū)別#

參考文章：
http://www.cnblogs.com/hyddd/archive/2009/03/31/1426026.html
http://www.jellythink.com/archives/806

109.get提交是否有字節(jié)限制，如果有是在哪限制的#

參考http://www.jellythink.com/archives/806

110.TCP的三次握手和四次揮手#

閱讀http://www.itdecent.cn/p/f7d1010fa603

111.session和cookie的區(qū)別#

參考http://www.cnblogs.com/shiyangxt/archive/2008/10/07/1305506.html

112.HTTP請求中Session實(shí)現(xiàn)原理#

參考http://blog.csdn.net/zhq426/article/details/2992488

113.redirect與forward區(qū)別#

參考http://www.cnblogs.com/wxgblogs/p/5602849.html

114.TCP和UDP區(qū)別#

參考http://www.cnblogs.com/bizhu/archive/2012/05/12/2497493.html

115.DDos攻擊及預(yù)防#

參考文章：
http://blog.csdn.net/huwei2003/article/details/45476743
http://www.leiphone.com/news/201509/9zGlIDvLhwguqOtg.html