J2EE框架面試題庫

時間：2024-11-03 17:49:44 煒玲 J2EE培訓

J2EE框架面試題庫

　　J2EE核心是一組技術規范與指南，其中所包含的各類組件、服務架構及技術層次，均有共同的標準及規格，讓各種依循J2EE架構的不同平臺之間，存在良好的兼容性，解決過去企業后端使用的信息產品彼此之間無法兼容，企業內部或外部難以互通的窘境。以下是小編整理的J2EE框架面試題庫，希望大家認真閱讀!

J2EE框架面試題庫

　　J2EE框架面試題庫1

　　1.Servlet 的生命周期

　　參考答案：Servlet 的生命周期主要為四個步驟實例化時調用構造方法，初始化 init()、業務處理 service()、銷毀 destory()。

　　1，啟動tomcat時，調用Servlet的構造方法

　　2、init 階段：init()方法在 Servlet 實例化的時候調用，而且只調用一次(對于

　　Servlet 的初始化，一般是第一次被請求時;或者在在 web.xml 中沒有配置

　　標簽的映射這個時候，我們可以配置元素中指定了子元素時，容器在啟動的時候自動加載這些 Servlet 并調用 init()方法) ， init()方法的作用是完成一些全局性的比較花費時間的初始化工作。

　　3、service()階段：Servlet 繼承了父類的 service()方法，那么前端 URL 發出的請求不管是以 get 方式或者 post 方式，都將直接走重寫的 service()方法，而不再走 doGet()和 goPost()方法。

　　4、終止階段調用 destroy()方法：Servlet 容器關閉時調用，用來關閉 Servlet 占用的一些資源。

　　2.Servlet3.0 有哪些新特性

　　參考答案： Servlet 3.0 作為 Java EE 6 規范體系中一員，隨著 Java EE 6 規范一起發布。該版本在前一版本 (Servlet 2.5) 的基礎上提供了若干新特性用于簡化 Web應用的開發和部署。其中有幾項特性的引入讓開發者感到非常奮：

　　1、異步處理支持：有了該特性，Servlet 線程不再需要一直阻塞，直到業務處

　　理完畢才能再輸出響應，最后才結束該 Servlet 線程。在接收到請求之后， Servlet線程可以將耗時的操作委派給另一個線程來完成，自己在不生成響應的情況下返回至容器。針對業務處理較耗時的情況，這將大大減少服務器資源的占用，并且提高并發處理速度。

　　2、新增的注解支持：該版本新增了若干注解，用于簡化 Servlet、過濾器 (Filter)和偷聽(Listener)的聲明，這使得 web.xml 部署描述文件從該版本開始不再是必選的了。

　　3、可插性支持：熟悉 Struts2 的開發者一定會對其通過插件的方式與包括

　　Spring 在內的各種常用框架的整合特性記憶猶新。將相應的插件封裝成 JAR 包

　　并放在類路徑下，Struts2 運行時便能自動加載這些插件。現在 Servlet 3.0 提供了類似的特性，開發者可以通過插件的方式很方便的擴充已有 Web 應用的功能，而不需要修改原有的應用。

　　4、原本文件上傳時通過 common-fileupload 或者 SmartUpload，上傳比較麻煩，在 Servlet 3.0 中不需要導入任何第三方 jar 包，并且提供了很方便進行文件上傳的功能;

　　5、ServletContext 的性能增強除了以上的新特性之外，ServletContext 對象的

　　功能在新版本中也得到了增強。現在，該對象支持在運行時動態部署 Servlet、

　　過濾器、偷聽，以及為 Servlet 和過濾器增加 URL 映射等。以 Servlet 為例，過濾器與偷聽與之類似。

　　3.forward 與與 redirect 區別

　　參考答案：

　　Forward ：轉發，是服務器內部的一種轉向行為，客戶端并不能察覺，URL 顯示的依然是轉發前的地址;它屬于一次 Request 請求，轉發目標頁依然可以使用

　　Request 范圍內的數據。使用場景：多用戶多角色的系統根據登錄用戶進行模塊的跳轉。

　　Redirect ：重定向，服務器會首先響應請求端一個狀態碼，請求端根據狀態碼再次發生的請求， URL 的地址會換成后一次請求的地址; 它屬于兩次 Request 請求，所以第一次 Request 請求范圍內的數據將丟失，不能再從 Request 中獲取數據。使用場景：Session 過期(或未登錄時)跳轉到登錄頁，系統異常跳轉到異常頁。

　　4.Session 與與 Cookie

　　參考答案：

　　Session:運行在服務器端，默認是保存在內存中，安全性高，可以存放對象，

