１：Servlet與CGI的區(qū)別

網(wǎng)址：http://blog.csdn.net/kobejayandy/article/details/11906125

概括來講，Servlet可以完成和CGI相同的功能。
　　CGI應(yīng)用開發(fā)比較困難，因為它要求程序員有處理參數(shù)傳遞的知識，這不是一種通用的技能。CGI不可移植，為某一特定平臺編寫的CGI應(yīng)用只能運行于這一環(huán)境中。每一個CGI應(yīng)用存在于一個由客戶端請求激活的進程中，并且在請求被服務(wù)后被卸載。這種模式將引起很高的內(nèi)存、CPU開銷，而且在同一進程中不能服務(wù)多個客戶。
　　Servlet提供了Java應(yīng)用程序的所有優(yōu)勢：可移植、穩(wěn)健、易開發(fā)。使用Servlet Tag技術(shù)，Servlet能夠生成嵌于靜態(tài)HTML頁面中的動態(tài)內(nèi)容。
　　Servlet對CGI的最主要優(yōu)勢在于一個Servlet被客戶端發(fā)送的第一個請求激活，然后它將繼續(xù)運行于后臺，等待以后的請求。每個請求將生成一個新的線程，而不是一個完整的進程。多個客戶能夠在同一個進程中同時得到服務(wù)。一般來說，Servlet進程只是在Web Server卸載時被卸載。

**Java **Servlet與CGI (Common Gateway Interface 公共網(wǎng)關(guān)接口)的比較:

與傳統(tǒng)的CGI和許多其他類似CGI的技術(shù)相比，Java Servlet具有更高的效率，更容易使用，功能更強大，具有更好的可移植性，更節(jié)省投資。在未來的技術(shù)發(fā)展過程中，Servlet有可能徹底取代CGI。

在傳統(tǒng)的CGI中，每個請求都要啟動一個新的進程，如果CGI程序本身的執(zhí)行時間較短，啟動進程所需要的開銷很可能反而超過實際執(zhí)行時間。而在Servlet中，每個請求由一個輕量級的Java線程處理(而不是重量級的操作系統(tǒng)進程)。

在傳統(tǒng)CGI中，如果有N個并發(fā)的對同一CGI程序的請求，則該CGI程序的代碼在內(nèi)存中重復(fù)裝載了N次；而對于Servlet，處理請求的是N個線程，只需要一份Servlet類代碼。在性能優(yōu)化方面，Servlet也比CGI有著更多的選擇。

*** 方便 **

Servlet提供了大量的實用工具例程，例如自動地解析和解碼HTML表單數(shù)據(jù)、讀取和設(shè)置HTTP頭、處理Cookie、跟蹤會話狀態(tài)等。

* 功能強大

在Servlet中，許多使用傳統(tǒng)CGI程序很難完成的任務(wù)都可以輕松地完成。例如，Servlet能夠直接和Web服務(wù)器交互，而普通的CGI程序不能。Servlet還能夠在各個程序之間共享數(shù)據(jù)，使得數(shù)據(jù)庫連接池之類的功能很容易實現(xiàn)。

