J2EE核心是一組技術規範與指南，其中所包含的各類組件、服務架構及技術層次，均有共同的標準及規格，讓各種依循J2EE架構的不同平臺之間，存在良好的兼容性，解決過去企業後端使用的信息產品彼此之間無法兼容，企業內部或外部難以互通的窘境。以下是小編整理的J2EE框架面試題庫，希望大家認真閱讀!
let 的生命週期
參考答案：Servlet 的生命週期主要爲四個步驟實例化時調用構造方法，初始化 init()、業務處理 service()、銷燬 destory()。
1，啓動tomcat時，調用Servlet的構造方法
2、init 階段：init()方法在 Servlet 實例化的時候調用，而且只調用一次(對於
Servlet 的初始化，一般是第一次被請求時;或者在在 中沒有配置
標籤的映射這個時候， 我們可以配置元素中指定了子元素時，容器在啓動的時候自動加載這些 Servlet 並調用 init()方法) ， init()方法的作用是完成一些全局性的比較花費時間的初始化工作。
3、service()階段：Servlet 繼承了父類的 service()方法，那麼前端 URL 發出的請求不管是以 get 方式或者 post 方式，都將直接走重寫的 service()方法，而不再走 doGet()和 goPost()方法。
4、終止階段調用 destroy()方法：Servlet 容器關閉時調用，用來關閉 Servlet 佔用的一些資源。
let3.0 有哪些新特性
參考答案： Servlet 3.0 作爲 Java EE 6 規範體系中一員， 隨着 Java EE 6 規範一起發佈。 該版本在前一版本 (Servlet 2.5) 的基礎上提供了若干新特性用於簡化 Web應用的開發和部署。其中有幾項特性的引入讓開發者感到非常奮：
1、異步處理支持：有了該特性，Servlet 線程不再需要一直阻塞，直到業務處
理完畢才能再輸出響應， 最後才結束該 Servlet 線程。 在接收到請求之後， Servlet線程可以將耗時的操作委派給另一個線程來完成， 自己在不生成響應的情況下返回至容器。針對業務處理較耗時的情況，這將大大減少服務器資源的佔用，並且提高併發處理速度。
2、 新增的註解支持： 該版本新增了若干註解， 用於簡化 Servlet、 過濾器 (Filter)和偷聽(Listener)的聲明，這使得 部署描述文件從該版本開始不再是必選的了。
3、可插性支持：熟悉 Struts2 的開發者一定會對其通過插件的方式與包括
Spring 在內的各種常用框架的整合特性記憶猶新。將相應的插件封裝成 JAR 包
並放在類路徑下，Struts2 運行時便能自動加載這些插件。現在 Servlet 3.0 提供了類似的特性，開發者可以通過插件的方式很方便的擴充已有 Web 應用的功能，而不需要修改原有的應用。
4、 原本文件上傳時通過 common-fileupload 或者 SmartUpload， 上傳比較麻煩，在 Servlet 3.0 中不需要導入任何第三方 jar 包，並且提供了很方便進行文件上傳的功能;
5、ServletContext 的性能增強除了以上的新特性之外，ServletContext 對象的
功能在新版本中也得到了增強。現在，該對象支持在運行時動態部署 Servlet、
過濾器、偷聽，以及爲 Servlet 和過濾器增加 URL 映射等。以 Servlet 爲例，過濾器與偷聽與之類似。
ard 與 與 redirect 區別
參考答案：
Forward ：轉發，是服務器內部的一種轉向行爲，客戶端並不能察覺，URL 顯示的依然是轉發前的地址;它屬於一次 Request 請求，轉發目標頁依然可以使用
Request 範圍內的數據。使用場景：多用戶多角色的系統根據登錄用戶進行模塊的跳轉。
Redirect ：重定向，服務器會首先響應請求端一個狀態碼，請求端根據狀態碼再次發生的請求， URL 的地址會換成後一次請求的地址; 它屬於兩次 Request 請求，所以第一次 Request 請求範圍內的數據將丟失，不能再從 Request 中獲取數據。使用場景：Session 過期(或未登錄時)跳轉到登錄頁，系統異常跳轉到異常頁。
ion 與 與 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 等其它緩存呢。總之根據業務場景需要來選擇就行了。
請求中 Get 和 和 Post 區別
參考答案：get,post 是前臺與後臺交互時兩種請求方式。
Get ：從 URL 上看它是以明文的方式展現(一般要對參數需要加密處理)在地
址欄中， 而且它對提交的內容長度有限制， 不能超過 1024Btye;Get 一般用於向服務器中請求數據(查詢時) 。
Post:是一種自動加密的請求方式， 而且理論請求的內容沒有長度限制， 一般用於表單提交，向服務器進行數據添加或者更新的時候使用。
中動態 INCLUDE 與靜態 INCLUDE 的區別
參考答案：
1、寫法不同，動態包含，而靜態包
含;動態包含中一般是同樣的 頁，而靜態包含可以是其它, 等文件。
2、動態包含是兩個獨立的文件，分別編譯，但它總會動態檢查被引入頁中的
內容變化，在執行到 jsp:include 時動態引入被包含的文件，而且可以向被引入的頁面中傳遞參數。靜態包含相當於在編譯前將被包含的文件插入到
