1.說下原生 jdbc 操作數(shù)據(jù)庫流程言津？
第一步： Class.forName()加載數(shù)據(jù)庫連接驅(qū)動(dòng)糠睡；
第二步： DriverManager.getConnection()獲取數(shù)據(jù)連接對(duì)象;
第三步：根據(jù) SQL 獲取 sql 會(huì)話對(duì)象元旬，有 2 種方式 Statement惰匙、 PreparedStatement ; 第四步：執(zhí)行 SQL 處理結(jié)果集砂吞，執(zhí)行 SQL 前如果有參數(shù)值就設(shè)置參數(shù)值 setXXX();
第五步：關(guān)閉結(jié)果集隔显、關(guān)閉會(huì)話、關(guān)閉連接
2.什么要使用 PreparedStatement避归？
1荣月、 PreparedStatement 接口繼承 Statement， PreparedStatement 實(shí)例包含已編譯的 SQL 語句梳毙，所 以其執(zhí)行
速度要快于 Statement 對(duì)象哺窄。
2 、 作 為 Statement 的 子 類 账锹， PreparedStatement 繼 承 了 Statement 的 所 有 功 能 萌业。 三 種 方 法 execute、 executeQuery 和 executeUpdate 已被更改以使之不再需要參數(shù)
3奸柬、在 JDBC 應(yīng)用中,在任何時(shí)候都不要使用 Statement生年，原因如下：
一、代碼的可讀性和可維護(hù)性.Statement 需要不斷地拼接廓奕，而 PreparedStatement 不會(huì)抱婉。
二档叔、 PreparedStatement 盡最大可能提高性能.DB 有緩存機(jī)制，相同的預(yù)編譯語句再次被調(diào)用不會(huì)再 次需要
編譯蒸绩。
三衙四、最重要的一點(diǎn)是極大地提高了安全性.Statement 容易被 SQL 注入，而 PreparedStatementc 傳入 的內(nèi)容不會(huì)和 sql 語句發(fā)生任何匹配關(guān)系患亿。
3.關(guān)系數(shù)據(jù)庫中連接池的機(jī)制是什么传蹈？
前提：為數(shù)據(jù)庫連接建立一個(gè)緩沖池。
1：從連接池獲取或創(chuàng)建可用連接
2：使用完畢之后步藕，把連接返回給連接池
3：在系統(tǒng)關(guān)閉前惦界，斷開所有連接并釋放連接占用的系統(tǒng)資源
4：能夠處理無效連接，限制連接池中的連接總數(shù)不低于或者不超過某個(gè)限定值咙冗。
其中有幾個(gè)概念需要大家理解：
最小連接數(shù)是連接池一直保持的數(shù)據(jù)連接沾歪。如果應(yīng)用程序?qū)?shù)據(jù)庫連接的使用量不大，將會(huì)有大量的數(shù) 據(jù)庫連接
資源被浪費(fèi)掉乞娄。
最大連接數(shù)是連接池能申請(qǐng)的最大連接數(shù)瞬逊。如果數(shù)據(jù)連接請(qǐng)求超過此數(shù)，后面的數(shù)據(jù)連接請(qǐng)求將被加入 到等待隊(duì)
列中仪或，這會(huì)影響之后的數(shù)據(jù)庫操作确镊。
如果最小連接數(shù)與最大連接數(shù)相差太大，那么范删，最先的連接請(qǐng)求將會(huì)獲利蕾域，之后超過最小連接數(shù)量的連 接請(qǐng)求等
價(jià)于建立一個(gè)新的數(shù)據(jù)庫連接。不過到旦，這些大于最小連接數(shù)的數(shù)據(jù)庫連接在使用完不會(huì)馬上被釋放旨巷，它 將被放到連接池中等待重復(fù)使用或是空閑超時(shí)后被釋放。
上面的解釋添忘，可以這樣理解：數(shù)據(jù)庫池連接數(shù)量一直保持一個(gè)不少于最小連接數(shù)的數(shù)量采呐，當(dāng)數(shù)量不夠 時(shí)，數(shù)據(jù)庫會(huì)
創(chuàng)建一些連接搁骑，直到一個(gè)最大連接數(shù)斧吐，之后連接數(shù)據(jù)庫就會(huì)等待。
4.http 的長連接和短連接
HTTP 協(xié)議有 HTTP/1.0 版本和 HTTP/1.1 版本仲器。 HTTP1.1 默認(rèn)保持長連接（HTTP persistent connection煤率，也
翻譯為持久連接），數(shù)據(jù)傳輸完成了保持 TCP 連接不斷開（不發(fā) RST 包乏冀、不四次握手）蝶糯，等待在同域 名下繼續(xù)用這個(gè)通道傳輸數(shù)據(jù)；相反的就是短連接辆沦。
在 HTTP/1.0 中昼捍，默認(rèn)使用的是短連接识虚。也就是說，瀏覽器和服務(wù)器每進(jìn)行一次 HTTP 操作端三，就建立一 次連接舷礼，任
務(wù)結(jié)束就中斷連接鹃彻。 從 HTTP/1.1 起郊闯，默認(rèn)使用的是長連接， 用以保持連接特性蛛株。
5.HTTP/1.1 與 HTTP/1.0 的區(qū)別
1 可擴(kuò)展性
a) HTTP/1.1 在消息中增加版本號(hào)团赁，用于兼容性判斷。
b) HTTP/1.1 增加了 OPTIONS 方法谨履，它允許客戶端獲取一個(gè)服務(wù)器支持的方法列表欢摄。
c) 為了與未來的協(xié)議規(guī)范兼容， HTTP/1.1 在請(qǐng)求消息中包含了 Upgrade 頭域笋粟，通過該頭域怀挠，客戶端 可以讓服務(wù)器知道它能夠支持的其它備用通信協(xié)議，服務(wù)器可以據(jù)此進(jìn)行協(xié)議切換害捕，使用備用協(xié)議與客 戶端進(jìn)行通信绿淋。
2 緩存
在 HTTP/1.0 中，使用 Expire 頭域來判斷資源的 fresh 或 stale尝盼，并使用條件請(qǐng)求（conditional request）來判斷資源是否仍有效吞滞。 HTTP/1.1 在 1.0 的基礎(chǔ)上加入了一些 cache 的新特性，當(dāng)緩存對(duì) 象的 Age 超過 Expire 時(shí)變stale 對(duì)象盾沫， cache 不需要直接拋棄 stale 對(duì)象裁赠，而是與源服務(wù)器進(jìn)行重新激 活（revalidation）。
3 帶寬優(yōu)化
HTTP/1.0 中赴精，存在一些浪費(fèi)帶寬的現(xiàn)象佩捞，例如客戶端只是需要某個(gè)對(duì)象的一部分，而服務(wù)器卻將整個(gè) 對(duì)象送過來了蕾哟。例如一忱，客戶端只需要顯示一個(gè)文檔的部分內(nèi)容，又比如下載大文件時(shí)需要支持?jǐn)帱c(diǎn)續(xù)傳功能渐苏，而不 是在發(fā)生斷連后不得不重新下載完整的包掀潮。
HTTP/1.1 中在請(qǐng)求消息中引入了 range 頭域，它允許只請(qǐng)求資源的某個(gè)部分琼富。在響應(yīng)消息中 Content-Range 頭域聲明了返回的這部分對(duì)象的偏移值和長度仪吧。如果服務(wù)器相應(yīng)地返回了對(duì)象所請(qǐng)求范圍的內(nèi)容，則響應(yīng) 碼為 206（Partial Content）鞠眉，它可以防止 Cache 將響應(yīng)誤以為是完整的一個(gè)對(duì)象薯鼠。
另外一種情況是請(qǐng)求消息中如果包含比較大的實(shí)體內(nèi)容择诈，但不確定服務(wù)器是否能夠接收該請(qǐng)求（如是否 有權(quán)限），此時(shí)若貿(mào)然發(fā)出帶實(shí)體的請(qǐng)求出皇，如果被拒絕也會(huì)浪費(fèi)帶寬羞芍。
HTTP/1.1 加入了一個(gè)新的狀態(tài)碼 100（Continue）〗妓遥客戶端事先發(fā)送一個(gè)只帶頭域的請(qǐng)求荷科，如果服務(wù) 器因?yàn)闄?quán)限拒絕了請(qǐng)求誓琼，就回送響應(yīng)碼 401（Unauthorized）擂错；如果服務(wù)器接收此請(qǐng)求就回送響應(yīng)碼 100配椭，客 戶端就可以繼續(xù)發(fā)送帶實(shí)體的完整請(qǐng)求了讥蟆。注意复濒， HTTP/1.0 的客戶端不支持 100 響應(yīng)碼装哆。但可以讓客戶端在請(qǐng)求消息 中加入 Expect頭域坪创，并將它的值設(shè)置為 100-continue只祠。
節(jié)省帶寬資源的一個(gè)非常有效的做法就是壓縮要傳送的數(shù)據(jù)瞎嬉。 Content-Encoding 是對(duì)消息進(jìn)行端到端 （end-toend）的編碼蝎毡，它可能是資源在服務(wù)器上保存的固有格式（如 jpeg 圖片格式）；在請(qǐng)求消息 中加入 Accept-Encoding頭域氧枣，它可以告訴服務(wù)器客戶端能夠解碼的編碼方式
4 長連接
HTTP/1.0 規(guī)定瀏覽器與服務(wù)器只保持短暫的連接沐兵，瀏覽器的每次請(qǐng)求都需要與服務(wù)器建立一個(gè) TCP 連 接，服務(wù)器完成請(qǐng)求處理后立即斷開 TCP 連接挑胸，服務(wù)器不跟蹤每個(gè)客戶也不記錄過去的請(qǐng)求痒筒。此外，由于大多數(shù) 網(wǎng)頁的流量都比較小茬贵，一次 TCP 連接很少能通過 slow-start 區(qū)簿透，不利于提高帶寬利用率。
HTTP 1.1 支持長連接（PersistentConnection）和請(qǐng)求的流水線（Pipelining）處理解藻，在一個(gè) TCP 連接 上可以傳送多個(gè) HTTP 請(qǐng)求和響應(yīng)老充，減少了建立和關(guān)閉連接的消耗和延遲。例如：一個(gè)包含有許多圖像的網(wǎng)頁文 件的多個(gè)請(qǐng)求和應(yīng)答可以在一個(gè)連接中傳輸螟左，但每個(gè)單獨(dú)的網(wǎng)頁文件的請(qǐng)求和應(yīng)答仍然需要使用各自的 連接啡浊。
HTTP 1.1 還允許客戶端不用等待上一次請(qǐng)求結(jié)果返回，就可以發(fā)出下一次請(qǐng)求胶背，但服務(wù)器端必須按照 接收到客戶端請(qǐng)求的先后順序依次回送響應(yīng)結(jié)果巷嚣，以保證客戶端能夠區(qū)分出每次請(qǐng)求的響應(yīng)內(nèi)容，這樣也顯著地減 少了整個(gè)下載過程所需要的時(shí)間
5 消息傳遞
HTTP 消息中可以包含任意長度的實(shí)體钳吟，通常它們使用 Content-Length 來給出消息結(jié)束標(biāo)志廷粒。但是， 對(duì)于很多動(dòng)態(tài)產(chǎn)生的響應(yīng)，只能通過緩沖完整的消息來判斷消息的大小坝茎，但這樣做會(huì)加大延遲涤姊。如果不使用長連 接，還可以通過連接關(guān)閉的信號(hào)來判定一個(gè)消息的結(jié)束嗤放。
HTTP/1.1 中引入了 Chunkedtransfer-coding 來解決上面這個(gè)問題思喊，發(fā)送方將消息分割成若干個(gè)任意大 小的數(shù)據(jù)塊，每個(gè)數(shù)據(jù)塊在發(fā)送時(shí)都會(huì)附上塊的長度次酌，最后用一個(gè)零長度的塊作為消息結(jié)束的標(biāo)志恨课。這 種方法允許發(fā)送方只緩沖消息的一個(gè)片段，避免緩沖整個(gè)消息帶來的過載
在 HTTP/1.0 中和措，有一個(gè) Content-MD5 的頭域庄呈，要計(jì)算這個(gè)頭域需要發(fā)送方緩沖完整個(gè)消息后才能進(jìn) 行。而HTTP/1.1 中派阱，采用 chunked 分塊傳遞的消息在最后一個(gè)塊（零長度）結(jié)束之后會(huì)再傳遞一個(gè)拖尾 （trailer），它包含一個(gè)或多個(gè)頭域斜纪，這些頭域是發(fā)送方在傳遞完所有塊之后再計(jì)算出值的贫母。發(fā)送方會(huì) 在消息中包含一個(gè) Trailer 頭域告訴接收方這個(gè)拖尾的存在。
6 Host 頭域
在HTTP1.0中認(rèn)為每臺(tái)服務(wù)器都綁定一個(gè)唯一的IP地址盒刚，因此腺劣，請(qǐng)求消息中的URL并沒有傳遞主機(jī)名（hostname）。
但隨著虛擬主機(jī)技術(shù)的發(fā)展因块，在一臺(tái)物理服務(wù)器上可以存在多個(gè)虛擬主機(jī)（Multi-homed Web Servers）橘原，并且它們共享一個(gè) IP 地址。
HTTP1.1 的請(qǐng)求消息和響應(yīng)消息都應(yīng)支持 Host 頭域涡上，且請(qǐng)求消息中如果沒有 Host 頭域會(huì)報(bào)告一個(gè)錯(cuò) 誤（400Bad Request）趾断。此外，服務(wù)器應(yīng)該接受以絕對(duì)路徑標(biāo)記的資源請(qǐng)求吩愧。
7 錯(cuò)誤提示
HTTP/1.0 中只定義了 16 個(gè)狀態(tài)響應(yīng)碼芋酌，對(duì)錯(cuò)誤或警告的提示不夠具體。 HTTP/1.1 引入了一個(gè) Warning 頭域雁佳，增加對(duì)錯(cuò)誤或警告信息的描述脐帝。
此外，在 HTTP/1.1 中新增了 24 個(gè)狀態(tài)響應(yīng)碼糖权，如 409（Con?ict）表示請(qǐng)求的資源與資源的當(dāng)前狀態(tài) 發(fā)生沖突堵腹；410（Gone）表示服務(wù)器上的某個(gè)資源被永久性的刪除
6.http 常見的狀態(tài)碼有哪些？
200 OK //客戶端請(qǐng)求成功
301 Moved Permanently（永久移除)星澳，請(qǐng)求的 URL 已移走疚顷。 Response 中應(yīng)該包含一個(gè) Location URL, 說明資
源現(xiàn)在所處的位置
302 found 重定向
400 Bad Request //客戶端請(qǐng)求有語法錯(cuò)誤， 不能被服務(wù)器所理解
401 Unauthorized //請(qǐng)求未經(jīng)授權(quán)募判，這個(gè)狀態(tài)代碼必須和 WWW-Authenticate 報(bào)頭域一起使用
403 Forbidden //服務(wù)器收到請(qǐng)求荡含，但是拒絕提供服務(wù)
404 Not Found //請(qǐng)求資源不存在咒唆， eg：輸入了錯(cuò)誤的 URL
500 Internal Server Error //服務(wù)器發(fā)生不可預(yù)期的錯(cuò)誤
503 Server Unavailable //服務(wù)器當(dāng)前不能處理客戶端的請(qǐng)求，一段時(shí)間后可能恢復(fù)正常
7.GET 和 POST 的區(qū)別释液？
從表面現(xiàn)像上面看 GET 和 POST 的區(qū)別：
- GET 請(qǐng)求的數(shù)據(jù)會(huì)附在 URL 之后（就是把數(shù)據(jù)放置在 HTTP 協(xié)議頭中）全释，以?分割 URL 和傳輸數(shù) 據(jù)，參數(shù)之間以&相連误债，如： login.action?name=zhagnsan&password=123456浸船。 POST 把提交 的數(shù)據(jù)則放置在是 HTTP 包的包體中。
- GET 方式提交的數(shù)據(jù)最多只能是 1024 字節(jié)寝蹈，理論上 POST 沒有限制李命，可傳較大量的數(shù)據(jù)。其實(shí)這 樣說是錯(cuò)誤的箫老，不準(zhǔn)確的： GET 方式提交的數(shù)據(jù)最多只能是 1024 字節(jié)"封字，因?yàn)?GET 是通過 URL 提交數(shù)據(jù)， 那么 GET 可提交的數(shù)據(jù)量就跟URL 的長度有直接關(guān)系了耍鬓。而實(shí)際上阔籽， URL 不存在參數(shù)上限的問 題， HTTP 協(xié)議規(guī)范沒有對(duì) URL 長度進(jìn)行限制牲蜀。這個(gè)限制是特定的瀏覽器及服務(wù)器對(duì)它的限制笆制。 IE對(duì)URL長度的限制是2083 字節(jié)(2K+35)。對(duì)于其他瀏覽器涣达，如 Netscape在辆、FireFox 等，理論上沒 有長度限制度苔，其限制取決于操作系統(tǒng)的支持匆篓。
- POST 的安全性要比 GET 的安全性高。注意：這里所說的安全性和上面 GET 提到的“安全”不是同 個(gè)概念林螃。上面“安全”的含義僅僅是不作數(shù)據(jù)修改奕删，而這里安全的含義是真正的 Security 的含義，比如：通過 GET 提交數(shù)據(jù)疗认，用戶名和密碼將明文出現(xiàn)在 URL 上完残，因?yàn)?1)登錄頁面有可能被瀏覽器緩存， (2) 其他人查看瀏覽器的歷史紀(jì)錄横漏，那么別人就可以拿到你的賬號(hào)和密碼了谨设，除此之外，使用 GET 提 交數(shù)據(jù)還可能會(huì)造成 Cross-site request forgery 攻擊缎浇。Get 是向服務(wù)器發(fā)索取數(shù)據(jù)的一種請(qǐng)求扎拣，而 Post 是向服務(wù)器提交數(shù)據(jù)的一種請(qǐng)求，在 FORM（表單）中， Method默認(rèn)為"GET"二蓝，實(shí)質(zhì) 上誉券，GET 和 POST 只是發(fā)送機(jī)制不同，并不是一個(gè)取一個(gè)發(fā)刊愚！
8.http 中重定向和請(qǐng)求轉(zhuǎn)發(fā)的區(qū)別踊跟？
本質(zhì)區(qū)別： 轉(zhuǎn)發(fā)是服務(wù)器行為，重定向是客戶端行為鸥诽。
重定向特點(diǎn)：兩次請(qǐng)求商玫，瀏覽器地址發(fā)生變化，可以訪問自己 web 之外的資源牡借，傳輸?shù)臄?shù)據(jù)會(huì)丟失拳昌。 請(qǐng)求轉(zhuǎn)發(fā)特點(diǎn)：一次強(qiáng)求，瀏覽器地址不變钠龙，訪問的是自己本身的 web 資源炬藤，傳輸?shù)臄?shù)據(jù)不會(huì)丟失
9.Cookie 和 Session 的區(qū)別
Cookie 是 web 服務(wù)器發(fā)送給瀏覽器的一塊信息，瀏覽器會(huì)在本地一個(gè)文件中給每個(gè) web 服務(wù)器存儲(chǔ) cookie俊鱼。以后瀏覽器再給特定的 web 服務(wù)器發(fā)送請(qǐng)求時(shí)刻像，同時(shí)會(huì)發(fā)送所有為該服務(wù)器存儲(chǔ)的 cookie。
Session 是存儲(chǔ)在 web 服務(wù)器端的一塊信息并闲。 session 對(duì)象存儲(chǔ)特定用戶會(huì)話所需的屬性及配置信息。 當(dāng)用戶在應(yīng)用程序的 Web 頁之間跳轉(zhuǎn)時(shí)谷羞，存儲(chǔ)在 Session 對(duì)象中的變量將不會(huì)丟失帝火，而是在整個(gè)用戶會(huì)話中一 直存在下。
**Cookie 和 session 的不同點(diǎn)： **
1湃缎、無論客戶端做怎樣的設(shè)置犀填， session 都能夠正常工作。當(dāng)客戶端禁用 cookie 時(shí)將無法使用 cookie嗓违。
2九巡、在存儲(chǔ)的數(shù)據(jù)量方面： session 能夠存儲(chǔ)任意的 java 對(duì)象， cookie 只能存儲(chǔ) String 類型的對(duì)象
10.session 共享怎么做的（分布式如何實(shí)現(xiàn) session 共享）
問題描述：一個(gè)用戶在登錄成功以后會(huì)把用戶信息存儲(chǔ)在 session 當(dāng)中蹂季，這時(shí) session 所在服務(wù)器為 server1冕广，那
么用戶在 session 失效之前如果再次使用 app，那么可能會(huì)被路由到 server2偿洁，這時(shí)問題來了撒汉， server 沒有該用戶的session，所以需要用戶重新登錄涕滋，這時(shí)的用戶體驗(yàn)會(huì)非常不好睬辐，所以我們想如何實(shí)現(xiàn)多臺(tái) server 之間共享 session，讓用戶狀態(tài)得以保存。
1溯饵、服務(wù)器實(shí)現(xiàn)的 session 復(fù)制或 session 共享侵俗，這類型的共享 session 是和服務(wù)器緊密相關(guān)的，比如 webSphere或JBOSS 在搭建集群時(shí)候可以配置實(shí)現(xiàn) session 復(fù)制或 session 共享丰刊，但是這種方式有一 個(gè)致命的缺點(diǎn)隘谣，就是不好擴(kuò)展和移植，比如我們更換服務(wù)器藻三，那么就要修改服務(wù)器配置洪橘。
2、利用成熟的技術(shù)做session復(fù)制棵帽，比如12306使用的gem?re熄求，比如常見的內(nèi)存數(shù)據(jù)庫如redis或 memorycache，這類方案雖然比較普適逗概，但是嚴(yán)重依賴于第三方弟晚，這樣當(dāng)?shù)谌椒?wù)器出現(xiàn)問題的時(shí) 候，那么將是應(yīng)用的災(zāi)難逾苫。
3卿城、將 session 維護(hù)在客戶端，很容易想到就是利用 cookie铅搓，但是客戶端存在風(fēng)險(xiǎn)瑟押，數(shù)據(jù)不安全，而且 可以存放的 數(shù)據(jù)量比較小星掰，所以將 session 維護(hù)在客戶端還要對(duì) session 中的信息加密多望。
我們實(shí)現(xiàn)的方案可以說是第二種方案和第三種方案的合體，可以利用 gem?re 實(shí)現(xiàn) session 復(fù)制共享氢烘， 還可以將 session 維護(hù)在 redis 中實(shí)現(xiàn) session 共享怀偷，同時(shí)可以將 session 維護(hù)在客戶端的 cookie 中，但是前提 是數(shù)據(jù)要加密播玖。
這三種方式可以迅速切換椎工，而不影響應(yīng)用正常執(zhí)行。我們?cè)趯?shí)踐中蜀踏，首選 gem?re 或者 redis 作為 session 共享的載體维蒙，一旦 session 不穩(wěn)定出現(xiàn)問題的時(shí)候，可以緊急切換 cookie 維護(hù) session 作為備 用脓斩，不影響應(yīng)用提供服務(wù)木西。
這里主要講解 redis 和 cookie 方案， gem?re 比較復(fù)雜大家可以自行查看 gem?re 工作原理随静。利用 redis 做 session 共享八千，首先需要與業(yè)務(wù)邏輯代碼解耦吗讶，不然 session 共享將沒有意義，其次支持動(dòng)態(tài)切換到客 戶端 cookie 模式恋捆。 redis 的方案是照皆，重寫服務(wù)器中的 HttpSession 和 HttpServletRequest，首先實(shí)現(xiàn) HttpSession 接口沸停，重寫 session的所有方法膜毁，將 session 以 hash 值的方式存在 redis 中，一個(gè) session 的 key 就是 sessionID愤钾， setAtrribute 重寫之后就是更新 redis 中的數(shù)據(jù)瘟滨， getAttribute 重寫 之后就是獲取 redis 中的數(shù)據(jù)，等等需要將 HttpSession 的接口一一實(shí)現(xiàn)
實(shí)現(xiàn)了 HttpSesson能颁，那么我們先將該 session 類叫做 MySession（當(dāng)然實(shí)踐中不是這么命名的）杂瘸，當(dāng) MySession出現(xiàn)之后問題才開始，怎么能在不影響業(yè)務(wù)邏輯代碼的情況下伙菊，還能讓原本的 request.getSession（） 獲取到的是MySession败玉，而不是服務(wù)器原生的 session。這里镜硕，我決定重寫服務(wù)器的 HttpServletRequet运翼，這里先稱為 MyRequest，但是這可不是單純的重寫兴枯，我需要在原生的 request 基 礎(chǔ)上重寫血淌，于是我決定在 ?lter 中，實(shí)現(xiàn) request 的偷梁換柱财剖，我的思路是這樣的六剥， MyRequest 的構(gòu)建器，必須以 request 作為參數(shù)峰伙，于是我在 ?lter 中將服務(wù)器原生的 request（也有 可能 是框 架封裝 過的 request ） ，當(dāng) 做參數(shù) new 出 來一 個(gè) MyRequest 该默，并 且 MyRequest 也 實(shí)現(xiàn) 了 HttpServletRequest 接口瞳氓，其實(shí)就是對(duì)原生 request 的一個(gè)增強(qiáng)，這里主要重寫了幾個(gè) request 的方 法栓袖，但是最重要的是重寫了 request.getSession()匣摘，寫到這里大家應(yīng)該都明白為什么重寫這個(gè)方法了
吧，當(dāng)然是為了獲取 MySession裹刮，于是這樣就在?lter中音榜，偷偷的將原生的request換成MyRequest了， 然后再將替換過的request傳入chan.doFilter()捧弃，這樣 ?lter 時(shí)候的代碼都使用的是 MyRequest 了赠叼，同 時(shí)對(duì)業(yè)務(wù)代碼是透明的擦囊，業(yè)務(wù)代碼獲取 session 的方法仍然是request.getSession（），但其實(shí)獲取到 的已經(jīng)是 MySession 了嘴办，這樣對(duì) session 的操作已經(jīng)變成了對(duì) redis 的操作瞬场。
這樣實(shí)現(xiàn)的好處有兩個(gè)，第一開發(fā)人員不需要對(duì) session 共享做任何關(guān)注涧郊， session 共享對(duì)用戶是透明 的贯被；第二， ?lter是可配置的妆艘，通過 ?lter 的方式可以將 session 共享做成一項(xiàng)可插拔的功能彤灶，沒有任何 侵入性。
這個(gè)時(shí)候已經(jīng)實(shí)現(xiàn)了一套可插拔的 session 共享的框架了批旺，但是我們想到如果 redis 服務(wù)出了問題幌陕，這時(shí)我們?cè)撛趺崔k呢，于是我們延續(xù) redis 的想法朱沃，想到可以將 session 維護(hù)在客戶端內(nèi)（加密的 cookie）苞轿，當(dāng)然實(shí) 現(xiàn)方法還是一樣的，我們重寫 HttpSession 接口逗物，實(shí)現(xiàn)其所有方法搬卒，比如 setAttribute 就是寫入 cookie， getAttribute 就是讀取cookie翎卓，我們可以將重寫的 session 稱作 MySession2契邀，這時(shí)怎么讓開 發(fā)人員透明的獲取到 MySession2 呢，實(shí)現(xiàn)方法還是在 ?lter 內(nèi)偷梁換柱失暴，在 MyRequest 加一個(gè)判斷坯门，讀取 sessionType 配置，如果 sessionType 是 redis 的逗扒，那么 getSession 的時(shí)候獲取到的是 MySession古戴，如果 sessionType 是 coolie 的，那么 getSession 的時(shí)候獲取到的是MySession2矩肩，以此 類推现恼，用同樣的方法就可以獲取到 MySession 3,4,5,6 等等。
這樣兩種方式都有了黍檩，那么我們?cè)鯇?shí)現(xiàn)兩種 session 共享方式的快速切換呢叉袍，剛剛我提到一個(gè) sessionType，這是用來決定獲取到session的類型的刽酱，只要變換sessionType就能實(shí)現(xiàn)兩種session共享方式的切換喳逛，但 是sessionType必須對(duì)所有的服務(wù)器都是一致的，如果不一致那將會(huì)出現(xiàn)比較嚴(yán)重的問題棵里，我們目前是 將 sessionType 維護(hù)在環(huán)境變量里润文，如果要切換 sessionType 就要重啟每一臺(tái)服務(wù)器姐呐，完成 session 共享的轉(zhuǎn)換，但是當(dāng)服務(wù)器太多的時(shí)候?qū)⑹且环N災(zāi)難转唉。而且重啟服務(wù)意味著服務(wù)的中斷皮钠，所以這樣的方 式只適合服務(wù)器規(guī)模比較小，而且用戶量比較少的情況赠法，當(dāng)服務(wù)器太多的時(shí)候麦轰，務(wù)必需要一種協(xié)調(diào)技 術(shù)，能夠讓服務(wù)器能夠及時(shí)獲取切換的通知砖织】钋郑基于這樣的原因，我們選用zookeeper 作為配置平臺(tái)侧纯，每 一臺(tái)服務(wù)器都會(huì)訂閱 zookeeper 上的配置新锈，當(dāng)我們切換 sessionType 之后，所有服務(wù)器都會(huì)訂閱到修 改之后的配置眶熬，那么切換就會(huì)立即生效妹笆，當(dāng)然可能會(huì)有短暫的時(shí)間延遲，但這是可以接受的娜氏。
11.在單點(diǎn)登錄中拳缠，如果 cookie 被禁用了怎么辦？
單點(diǎn)登錄的原理是后端生成一個(gè) session ID贸弥，然后設(shè)置到 cookie窟坐，后面的所有請(qǐng)求瀏覽器都會(huì)帶上 cookie，然后服務(wù)端從 cookie 里獲取 session ID绵疲，再查詢到用戶信息哲鸳。所以，保持登錄的關(guān)鍵不是 cookie盔憨，而 是通過 cookie 保存和傳輸?shù)?session ID徙菠，其本質(zhì)是能獲取用戶信息的數(shù)據(jù)。除了 cookie郁岩，還通常使用 HTTP 請(qǐng)求頭來傳輸懒豹。但是這個(gè)請(qǐng)求頭瀏覽器不會(huì)像 cookie 一樣自動(dòng)攜帶，需要手工處理驯用。
12.什么是 jsp，什么是 Servlet儒老？ jsp 和 Servlet 有什么區(qū)別蝴乔？
jsp 本質(zhì)上就是一個(gè) Servlet，它是 Servlet 的一種特殊形式（由 SUN 公司推出）驮樊，每個(gè) jsp 頁面都是一個(gè) servlet
實(shí)例薇正。
Servlet 是由 Java 提供用于開發(fā) web 服務(wù)器應(yīng)用程序的一個(gè)組件片酝，運(yùn)行在服務(wù)端，由 servlet 容器管理挖腰，用來生成動(dòng)態(tài)內(nèi)容雕沿。一個(gè) servlet 實(shí)例是實(shí)現(xiàn)了特殊接口 Servlet 的 Java 類，所有自定義的 servlet 均必須實(shí)現(xiàn) Servlet 接口猴仑。
區(qū)別：
jsp 是 html 頁面中內(nèi)嵌的 Java 代碼审轮，側(cè)重頁面顯示；
Servlet 是 html 代碼和 Java 代碼分離辽俗，側(cè)重邏輯控制疾渣， mvc 設(shè)計(jì)思想中 jsp 位于視圖層， servlet 位 于控制層
Jsp 運(yùn)行機(jī)制：如下圖
JVM 只能識(shí)別 Java 類崖飘，并不能識(shí)別 jsp 代碼榴捡！ web 容器收到以.jsp 為擴(kuò)展名的 url 請(qǐng)求時(shí)，會(huì)將訪問 請(qǐng)求交給 tomcat 中 jsp 引擎處理朱浴，每個(gè) jsp 頁面第一次被訪問時(shí)吊圾， jsp 引擎將 jsp 代碼解釋為一個(gè) servlet 源程 序，接著編譯servlet 源程序生成.class 文件翰蠢，再有 web 容器 servlet 引擎去裝載執(zhí)行 servlet 程序项乒，實(shí) 現(xiàn)頁面交互。
13.jsp 有哪些域?qū)ο蠛蛢?nèi)置對(duì)象及他們的作用躏筏？
四大域?qū)ο螅?br> （1） pageContext page 域-指當(dāng)前頁面板丽，在當(dāng)前 jsp 頁面有效，跳到其它頁面失效
（2） request request 域-指一次請(qǐng)求范圍內(nèi)有效趁尼，從 http 請(qǐng)求到服務(wù)器處理結(jié)束埃碱，返回響應(yīng)的整個(gè)過 程。
在這個(gè)過程中使用 forward（請(qǐng)求轉(zhuǎn)發(fā)）方式跳轉(zhuǎn)多個(gè) jsp酥泞，在這些頁面里你都可以使用這個(gè)變量 （3） session session 域-指當(dāng)前會(huì)話有效范圍砚殿，瀏覽器從打開到關(guān)閉過程中，轉(zhuǎn)發(fā)芝囤、重定向均可以使 用
（4） application context 域-指只能在同一個(gè) web 中使用似炎，服務(wù)器未關(guān)閉或者重啟，數(shù)據(jù)就有效
九大內(nèi)置對(duì)象：
14.什么是 xml悯姊，使用 xml 的優(yōu)缺點(diǎn)羡藐， xml 的解析器有哪幾種，分 別有什么區(qū)別悯许？
xml 是一種可擴(kuò)展性標(biāo)記語言仆嗦，支持自定義標(biāo)簽（使用前必須預(yù)定義）使用 DTD 和 XML Schema 標(biāo)準(zhǔn) 化 XML 結(jié)
構(gòu)
優(yōu)點(diǎn)：用于配置文件，格式統(tǒng)一先壕，符合標(biāo)準(zhǔn)瘩扼；用于在互不兼容的系統(tǒng)間交互數(shù)據(jù)谆甜，共享數(shù)據(jù)方便；
缺點(diǎn)： xml 文件格式復(fù)雜集绰，數(shù)據(jù)傳輸占流量规辱，服務(wù)端和客戶端解析 xml 文件占用大量資源且不易維護(hù) Xml 常用解析器有 2 種，分別是： DOM 和 SAX;
主要區(qū)別在于它們解析 xml 文檔的方式不同栽燕。使用 DOM 解析纫谅， xml 文檔以 DOM樹形結(jié)構(gòu)加載入內(nèi) 存询吴，而 SAX 采用的是事件模型奉瘤，
15.談?wù)勀銓?duì) ajax 的認(rèn)識(shí)藕赞？
Ajax 是一種創(chuàng)建交互式網(wǎng)頁應(yīng)用的的網(wǎng)頁開發(fā)技術(shù)批销； Asynchronous JavaScript and XML”的縮寫骡技。
Ajax 的優(yōu)勢：
通過異步模式，提升了用戶體驗(yàn)掸驱。
優(yōu)化了瀏覽器和服務(wù)器之間的傳輸，減少不必要的數(shù)據(jù)往返鬼癣，減少了帶寬占用陶贼。
Ajax 引擎在客戶端運(yùn)行，承擔(dān)了一部分本來由服務(wù)器承擔(dān)的工作待秃，從而減少了大用戶量下的服務(wù)器負(fù) 載拜秧。
Ajax 的最大特點(diǎn)：
可以實(shí)現(xiàn)局部刷新，在不更新整個(gè)頁面的前提下維護(hù)數(shù)據(jù)章郁，提升用戶體驗(yàn)度枉氮。
注意：ajax在實(shí)際項(xiàng)目開發(fā)中使用率非常高（牢固掌握），針對(duì)ajax的詳細(xì)描述
16.jsonp 原理
JavaScript 是一種在 Web 開發(fā)中經(jīng)常使用的前端動(dòng)態(tài)腳本技術(shù)暖庄。在 JavaScript 中聊替，有一個(gè)很重要的安 全性限制，被稱為“Same-Origin Policy”（同源策略）雄驹。這一策略對(duì)于 JavaScript 代碼能夠訪問的頁面 內(nèi)容做了很重要的限制佃牛，即 JavaScript 只能訪問與包含它的文檔在同一域下的內(nèi)容。
JavaScript 這個(gè)安全策略在進(jìn)行多 iframe 或多窗口編程医舆、以及 Ajax 編程時(shí)顯得尤為重要俘侠。根據(jù)這個(gè)策 略，在 baidu.com 下的頁面中包含的 JavaScript 代碼蔬将，不能訪問在 google.com 域名下的頁面內(nèi)容爷速； 甚至不同的子域名之間的頁面也不能通過 JavaScript 代碼互相訪問。對(duì)于 Ajax 的影響在于霞怀，通過 XMLHttpRequest 實(shí)現(xiàn)的Ajax 請(qǐng)求惫东，不能向不同的域提交請(qǐng)求，例如，在 abc.example.com 下的頁 面廉沮，不能向 def.example.com 提交Ajax 請(qǐng)求颓遏，等等。
然而滞时，當(dāng)進(jìn)行一些比較深入的前端編程的時(shí)候叁幢，不可避免地需要進(jìn)行跨域操作，這時(shí)候“同源策略”就顯 得過于苛刻坪稽。 JSONP 跨域 GET 請(qǐng)求是一個(gè)常用的解決方案曼玩，下面我們來看一下 JSONP 跨域是如何實(shí)現(xiàn) 的，并且探討下 JSONP 跨域的原理窒百。
jsonp 的最基本的原理是：動(dòng)態(tài)添加一個(gè)標(biāo)簽黍判， 使用 script 標(biāo)簽的 src 屬性沒有跨域的限制的特點(diǎn)實(shí)現(xiàn) 跨域。首先在客戶端注冊(cè)一個(gè) callback, 然后把 callback 的名字傳給服務(wù)器篙梢。此時(shí)顷帖，服務(wù)器先生成 json 數(shù)據(jù)。 然后以 javascript 語法的方式庭猩，生成一個(gè) function , function 名字就是傳遞上來的參數(shù) jsonp窟她。 最后將json 數(shù)據(jù)直接以入?yún)⒌姆绞剑胖玫?function 中蔼水，這樣就生成了一段 js 語法的文檔震糖，返回給客 戶端。
客戶端瀏覽器趴腋，解析 script 標(biāo)簽吊说，并執(zhí)行返回的 javascript 文檔，此時(shí)數(shù)據(jù)作為參數(shù)优炬，傳入到了客戶端 預(yù)先定義
好的 callback 函數(shù)里颁井。
17.談?wù)勀銓?duì) restful 的理解以及在項(xiàng)目中的使用？
一種軟件架構(gòu)風(fēng)格蠢护、設(shè)計(jì)風(fēng)格雅宾，而不是標(biāo)準(zhǔn)，只是提供了一組設(shè)計(jì)原則和約束條件葵硕。它主要用于客戶端 和服務(wù)器交
互類的軟件眉抬。 REST 指的是一組架構(gòu)約束條件和原則。滿足這些約束條件和原則的應(yīng)用程序或設(shè)計(jì)就是 RESTful懈凹。
它結(jié)構(gòu)清晰蜀变、符合標(biāo)準(zhǔn)、易于理解介评、擴(kuò)展方便库北，所以正得到越來越多網(wǎng)站的采用爬舰。
給大家推薦如下一篇博客，該博客從多個(gè)維度講解了什么是 Restful 并且給了 Restful 風(fēng)格樣式的 API 接口寒瓦。
18.什么是 webService情屹？
WebService 是一種跨編程語言和跨操作系統(tǒng)平臺(tái)的遠(yuǎn)程調(diào)用技術(shù)。所謂跨編程語言和跨操作平臺(tái)杂腰，就 是說服務(wù)端程序采用 java 編寫屁商，客戶端程序則可以采用其他編程語言編寫，反之亦然颈墅！跨操作系統(tǒng)平 臺(tái)則是指服務(wù)端程序和
戶端程序可以在不同的操作系統(tǒng)上。
19.常見的遠(yuǎn)程調(diào)用技術(shù)
RMI 是 java 語言本身提供的遠(yuǎn)程通訊協(xié)議雾袱，穩(wěn)定高效恤筛，是 EJB 的基礎(chǔ)。但它只能用于 JAVA 程序之間的 通訊芹橡。
Hessian 和 Burlap 是 caucho 公司提供的開源協(xié)議毒坛，基于 HTTP 傳輸，服務(wù)端不用開防火墻端口林说。協(xié) 議的規(guī)范公
開煎殷，可以用于任意語言⊥嚷幔跨平臺(tái)有點(diǎn)小問題豪直。
Httpinvoker 是 SpringFramework 提供的遠(yuǎn)程通訊協(xié)議，只能用于 JAVA 程序間的通訊珠移，且服務(wù)端和客 戶端必須
使用 SpringFramework弓乙。
Web service 是連接異構(gòu)系統(tǒng)或異構(gòu)語言的首選協(xié)議，它使用 SOAP 形式通訊钧惧，可以用于任何語言暇韧，目 前的許多
開發(fā)工具對(duì)其的支持也很好。
效率相比： RMI > Httpinvoker >= Hessian >> Burlap >> web service浓瞪。