* 可移植性好

    Servlet用Java編寫，Servlet [API](http://baike.baidu.com/view/16068.htm)具有完善的標準。因此，為IPlanet Enterprise Server寫的Servlet無需任何實質(zhì)上的改動即可移植到[Apache](http://baike.baidu.com/view/28283.htm)、[Microsoft ](http://baike.baidu.com/view/2422.htm)IIS或者WebStar。幾乎所有的主流服務(wù)器都直接或通過插件支持Servlet。

２：GET和POST區(qū)別 / doGet()和doPost()的區(qū)別

網(wǎng)址：http://www.cnblogs.com/cyy-13/p/5711235.html

1，生成方式
get方式有四種：1）直接在URL地址欄中輸入URL。2）網(wǎng)頁中的超鏈接。3）form中method為get。4）form中method為空時，默認是get提交。
post只知道有一種：form中method屬性為post。
2、數(shù)據(jù)傳送方式
get方式：表單數(shù)據(jù)存放在URL地址后面。所有g(shù)et方式提交時HTTP中沒有消息體。
post方式：表單數(shù)據(jù)存放在HTTP協(xié)議的消息體中以實體的方式傳送到服務(wù)器。
3、服務(wù)器獲取數(shù)據(jù)方式
GET方式：服務(wù)器采用request.QueryString來獲取變量的值。
POST方式：服務(wù)器采用request.Form來獲取數(shù)據(jù)。
4、傳送的數(shù)據(jù)量
GET方式：數(shù)據(jù)量長度有限制，一般不超過2kb。因為是參數(shù)傳遞，且在地址欄中，故數(shù)據(jù)量有限制。
POST方式：適合大規(guī)模的數(shù)據(jù)傳送。因為是以實體的方式傳送的。
5、安全性
GET方式：安全性差。因為是直接將數(shù)據(jù)顯示在地址欄中，瀏覽器有緩沖，可記錄用戶信息。所以安全性低。
POST方式：安全性高。因為post方式提交數(shù)據(jù)時是采用的HTTP post機制，是將表單中的字段與值放置在HTTP HEADER內(nèi)一起傳送到ACTION所指的URL中，用戶是看不見的。
6、在用戶刷新時
GET方式：不會有任何提示、
POST方式：會彈出提示框，問用戶是否重新提交

1. get是從服務(wù)器上獲取數(shù)據(jù)，post是向服務(wù)器傳送數(shù)據(jù)。
2. get是把參數(shù)數(shù)據(jù)隊列加到提交表單的ACTION屬性所指的URL中，值和表單內(nèi)各個字段一一對應(yīng)，在URL中可以看到。post是通過HTTP post機制，將表單內(nèi)各個字段與其內(nèi)容放置在HTML HEADER內(nèi)一起傳送到ACTION屬性所指的URL地址。用戶看不到這個過程。
3. 對于get方式，服務(wù)器端用Request.QueryString獲取變量的值，對于post方式，服務(wù)器端用Request.Form獲取提交的數(shù)據(jù)。
4. get傳送的數(shù)據(jù)量較小，不能大于2KB。post傳送的數(shù)據(jù)量較大，一般被默認為不受限制。但理論上，IIS4中最大量為80KB，IIS5中為100KB。
5. get安全性非常低，post安全性較高。但是執(zhí)行效率卻比Post方法好。 建議： 1、get方式的安全性較Post方式要差些，包含機密信息的話，建議用Post數(shù)據(jù)提交方式；
   2、在做數(shù)據(jù)查詢時，建議用Get方式；而在做數(shù)據(jù)添加、修改或刪除時，建議用Post方式；
6. Servlet的doGet/doPost 是在 javax.servlet.http.HttpServlet 中實現(xiàn)的
   doGet：處理GET請求
   doPost：處理POST請求
   當發(fā)出客戶端請求的時候，調(diào)用service 方法并傳遞一個請求和響應(yīng)對象。Servlet首先判斷該請求是GET 操作還是POST 操作。然后它調(diào)用下面的一個方法：doGet 或 doPost。如果請求是GET就調(diào)用doGet方法，如果請求是POST就調(diào)用doPost方法。doGet和doPost都接受請求(HttpServletRequest)和響應(yīng)(HttpServletResponse)。
   get只有一個流，參數(shù)附加在url后，地址行顯示要傳送的信息，大小個數(shù)有嚴格限制且只能是字符串，大小限制在1024KB。post的參數(shù)是通過另外的流傳遞的， 不通過url，所以可以很大，也可以傳遞二進制數(shù)據(jù)，如文件的上傳。
   get通過URL提交的參數(shù)會顯示在地址欄中，這在系統(tǒng)的安全方面可能帶來問題；post提交的參數(shù)不會顯示在地址欄中。這樣post就可以提高get的安全性能，避免數(shù)據(jù)的泄露。
   當form框里面的method為get時，執(zhí)行doGet方法，使用get提交就必須在服務(wù)器端用doGet()方法接收；當form框里面的method為post時，執(zhí)行doPost方法，使用post提交就必須在服務(wù)器端用doPost()方法接收。
   在request請求里面，編碼轉(zhuǎn)換；get方法得到的內(nèi)容每一個都要進行編碼轉(zhuǎn)換，而post方法則只要設(shè)置request.setCharacterEncoding("UTF-8")就可以，不要再從request得到的每個數(shù)據(jù)進行編碼轉(zhuǎn)換了。
7. 1、安全
   GET調(diào)用在URL里顯示正傳送給SERVLET的數(shù)據(jù)，這在系統(tǒng)的安全方面可能帶來問題，例如用戶名和密碼等
   POST就可以在一定程度上解決此類問題
   2、服務(wù)器接收方式
   服務(wù)器隨機接受GET方法的數(shù)據(jù)，一旦斷電等原因，服務(wù)器也不知道信息是否發(fā)送完畢
   而POST方法，服務(wù)器先接受數(shù)據(jù)信息的長度，然后再接受數(shù)據(jù)
   3、form運行方式
   當form框里面的method為get時，執(zhí)行doGet方法
   當form框里面的method為post時，執(zhí)行doPost方法
   4、容量限制
   GET方法后面的信息量字節(jié)大小不要超過1.3K，而Post則沒有限制
8. 最后說明的是：
9. 你可以用service()來實現(xiàn)，它包含了doget和dopost ；service方法是接口中的方法，servlet容器把所有請求發(fā)送到該方法，該方法默認行為是轉(zhuǎn)發(fā)http請求到doXXX方法中，如果你重載了該方法，默認操作被覆蓋，不再進行轉(zhuǎn)發(fā)操作！
   service()是在javax.servlet.Servlet接口中定義的, 在 javax.servlet.GenericServlet
   中實現(xiàn)了這個接口, 而 doGet/doPost 則是在 javax.servlet.http.HttpServlet 中實現(xiàn)的, javax.servlet.http.HttpServlet 是 javax.servlet.GenericServlet 的子類.
10. 所有可以這樣理解, 其實所有的請求均首先由 service() 進行處理, 而在 javax.servlet.http.HttpServlet 的 service() 方法中, 主要做的事情就是判斷請求類型是 Get 還是 Post, 然后調(diào)用對應(yīng)的 doGet/doPost 執(zhí)行.

３：Struts1和Struts2的區(qū)別和對比

網(wǎng)址：http://blog.csdn.net/john2522/article/details/7436307/

struts2不是struts1的升級，而是繼承的webwork的血統(tǒng)，它吸收了struts1和webwork的優(yōu)勢。

先看struts的Action官方注釋（struts1.3.8源代碼）

/**
* <p>An <strong>Action</strong> is an adapter between the contents of an
* incoming HTTP request and the corresponding business logic that should be
* executed to process this request. The controller (RequestProcessor) will
* select an appropriate Action for each request, create an instance (if
* necessary), and call the <code>execute</code> method.</p>
*
* <p>Actions must be programmed in a thread-safe manner, because the
* controller will share the same instance for multiple simultaneous requests.
* This means you should design with the following items in mind: </p>
*
* <ul>
*
* <li>Instance and static variables MUST NOT be used to store information
* related to the state of a particular request. They MAY be used to share
* global resources across requests for the same action.</li>
*
* <li>Access to other resources (JavaBeans, session variables, etc.) MUST be
* synchronized if those resources require protection. (Generally, however,
* resource classes should be designed to provide their own protection where
* necessary.</li>
*
* </ul>
*
* <p>When an <code>Action</code> instance is first created, the controller
* will call <code>setServlet</code> with a non-null argument to identify the
* servlet instance to which this Action is attached. When the servlet is to
* be shut down (or restarted), the <code>setServlet</code> method will be
* called with a <code>null</code> argument, which can be used to clean up any
* allocated resources in use by this Action.</p>
*
* @version $Rev: 471754 $ $Date: 2005-08-26 21:58:39 -0400 (Fri, 26 Aug 2005)
* $
*

public class Action {

//代碼省略。。。。。。。

}

再看struts2的Action注釋（struts2.3.1.2）

package com.opensymphony.xwork2;

/**
* All actions <b>may</b> implement this interface, which exposes the <code>execute()</code> method.
* <p/>
* However, as of XWork 1.1, this is <b>not</b> required and is only here to assist users. You are free to create POJOs
* that honor the same contract defined by this interface without actually implementing the interface.
*/
public interface Action {

/\*\*
 \* The action execution was successful. Show result\
 \* view to the end user.
 \*/
public static final String SUCCESS = \"success\";

/\*\*
 \* The action execution was successful but do not\
 \* show a view. This is useful for actions that are\
 \* handling the view in another fashion like redirect.\
 \*/
public static final String NONE = \"none\";

/\*\*
 \* The action execution was a failure.
 \* Show an error view, possibly asking the
 \* user to retry entering data.
 \*/
public static final String ERROR = \"error\";

/\*\*
 \* The action execution require more input
 \* in order to succeed.
 \* This result is typically used if a form
 \* handling action has been executed so as
 \* to provide defaults for a form. The\
 \* form associated with the handler should be\
 \* shown to the end user.\
 \* \<p/\>\
 \* This result is also used if the given input\
 \* params are invalid, meaning the user\
 \* should try providing input again.\
 \*/\
public static final String INPUT = \"input\";

/\*\*\
 \* The action could not execute, since the\
 \* user most was not logged in. The login view\
 \* should be shown.\
 \*/\
public static final String LOGIN = \"login\";

/\*\*\
 \* Where the logic of the action is executed.\
 \*\
 \* @return a string representing the logical result of the execution.\
 \*         See constants in this interface for a list of standard result values.\
 \* @throws Exception thrown if a system level exception occurs.\
 \*                   \<b\>Note:\</b\> Application level exceptions should be handled by returning\
 \*                   an error value, such as \<code\>Action.ERROR\</code\>.\
 \*/\
public String execute() throws Exception;

}

** Struts1和Struts2的區(qū)別和對比:

**Action 類:
? Struts1要求Action類繼承一個抽象基類。Struts1的一個普遍問題是使用抽象類編程而不是接口，而struts2的Action是接口。
? Struts 2 Action類可以實現(xiàn)一個Action接口，也可實現(xiàn)其他接口，使可選和定制的服務(wù)成為可能。Struts2提供一個ActionSupport基類去 實現(xiàn) 常用的接口。Action接口不是必須的，任何有execute標識的POJO對象都可以用作Struts2的Action對象。

線程模式:
? Struts1 Action是單例模式并且必須是線程安全的，因為僅有Action的一個實例來處理所有的請求。單例策略限制了Struts1 Action能作的事，并且要在開發(fā)時特別小心。Action資源必須是線程安全的或同步的。
? Struts2 Action對象為每一個請求產(chǎn)生一個實例，因此沒有線程安全問題。（實際上，servlet容器給每個請求產(chǎn)生許多可丟棄的對象，并且不會導(dǎo)致性能和垃圾回收問題）

Servlet 依賴:
? Struts1 Action 依賴于Servlet API ,因為當一個Action被調(diào)用時HttpServletRequest 和 HttpServletResponse 被傳遞給execute方法。
? Struts 2 Action不依賴于容器，允許Action脫離容器單獨被[測試]{.underline}。如果需要，Struts2 Action仍然可以訪問初始的request和response。但是，其他的元素減少或者消除了直接訪問HttpServetRequest 和 HttpServletResponse的必要性。

可測性:
? 測試Struts1 Action的一個主要問題是execute方法暴露了servlet API（這使得測試要依賴于容器）。一個第三方擴展－－Struts TestCase－－提供了一套Struts1的模擬對象（來進行測試）。
? Struts 2 Action可以通過初始化、設(shè)置屬性、調(diào)用方法來測試，"依賴注入"支持也使測試更容易。

捕獲輸入:
? Struts1 使用ActionForm對象捕獲輸入。所有的ActionForm必須繼承一個基類。因為其他JavaBean不能用作ActionForm，開發(fā)者經(jīng)常創(chuàng)建多余的類捕獲輸入。動態(tài)Bean（DynaBeans）可以作為創(chuàng)建傳統(tǒng)ActionForm的選擇，但是，開發(fā)者可能是在重新描述(創(chuàng)建)已經(jīng)存 在的JavaBean（仍然會導(dǎo)致有冗余的javabean）。
? Struts 2直接使用Action屬性作為輸入屬性，消除了對第二個輸入對象的需求。輸入屬性可能是有自己(子)屬性的rich對象類型。Action屬性能夠通過 web頁面上的taglibs訪問。Struts2也支持ActionForm模式。rich對象類型，包括業(yè)務(wù)對象，能夠用作輸入/輸出對象。這種 ModelDriven 特性簡化了taglib對POJO輸入對象的引用。

表達式語言：
? Struts1 整合了JSTL，因此使用JSTL EL。這種EL有基本對象圖遍歷，但是對集合和索引屬性的支持很弱。
? Struts2可以使用JSTL，但是也支持一個更強大和靈活的表達式語言－－"Object Graph Notation Language" (OGNL).

綁定值到頁面（view）:
? Struts 1使用標準JSP機制把對象綁定到頁面中來訪問。
? Struts 2 使用 "ValueStack"技術(shù)，使taglib能夠訪問值而不需要把你的頁面（view）和對象綁定起來。ValueStack策略允許通過一系列名稱相同但類型不同的屬性重用頁面（view）。

類型轉(zhuǎn)換：
? Struts 1 ActionForm 屬性通常都是String類型。Struts1使用Commons-Beanutils進行類型轉(zhuǎn)換。每個類一個轉(zhuǎn)換器，對每一個實例來說是不可配置的。
? Struts2 使用OGNL進行類型轉(zhuǎn)換。提供基本和常用對象的轉(zhuǎn)換器。

校驗：
? Struts 1支持在ActionForm的validate方法中手動校驗，或者通過Commons Validator的擴展來校驗。同一個類可以有不同的校驗內(nèi)容，但不能校驗子對象。
? Struts2支持通過validate方法和XWork校驗框架來進行校驗。XWork校驗框架使用為屬性類類型定義的校驗和內(nèi)容校驗，來支持chain校驗子屬性

Action執(zhí)行的控制：
? Struts1支持每一個模塊有單獨的Request Processors（生命周期），但是模塊中的所有Action必須共享相同的生命周期。
? Struts2支持通過攔截器堆棧（Interceptor Stacks）為每一個Action創(chuàng)建不同的生命周期。堆棧能夠根據(jù)需要和不同的Action一起使用。

一、 引言Struts的第一個版本是在2001年5月份發(fā)布的。它的最初設(shè)想是通過結(jié)合JSP和Servlet，使Web應(yīng)用的視圖和業(yè)務(wù)/應(yīng)用邏輯得以清晰地分離開來。在Struts之前，最常見的做法是在JSP中加入業(yè)務(wù)和應(yīng)用邏輯，或者在Servlet中通過println()來生成視圖。

自從第一版發(fā)布以來，Struts實際上已成為業(yè)界公認的Web應(yīng)用標準。它的炙手可熱也為自己帶來了改進和變更，所以不但要跟上對Web應(yīng)用框架不斷變化的需求，而且要與日漸增多競爭激烈的眾多框架的特性相融合。到最后，產(chǎn)生了幾個下一代Struts的解決方案。其中兩個最受矚目的方案是Shale和Struts Ti。

Shale是一個基于構(gòu)件的框架，并在最近成為Apache的頂級項目。而Struts Ti則是在Struts的成功經(jīng)驗基礎(chǔ)上繼續(xù)堅持對前端控制器（Front Controller）和MVC（model-view-controller）模式進行改進。WebWork項目是在2002年3月發(fā)布的，它對Struts式框架進行了革命性改進，引進了不少新的思想、概念和功能，但和原Struts代碼并不兼容。WebWork是一個成熟的框架，經(jīng)過了好幾次重大的改進與發(fā)布。在2005年12月，WebWork與Struts Ti宣布合并。與此同時，Struts Ti改名為Struts Action Framework 2.0，成為Struts真正的繼承者。最后要注意的是，并不是說Struts或WebWork項目已經(jīng)停止開發(fā)了。由于人們對這兩個項目的興趣仍然很高，而且也有很多開發(fā)者仍然愿意使用它們，因此這兩個項目還在繼續(xù)開發(fā)中，繼續(xù)修復(fù)Bug，改進功能和繼續(xù)添加新功能。

二、 Action的區(qū)別對于有著豐富的Struts1.x開發(fā)經(jīng)驗的朋友來說，都十分的清楚Action是整個Struts框架的核心內(nèi)容，當然Struts2也不例外。不過，Struts1.x與Struts2的Action模型很大的區(qū)別。Struts2和Struts1.x的差別，最明顯的 就是Struts2是一個pull-MVC[架構(gòu)]{.underline}。

這是什么意思呢？從開發(fā)者角度看，就是說需要顯示給用戶的數(shù)據(jù)可以直接從Action中獲取，而不像 Struts1.x那樣，必須把相應(yīng)的Bean存到Page、Request或者Session中才能獲取。Struts1.x 必須繼承org.apache.struts.action.Action或者其子類，表單數(shù)據(jù)封裝在FormBean中。

Struts 2無須繼承任何類型或?qū)崿F(xiàn)任何接口，表單數(shù)據(jù)包含在Action中，通過Getter和Setter獲取（如下面的ActionForStruts2的代碼示例）。雖然，在理論上Struts2的Action無須實現(xiàn)任何接口或者是繼承任何的類，但是，在實際編程過程中，為了更加方便的實現(xiàn)Action，大多數(shù)情況下都會繼承com.opensymphony.xwork2.ActionSupport類，并且重載（Override）此類里的String execute()方法。

