01Javaweb面試題集答案

1、Javaweb面試題及答案L說(shuō)下原生JDBC操作數(shù)據(jù)庫(kù)流程？第一步：Class.forNameO加載數(shù)據(jù)庫(kù)連接驅(qū)動(dòng)；第二步:DriverManager.getConnectionO獲取數(shù)據(jù)連接對(duì)象；第三步：根據(jù)SQL獲取sql會(huì)話對(duì)象，有2種方式Statement. PreparedStatement;第四步：執(zhí)行SQL,執(zhí)行SQL前如果有參數(shù)值就設(shè)西參數(shù)值setXXXQ;第五步：處理結(jié)果集；第六步：關(guān)閉結(jié)果集、關(guān)閉會(huì)話、關(guān)閉連接。2、為什么要使用 PreparedStatement ?PreparedStatement接口繼承Statement, PreparedStatement實(shí)例包含已

2、編譯的SQL語(yǔ)句，所以其執(zhí)行速度要快于Statement對(duì) 象.作為 Statement 的子類，PreparedStatement 繼承了 Statement 的所有功能。三種方法 execute、executeQuery 和 executeUpdate 已被更改以使之不再需要參數(shù).在JDBC應(yīng)用中，多數(shù)情況下使用PreparedStatement,原因如下：代碼的可讀性和可維護(hù)性.Statement需要不斷地拼接，而PreparedStatement不會(huì).PreparedStatement盡最大可能提高性能.DB有緩存機(jī)制，相同的預(yù)編深語(yǔ)句再次被調(diào)用不會(huì)再次需要編譯.最重變的一點(diǎn)是極大地提

3、高了安全性。Statement容易被SQL注入，而PreparedStatement傳入的內(nèi)容不會(huì)和sql語(yǔ)句發(fā)生任何匹配 關(guān)系.3、 的長(zhǎng)連接和短連接區(qū)別？ 協(xié)議有 /1.0版本和 /1.1版本. 1.1默認(rèn)保持長(zhǎng)連接( persistent connection ,也翻譯為持久連接)，數(shù) 據(jù)傳輸完成了保持TCP連接不斷開(不發(fā)RST包、不四次握手)，等待在同域名下繼續(xù)用這個(gè)通道傳輸數(shù)據(jù)；相反的就是短連接.在 /1.0中，默認(rèn)使用的是短連接.也就是說(shuō)，瀏覽器和服務(wù)器每進(jìn)行一次 操作，就建立一次連接，任務(wù)結(jié)束就中斷連接.從 /1.1起，默認(rèn)使用的是長(zhǎng)連接，用以保持連接特性.4. /1.1 與

4、/1.0 的區(qū)別？可擴(kuò)展性 /L1在消息中增加版本號(hào)，用于兼容性判斷。HRP/1.1增加了 OPTIONS方法，它允許客戶端獲取一個(gè)服務(wù)器支持的方法列衷.為了與未來(lái)的協(xié)議規(guī)范兼容，HUP/1.1在請(qǐng)求消息中包含了 Upgrade頭域，通過(guò)該頭域，客戶端可以讓服務(wù)器知道它能夠支持的具 它備用通信協(xié)議，服務(wù)器可以據(jù)此進(jìn)行協(xié)議切換，使用備用協(xié)設(shè)與客戶端進(jìn)行通信.緩存在 /1.0中使用Expire頭域來(lái)判斷資源的fresh或stale并使用條件請(qǐng)求conditional request原判斷資源是否仍有效。 /1.1 在1.0的基礎(chǔ)上加入了一些cache的新特性，當(dāng)緩存對(duì)象的Age超過(guò)Expire時(shí)變

