Javaweb面試題及答案

1、說(shuō)下原生JDBC操作數(shù)據(jù)庫(kù)流程？

● 第一步：Class.forName()加載數(shù)據(jù)庫(kù)連接驅(qū)動(dòng)；

● 第二步：DriverManager.getConnection()獲取數(shù)據(jù)連接對(duì)象;

● 第三步：根據(jù)SQL獲取sql會(huì)話對(duì)象，有2種方式 Statement、PreparedStatement ;

● 第四步：執(zhí)行SQL，執(zhí)行SQL前如果有參數(shù)值就設(shè)置參數(shù)值setXXX();

● 第五步：處理結(jié)果集；

● 第六步：關(guān)閉結(jié)果集、關(guān)閉會(huì)話、關(guān)閉連接。

2、為什么要使用PreparedStatement？

PreparedStatement接口繼承Statement，PreparedStatement實(shí)例包含已編譯的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)是極大地提高了安全性。Statement容易被SQL注入，而PreparedStatement傳入的內(nèi)容不會(huì)和sql 語(yǔ)句發(fā)生任何匹配關(guān)系。

3、http的長(zhǎng)連接和短連接區(qū)別？

HTTP協(xié)議有HTTP/1.0版本和HTTP/1.1版本。HTTP1.1默認(rèn)保持長(zhǎng)連接（HTTP persistent connection，也翻譯為持久連接），數(shù)據(jù)傳輸完成了保持TCP連接不斷開(kāi)（不發(fā)RST包、不四次握手），等待在同域名下繼續(xù)用這個(gè)通道傳輸數(shù)據(jù)；相反的就是短連接。

在 HTTP/1.0 中，默認(rèn)使用的是短連接。也就是說(shuō)，瀏覽器和服務(wù)器每進(jìn)行一次HTTP操作，就建立一次連接，任務(wù)結(jié)束就中斷連接。從HTTP/1.1起，默認(rèn)使用的是長(zhǎng)連接，用以保持連接特性。

4、HTTP/1.1與HTTP/1.0的區(qū)別？

● 可擴(kuò)展性

● HTTP/1.1在消息中增加版本號(hào)，用于兼容性判斷。

● HTTP/1.1增加了OPTIONS方法，它允許客戶端獲取一個(gè)服務(wù)器支持的方法列表。

● 為了與未來(lái)的協(xié)議規(guī)范兼容，HTTP/1.1在請(qǐng)求消息中包含了Upgrade頭域，通過(guò)該頭域，客戶端可以讓服務(wù)器知道它能夠支持的其它備用通信協(xié)議，服務(wù)器可以據(jù)此進(jìn)行協(xié)議切換，使用備用協(xié)議與客戶端進(jìn)行通信。

● 緩存

在HTTP/1.0中，使用Expire頭域來(lái)判斷資源的fresh或stale，并使用條件請(qǐng)求（conditional request）來(lái)判斷資源是否仍有效。HTTP/1.1在1.0的基礎(chǔ)上加入了一些cache的新特性，當(dāng)緩存對(duì)象的Age超過(guò)Expire時(shí)變?yōu)閟tale對(duì)象，cache不需要直接拋棄stale對(duì)象，而是與源服務(wù)器進(jìn)行重新激活（revalidation）。

● 帶寬優(yōu)化