首先，從ActionForStruts2可以看出，返回的對象不是ActionForward，而是String。如果你不喜歡以字符串的形式出現(xiàn)在你的代碼中，有個Helper接口Action可以以常量方式提供常見結(jié)果，如"success"、"none"、"error"、"input"和"login"。

另外，按照慣例，在Struts1.x中只有"execute"方法能調(diào)用Action, 但在Struts2中并非必要，任何聲明為public String methodName() 方法，都能通過配置來調(diào)用Action。

最后，和Struts1.x最大的革命性的不同是，Struts2處理Action過程中調(diào)用的方法（"execute"方法）是不帶參數(shù)的。

那如何獲取所需要的對象呢？答案是使用IoC（反轉(zhuǎn)控制，Inversion of Control)，也叫"依賴注入（Dependency Injection）"的模式（想更多地了解這方面信息請看Martin Fowler的文章[http://www.martinfowler.com/articles/injection.html]{.underline}）。[spring]{.underline}框架使得這個模式流行起來，然而Struts2的前身（WebWork）也同時應(yīng)用上了這個模式。

三、 IoCIoC(Inversion of Control，以下譯為控制反轉(zhuǎn)），隨著[Java]{.underline}社區(qū)中輕量級容器（Lightweight Contianer）的推廣而越來越為大家耳熟能詳。在此，無需再多費唇舌來解釋"什么是控制反轉(zhuǎn)"和"為什么需要控制反轉(zhuǎn)"。因為互聯(lián)網(wǎng)上已經(jīng)有非常多的文章對諸如此類的問題作了精彩而準確的回答。

讀者可以去讀一下Rod Johnson和Juergen Hoeller合著的《Expert one-on-one J2EE Development without EJB》或Martin Fowler所寫的《Inversion of Control Containers and the Dependency Injection pattern》。眾所周知，Struts2是以Webwork 2作為基礎(chǔ)發(fā)展出來。而在Webwork 2.2之前的Webwork版本，其自身有一套控制反轉(zhuǎn)的實現(xiàn)，Webwork 2.2在Spring 框架的如火如荼發(fā)展的背景下，決定放棄控制反轉(zhuǎn)功能的開發(fā)，轉(zhuǎn)由Spring實現(xiàn)。

值得一提的是，Spring確實是一個值得學習的框架，因為有越來越多的開源組件（如iBATIS等）都放棄與Spring重疊的功能的開發(fā)。因此，Struts2推薦大家通過Spring實現(xiàn)控制反轉(zhuǎn)。

為了更好地了解反轉(zhuǎn)控制，下面來看一個例子，如何利用IoC在Action處理過程中可以訪問到當前請求HttpServerRequest對象。在例子中，使用的依賴注入機制是接口注入。就如其名稱一樣，接口注入需要的是已經(jīng)被實現(xiàn)了的接口。

這個接口包含了相應(yīng)屬性的setter，為Action提供值。

例子中使用了ServletRequestAware接口，如下：

public interface ServletRequestAware { public void setServletRequest(HttpServletRequest request);}

當繼承這個接口后，原本簡單的Action看起來有點復(fù)雜了，但是這時可以獲取HttpServerRequest對象來使用了。

public class IoCForStruts2 implements ServletRequestAware {

    private HttpServletRequest request;

    public void setServletRequest(HttpServletRequest request)  {

                 this.request = request; }

   public String execute() throws Exception {

       // 可以開始使用request對象進行工作了

         return Action.SUCCESS; }

}

看起來現(xiàn)在這些屬性是類級別的，并不是線程安全的，會出現(xiàn)問題。

其實在Struts2里并沒有問題，因為每個請求過來的時候都會產(chǎn)生一個新的Action對象實例，它并沒有和其他請求共享一個對象，所以不需要考慮線程安全問題。

攔截器 Interceptor（以下譯為攔截器），在AOP（Aspect-Oriented Programming）中用于在某個方法或字段被訪問之前，進行攔截然后在之前或之后加入某些操作。

攔截是AOP的一種實現(xiàn)策略。在Webwork的中文文檔的解釋為------攔截器是動態(tài)攔截Action調(diào)用的對象。它提供了一種機制可以使開發(fā)者定義在一個action執(zhí)行的前后執(zhí)行的代碼，也可以在一個action執(zhí)行前阻止其執(zhí)行。同時也提供了一種可以提取action中可重用的部分的方式。Struts1.x的標準框架中不提供任何形式的攔截器，雖一個名為SAIF的附加項目則實現(xiàn)了這樣的功能，但它的適用的范圍還很有限。

攔截器是Struts2的一個強有力的工具，有許多功能（feature）都是構(gòu)建于它之上，如國際化、轉(zhuǎn)換器，校驗等。談到攔截器，還有一個流行的詞------攔截器鏈（Interceptor Chain，在Struts2中稱為攔截器棧Interceptor Stack）。

攔截器鏈就是將攔截器按一定的順序聯(lián)結(jié)成一條鏈。在訪問被攔截的方法或字段時，攔截器鏈中的攔截器就會按其之前定義的順序被調(diào)用。

Struts 2的攔截器實現(xiàn)相對比較簡單。當請求到達Struts2的ServletDispatcher時，Struts 2會查找配置文件，并根據(jù)其配置實例化相對的攔截器對象，然后串成一個列表（list），最后一一地調(diào)用列表中的攔截器，Struts 2已經(jīng)提供豐富多樣功能齊全的攔截器實現(xiàn)。

讀者可以到struts2-all-2.0.6.jar或struts2-core-2.0.6.jar包的struts-default.xml查看關(guān)于默認的攔截器與攔截器鏈的配置。作為"框架（framework）"，可擴展性是不可缺少的，因為世上沒有放之四海而皆準的東西。

雖然，Struts 2為我們提供如此豐富的攔截器實現(xiàn)，但是這并不意味我們失去創(chuàng)建自定義攔截器的能力，恰恰相反，在Struts 2自定義攔截器是相當容易的一件事。

前面已經(jīng)簡要介紹了 Struts2的起源，并詳細對比了Struts2和Struts1.x的差異，讀者應(yīng)該對Struts2的基礎(chǔ)有所了解了------包括高層的框架概念和基礎(chǔ) 的請求流程，并理解Struts1.x和Struts2兩者之間在Action方面的差別，Struts2加強了對攔截器與IoC的支持，而在 Struts1.x中，這些特性是很難想象的。

同時，讀者應(yīng)該明白： Struts2是WebWork的升級，而不是Struts 1.x的升級。雖然Struts 2提供了與Struts1.x的兼容，但已經(jīng)不是Struts1.x的升級。對于已有Struts1.x開發(fā)經(jīng)驗的開發(fā)者而言，Struts1.x的開發(fā) 經(jīng)驗對于Struts2并沒有太大的幫助；相反，對于已經(jīng)有WebWork開發(fā)經(jīng)驗的開發(fā)者而言，WebWork的開發(fā)經(jīng)驗對Struts2的開發(fā)將有很 好的借鑒意義。

4：spring事務(wù)的傳播特性

網(wǎng)址：http://blog.csdn.net/loadhai/article/details/17800537

所謂事務(wù)傳播行為就是多個事務(wù)方法相互調(diào)用時，事務(wù)如何在這些方法間傳播。Spring 支持 7 種事務(wù)傳播行為：

• PROPAGATION_REQUIRED 如果當前沒有事務(wù)，就新建一個事務(wù)，如果已經(jīng)存在一個事務(wù)中，加入到這個事務(wù)中。這是最常見的選擇。
• PROPAGATION_SUPPORTS 支持當前事務(wù)，如果當前沒有事務(wù)，就以非事務(wù)方式執(zhí)行。
• PROPAGATION_MANDATORY 使用當前的事務(wù)，如果當前沒有事務(wù)，就拋出異常。
• PROPAGATION_REQUIRES_NEW 新建事務(wù)，如果當前存在事務(wù)，把當前事務(wù)掛起。
• PROPAGATION_NOT_SUPPORTED 以非事務(wù)方式執(zhí)行操作，如果當前存在事務(wù)，就把當前事務(wù)掛起。
• PROPAGATION_NEVER 以非事務(wù)方式執(zhí)行，如果當前存在事務(wù)，則拋出異常。
• PROPAGATION_NESTED 如果當前存在事務(wù)，則在嵌套事務(wù)內(nèi)執(zhí)行。如果當前沒有事務(wù)，則執(zhí)行與 PROPAGATION_REQUIRED 類似的操作。

Spring 默認的事務(wù)傳播行為是 PROPAGATION_REQUIRED，它適合于絕大多數(shù)的情況。假設(shè) ServiveX#methodX() 都工作在事務(wù)環(huán)境下（即都被 Spring 事務(wù)增強了），假設(shè)程序中存在如下的調(diào)用鏈：Service1#method1()->Service2#method2()->Service3#method3()，那么這 3 個服務(wù)類的 3 個方法通過 Spring 的事務(wù)傳播機制都工作在同一個事務(wù)中。

5： java中AWT和SWing的區(qū)別與聯(lián)系

網(wǎng)址：http://blog.csdn.net/iamluole/article/details/8142257

AWT和Swing都是Java中的包。

AWT(Abstract Window Toolkit)：抽象窗口工具包，早期編寫圖形界面應(yīng)用程序的包。

Swing ：為解決 AWT 存在的問題而新開發(fā)的圖形界面包。Swing是對AWT的改良和擴展。

AWT和Swing的實現(xiàn)原理不同：
AWT的圖形函數(shù)與操作系統(tǒng)提供的圖形函數(shù)有著一一對應(yīng)的關(guān)系。也就是說，當我們利用 AWT構(gòu)件圖形用戶界面的時候，實際上是在利用操作系統(tǒng)的圖形庫。
不同的操作系統(tǒng)其圖形庫的功能可能不一樣，在一個平臺上存在的功能在另外一個平臺上則可能不存在。為了實現(xiàn)Java語言所宣稱的"一次編譯，到處運行"的概念，AWT不得不通過犧牲功能來實現(xiàn)平臺無關(guān)性。因此，AWT 的圖形功能是各操作系統(tǒng)圖形功能的"交集"。
因為AWT是依靠本地方法來實現(xiàn)功能的，所以AWT控件稱為"重量級控件"。

   而Swing ，不僅提供了AWT 的所有功能，還用純粹的Java代碼對AWT的功能進行了大幅度的擴充。
   例如：并不是所有的操作系統(tǒng)都提供了對樹形控件的支持， Swing則利用了AWT中所提供的基本作圖方法模擬了一個樹形控件。
   由于 Swing是用純粹的Java代碼來實現(xiàn)的，因此wing控件在各平臺通用。
   因為Swing不使用本地方法，故Swing控件稱為"輕量級控件"。 

   AWT和Swing之間的區(qū)別：
   1)AWT 是基于本地方法的C/C++程序，其運行速度比較快；Swing是基于AWT的Java程序，其運行速度比較慢。
   2)AWT的控件在不同的平臺可能表現(xiàn)不同，而Swing在所有平臺表現(xiàn)一致。

   在實際應(yīng)用中，應(yīng)該使用AWT還是Swing取決于應(yīng)用程序所部署的平臺類型。例如：
   1)對于一個嵌入式應(yīng)用，目標平臺的硬件資源往往非常有限，而應(yīng)用程序的運行速度又是項目中至關(guān)重要因素。在這種矛盾的情況下，簡單而高效的AWT當然成了嵌入式Java的第一選擇。
   2)在普通的基于PC或者是工作站的標準Java應(yīng)用中，硬件資源對應(yīng)用程序所造成的限制往往不是項目中的關(guān)鍵因素。所以在標準版的Java中則提倡使用Swing， 也就是通過犧牲速度來實現(xiàn)應(yīng)用程序的功能。