5、為stale對(duì)象，cache不需要亙接拋棄stale對(duì)象，而 是與源服務(wù)器進(jìn)行更新激活(revalidation ).帶寬優(yōu)化HUP/1.0中，存在一些浪費(fèi)帶寬的現(xiàn)象，例如客戶端只是需要某個(gè)對(duì)象的一局部，而服務(wù)器卻將整個(gè)對(duì)象送過(guò)來(lái)了,例如，客戶端只需 要顯示一個(gè)文檔的局部?jī)?nèi)容，又比方下載大文件時(shí)需要支持?jǐn)帱c(diǎn)續(xù)傳功能，而不是在發(fā)生斷連后不得不里新下載完整的包. /L1中在請(qǐng)求消息中引入了 range頭域,它允許只請(qǐng)求資源的某個(gè)局部.在響應(yīng)消息中Content-Range頭域聲明了返回的這局部 對(duì)象的偏移值和長(zhǎng)度.如果I員務(wù)器相應(yīng)地返回了對(duì)象所請(qǐng)求范圍的內(nèi)容，那么響應(yīng)碼為206 ( Partial

6、 Content),它可以防止Cache將響 應(yīng)誤以為是完型的一個(gè)對(duì)象，另夕1種情況是請(qǐng)求消息中如果包含比擬大的實(shí)體內(nèi)容，但不確定務(wù)器是否能夠接收該請(qǐng)求(如是否有權(quán)限),此時(shí)假設(shè)貿(mào)然發(fā)出帶實(shí) 體的請(qǐng)求，如果被拒絕也會(huì)浪費(fèi)帶寬.HRP/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)求了.注意， /1.0的客戶端不支持100響應(yīng)碼.但可以讓客戶端在請(qǐng)求消息中加入Expect頭域，并將它的值

7、設(shè)置為100-continue.節(jié) 省帶寬資源的一個(gè)非常有效的做法就是壓縮要傳送的數(shù)據(jù).Content-Encoding是對(duì)消息進(jìn)行端到端(end-to-end )的編碼，它可能是 資源在服務(wù)器上保存的固有格式(如jpeg圖片格式)；在請(qǐng)求消息中加入Accept-Encoding頭域，它可以告訴服務(wù)器客戶端能夠解碼 的編碼方式.長(zhǎng)連接 /L0規(guī)定瀏覽器與服務(wù)器只保持短暫的連接，瀏覽器的每次請(qǐng)求都需要與服務(wù)器建立一個(gè)TCP連接，服務(wù)器完成請(qǐng)求處理后立即 斷開TCP連接服務(wù)器不跟蹤每個(gè)客戶也不記錄過(guò)去的請(qǐng)求.此外，由于大多數(shù)網(wǎng)頁(yè)的流量都比擬小，一次TCP連接很少能通過(guò)slow-start 區(qū),不利

8、于提高帶寬利用率。 1.1支持長(zhǎng)連接(PersistentConnection )和請(qǐng)求的流水線(Pipelining )處理,在一個(gè)TCP連接上可以傳送多個(gè) 請(qǐng)求和 嗚應(yīng)，減少了建立和關(guān)閉連接的消楸口延遲。例如：一個(gè)包含有許多圖像的網(wǎng)頁(yè)文件的多個(gè)請(qǐng)求和應(yīng)答可以在一個(gè)連接中傳輸，但每個(gè) 單獨(dú)的網(wǎng)頁(yè)文件的請(qǐng)求和應(yīng)答仍然需要使用各自的連接. 1.1還允許客戶端不用等待上一次請(qǐng)求結(jié)果返回，就可以發(fā)出下一次請(qǐng)求，回員務(wù)器端必須按照接收到客戶端請(qǐng)求的先后順序依次 回送響應(yīng)結(jié)果，以保證客戶端能夠區(qū)分出每次請(qǐng)求的響應(yīng)內(nèi)容，這樣也顯著地減少了整個(gè)下載過(guò)程所需要的時(shí)間.消息傳遞 消息中可以包含任過(guò)長(zhǎng)度的實(shí)體，通

9、常它們使用Content-Length來(lái)給出消息結(jié)束標(biāo)志。但是，對(duì)于很多動(dòng)態(tài)產(chǎn)生的響應(yīng)，只能 通過(guò)緩沖完整的消息來(lái)判斷消息的大小，但這樣做會(huì)加大延遲,如果不使用長(zhǎng)連接，還可以通過(guò)連接關(guān)閉的信號(hào)來(lái)判定一個(gè)消息的結(jié)束. /1.1中引入了 Chunkedtransfer-coding來(lái)解決上面這個(gè)問(wèn)題，發(fā)送方將消息分割成假設(shè)干個(gè)任意大的數(shù)據(jù)塊，每個(gè)數(shù)據(jù)塊在發(fā)送 時(shí)都會(huì)附上塊的長(zhǎng)度，最后用一個(gè)零長(zhǎng)度的塊作為消息結(jié)束的標(biāo)志.這種方法允許發(fā)送方只緩沖消息的一個(gè)片段，防止緩沖整個(gè)消息帶 來(lái)的過(guò)載.在 /L0中，有一個(gè)Content-MDS的頭域，要計(jì)算這個(gè)頭域需要發(fā)送方緩沖完整個(gè)消息后才能進(jìn)行.而 /1.1