HTTP/1.0中，存在一些浪費(fèi)帶寬的現(xiàn)象，例如客戶端只是需要某個(gè)對(duì)象的一部分，而服務(wù)器卻將整個(gè)對(duì)象送過(guò)來(lái)了。例如，客戶端只需要顯示一個(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ì)象的偏移值和長(zhǎng)度。如果服務(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-to-end）的編碼，它可能是資源在服務(wù)器上保存的固有格式（如 jpeg 圖片格式）；在請(qǐng)求消息中加入Accept-Encoding頭域，它可以告訴服務(wù)器客戶端能夠解碼的編碼方式。

● 長(zhǎng)連接

HTTP/1.0規(guī)定瀏覽器與服務(wù)器只保持短暫的連接，瀏覽器的每次請(qǐng)求都需要與服務(wù)器建立一個(gè)TCP連接，服務(wù)器完成請(qǐng)求處理后立即斷開(kāi)TCP連接，服務(wù)器不跟蹤每個(gè)客戶也不記錄過(guò)去的請(qǐng)求。此外，由于大多數(shù)網(wǎng)頁(yè)的流量都比較小，一次TCP連接很少能通過(guò)slow-start區(qū)，不利于提高帶寬利用率。

HTTP 1.1支持長(zhǎng)連接（PersistentConnection）和請(qǐng)求的流水線（Pipelining）處理，在一個(gè) TCP連接上可以傳送多個(gè)HTTP請(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)答仍然需要使用各自的連接。

HTTP1.1還允許客戶端不用等待上一次請(qǐng)求結(jié)果返回，就可以發(fā)出下一次請(qǐng)求，但服務(wù)器端必須按照接收到客戶端請(qǐng)求的先后順序依次回送響應(yīng)結(jié)果，以保證客戶端能夠區(qū)分出每次請(qǐng)求的響應(yīng)內(nèi)容，這樣也顯著地減少了整個(gè)下載過(guò)程所需要的時(shí)間。

● 消息傳遞

HTTP消息中可以包含任意長(zhǎng)度的實(shí)體，通常它們使用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é)束。

HTTP/1.1中引入了Chunkedtransfer-coding來(lái)解決上面這個(gè)問(wèn)題，發(fā)送方將消息分割成若干個(gè)任意大小的數(shù)據(jù)塊，每個(gè)數(shù)據(jù)塊在發(fā)送時(shí)都會(huì)附上塊的長(zhǎng)度，最后用一個(gè)零長(zhǎng)度的塊作為消息結(jié)束的標(biāo)志。這種方法允許發(fā)送方只緩沖消息的一個(gè)片段，避免緩沖整個(gè)消息帶來(lái)的過(guò)載。

在HTTP/1.0中，有一個(gè)Content-MD5的頭域，要計(jì)算這個(gè)頭域需要發(fā)送方緩沖完整個(gè)消息后才能進(jìn)行。而HTTP/1.1中，采用chunked分塊傳遞的消息在最后一個(gè)塊（零長(zhǎng)度）結(jié)束之后會(huì)再傳遞一個(gè)拖尾（trailer），它包含一個(gè)或多個(gè)頭域，這些頭域是發(fā)送方在傳遞完所有塊之后再計(jì)算出值的。發(fā)送方會(huì)在消息中包含一個(gè)Trailer頭域告訴接收方這個(gè)拖尾的存在。

● Host頭域

在HTTP1.0中認(rèn)為每臺(tái)服務(wù)器都綁定一個(gè)唯一的IP地址，因此，請(qǐng)求消息中的URL并沒(méi)有傳遞主機(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)求消息中如果沒(méi)有 Host 頭域會(huì)報(bào)告一個(gè)錯(cuò)誤（400 Bad Request）。此外，服務(wù)器應(yīng)該接受以絕對(duì)路徑標(biāo)記的資源請(qǐng)求。

● 錯(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（Conflict）表示請(qǐng)求的資源與資源的當(dāng)前狀態(tài)發(fā)生沖突；410（Gone）表示服務(wù)器上的某個(gè)資源被永久性的刪除。

5、http常見(jiàn)的狀態(tài)碼有哪些？

● 200 OK 客戶端請(qǐng)求成功

● 301Moved Permanently（永久移除)，請(qǐng)求的URL已移走。Response中應(yīng)該包含一個(gè) Location URL，說(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ò)誤的URL

● 500 Internal Server Error 服務(wù)器發(fā)生不可預(yù)期的錯(cuò)誤

● 503 Server Unavailable 服務(wù)器當(dāng)前不能處理客戶端的請(qǐng)求，一段時(shí)間后可能恢復(fù)正常