　　可以設置生命周期，當服務器端維護 Session 對象過多的時候，會影響到服務器的性能，可以將一部分 Session 序列化到硬盤上存儲。當用戶第一次請求生成Session 對象時會生成 sessionID 用來標識此對象，SessionID 將會返回給用戶保存在 Cookie 中。

　　Cookie:是保存在客戶端，一般不超過 4k，用戶客戶端對 cookie 數據量也有限制，好像 20 個左右，Cookie 安全性低，可以被改寫，而且容易被瀏覽器禁用，但如果 Cookie 完全被禁用，Session 的會話功能也將失效。

　　5.如何實現一個自己的 session

　　參考答案：要寫一個自己的 session，首先要知道 session 的幾個特點：第一，

　　能夠進行對象的保存;第二，有一個唯一的識別碼 sessionID 可以通過 cookie 中的 sessionID 來找到 session 對象;第三，就是可以設置 session 的有效期;解決這三點就可以來實現我們自己的 session 了;上面三個條件中最容易實現的就是sessinID，在 Java 中生成一個不重復的 ID 太容易了，這里用 UUID 生成一個 32位序列作為唯一識別碼 token(token 就是上面的 sessionID，自己寫時就不要用原來的名稱了) 。下面推薦三種方案，面試時根據自己的理解選擇。

　　第一種Map 方案：

　　1、定義一個全局的靜態的Map 對象(最好用線程安全的實現類) ;

　　2、用戶首次訪問時生成一個 token 作為 Map 中的 key 值，Map 中的 value可以根據需要定義成對象，此對象里面一定要有一個時間字段，來記錄用戶最近一次的訪問時間;

　　3、定義一個后臺線程，用來監控 Map 中對象的日期與系統日期時間的差值，當大于設定的時間時，就把對象從 Map 中刪除(模擬 session 過期清理)。

　　第二種 SQL 方案：

　　1、建一張 t_session 表，里面的主鍵為 token，至少有一個日期字段，其余的字段根據保存的對象需要建立;

　　2、用戶首次訪問時生成一個 token 作為主鍵，同時插入一個當前日期;后續只要用戶對 Session 要操作的地方，就要更新 t_session 中的日期字段;

　　3、定義一個數據 JOB，用來監控 t_session 中對象的日期與系統日期時間的差值，當大于設定的時間時，就把對象從t_session中刪除(模擬session過期清理)。

　　第三種緩存方案：

　　1、引入一個緩存 Encache 對象;

　　2、用戶首次訪問時生成一個 token 作為 Encache 中的 key 值，Value 值可以根據需要定義對象，最好是實現了序列化。

　　3、在緩存配置中聲明一個過期日期。

　　綜上：第一種方案有一個問題，就是當 Map 存和的對象足夠多的時候，后臺線程在掃描的時候會不會造成前臺用戶操作 Map 對象的阻塞，從原理上是有這存情況發生，總之隨著 Map 存放的東西越多，性能下降的越厲害。第二種方案不

　　多說了，每次操作都可能引起后臺數據表的操作，而且在線用戶多的時候，只是這塊就會占用很多的連接數，有點浪費系統資源。第三種方案是我比較推崇的方試，不用再擔心過期時間的管理，緩存本身就有過期時間管理的機制，有人擔心Encache 是與應用綁定發布的，不容易做分布式，其實多慮了，Encache 本身支持分布式的，即使有問題，我們還有 memcached 等其它緩存呢。總之根據業務場景需要來選擇就行了。

　　6.Http 請求中 Get 和和 Post 區別

　　參考答案：get,post 是前臺與后臺交互時兩種請求方式。

　　Get ：從 URL 上看它是以明文的方式展現(一般要對參數需要加密處理)在地

　　址欄中，而且它對提交的內容長度有限制，不能超過 1024Btye;Get 一般用于向服務器中請求數據(查詢時) 。

　　Post:是一種自動加密的請求方式，而且理論請求的內容沒有長度限制，一般用于表單提交，向服務器進行數據添加或者更新的時候使用。

　　7.JSP 中動態 INCLUDE 與靜態 INCLUDE 的區別

　　參考答案：

　　1、寫法不同，動態包含，而靜態包

　　含;動態包含中一般是同樣的jsp 頁，而靜態包含可以是其它.txt,.html 等文件。

　　2、動態包含是兩個獨立的文件，分別編譯，但它總會動態檢查被引入頁中的

　　內容變化，在執行到 jsp:include 時動態引入被包含的文件，而且可以向被引入的頁面中傳遞參數。靜態包含相當于在編譯前將被包含的文件插入到

　　J2EE框架面試題庫2