10、中采用chunked 分塊傳遞的消息在最后一個(gè)塊(零長(zhǎng)度)結(jié)束之后會(huì)再傳遞一個(gè)拖尾(trailer),它包含一個(gè)或多個(gè)頭域，這些頭域是發(fā)送方在傳遞完所 有塊之后再計(jì)箕出值的.發(fā)送方會(huì)在消息中包含一個(gè)Trailer頭域告訴接收方這個(gè)拖尾的存在. Host頭域在 L0中認(rèn)為每臺(tái)服務(wù)器都綁定一個(gè)唯一的IP地址，因此，請(qǐng)求消息中的URL并沒有傳遞主機(jī)名(hostname ).但隨著虛擬主 機(jī)技術(shù)的開展，在一臺(tái)物理服務(wù)器上可以存在多個(gè)虛擬主機(jī)(Multi-homed Web Servers ),并且它們共享一個(gè)IP地址. L1的 請(qǐng)求消息和響應(yīng)消息都應(yīng)支持Host頭域，且請(qǐng)求消息中如果沒有Host頭域會(huì)

11、報(bào)告一個(gè)靖誤(400 Bad Request).此外,服務(wù)器應(yīng) 該接受以絕對(duì)路徑標(biāo)記的資源請(qǐng)求.錯(cuò)誤提示HUP/1.0中只定義了 16個(gè)狀態(tài)響應(yīng)碼，對(duì)錯(cuò)誤或警告的提示不夠具體。 /1.1引入了一個(gè)Warning頭域，增加對(duì)錯(cuò)誤或警告信 息的描述.此外，在 /1.1中新增了 24個(gè)狀態(tài)響應(yīng)碼，如409( Conflict)表示請(qǐng)求的資源與資源的當(dāng)前狀態(tài)發(fā)生沖突;410( Gone ) 表示服務(wù)據(jù)上的某個(gè)資源被永久性的刪除.5、 常見的狀態(tài)碼有哪些？200 0K客戶端請(qǐng)求成功301Moved Permanently (永久移除),請(qǐng)求的URL已移走。Response中應(yīng)該包含Location UR

12、L ,說(shuō)明資源現(xiàn)在所處的位置 302found重定向400Bad Request客戶端請(qǐng)求有語(yǔ)法錯(cuò)誤，不能被服務(wù)器所理解401Unauthorized請(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ò)誤的URL500 Internal Server Error服務(wù)gg發(fā)生不可預(yù)期的1自誤503 Server Unavailable服務(wù)器當(dāng)前不能處理客戶端的請(qǐng)求,一段時(shí)間后可能恢且正常6、GET和POST的區(qū)別？GET請(qǐng)求的數(shù)據(jù)會(huì)附在URL之后（就是把數(shù)

13、據(jù)放置在 協(xié)議頭中）,以?分割URL和傳諭數(shù)據(jù)，參數(shù)之間以&相連，如： login.action?name=zhagnsan&password=123456. POST 把提交的數(shù)據(jù)那么放音在是 包的包體中.GET方式提交的數(shù)據(jù)最多只能是1024字節(jié)，理論上POST沒有限制，可傳較大量的數(shù)據(jù).其實(shí)這樣說(shuō)是錯(cuò)誤的，不準(zhǔn)確的：GET 方式提交的數(shù)據(jù)最多只能是1024字節(jié)，因?yàn)镚ET是通過(guò)URL提交數(shù)據(jù)，另法GET可提交的數(shù)據(jù)量就跟URL的長(zhǎng)度有直接關(guān)系了. 而實(shí)際上，URL不存在參數(shù)上限的問(wèn)題， 協(xié)議規(guī)范沒有對(duì)URL長(zhǎng)度進(jìn)行限制.這個(gè)限制是特定的瀏覽器及服務(wù)器對(duì)它的限制.正 對(duì)URL長(zhǎng)度的限制是2

14、083字節(jié)（2K+35）.對(duì)于其他瀏覽器,如Netscape. FireFox等，理論上沒有長(zhǎng)度限制，其限制取決于掾作系統(tǒng) 的支持.POST的安全性要比GET的安全性高.注意：這里所說(shuō)的安全性和上面GET提到的安全”不是同個(gè)概念。上面安全”的含義僅 僅是不作數(shù)據(jù)修改，而這里安全的含義是真正的Security的含義，比方：通過(guò)GET提交數(shù)據(jù)，用戶名和密碼將明文出現(xiàn)在URL上，因 為登錄頁(yè)面有可能被瀏覽器緩存，其他人查看瀏覽器的歷史紀(jì)錄，那么別人就可以拿到你的賬號(hào)和空碼了，除此之外，使用GET提交 數(shù)據(jù)還可能會(huì)造成Cross-site request forgery攻擊.Get是向服務(wù)器發(fā)索取數(shù)據(jù)