6、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沒(méi)有限制，可傳較大量的數(shù)據(jù)。其實(shí)這樣說(shuō)是錯(cuò)誤的，不準(zhǔn)確的：“GET方式提交的數(shù)據(jù)最多只能是1024字節(jié)"，因?yàn)?GET 是通過(guò)URL提交數(shù)據(jù)，那么GET可提交的數(shù)據(jù)量就跟URL的長(zhǎng)度有直接關(guān)系了。而實(shí)際上，URL不存在參數(shù)上限的問(wèn)題，HTTP協(xié)議規(guī)范沒(méi)有對(duì)URL長(zhǎng)度進(jìn)行限制。這個(gè)限制是特定的瀏覽器及服務(wù)器對(duì)它的限制。IE對(duì)URL長(zhǎng)度的限制是2083字節(jié)(2K+35)。對(duì)于其他瀏覽器，如Netscape、FireFox等，理論上沒(méi)有長(zhǎng)度限制，其限制取決于操作系統(tǒng)的支持。

● POST的安全性要比GET的安全性高。注意：這里所說(shuō)的安全性和上面 GET 提到的“安全”不是同個(gè)概念。上面“安全”的含義僅僅是不作數(shù)據(jù)修改，而這里安全的含義是真正的 Security的含義，比如：通過(guò)GET 提交數(shù)據(jù)，用戶名和密碼將明文出現(xiàn)在URL上，因?yàn)榈卿涰?yè)面有可能被瀏覽器緩存，其他人查看瀏覽器的歷史紀(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ā)。

7、http中重定向和請(qǐng)求轉(zhuǎn)發(fā)的區(qū)別？

本質(zhì)區(qū)別：轉(zhuǎn)發(fā)是服務(wù)器行為，重定向是客戶端行為。

重定向特點(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。以后瀏覽器再給特定的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è)之間跳轉(zhuǎn)時(shí)，存儲(chǔ)在Session對(duì)象中的變量將不會(huì)丟失，而是在整個(gè)用戶會(huì)話中一直存在下去。

● Cookie和 Session的不同點(diǎn)：

無(wú)論客戶端做怎樣的設(shè)置，Session都能夠正常工作。當(dāng)客戶端禁用Cookie時(shí)將無(wú)法使用Cookie。

在存儲(chǔ)的數(shù)據(jù)量方面：Session能夠存儲(chǔ)任意的java對(duì)象，Cookie只能存儲(chǔ)String類型的對(duì)象。

9、2.session共享怎么做的（分布式如何實(shí)現(xiàn)session共享）？

問(wèn)題描述：一個(gè)用戶在登錄成功以后會(huì)把用戶信息存儲(chǔ)在session當(dāng)中，這時(shí)session所在服務(wù)器為server1，那么用戶在session失效之前如果再次使用app，那么可能會(huì)被路由到 server2，這時(shí)問(wèn)題來(lái)了，server2沒(méi)有該用戶的session，所以需要用戶重新登錄，這時(shí)的用戶體驗(yàn)會(huì)非常不好，所以我們想如何實(shí)現(xiàn)多臺(tái)server之間共享session，讓用戶狀態(tài)得以保存。

● 服務(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ù)器配置。