在java中，AWT包的名稱是java.awt，Swing包的名稱是javax.swing。

Swing組件按功能可分為如下幾類:
　　1、頂層容器:JFrame, JApplet, JDialog和JWindow。
　　2、中間容器:JPanel, JScrollPane, JSplitPane, JTooIBar等。
　　3、特殊容器:在用戶界面上具有特殊作用的中間容器，如JlnternalFrame、JRootPane、JLayeredPane和JDestopPane等。
　　4、基本組件:實現(xiàn)人機交互的組件，如Button、 JComboBox、Just, Menu、Mider等。
　　5、不可編輯信息的顯示組件:向用戶顯示不可編輯信息的組件，如JLabel、JProgressBar和JTooITip等。
　　6、可編輯信息的顯示組件:向用戶顯示能被編輯的格式化信息的組件，如JTable、JTextArea和JTextField等。
　　7、特殊對話框組件:可以直接產(chǎn)生特殊對話框的組件，如JColorChoosor和JFileChooser等。

Swing的4個頂層容器類直接繼承了AWT組件，而不是從JComponent派生出來的，它們分別是：JFrame、JDialog、JApplet和JWindow。
頂層容器類并不是輕量級組件，而是重量級組件(需要部分委托給運行平臺上GUI組件的對等體)。