15、的一種請(qǐng)求，而Post是向服務(wù)器提交數(shù)據(jù)的一種請(qǐng)求，在FORM （表單）中，Method默認(rèn)為“GE, 實(shí)質(zhì)上GET和POST只是發(fā)送機(jī)制不同，并不是一個(gè)取一個(gè)發(fā).7、 中重定向和諳求轉(zhuǎn)發(fā)的區(qū)別？本質(zhì)區(qū)別：轉(zhuǎn)發(fā)是I艮務(wù)器行為，變定向是客戶端行為.否認(rèn)向特點(diǎn)：兩次請(qǐng)求，瀏覽器地址發(fā)生變化，可以訪問(wèn)自己web之外的資源，傳輸?shù)臄?shù)據(jù)會(huì)喪失.請(qǐng)求轉(zhuǎn)發(fā)特點(diǎn)：一次強(qiáng)求，瀏覽器地址不變，訪問(wèn)的是自己本身的web資源，傳輸?shù)臄?shù)據(jù)不會(huì)喪失.8、Cookie 和 Session 的區(qū)別?Cookie是web服務(wù)器發(fā)送給瀏覽器的一塊信息，瀏覽器會(huì)在本地一個(gè)文件中給每個(gè)web服務(wù)器存儲(chǔ)Cookie.以后瀏覽甥再給特定

16、的 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頁(yè)之 間，篦時(shí)，存儲(chǔ)在Session對(duì)象中的變量將不會(huì)喪失，而是在整個(gè)用戶會(huì)話中一直存在下去.Cookie和Session的不同點(diǎn):無(wú)論客戶端做怎樣的設(shè)爸,Session都能夠正常工作.當(dāng)客戶端禁用Cookie時(shí)將無(wú)法使用Cookie.在存儲(chǔ)的數(shù)據(jù)量方面：Session能夠存悌任意的java對(duì)象，Cookie只能存儲(chǔ)String類型的對(duì)象.9、2.session共享怎么做的（分布式如何實(shí)現(xiàn)sess

17、ion共享）？問(wèn)題描述：一個(gè)用戶在登錄成功以后會(huì)把用戶信息存儲(chǔ)在session當(dāng)中，這時(shí)session所在服務(wù)器為serveri ,刃及用戶在session失效 之前如果再次使用app ,刃彩可能會(huì)被路由到server2,這時(shí)問(wèn)題來(lái)了，server2沒有該用戶的session ,所以需要用戶或新登錄，這時(shí) 的用戶體驗(yàn)會(huì)非常不好，所以我們想如何實(shí)現(xiàn)多臺(tái)server之間共享session ,讓用戶狀態(tài)得以保存。服務(wù)器實(shí)現(xiàn)的session豆制或session共享，這類型的共享session是和服務(wù)器緊密相關(guān)的，比方WebSphere或JBOSS在搭建集群 時(shí)候可以配置實(shí)現(xiàn)session豆制或sess

18、ion共享，但是這種方式有一個(gè)致命的缺點(diǎn),就是不好擴(kuò)展和移植,比方我們更換服務(wù)器,那么 就要修改服務(wù)器配置.利用成熟的技術(shù)session復(fù)制，比方12306使用的gemfire，比方常見的內(nèi)存數(shù)據(jù)庫(kù)如redis或memorycache ,這類方案雖然比擬 普適，但是嚴(yán)重依賴于第三方，這樣當(dāng)?shù)谌椒?wù)器出現(xiàn)問(wèn)題的時(shí)候，那么將是應(yīng)用的災(zāi)難.將session維護(hù)在客戶端，很容易想到就是利用cookie，但是客戶端存在風(fēng)險(xiǎn),數(shù)據(jù)不安全，而且可以存放的數(shù)據(jù)幽戚小,所以將 session維護(hù)在客戶端還要對(duì)session中的信息加密.我們實(shí)現(xiàn)的方案可以說(shuō)是第二種方案和第三種方案的合體，可以利用gemfire