● 利用成熟的技術(shù)session復(fù)制，比如12306使用的gemfire，比如常見(jiàn)的內(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實(shí)現(xiàn)session復(fù)制共享，還可以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ù)邏輯代碼解耦，不然session共享將沒(méi)有意義，其次支持動(dòng)態(tài)切換到客戶端cookie模式。redis的方案是，重寫(xiě)服務(wù)器中的HttpSession和HttpServletRequest，首先實(shí)現(xiàn)HttpSession接口，重寫(xiě)session的所有方法，將session以hash值的方式存在redis中，一個(gè)session的key就是sessionID，setAtrribute重寫(xiě)之后就是更新redis中的數(shù)據(jù)，getAttribute重寫(xiě)之后就是獲取redis中的數(shù)據(jù)，等等需要將HttpSession的接口一一實(shí)現(xiàn)。實(shí)現(xiàn)了HttpSesson，那么我們先將該session類叫做MySession（當(dāng)然實(shí)踐中不是這么命名的），當(dāng)MySession出現(xiàn)之后問(wèn)題才開(kāi)始，怎么能在不影響業(yè)務(wù)邏輯代碼的情況下，還能讓原本的request.getSession()獲取到的是MySession，而不是服務(wù)器原生的session。這里，我決定重寫(xiě)服務(wù)器的HttpServletRequet，這里先稱為MyRequest，但是這可不是單純的重寫(xiě)，我需要在原生的request基礎(chǔ)上重寫(xiě)，于是我決定在filter中，實(shí)現(xiàn)request的偷梁換柱，我的思路是這樣的，MyRequest的構(gòu)建器，必須以request作為參數(shù)，于是我在filter中將服務(wù)器原生的request（也有可能是框架封裝過(guò)的request），當(dāng)做參數(shù)new出來(lái)一個(gè)MyRequest，并且MyRequest也實(shí)現(xiàn)了HttpServletRequest接口，其實(shí)就是對(duì)原生request的一個(gè)增強(qiáng)，這里主要重寫(xiě)了幾個(gè)request的方法，但是最重要的是重寫(xiě)了request.getSession()，寫(xiě)到這里大家應(yīng)該都明白為什么重寫(xiě)這個(gè)方法了吧，當(dāng)然是為了獲取MySession，于是這樣就在filter中，偷偷的將原生的request換成MyRequest了，然后再將替換過(guò)的request傳入chan.doFilter()，這樣filter時(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è)，第一開(kāi)發(fā)人員不需要對(duì)session共享做任何關(guān)注，session共享對(duì)用戶是透明的；第二，filter是可配置的，通過(guò)filter的方式可以將session共享做成一項(xiàng)可插拔的功能，沒(méi)有任何侵入性。這個(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)方法還是一樣的，我們重寫(xiě)HttpSession接口，實(shí)現(xiàn)其所有方法，比如setAttribute就是寫(xiě)入cookie，getAttribute就是讀取cookie，我們可以將重寫(xiě)的session稱作MySession2，這時(shí)怎么讓開(kāi)發(fā)人員透明的獲取到MySession2呢，實(shí)現(xiàn)方法還是在filter內(nèi)偷梁換柱，在MyRequest加一個(gè)判斷，讀取sessionType配置，如果sessionType是redis的，那么getSession的時(shí)候獲取到的是MySession，如果sessionType是coolie的，那么getSession的時(shí)候獲取到的是MySession2，以此類推，用同樣的方法就可以獲取到MySession3，4，5，6等等。

這樣兩種方式都有了，那么我們?cè)鯇?shí)現(xiàn)兩種session共享方式的快速切換呢，剛剛我提到一個(gè)sessionType，這是用來(lái)決定獲取到session的類型的，只要變換sessionType就能實(shí)現(xiàn)兩種session共享方式的切換，但是sessionType必須對(duì)所有的服務(wù)器都是一致的，如果不一致那將會(huì)出現(xiàn)比較嚴(yán)重的問(wè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í)間延遲，但這是可以接受的。

10、在單點(diǎn)登錄中，如果cookie被禁用了怎么辦？???????

單點(diǎn)登錄的原理是后端生成一個(gè)sessionID，然后設(shè)置到cookie，后面的所有請(qǐng)求瀏覽器都會(huì)帶上cookie，然后服務(wù)端從cookie里獲取sessionID，再查詢到用戶信息。所以，保持登錄的關(guān)鍵不是cookie，而是通過(guò)cookie保存和傳輸?shù)膕essionID，其本質(zhì)是能獲取用戶信息的數(shù)據(jù)。除了cookie，還通常使用HTTP請(qǐng)求頭來(lái)傳輸。但是這個(gè)請(qǐng)求頭瀏覽器不會(huì)像cookie一樣自動(dòng)攜帶，需要手工處理。??????????????