JavaWEB面試題
1.說下原生 jdbc 操作數據庫流程？（2017-11-25-wzz）
第一步： Class.forName()加載數據庫連接驅動；
第二步： DriverManager.getConnection()獲取數據連接對象;
第三步：根據 SQL 獲取 sql 會話對象，有 2 種方式 Statement、 PreparedStatement ;
第四步：執行 SQL 處理結果集，執行 SQL 前如果有參數值就設置參數值 setXXX();
第五步：關閉結果集、關閉會話、關閉連接
2.什麼要使用 PreparedStatement？
1、 PreparedStatement 接口繼承 Statement， PreparedStatement 實例包含已編譯的 SQL 語句，所以其執行
速度要快於 Statement 對象。
2 、 作 爲 Statement 的 子 類 ， PreparedStatement 繼 承 了 Statement 的 所 有 功 能 。 三 種 方
法 execute、 executeQuery 和 executeUpdate 已被更改以使之不再需要參數
3、在 JDBC 應用中,在任何時候都不要使用 Statement，原因如下：
一、代碼的可讀性和可維護性.Statement 需要不斷地拼接，而 PreparedStatement 不會。
二、 PreparedStatement 盡最大可能提高性能.DB 有緩存機制，相同的預編譯語句再次被調用不會再次需要
編譯。
三、最重要的一點是極大地提高了安全性.Statement 容易被 SQL 注入，而 PreparedStatementc 傳入的內容不會和 sql 語句發生任何匹配關係。
3.關係數據庫中連接池的機制是什麼？
前提：爲數據庫連接建立一個緩衝池。
1：從連接池獲取或創建可用連接
2：使用完畢之後，把連接返回給連接池
3：在系統關閉前，斷開所有連接並釋放連接佔用的系統資源
4：能夠處理無效連接，限制連接池中的連接總數不低於或者不超過某個限定值。
其中有幾個概念需要大家理解：
最小連接數是連接池一直保持的數據連接。如果應用程序對數據庫連接的使用量不大，將會有大量的數據庫連接
資源被浪費掉。
最大連接數是連接池能申請的最大連接數。如果數據連接請求超過此數，後面的數據連接請求將被加入到等待隊
列中，這會影響之後的數據庫操作。
如果最小連接數與最大連接數相差太大，那麼，最先的連接請求將會獲利，之後超過最小連接數量的連接請求等
價於建立一個新的數據庫連接。不過，這些大於最小連接數的數據庫連接在使用完不會馬上被釋放，它將被放到連接池中等待重複使用或是空閒超時後被釋放。
上面的解釋，可以這樣理解：數據庫池連接數量一直保持一個不少於最小連接數的數量，當數量不夠時，數據庫會
創建一些連接，直到一個最大連接數，之後連接數據庫就會等待。
4.http 的長連接和短連接
HTTP 協議有 HTTP/1.0 版本和 HTTP/1.1 版本。 HTTP1.1 默認保持長連接（HTTP persistent connection，也
翻譯爲持久連接），數據傳輸完成了保持 TCP 連接不斷開（不發 RST 包、不四次握手），等待在同域名下繼續用這個通道傳輸數據；相反的就是短連接。
在 HTTP/1.0 中，默認使用的是短連接。也就是說，瀏覽器和服務器每進行一次 HTTP 操作，就建立一次連接，任
務結束就中斷連接。 從 HTTP/1.1 起，默認使用的是長連接， 用以保持連接特性。
5.HTTP/1.1 與 HTTP/1.0 的區別
1 可擴展性
a) HTTP/1.1 在消息中增加版本號，用於兼容性判斷。
b) HTTP/1.1 增加了 OPTIONS 方法，它允許客戶端獲取一個服務器支持的方法列表。
c) 爲了與未來的協議規範兼容， HTTP/1.1 在請求消息中包含了 Upgrade 頭域，通過該頭域，客戶端可以讓服務器知道它能夠支持的其它備用通信協議，服務器可以據此進行協議切換，使用備用協議與客戶端進行通信。
2 緩存
在 HTTP/1.0 中，使用 Expire 頭域來判斷資源的 fresh 或 stale，並使用條件請求（conditional request）來判斷資源是否仍有效。 HTTP/1.1 在 1.0 的基礎上加入了一些 cache 的新特性，當緩存對象的 Age 超過 Expire 時變stale 對象， cache 不需要直接拋棄 stale 對象，而是與源服務器進行重新激活（revalidation）。
3 帶寬優化
HTTP/1.0 中，存在一些浪費帶寬的現象，例如客戶端只是需要某個對象的一部分，而服務器卻將整個對象送過來
了。例如，客戶端只需要顯示一個文檔的部分內容，又比如下載大文件時需要支持斷點續傳功能，而不是在發生斷連後不得不重新下載完整的包。
HTTP/1.1 中在請求消息中引入了 range 頭域，它允許只請求資源的某個部分。在響應消息中 Content-Range 頭
域聲明瞭返回的這部分對象的偏移值和長度。如果服務器相應地返回了對象所請求範圍的內容，則響應碼爲 206
（Partial Content），它可以防止 Cache 將響應誤以爲是完整的一個對象。
另外一種情況是請求消息中如果包含比較大的實體內容，但不確定服務器是否能夠接收該請求（如是否有權限），
此時若貿然發出帶實體的請求，如果被拒絕也會浪費帶寬。
HTTP/1.1 加入了一個新的狀態碼 100（Continue）。客戶端事先發送一個只帶頭域的請求，如果服務器因爲權
限拒絕了請求，就回送響應碼 401（Unauthorized）；如果服務器接收此請求就回送響應碼 100，客戶端就可以繼續
發送帶實體的完整請求了。注意， HTTP/1.0 的客戶端不支持 100 響應碼。但可以讓客戶端在請求消息中加入 Expect頭域，並將它的值設置爲 100-continue。
節省帶寬資源的一個非常有效的做法就是壓縮要傳送的數據。 Content-Encoding 是對消息進行端到端（end-toend）的編碼，它可能是資源在服務器上保存的固有格式（如 jpeg 圖片格式）；在請求消息中加入 Accept-Encoding
頭域，它可以告訴服務器客戶端能夠解碼的編碼方式
4 長連接
HTTP/1.0 規定瀏覽器與服務器只保持短暫的連接，瀏覽器的每次請求都需要與服務器建立一個 TCP 連接，服務
器完成請求處理後立即斷開 TCP 連接，服務器不跟蹤每個客戶也不記錄過去的請求。此外，由於大多數網頁的流量都比較小，一次 TCP 連接很少能通過 slow-start 區，不利於提高帶寬利用率。
HTTP 1.1 支持長連接（PersistentConnection）和請求的流水線（Pipelining）處理，在一個 TCP 連接上可以傳
送多個 HTTP 請求和響應，減少了建立和關閉連接的消耗和延遲。例如：一個包含有許多圖像的網頁文件的多個請求和應答可以在一個連接中傳輸，但每個單獨的網頁文件的請求和應答仍然需要使用各自的連接。
HTTP 1.1 還允許客戶端不用等待上一次請求結果返回，就可以發出下一次請求，但服務器端必須按照接收到客戶
端請求的先後順序依次回送響應結果，以保證客戶端能夠區分出每次請求的響應內容，這樣也顯著地減少了整個下載過程所需要的時間
5 消息傳遞
HTTP 消息中可以包含任意長度的實體，通常它們使用 Content-Length 來給出消息結束標誌。但是，對於很多動
態產生的響應，只能通過緩衝完整的消息來判斷消息的大小，但這樣做會加大延遲。如果不使用長連接，還可以通過連接關閉的信號來判定一個消息的結束。
HTTP/1.1 中引入了 Chunkedtransfer-coding 來解決上面這個問題，發送方將消息分割成若干個任意大小的數據塊，每個數據塊在發送時都會附上塊的長度，最後用一個零長度的塊作爲消息結束的標誌。這種方法允許發送方只
緩衝消息的一個片段，避免緩衝整個消息帶來的過載
在 HTTP/1.0 中，有一個 Content-MD5 的頭域，要計算這個頭域需要發送方緩衝完整個消息後才能進行。而
HTTP/1.1 中，採用 chunked 分塊傳遞的消息在最後一個塊（零長度）結束之後會再傳遞一個拖尾（trailer），它包含一個或多個頭域，這些頭域是發送方在傳遞完所有塊之後再計算出值的。發送方會在消息中包含一個 Trailer 頭域告訴接收方這個拖尾的存在。
6 Host 頭域
在HTTP1.0中認爲每臺服務器都綁定一個唯一的IP地址，因此，請求消息中的URL並沒有傳遞主機名（hostname）。
但隨着虛擬主機技術的發展，在一臺物理服務器上可以存在多個虛擬主機（Multi-homed Web Servers），並且它們共享一個 IP 地址。
HTTP1.1 的請求消息和響應消息都應支持 Host 頭域，且請求消息中如果沒有 Host 頭域會報告一個錯誤（400
Bad Request）。此外，服務器應該接受以絕對路徑標記的資源請求。
7 錯誤提示
HTTP/1.0 中只定義了 16 個狀態響應碼，對錯誤或警告的提示不夠具體。 HTTP/1.1 引入了一個 Warning 頭域，
增加對錯誤或警告信息的描述。
此外，在 HTTP/1.1 中新增了 24 個狀態響應碼，如 409（Conflict）表示請求的資源與資源的當前狀態發生衝突；
410（Gone）表示服務器上的某個資源被永久性的刪除
6.http 常見的狀態碼有哪些？
200 OK //客戶端請求成功
301 Moved Permanently（永久移除)，請求的 URL 已移走。 Response 中應該包含一個 Location URL, 說明資
源現在所處的位置
302 found 重定向
400 Bad Request //客戶端請求有語法錯誤， 不能被服務器所理解
401 Unauthorized //請求未經授權，這個狀態代碼必須和 WWW-Authenticate 報頭域一起使用
403 Forbidden //服務器收到請求，但是拒絕提供服務
404 Not Found //請求資源不存在， eg：輸入了錯誤的 URL
500 Internal Server Error //服務器發生不可預期的錯誤
503 Server Unavailable //服務器當前不能處理客戶端的請求，一段時間後可能恢復正常
7.GET 和 POST 的區別？
從表面現像上面看 GET 和 POST 的區別：
-
GET 請求的數據會附在 URL 之後（就是把數據放置在 HTTP 協議頭中），以?分割 URL 和傳輸數據，參數之間以&相連，如： login.action?name=zhagnsan&password=123456。 POST 把提交的數據則放置在是 HTTP 包的包體中。
-
GET 方式提交的數據最多隻能是 1024 字節，理論上 POST 沒有限制，可傳較大量的數據。其實這樣說是錯誤
的，不準確的： GET 方式提交的數據最多隻能是 1024 字節"，因爲 GET 是通過 URL 提交數據，那麼 GET 可提交的數據量就跟URL 的長度有直接關係了。而實際上， URL 不存在參數上限的問題， HTTP 協議規範沒有對 URL 長度進行限制。這個限制是特定的瀏覽器及服務器對它的限制。 IE對URL長度的限制是2083 字節(2K+35)。對於其他瀏覽器，如 Netscape、FireFox 等，理論上沒有長度限制，其限制取決於操作系統的支持。 -
POST 的安全性要比 GET 的安全性高。注意：這裏所說的安全性和上面 GET 提到的“安全”不是同個概念。上
面“安全”的含義僅僅是不作數據修改，而這裏安全的含義是真正的 Security 的含義，比如：通過 GET 提交數據，用戶名和密碼將明文出現在 URL 上，因爲(1)登錄頁面有可能被瀏覽器緩存， (2)其他人查看瀏覽器的歷史紀錄，那麼別人就可以拿到你的賬號和密碼了，除此之外，使用 GET 提交數據還可能會造成 Cross-site request forgery 攻擊。Get 是向服務器發索取數據的一種請求，而 Post 是向服務器提交數據的一種請求，在 FORM（表單）中， Method默認爲"GET"，實質上， GET 和 POST 只是發送機制不同，並不是一個取一個發！
8.http 中重定向和請求轉發的區別？
本質區別： 轉發是服務器行爲，重定向是客戶端行爲。
重定向特點：兩次請求，瀏覽器地址發生變化，可以訪問自己 web 之外的資源，傳輸的數據會丟失。
請求轉發特點：一次強求，瀏覽器地址不變，訪問的是自己本身的 web 資源，傳輸的數據不會丟失
9.Cookie 和 Session 的區別
Cookie 是 web 服務器發送給瀏覽器的一塊信息，瀏覽器會在本地一個文件中給每個 web 服務器存儲 cookie。
以後瀏覽器再給特定的 web 服務器發送請求時，同時會發送所有爲該服務器存儲的 cookie。
Session 是存儲在 web 服務器端的一塊信息。 session 對象存儲特定用戶會話所需的屬性及配置信息。當用戶在
應用程序的 Web 頁之間跳轉時，存儲在 Session 對象中的變量將不會丟失，而是在整個用戶會話中一直存在下。
Cookie 和 session 的不同點：
1、無論客戶端做怎樣的設置， session 都能夠正常工作。當客戶端禁用 cookie 時將無法使用 cookie。
2、在存儲的數據量方面： session 能夠存儲任意的 java 對象， cookie 只能存儲 String 類型的對象
10.session 共享怎麼做的（分佈式如何實現 session 共享）
問題描述：一個用戶在登錄成功以後會把用戶信息存儲在 session 當中，這時 session 所在服務器爲 server1，那
麼用戶在 session 失效之前如果再次使用 app，那麼可能會被路由到 server2，這時問題來了， server 沒有該用戶的session，所以需要用戶重新登錄，這時的用戶體驗會非常不好，所以我們想如何實現多臺 server 之間共享 session，讓用戶狀態得以保存。
1、服務器實現的 session 複製或 session 共享，這類型的共享 session 是和服務器緊密相關的，比如 webSphere或 JBOSS 在搭建集羣時候可以配置實現 session 複製或 session 共享，但是這種方式有一個致命的缺點，就是不好擴展和移植，比如我們更換服務器，那麼就要修改服務器配置。
2、利用成熟的技術做session複製，比如12306使用的gemfire，比如常見的內存數據庫如redis或memorycache，這類方案雖然比較普適，但是嚴重依賴於第三方，這樣當第三方服務器出現問題的時候，那麼將是應用的災難。
3、將 session 維護在客戶端，很容易想到就是利用 cookie，但是客戶端存在風險，數據不安全，而且可以存放的 數據量比較小，所以將 session 維護在客戶端還要對 session 中的信息加密。
我們實現的方案可以說是第二種方案和第三種方案的合體，可以利用 gemfire 實現 session 複製共享，還可以將
session 維護在 redis 中實現 session 共享，同時可以將 session 維護在客戶端的 cookie 中，但是前提是數據要加密。
這三種方式可以迅速切換，而不影響應用正常執行。我們在實踐中，首選 gemfire 或者 redis 作爲 session 共享的載體，一旦 session 不穩定出現問題的時候，可以緊急切換 cookie 維護 session 作爲備用，不影響應用提供服務。
這裏主要講解 redis 和 cookie 方案， gemfire 比較複雜大家可以自行查看 gemfire 工作原理。利用 redis 做
session 共享，首先需要與業務邏輯代碼解耦，不然 session 共享將沒有意義，其次支持動態切換到客戶端 cookie 模式。 redis 的方案是，重寫服務器中的 HttpSession 和 HttpServletRequest，首先實現 HttpSession 接口，重寫 session的所有方法，將 session 以 hash 值的方式存在 redis 中，一個 session 的 key 就是 sessionID， setAtrribute 重寫之後就是更新 redis 中的數據， getAttribute 重寫之後就是獲取 redis 中的數據，等等需要將 HttpSession 的接口一一實現
實現了 HttpSesson，那麼我們先將該 session 類叫做 MySession（當然實踐中不是這麼命名的），當 MySession
出現之後問題纔開始，怎麼能在不影響業務邏輯代碼的情況下，還能讓原本的 request.getSession（）獲取到的是MySession，而不是服務器原生的 session。這裏，我決定重寫服務器的 HttpServletRequet，這裏先稱爲 MyRequest，但是這可不是單純的重寫，我需要在原生的 request 基礎上重寫，於是我決定在 filter 中，實現 request 的偷樑換柱，我的思路是這樣的， MyRequest 的構建器，必須以 request 作爲參數，於是我在 filter 中將服務器原生的 request（也有 可能 是框 架封裝 過的 request ） ，當 做參數 new 出 來一 個 MyRequest ，並 且 MyRequest 也 實現 了HttpServletRequest 接口，其實就是對原生 request 的一個增強，這裏主要重寫了幾個 request 的方法，但是最重要的是重寫了 request.getSession()，寫到這裏大家應該都明白爲什麼重寫這個方法了吧，當然是爲了獲取 MySession，於是這樣就在filter中，偷偷的將原生的request換成MyRequest了，然後再將替換過的request傳入chan.doFilter()，這樣 filter 時候的代碼都使用的是 MyRequest 了，同時對業務代碼是透明的，業務代碼獲取 session 的方法仍然是request.getSession（），但其實獲取到的已經是 MySession 了，這樣對 session 的操作已經變成了對 redis 的操作。
這樣實現的好處有兩個，第一開發人員不需要對 session 共享做任何關注， session 共享對用戶是透明的；第二， filter是可配置的，通過 filter 的方式可以將 session 共享做成一項可插拔的功能，沒有任何侵入性。
這個時候已經實現了一套可插拔的 session 共享的框架了，但是我們想到如果 redis 服務出了問題，這時我們該怎
麼辦呢，於是我們延續 redis 的想法，想到可以將 session 維護在客戶端內（加密的 cookie），當然實現方法還是一樣的，我們重寫 HttpSession 接口，實現其所有方法，比如 setAttribute 就是寫入 cookie， getAttribute 就是讀取cookie，我們可以將重寫的 session 稱作 MySession2，這時怎麼讓開發人員透明的獲取到 MySession2 呢，實現方法還是在 filter 內偷樑換柱，在 MyRequest 加一個判斷，讀取 sessionType 配置，如果 sessionType 是 redis 的，那麼 getSession 的時候獲取到的是 MySession，如果 sessionType 是 coolie 的，那麼 getSession 的時候獲取到的是MySession2，以此類推，用同樣的方法就可以獲取到 MySession 3,4,5,6 等等。
這樣兩種方式都有了，那麼我們怎實現兩種 session 共享方式的快速切換呢，剛剛我提到一個 sessionType，這
是用來決定獲取到session的類型的，只要變換sessionType就能實現兩種session共享方式的切換，但是sessionType必須對所有的服務器都是一致的，如果不一致那將會出現比較嚴重的問題，我們目前是將 sessionType 維護在環境變量裏，如果要切換 sessionType 就要重啓每一臺服務器，完成 session 共享的轉換，但是當服務器太多的時候將是一種災難。而且重啓服務意味着服務的中斷，所以這樣的方式只適合服務器規模比較小，而且用戶量比較少的情況，當服務器太多的時候，務必需要一種協調技術，能夠讓服務器能夠及時獲取切換的通知。基於這樣的原因，我們選用zookeeper 作爲配置平臺，每一臺服務器都會訂閱 zookeeper 上的配置，當我們切換 sessionType 之後，所有服務器都會訂閱到修改之後的配置，那麼切換就會立即生效，當然可能會有短暫的時間延遲，但這是可以接受的。
11.在單點登錄中，如果 cookie 被禁用了怎麼辦？
單點登錄的原理是後端生成一個 session ID，然後設置到 cookie，後面的所有請求瀏覽器都會帶上 cookie，
然後服務端從 cookie 裏獲取 session ID，再查詢到用戶信息。所以，保持登錄的關鍵不是 cookie，而是通過
cookie 保存和傳輸的 session ID，其本質是能獲取用戶信息的數據。除了 cookie，還通常使用 HTTP 請求頭來傳
輸。但是這個請求頭瀏覽器不會像 cookie 一樣自動攜帶，需要手工處理。
12.什麼是 jsp，什麼是 Servlet？ jsp 和 Servlet 有什麼區別？
jsp 本質上就是一個 Servlet，它是 Servlet 的一種特殊形式（由 SUN 公司推出），每個 jsp 頁面都是一個 servlet
實例。
Servlet 是由 Java 提供用於開發 web 服務器應用程序的一個組件，運行在服務端，由 servlet 容器管理，用來生
成動態內容。一個 servlet 實例是實現了特殊接口 Servlet 的 Java 類，所有自定義的 servlet 均必須實現 Servlet 接口。
區別：
jsp 是 html 頁面中內嵌的 Java 代碼，側重頁面顯示；
Servlet 是 html 代碼和 Java 代碼分離，側重邏輯控制， mvc 設計思想中 jsp 位於視圖層， servlet 位於控制層
Jsp 運行機制：如下圖
JVM 只能識別 Java 類，並不能識別 jsp 代碼！ web 容器收到以.jsp 爲擴展名的 url 請求時，會將訪問請求交給
tomcat 中 jsp 引擎處理，每個 jsp 頁面第一次被訪問時， jsp 引擎將 jsp 代碼解釋爲一個 servlet 源程序，接着編譯servlet 源程序生成.class 文件，再有 web 容器 servlet 引擎去裝載執行 servlet 程序，實現頁面交互。
13.jsp 有哪些域對象和內置對象及他們的作用？
四大域對象：
（1） pageContext page 域-指當前頁面，在當前 jsp 頁面有效，跳到其它頁面失效
（2） request request 域-指一次請求範圍內有效，從 http 請求到服務器處理結束，返回響應的整個過程。
在這個過程中使用 forward（請求轉發）方式跳轉多個 jsp，在這些頁面裏你都可以使用這個變量
（3） session session 域-指當前會話有效範圍，瀏覽器從打開到關閉過程中，轉發、重定向均可以使用
（4） application context 域-指只能在同一個 web 中使用，服務器未關閉或者重啓，數據就有效
九大內置對象：
| 生命週期 | 作用域 | 使用情況 | |
|---|---|---|---|
| Request | 一次請求 | 只在 Jsp 頁面內 有效 | 用於接受通過 HTTP 協議傳送到服務器 的數據（包括頭信息、系統信息、請 求方式以及請求參數等）。 |
| Reponse | 一次響應 | 只在 Jsp 頁面內 有效 | 表示服務器端對客戶端的迴應。主要 用於設置頭信息、跳轉、 Cookie |
| Session | 從存入數據開始，默認閒置 30 分鐘後失 效 | 會話內有效 | 用於存儲特定的用戶會話所需的信息 |
| Out | http://www.cnblogs.com/leirenyuan/p/601 6063.html | 用於在 Web 瀏覽器內輸出信息，並且 管理應用服務器上的輸出緩衝區 | |
| PageContext | 詳細瞭解： http://www.cnblogs.com/leirenyuan/p/601 6063.html | 用於存取其他隱含對象，如 request、 reponse、 session、 application 等對 象。（ 實際上， pageContext 對象提供 了對 JSP 頁面所有的對象及命名空間的 訪問 | |
| Page | http://www.cnblogs.com/leirenyuan/p/601 6063.html | page 對象代表 JSP 本身（對應 this） ， 只有在 JSP 頁面內纔是合法的 | |
| Exception | http://www.cnblogs.com/leirenyuan/p/601 6063.html | 顯示異常信息， 必須在 page 指令中設 定< %@ page isErrorPage=“true” %>才能 使用，在一般的 JSP 頁面中使用該對象 將無法編譯 JSP 文件 | |
| Application | 服務器啓動發送第一個請求時就產生了 Application 對象，直到服務器關閉。 | 用於存儲和訪問來自任何頁面的變量 所有的用戶分享一個 Application 對象 | |
| Config | http://www.cnblogs.com/leirenyuan/p/601 6063.html | 取得服務器的配置信息 |
14.什麼是 xml，使用 xml 的優缺點， xml 的解析器有哪幾種，分別有什麼區別？
xml 是一種可擴展性標記語言，支持自定義標籤（使用前必須預定義）使用 DTD 和 XML Schema 標準化 XML 結
構
優點：用於配置文件，格式統一，符合標準；用於在互不兼容的系統間交互數據，共享數據方便；
缺點： xml 文件格式複雜，數據傳輸佔流量，服務端和客戶端解析 xml 文件佔用大量資源且不易維護Xml 常用解析器有 2 種，分別是： DOM 和 SAX;
主要區別在於它們解析 xml 文檔的方式不同。使用 DOM 解析， xml 文檔以 DOM樹形結構加載入內存，而 SAX 採用的是事件模型，
15.談談你對 ajax 的認識？
Ajax 是一種創建交互式網頁應用的的網頁開發技術； Asynchronous JavaScript and XML”的縮寫。
Ajax 的優勢：
通過異步模式，提升了用戶體驗。
優化了瀏覽器和服務器之間的傳輸，減少不必要的數據往返，減少了帶寬佔用。
Ajax 引擎在客戶端運行，承擔了一部分本來由服務器承擔的工作，從而減少了大用戶量下的服務器負載。
Ajax 的最大特點：
可以實現局部刷新，在不更新整個頁面的前提下維護數據，提升用戶體驗度。
注意：ajax 在 實 際 項 目 開 發 中 使 用 率 非 常 高 （ 牢 固 掌 握 ） ， 針 對 ajax 的 詳 細 描 述 ：
16.jsonp 原理
JavaScript 是一種在 Web 開發中經常使用的前端動態腳本技術。在 JavaScript 中，有一個很重要的安全性限制，被稱爲“Same-Origin Policy”（同源策略）。這一策略對於 JavaScript 代碼能夠訪問的頁面內容做了很重要的限制，即 JavaScript 只能訪問與包含它的文檔在同一域下的內容。
JavaScript 這個安全策略在進行多 iframe 或多窗口編程、以及 Ajax 編程時顯得尤爲重要。根據這個策略，在 baidu.com 下的頁面中包含的 JavaScript 代碼，不能訪問在 google.com 域名下的頁面內容；甚至不同的子域名之間的頁面也不能通過 JavaScript 代碼互相訪問。對於 Ajax 的影響在於，通過 XMLHttpRequest 實現的Ajax 請求，不能向不同的域提交請求，例如，在 abc.example.com 下的頁面，不能向 def.example.com 提交Ajax 請求，等等。
然而，當進行一些比較深入的前端編程的時候，不可避免地需要進行跨域操作，這時候“同源策略”就顯得過於苛刻。 JSONP 跨域 GET 請求是一個常用的解決方案，下面我們來看一下 JSONP 跨域是如何實現的，並且探討下 JSONP 跨域的原理。
jsonp 的最基本的原理是：動態添加一個
客戶端瀏覽器，解析 script 標籤，並執行返回的 javascript 文檔，此時數據作爲參數，傳入到了客戶端預先定義
好的 callback 函數裏。
17.談談你對 restful 的理解以及在項目中的使用？
一種軟件架構風格、設計風格，而不是標準，只是提供了一組設計原則和約束條件。它主要用於客戶端和服務器交
互類的軟件。 REST 指的是一組架構約束條件和原則。滿足這些約束條件和原則的應用程序或設計就是 RESTful。
它結構清晰、符合標準、易於理解、擴展方便，所以正得到越來越多網站的採用。
給大家推薦如下一篇博客，該博客從多個維度講解了什麼是 Restful 並且給了 Restful 風格樣式的 API 接口。
18.什麼是 webService？
WebService 是一種跨編程語言和跨操作系統平臺的遠程調用技術。所謂跨編程語言和跨操作平臺，就是說服務端程序採用 java 編寫，客戶端程序則可以採用其他編程語言編寫，反之亦然！跨操作系統平臺則是指服務端程序和
戶端程序可以在不同的操作系統上。
19.常見的遠程調用技術
RMI 是 java 語言本身提供的遠程通訊協議，穩定高效，是 EJB 的基礎。但它只能用於 JAVA 程序之間的通訊。
Hessian 和 Burlap 是 caucho 公司提供的開源協議，基於 HTTP 傳輸，服務端不用開防火牆端口。協議的規範公
開，可以用於任意語言。跨平臺有點小問題。
Httpinvoker 是 SpringFramework 提供的遠程通訊協議，只能用於 JAVA 程序間的通訊，且服務端和客戶端必須
使用 SpringFramework。
Web service 是連接異構系統或異構語言的首選協議，它使用 SOAP 形式通訊，可以用於任何語言，目前的許多
開發工具對其的支持也很好。
9.常見的遠程調用技術
RMI 是 java 語言本身提供的遠程通訊協議，穩定高效，是 EJB 的基礎。但它只能用於 JAVA 程序之間的通訊。
Hessian 和 Burlap 是 caucho 公司提供的開源協議，基於 HTTP 傳輸，服務端不用開防火牆端口。協議的規範公
開，可以用於任意語言。跨平臺有點小問題。
Httpinvoker 是 SpringFramework 提供的遠程通訊協議，只能用於 JAVA 程序間的通訊，且服務端和客戶端必須
使用 SpringFramework。
Web service 是連接異構系統或異構語言的首選協議，它使用 SOAP 形式通訊，可以用於任何語言，目前的許多
開發工具對其的支持也很好。
效率相比： RMI > Httpinvoker >= Hessian >> Burlap >> web service。
另外，還整理了一個整理了一本面試電子書，共 300頁！目錄如下
差不多花了大半個月在整理成冊，另外創建了一個比較大家關心的內推羣，自建立起就很受歡迎！羣裏目前有不少獵頭和各大互聯網公司HR，大多數來自，北京，上海，廣州，深圳，杭州，希望能給大家來帶幫助！
給俺點個讚唄，可以讓更多的人看到這篇文章，順便激勵下我，嘻嘻。
作者簡潔
作者：大家好，我是軍長，一如既往的爲廣大Java讀者奉獻MySQL、SSM、Redis、Spring，並且整理了300頁Java面試手冊，個人博客 全部是Java，分佈式，大數據的系列文章。 轉載說明：未獲得授權，禁止轉載