1.什麼是事務控制？
答：事務控制就是將一系列操作當成一個不可拆分的邏輯單元，保證這些操作要麼都成功，要麼都失敗。在關係數據庫中，一個事務可以是一條SQL語句，一組SQL語句或整個程序。
事務是恢復和併發控制的基本單位。
事務應該具有4個屬性：原子性、一致性、隔離性、持續性。這四個屬性通常稱爲ACID特性。
原子性（atomicity）。一個事務是一個不可分割的工作單位，事務中包括的諸操作要麼都做，要麼都不做。
一致性（consistency）。事務必須是使數據庫從一個一致性狀態變到另一個一致性狀態。一致性與原子性是密切相關的。
隔離性（isolation）。一個事務的執行不能被其他事務干擾。即一個事務內部的操作及使用的數據對併發的其他事務是隔離的，併發執行的各個事務之間不能互相干擾。
持久性（durability）。持續性也稱永久性（permanence），指一個事務一旦提交，它對數據庫中數據的改變就應該是永久性的。接下來的其他操作或故障不應該對其有任何影響。
事務有兩種操作：提交，回滾
2.過濾器的作用？
過濾器是一個對象，可以傳輸請求或修改響應。它可以在請求到達Servlet/JSP之前對其進行預處理，而且能夠在響應離開Servlet/JSP之後對其進行後處理。所以如果你有幾個Servlet/JSP需要執行同樣的數據轉換或頁面處理的話，你就可以寫一個過濾器類，然後在部署描述文件（web.xml）中把該過濾器與對應的Servlet/JSP聯繫起來。你可以一個過濾器以作用於一個或一組servlet，零個或多個過濾器能過濾一個或多個servlet。一個過濾器實現java.servlet.Filter接口並定義它的三個方法：1． void init(FilterConfig config) throws ServletException:在過濾器執行service前被調用，以設置過濾器的配置對象。2． void destroy();在過濾器執行service後被調用。3． Void doFilter(ServletRequest req,ServletResponse res,FilterChain chain) throws IOException,ServletException;
3.爲什麼要引入連接池？
首先在Web開發中，如果使用 JDBC連接數據庫，那麼每次訪問請求都必須建立連接——打開數據庫——存取數據庫——關閉連接等一系列步驟。但是我們知道數據庫的連接打開不僅費時，而且消耗比較多的系統資源。如果進行數據庫操作的次數比較少，那麼還不至於有多大的影響，但是假如頻繁的進行數據庫操作，那麼系統的性能將會受到很大影響。
其次，是造成數據庫連接泄漏。數據庫連接泄漏這個詞是第一次聽說，指的是如果在某次使用或者某段程序中沒有正確地關閉Connection、 Statement和ResultSet資源，那麼每次執行都會留下一些沒有關閉的連接，這些連接失去了引用而不能得到重新使用，因此就造成了數據庫連接的泄漏。數據庫連接的資源是寶貴而且是有限的，如果在某段使用頻率很高的代碼中出現這種泄漏，那麼數據庫連接資源將被耗盡，影響系統的正常運轉。
爲了解決上述問題，因此就引入了數據庫連接池技術。用一句話概括數據庫連接池技術那就是負責分配、管理和釋放數據庫連接。
4.JSP中動態INCLUDE與靜態INCLUDE的區別？
動態INCLUDE用jsp:include動作實現它總是會檢查所含文件中的變化，適合用於包含動態頁面，並且可以帶參數。
靜態INCLUDE用include僞碼實現,定不會檢查所含文件的變化，適用於包含靜態頁面
<%@include file=”"%> 編譯期導入合併成1個Servlet 效率較高 (用include僞碼實現，適用於包含靜態頁面)
<jsp:include file=”"> 動態連接效率低於<%@include file=”"%> (但它總是會檢查所含文件中的變化，適合用於包含動態頁面，並且可以帶參數)
主要就是1個編譯期就合成1個Servlet了一個是2個Servlet 動態連接
（JSP 最終就是被容器編譯成個 Servlet ）
5. jsp中，session對象存在哪個地方，如何進行存取，存在服務器哪個地方，如何存的？
1、session在何時被創建
一個常見的誤解是以爲session在有客戶端訪問時就被創建，然而事實是直到某server端程序調用 HttpServletRequest.getSession(true)這樣的語句時才被創建，注意如果JSP沒有顯示的使用 <% @page session=”false”%> 關閉session，則JSP文件在編譯成Servlet時將會自動加上這樣一條語句 HttpSession session = HttpServletRequest.getSession(true);這也是JSP中隱含的 session對象的來歷。
由於session會消耗內存資源，因此，如果不打算使用session，應該在所有的JSP中關閉它。
2、session何時被刪除
綜合前面的討論，session在下列情況下被刪除a.程序調用HttpSession.invalidate();或b.距離上一次收到客戶端發送的session id時間間隔超過了session的超時設置;或c.服務器進程被停止（非持久session）
3、如何做到在瀏覽器關閉時刪除session
嚴格的講，做不到這一點。可以做一點努力的辦法是在所有的客戶端頁面裏使用javascript代碼window.oncolose來監視瀏覽器的關閉動作，然後向服務器發送一個請求來刪除session。但是對於瀏覽器崩潰或者強行殺死進程這些非常規手段仍然無能爲力。
4、有個HttpSessionListener是怎麼回事
你可以創建這樣的listener去監控session的創建和銷燬事件，使得在發生這樣的事件時你可以做一些相應的工作。注意是session的創建和銷毀動作觸發listener，而不是相反。類似的與HttpSession有關的listener還有 HttpSessionBindingListener，HttpSessionActivationListener和 HttpSessionAttributeListener。
5、存放在session中的對象必須是可序列化的嗎
不是必需的。要求對象可序列化只是爲了session能夠在集羣中被複制或者能夠持久保存或者在必要時server能夠暫時把session交換出內存。在 Weblogic Server的session中放置一個不可序列化的對象在控制檯上會收到一個警告。我所用過的某個iPlanet版本如果 session中有不可序列化的對象，在session銷燬時會有一個Exception，很奇怪。
6、如何才能正確的應付客戶端禁止cookie的可能性
對所有的URL使用URL重寫，包括超鏈接，form的action，和重定向的URL，具體做法參見
http://e-docs.bea.com/wls/docs70/webapp/sessions.html#100770
7、開兩個瀏覽器窗口訪問應用程序會使用同一個session還是不同的session
參見第三小節對cookie的討論，對session來說是隻認id不認人，因此不同的瀏覽器，不同的窗口打開方式以及不同的cookie存儲方式都會對這個問題的答案有影響。
8、如何防止用戶打開兩個瀏覽器窗口操作導致的session混亂
這個問題與防止表單多次提交是類似的，可以通過設置客戶端的令牌來解決。就是在服務器每次生成一個不同的id返回給客戶端，同時保存在session裏，客戶端提交表單時必須把這個id也返回服務器，程序首先比較返回的id與保存在session裏的值是否一致，如果不一致則說明本次操作已經被提交過了。可以參看《J2EE核心模式》關於表示層模式的部分。需要注意的是對於使用javascript window.open打開的窗口，一般不設置這個id，或者使用單獨的id，以防主窗口無法操作，建議不要再window.open打開的窗口裏做修改操作，這樣就可以不用設置。
9、爲什麼在Weblogic Server中改變session的值後要重新調用一次session.setValue
做這個動作主要是爲了在集羣環境中提示Weblogic Server session中的值發生了改變，需要向其他服務器進程複製新的session值。
10、爲什麼session不見了
排除session正常失效的因素之外，服務器本身的可能性應該是微乎其微的，雖然筆者在iPlanet6SP1加若干補丁的Solaris版本上倒也遇到過；瀏覽器插件的可能性次之，筆者也遇到過3721插件造成的問題；理論上防火牆或者代理服務器在cookie處理上也有可能會出現問題。
出現這一問題的大部分原因都是程序的錯誤，最常見的就是在一個應用程序中去訪問另外一個應用程序。我們在下一節討論這個問題。
6.<%…%>和<%!…%>的區別？
<%…%>用於在JSP頁面中嵌入Java腳本
<%!…%>用於在JSP頁面中申明變量或方法，可以在該頁面中的<%…%>腳本中調用，聲明的變量相當於Servlet中的定義的成員變量
7.什麼是WEBSERVICE?及它的常用開發框架？
Web Service就是爲了使原來各孤立的站點之間的信息能夠相互通信、共享而提出的一種接口。
Web Service所使用的是Internet上統一、開放的標準，如HTTP、XML、SOAP（簡單對象訪問協議）、WSDL等，所以Web Service可以在任何支持這些標準的環境（Windows,Linux）中使用。
優勢：(1).跨平臺。
(2).SOAP協議是基於XML和HTTP這些業界的標準的，得到了所有的重要公司的支持。
(3).由於使用了SOAP，數據是以ASCII文本的方式而非二進制傳輸，調試很方便；並且由於這樣，它的數據容易通過防火牆，不需要防火牆爲了程序而單獨開一個“漏洞”。
(4).此外，WebService實現的技術難度要比CORBA和DCOM小得多。
(5).要實現B2B集成，EDI比較完善與比較複雜；而用WebService則可以低成本的實現，小公司也可以用上
(6).在C/S的程序中，WebService可以實現網頁無整體刷新的與服務器打交道並取數。
缺點：
(1).WebService使用了XML對數據封裝，會造成大量的數據要在網絡中傳輸。
(2).WebService規範沒有規定任何與實現相關的細節，包括對象模型、編程語言，這一點，它不如CORBA
webservice的幾種常用框架及開發過程：
Net環境 IDE爲Microsoft Visual Studio2005
Java環境 CXF CXF的前身是Xfire，具體內容可參照http://xfire.codehaus.org/ 。
IDE爲Eclipse 3.2 （JDK 1.5以上）
NetBeans 由於Sun已經在J2EE5.0中提供了對Jax-ws規範的實現，並且提供了NetBeans IDE對J2EE5.0的支持，使得開發web service非常簡單。前提條件是我們需要到http://www.netbeans.org/ 下載NetBeans 6.0。官方的下載文件中已經集成了Tomcat6.0和J2EE5.0。
Axis 比較
? 開發過程比較
1、NetBeans IDE基本可以與.Net的開發工具VS 2005相媲美，後者有內嵌的測試服務器，前者也可以使用內嵌的glassfish。
2、CXF相對而言也比較簡單(依賴於與Spring的集成)，Axis要更復雜些，且難以掌握
? 性能比較
1、 CXF對於大數據量的處理，性能要優於NetBeans IDE開發的webservice；小數據量的處理兩者差不
2、對於.Net開發的webservice的性能很難與Java環境下開發的webservice進行性能比較，由於應用服務器不相同（前者依賴於IIS的支持）。
? 結論
考慮到服務的性能和現有應用的整合，使用CXF進行web service開發是比較適中的選擇。從簡單易用方面考慮，可以使用NetBeans進行上手入門。從與之前作的webservice的兼容方面考慮，可以採用Axis，只有它還支持RPC的調用方式。
8.請具體說J2EE是怎樣分層的？
1.客戶端層(Client Tier) 客戶端層用來實現企業級應用系統的操作界面和顯示，另外，某些客戶端程序也可實現業務邏輯
可分爲基於Web的和非基於Web的客戶端兩種情況
基於Web的情況下主要作爲企業Web服務器的瀏覽器
非基於Web的客戶層則是獨立的應用程序，可以完成瘦客戶機無法完成的任務
2.Web層 Web層由Web組件組成 ,J2EE Web組件包括JSP頁面和Servlets
Web層也可以包括一些JavaBeans Web層主要用來處理客戶請求,調用相應的邏輯塊,並把結果以動態網頁的形式返回到客戶端。
3.業務層(Business Tier) 業務層也叫EJB層或應用層，它由EJB服務器和EJB組件組成
一般情況下許多開發商把Web服務器和EJB服務器產品結合在一起發佈，稱爲應用服務器 .EJB層用來實現企業級信息系統的業務邏輯。這是企業級應用的核心，由運行在業務層中的EJB來處理。一個Bean從客戶端接收數據、處理，然後把數據送到企業信息系統層存儲起來。同樣，一個Bean也可以從企業信息系統取出數據，發送到客戶端程序。業務層中的EJB要運行在容器中，容器解決了底層的問題，如事務處理、生命週期、狀態管理、多線程安全管理、資源池等
4.企業信息系統層（Enterprise Information System tier)處理企業系統軟件，包括企業基礎系統、數據庫系統及其他遺留的系統。J2EE支持連接架構（Connector Architecture)。提供連接J2EE平臺和企業信息系統層的標準API。
9.EJB容器提供的服務？
容器提供的服務有很多,包括：1.組件池和壽命週期管理 2.客戶端會話管理 3.數據庫連接池
4.事務管理 5.驗證與訪問控制 6.持久性
10. EJB的角色和三個對象？
六個角色分別是EJB組件開發者（Enterprise Bean Provider）、應用組合者（Application Assembler）、部署者（Deployer）、EJB 服務器提供者（EJB Server Provider）、EJB 容器提供者（EJB Container Provider）、系統管理員（System Administrator）。三個對象是Remote（Local）接口、Home（LocalHome）接口，Bean類
11.你對spring+struts的耦合方式和原理？
使用了Spring的IoC來實組件之間的依賴關係注入, 使控制層與業務實現分離，即客戶通過
調用業務委託接口來調用具體的業務組件的實例，避免控制層與業務層的藕合帶來的維護
或升級困難。由Spring爲DAO生成代理對象來爲DAO添加事務服務，由IoC容器DAO的代理實例注入到業務組件中,業務組件通過DAO的委託接口調用DAO對象，使得上層組件不直接依賴於DAO的實現類，使得持久層更換或修改不影響上層組件。
12.對於apache common通信包瞭解多少？
Commons BeanUtils
說明：針對Bean的一個工具集。由於Bean往往是有一堆get和set組成，所以BeanUtils也是在此基礎上進行一些包裝。
Commons Codec
說明：這個工具是用來編碼和解碼的，包括Base64，URL，Soundx等等。
Commons CLI
說明：這是一個處理命令的工具.比如main方法輸入的string[]需要解析。你可以預先定義好參數的規則，然後就可以調用CLI來解析。
Commons Collections
說明：你可以把這個工具看成是java.util的擴展。
Commons Configuration
說明：這個工具是用來幫助處理配置文件的，支持很多種存儲方式
1. Properties files 2. XML documents 3. Property list files (.plist)
4. JNDI 5. JDBC Datasource 6. System properties 7. Applet parameters
8. Servlet parameters
Commons DBCP
說明：Database Connection pool, Tomcat就是用的這個
Commons DbUtils
說明：我以前在寫數據庫程序的時候，往往把數據庫操作單獨做一個包
Commons FileUpload
說明：jsp的上傳文件功
Commons HttpClient
說明：這個工具可以方便通過編程的方式去訪問網站。
Apache Common BeanUtil
是一個常用的在對象之間複製數據的工具類，著名的web開發框架struts就是依賴於它進行ActionForm的創建。
13.Spring框架解析？
Spring既是全面的又是模塊化的。Spring有分層的體系結構，這意味着你能選擇僅僅使用
它任何一個獨立的部分，而它的架構又是內部一致。因此你能從你的學習中，得到最大的
價值。例如，你可能選擇僅僅使用Spring來簡單化JDBC的使用，或用來管理所有的業務對
象。
它的設計從一開始就是要幫助你編寫易於測試的代碼。Spring是使用測試驅動開發的工程
的理想框架。
Spring不會給你的工程添加對其他的框架依賴。Spring也許稱得上是個一站式解決方案，
提供了一個典型應用所需要的大部分基礎架構。它還涉及到了其他framework沒有考慮到的
內容。
Spring的核心即是個IoC/DI的容器，它可以幫程序設計人員完成組件之間的依賴關係注
入，使得組件之間的依賴達到最小，進而提高組件的重用性，Spring是個低侵入性（invas
ive）的框架，Spring中的組件並不會意識到它正置身於Spring中，這使得組件可以輕易的
從框架中脫離，而幾乎不用任何的修改，反過來說，組件也可以簡單的方式加入至框架
中，使得組件甚至框架的整合變得容易。
Spring最爲人重視的另一方面是支持AOP（Aspect-Oriented Programming），然而AOP框架
只是Spring支持的一個子框架，說Spring框架是AOP框架並不是一件適當的描述，人們對於
新奇的 AOP關注映射至Spring上，使得人們對於Spring的關注集中在它的AOP框架上，雖然
有所誤解，但也突顯了Spring的另一個令人關注的特色。
Spring也提供MVC Web框架的解決方案，但您也可以將自己所熟悉的MVC Web框架與Spring
解合，像是Struts、Webwork等等，都可以與Spring整合而成爲進用於自己的解決方案。Sp
ring也提供其它方面的整合，像是持久層的整合如JDBC、O/R Mapping工具（Hibernate、i
BATIS）、事務處理等等，Spring作了對多方面整合的努力，故說Spring是個全方位的應用
程序框架
14.Spring IoC底層運行原理？
Spring IoC 反向控制原理：
IoC，直觀地講，就是容器控制程序之間的關係，而非傳統實現中，由程序代碼直接操控。這也就是所謂“控制反轉”的概念所在。控制權由應用代碼中轉到了外部容器，控制權的轉移是所謂反轉。IoC還有另外一個名字——“依賴注入（Dependency Injection）”。從名字上理解，所謂依賴注入，即組件之間的依賴關係由容器在運行期決定，形象地說，即由容器動態地將某種依賴關係注入到組件之中。
反向控制是Spring框架的核心。通常，應用代碼需要告知容器或框架,讓它們找到自身所需要的類,然後再由應用代碼創建待使用的對象實例。因此，應用代碼在使用實例之前，需要創建對象實例。然而，IoC模式中,創建對象實例的任務交給IoC容器或框架(實現了IoC設計模式的框架也被稱爲 IoC容器)，使得應用代碼只需要直接使用實例[5]，這就是IoC。相對IoC 而言，“依賴注入”的確更加準確的描述了這種設計理念。所謂依賴注入，即組件之間的依賴關係由容器在運行期決定，形象的來說，即由容器動態的將某種依賴關系注入到組件之中。
任何重要的系統都需要至少兩個相互合作的類來完成業務邏輯。通常，每個對象都要自己負責得到它的合作（依賴）對象。你會發現，這樣會導致代碼耦合度高而且難於測試。使用IoC，對象的依賴都是在對象創建時由負責協調系統中各個對象的外部實體提供的，這樣使軟件組件鬆散連接成爲可能。
15. Ajax是如何工作的？
Ajax 基本上就是把 JavaScript 技術和 XMLHttpRequest 對象放在 Web 表單和服務器之間。當用戶填寫表單時，數據發送給一些 JavaScript 代碼而不是直接發送給服務器。相反，JavaScript 代碼捕獲表單數據並向服務器發送請求。同時用戶屏幕上的表單也不會閃爍、消失或延遲。換句話說，JavaScript 代碼在幕後發送請求，用戶甚至不知道請求的發出。更好的是，請求是異步發送的，就是說 JavaScript 代碼（和用戶）不用等待服務器的響應。因此用戶可以繼續輸入數據、滾動屏幕和使用應用程序。
然後，服務器將數據返回 JavaScript 代碼（仍然在 Web 表單中），後者決定如何處理這些數據。它可以迅速更新表單數據，讓人感覺應用程序是立即完成的，表單沒有提交或刷新而用戶得到了新數據。 JavaScript 代碼甚至可以對收到的數據執行某種計算，再發送另一個請求，完全不需要用戶干預！這就是 XMLHttpRequest 的強大之處。它可以根據需要自行與服務器進行交互，用戶甚至可以完全不知道幕後發生的一切。結果就是類似於桌面應用程序的動態、快速響應、高交互性的體驗，但是背後又擁有互聯網的全部強大力量。
16.列出曾經使用過的開源框架、工具以及類庫等？對哪些Web框架比較熟悉？分析下這些Web框架的優缺點？
開源框架:struts、hiberante、spring、dwr
工具:eclipse3.4、MyEclipse5.5、JBuild、NetBeans、JBossIDE2.0、Dreamweave
類庫: Java提供的部分常用包
java.lang.*—— Java編程語言的基本類庫
java.util.*——– 包括集合類、時間處理模式、日期時間工具等各類常用工具包
java.io———–提供了通過數據流、對象序列以及文件系統實現的系統輸入、輸出
java.sql———提供了訪問和處理來自於Java標準數據源數據的類
java.applet—–提供了創建applet需要的所有類
java.awt.*——- 提供了創建用戶界面以及繪製和管理圖形、圖像的類
javax.swing.*—- 提供了一系列輕量級的用戶界面組件，是目前Java用戶界面常用的包
java.math.*—— 提供了簡明的整數算術以及十進制算術的基本函數
java.rmi———-提供了與遠程方法調用相關的所有類
javax.naming.*— 爲命名服務提供了一系列類和接口
java.net———-提供了用於實現網絡通訊應用的所有類
java.test———包括以一種獨立於自然語言的方式處理文本、日期、數字和消息的類和接口
比較熟悉Web框架:struts1.2、struts2.0、spring mvc、WebWork
struts優缺點:
1. 實現MVC模式，結構清晰,使開發者只關注業務邏輯的實現.
2. 有豐富的tag可以用 ,Struts的標記庫(Taglib)，如能靈活動用，則能大大提高開發效率。另外，就目前國內的JSP開發者而言，除了使用JSP自帶的常用標記外，很少開發自己的標記，或許Struts是一個很好的起點。
3. 頁面導航.頁面導航將是今後的一個發展方向，事實上，這樣做，使系統的脈絡更加清晰。通過一個配置文件，即可把握整個系統各部分之間的聯繫，這對於後期的維護有着莫大的好處。尤其是當另一批開發者接手這個項目時，這種優勢體現得更加明顯。
4. 提供Exception處理機制 .
5. 數據庫鏈接池管理
6. 支持I18N
缺點:
1、轉到展示層時，需要配置forward，每一次轉到展示層，相信大多數都是直接轉到jsp，而涉及到轉向，需要配置forward，如果有十個展示層的 jsp，需要配置十次struts，而且還不包括有時候目錄、文件變更，需要重新修改forward，注意，每次修改配置之後，要求重新部署整個項目，而 tomcate這樣的服務器，還必須重新啓動服務器，如果業務變更復雜頻繁的系統，這樣的操作簡單不可想象。現在就是這樣，幾十上百個人同時在線使用我們的系統，大家可以想象一下，我的煩惱有多大。
2、 Struts 的Action必需是thread－safe方式，它僅僅允許一個實例去處理所有的請求。所以action用到的所有的資源都必需統一同步，這個就引起了線程安全的問題。
3、測試不方便. Struts的每個Action都同Web層耦合在一起，這樣它的測試依賴於Web容器，單元測試也很難實現。不過有一個Junit的擴展工具Struts TestCase可以實現它的單元測試。
4、類型的轉換. Struts的FormBean把所有的數據都作爲String類型，它可以使用工具Commons-Beanutils進行類型轉化。但它的轉化都是在Class級別，而且轉化的類型是不可配置的。類型轉化時的錯誤信息返回給用戶也是非常困難的。
5、對Servlet的依賴性過強. Struts處理Action時必需要依賴ServletRequest 和ServletResponse，所有它擺脫不了Servlet容器。
6、前端表達式語言方面.Struts集成了JSTL，所以它主要使用JSTL的表達式語言來獲取數據。可是JSTL的表達式語言在Collection和索引屬性方面處理顯得很弱。
7、對Action執行的控制困難. Struts創建一個Action，如果想控制它的執行順序將會非常困難。甚至你要重新去寫Servlet來實現你的這個功能需求。
8、對Action 執行前和後的處理. Struts處理Action的時候是基於class的hierarchies，很難在action處理前和後進行操作。
9、對事件支持不夠. 在struts中，實際是一個表單Form對應一個Action類(或DispatchAction)，換一句話說：在Struts中實際是一個表單只能對應一個事件，struts這種事件方式稱爲application event，application event和component event相比是一種粗粒度的事件。
Struts重要的表單對象ActionForm是一種對象，它代表了一種應用，這個對象中至少包含幾個字段，這些字段是Jsp頁面表單中的input字段，因爲一個表單對應一個事件，所以，當我們需要將事件粒度細化到表單中這些字段時，也就是說，一個字段對應一個事件時，單純使用Struts就不太可能，當然通過結合JavaScript也是可以轉彎實現的。
spring mvc優缺點: 他是一個典型的可以說是教科書式的mvc構架，而不像structs等都是變種或者不是完全基於mvc系統的框架，對於初學者或者想了解mvc的我覺得 spring是最好的，他的實現就是教科書！第二他和tapestry一樣是一個純正的servlet系統，這也是他和tapestry相比 structs所沒有的優勢。而且框架本身有代碼，而且看起來也不費勁比較簡單可以理解。
缺點：使用人數少、jsp中要寫很多代碼、控制器過於靈活，缺少一個公用控制器
WebWork 優缺點: 優點：結構簡單易於擴展、標籤庫易於定製、攔截器非常出色
缺點：文檔示例很少、客戶端驗證技術不成熟
17.介紹幾種常用的設計模式：
1.業務委託模式：表示層組件將與業務層服務交互。這樣，業務層改變會使表示層也需要改變。業務委託模式可以解決這個問題。
業務委託模式的目的就是減少表示層和業務層的耦合，隱藏業務服務的各種複雜實現細節，如查找與訪問細節。
2.會話門面模式：在服務器方編寫服務層組件時，我們要處理複雜的企業Bean，封裝業務邏輯和數據。由於提供的接口很複雜，因此會使服務層也更復雜。會話門面設計模式可以減少這種複雜性。
會話門面模式在需要隱藏業務層對象交互的細節時很有用。其主要意圖是處理幾種工作流。也就是管理業務對象，提供客戶的統一、粗粒度對象服務訪問。在對象術語中，粗粒度對象具有自己的壽命週期，同時管理自己與其他對象的關係。此外，粗粒度對象的方法通常是高層的（例如addPerson（）而不是 setLastName（）、setFirstName（）之類的）。
3.數值對象設計模式：在用ejb框架建立的企業應用程序中，不同的分佈式組件之間需要交換數據。此外，前面曾介紹過，EJB框架將企業應用程序業務組件實現爲會話Bean或實體Bean。而數值對象設計模式可以簡化企業 Bean之間的數據交換。用數值對象設計模式封裝業務數據。客戶向EJB請求業務數據是，EJB構造數值對象，在對象中填入數據，按數值傳遞給客戶。如果客戶需要返回數據，則也差不多：構造數值對象，在對象中填入數據併發送給EJB。
4.累積實體設計模式：衆所周知，實體Bean主要用於持久存儲。設計企業應用程序時，實體Bean不需要表示每個持久對象，這更適合數據結構方法。累積實體設計模式可以設計這種粗粒機制。累積實體設計模式用於建模、表示和管理一組相關持久對象，而不是細粒實體Bean。它表示完整的對象圖。
5.工廠模式：工廠模式是一種經常被使用到的模式，根據工廠模式實現的類可以根據提供的數據生成一組類中某一個類的實例，通常這一組類有一個公共的抽象父類並且實現了相同的方法，但是這些方法針對不同的數據進行了不同的操作。首先需要定義一個基類，該類的子類通過不同的方法實現了基類中的方法。然後需要定義一個工廠類，工廠類可以根據條件生成不同的子類實例。當得到子類的實例後，開發人員可以調用基類中的方法而不必考慮到底返回的是哪一個子類的實例。
6.DAO 模式通過對底層數據的封裝，爲業務曾提供一個面向對象的接口，使得業務邏輯開發員可以面向業務中的實體進行編碼。通過引入DAO模式，業務邏輯更加清晰，且富於形象性和描述性，這將爲日後的維護帶來極大的便利。試想，在業務曾通過Customer.getName方法獲得客戶姓名，相對於直接通過SQL語句訪問數據庫表並從ResultSet中獲得某個字符型字段而言，哪種方式更加易於業務邏輯的形象化和簡潔化？
DAO模式,在項目開發中主要用在數據層，封裝數據的訪問操作，爲業務層提供數據服務。
7.MVC模式,在J2EE項目開發中主要用在表示層框架中,很好解決視圖和流程控制。在項目中採用的Struts、WebWork等框架。
8.IoC模式,在項目開發中業務層有大量對象，他們之間存在依賴關係，可以使用IoC模式減少他們之間的代碼耦合，提高系統的可擴展性。實際項目中使用的Spring框架來實現業務組件的裝配。
9.Observer模式，在Servlet的監聽器中應用到了觀察者模式。
10.singleton單例模式和Factory工廠模式結合使用在項目中無需使用者瞭解過多的細節就可獲取有關的對象實例。比如Hibernate項目中通過SessionFactory來獲取Session。
11.bridge模式，在項目中使用JDBC驅動訪問數據庫。
18.幾種常用的數據結構及內部實現原理？
鏈表：一個鏈表由很多節點組成，每個節點包含表示內容的數據域和指向下一個節點的鏈域兩部分。正是通過鏈域將節點連接形成一個表。圍繞鏈表的基本操作有添加節點、刪除節點和查找節點等。
堆棧：限定了只能從線性表的一端進行數據的存取，這一端稱爲棧頂，另一端爲棧底。入棧操作是先向棧頂方向移動一位，存入數據；出棧操作則是取出棧頂數據，然後向棧底移動一位。體現LIFO/FILO的思想。
隊列：限定了數據只能從線性表的一端存入，從另一端取出。存入一端成爲隊尾，取出一端稱爲隊首。體現LILO/FIFO的思想。
二叉樹：樹中的每個節點最多有兩個子節點。這兩個子節點分別稱爲左子節點和右子節點。在建立二叉搜索樹時，要求一個節點的左子節點的關鍵字值小於這個節點而右子節點的關鍵字值大於或等於這個節點。常見的遍歷操作有前序、中序和後序遍歷。