19、實(shí) 現(xiàn)session豆制共享，還可以session維護(hù)在redis中實(shí)現(xiàn)session共享，同時(shí)可以將session維護(hù)在客戶端的cookie中，但是前提是 數(shù)據(jù)要加密。這三種方式可以迅速切換，而不影響應(yīng)用正常執(zhí)行.我們?cè)趯?shí)踐中，首選gemfire或者redis作為session共享的載體， 一旦session不穩(wěn)定出現(xiàn)問(wèn)題的時(shí)候，可以緊急切換cookie維護(hù)session作為備用，不影響應(yīng)用提供服務(wù).這里主要講解redis和cookie方案，gemfire匕嫩復(fù)雜大家可以自行查看gemfire工作原理.利用redis做session共享，首先需要與 業(yè)務(wù)邏擔(dān)代碼解酒,不然session共享將

20、沒有意義，其次支持動(dòng)態(tài)切換到客戶端cookie模式redis的方案是，至寫服務(wù)器中的 Session 和 ServletRequest,首卷t現(xiàn) Session 接口，重寫 session 的所有方法，格 session 以 hash 值的方式存在 redis 中，一個(gè)session的key就是sessionlD , setAtrribute至寫之后就是更新redis中的數(shù)據(jù),getAttribute *寫之后就是駛?cè)edis中的 數(shù)據(jù),等等需要將 Session的接口一實(shí)現(xiàn).實(shí)現(xiàn)了 Sesson ,那么我們先將該session類叫做MySession （當(dāng)然實(shí)踐中不是 這么命名的），當(dāng)My

21、Session出現(xiàn)之后問(wèn)題才開始，怎么能在不影響業(yè)務(wù)邏娼代碼的情況下,還能讓原本的request.getSession。獲取 到的是MySession ,而不是服務(wù)器原生的session.這里,我決定歪寫服務(wù)器的 ServletRequet,這里先稱為MyRequest,但是這 可不是單純的重寫，我需要在原生的request基礎(chǔ)上重寫，于是我決定在filter中，實(shí)現(xiàn)request的愉梁換柱，我的思路是這樣的, MyRequest的構(gòu)建器，必須以request作為參數(shù)，于是我在filter中將服務(wù)器原生的request （也有可能是框架封裝過(guò)的request）, 當(dāng)做參數(shù)new出來(lái)一個(gè)MyRe

22、quest,并且MyRequest降現(xiàn)了 ServletRequest接口，其實(shí)就是對(duì)原生request的f 增強(qiáng)， 這里主要更寫了幾個(gè)request的方法，但是最重要的是至寫了 request.getSessionQ ,寫到這里大家應(yīng)該都明白為什么歪寫這個(gè)方法了 吧，當(dāng)然是為了獲取MySession ,于是這樣就在filter中，偷價(jià)的將原生的request換成MyRequest 了 ,然后再將替換過(guò)的request 傳入chan.doFilter（）,這樣filter時(shí)候的代碼都使用的是MyRequest 了，同時(shí)對(duì)業(yè)務(wù)代碼是透明的，業(yè)務(wù)代碼獲取session的方法仍然 是request.

23、getSessionQ，但其實(shí)獲取到的已經(jīng)是MySession 了 ,這樣對(duì)session的操作已經(jīng)變成了對(duì)redis的操作.這樣實(shí)現(xiàn)的好處 有兩個(gè)，第一開發(fā)人員不需要對(duì)session共享做任何關(guān)注，session共享對(duì)用戶是透明的；第二,filter是可配置的，通過(guò)filter的方式 可以將session共享做成一項(xiàng)可插拔的功能，沒有任何侵入性.這個(gè)時(shí)候已經(jīng)實(shí)現(xiàn)了一套可插拔的session共享的框架了，但是我們想 到如果redis服務(wù)出了問(wèn)題，這時(shí)我們?cè)撛趺崔k呢，于是我們延續(xù)redis的想法，想到可以將session維護(hù)在客戶端內(nèi)（加密的cookie ）, 當(dāng)然實(shí)現(xiàn)方法還是一樣的，我們?nèi)珜?Session接口，實(shí)現(xiàn)其所有方法，比方setAttribute就是寫入cookie , getAttribute就是讀 取cookie ,我們可以將重寫的session稱作MySession2 ,這時(shí)怎么讓開發(fā)人員透明的獲取到MySession2呢，實(shí)現(xiàn)方法還是在filter 內(nèi)偷梁換住，在MyRequest加一個(gè)判斷，讀取sessionType配置,如果sessionType是redis的,另及 getSession的時(shí)候獲取到的 是MySession