頂層容器中：
1.JApplet可作為java小應(yīng)用程序的窗體，但通常使用java.applet.Applet類來創(chuàng)建小應(yīng)用程序。
2.JFrame集成自AWTFrame類，通常作為主窗體使用。
3.JDialog用于創(chuàng)建對話框的窗體。
4.JWindow與AWT中的Window相似，但幾乎不用，因為沒有太大的實用價值。

Swing組件的類名和對應(yīng)AWT組件的類名基本一致，只要在原來的AWT組件類名前添加"J"即可，但有如下幾個例外：
　　1、JComboBox:對應(yīng)于AWT里的Choice組件，但比Choice組件功能更豐富。
　　2、JFileChooser:對位于AWT里的FileDialog組件。
　　3、JSrcoIIBar:對應(yīng)AWT里的Scrollbar。注意兩個組件類名中b字母的大小寫差別。
　　4、JCheckBox:對應(yīng)于AWT里的Checkbox。注意兩個組件類名中b字母的大小寫差別。
　　5、JCheckBoxMenuItem:對應(yīng)于AWT里的CheckboxMenuItem，注意兩個組件類名中b字母的大小寫差別。

上面JCheckBox和JCheckBoxMenuItem與Checkbox和CheckboxMenuItem字母B的大小寫差別，主要是因為早期Java命名不太規(guī)范造成的。