１：Servlet与CGI的区别

网址：http://blog.csdn.net/kobejayandy/article/details/11906125

概括来讲，Servlet可以完成和CGI相同的功能。
　　CGI应用开发比较困难，因为它要求程序员有处理参数传递的知识，这不是一种通用的技能。CGI不可移植，为某一特定平台编写的CGI应用只能运行于这一环境中。每一个CGI应用存在于一个由客户端请求激活的进程中，并且在请求被服务后被卸载。这种模式将引起很高的内存、CPU开销，而且在同一进程中不能服务多个客户。
　　Servlet提供了Java应用程序的所有优势：可移植、稳健、易开发。使用Servlet Tag技术，Servlet能够生成嵌于静态HTML页面中的动态内容。
　　Servlet对CGI的最主要优势在于一个Servlet被客户端发送的第一个请求激活，然后它将继续运行于后台，等待以后的请求。每个请求将生成一个新的线程，而不是一个完整的进程。多个客户能够在同一个进程中同时得到服务。一般来说，Servlet进程只是在Web Server卸载时被卸载。

**Java **Servlet与CGI (Common Gateway Interface 公共网关接口)的比较:

与传统的CGI和许多其他类似CGI的技术相比，Java Servlet具有更高的效率，更容易使用，功能更强大，具有更好的可移植性，更节省投资。在未来的技术发展过程中，Servlet有可能彻底取代CGI。

在传统的CGI中，每个请求都要启动一个新的进程，如果CGI程序本身的执行时间较短，启动进程所需要的开销很可能反而超过实际执行时间。而在Servlet中，每个请求由一个轻量级的Java线程处理(而不是重量级的操作系统进程)。

在传统CGI中，如果有N个并发的对同一CGI程序的请求，则该CGI程序的代码在内存中重复装载了N次；而对于Servlet，处理请求的是N个线程，只需要一份Servlet类代码。在性能优化方面，Servlet也比CGI有着更多的选择。

*** 方便 **

Servlet提供了大量的实用工具例程，例如自动地解析和解码HTML表单数据、读取和设置HTTP头、处理Cookie、跟踪会话状态等。

* 功能强大

在Servlet中，许多使用传统CGI程序很难完成的任务都可以轻松地完成。例如，Servlet能够直接和Web服务器交互，而普通的CGI程序不能。Servlet还能够在各个程序之间共享数据，使得数据库连接池之类的功能很容易实现。

* 可移植性好

    Servlet用Java编写，Servlet [API](http://baike.baidu.com/view/16068.htm)具有完善的标准。因此，为IPlanet Enterprise Server写的Servlet无需任何实质上的改动即可移植到[Apache](http://baike.baidu.com/view/28283.htm)、[Microsoft ](http://baike.baidu.com/view/2422.htm)IIS或者WebStar。几乎所有的主流服务器都直接或通过插件支持Servlet。

２：GET和POST区别 / doGet()和doPost()的区别

网址：http://www.cnblogs.com/cyy-13/p/5711235.html

1，生成方式
get方式有四种：1）直接在URL地址栏中输入URL。2）网页中的超链接。3）form中method为get。4）form中method为空时，默认是get提交。
post只知道有一种：form中method属性为post。
2、数据传送方式
get方式：表单数据存放在URL地址后面。所有get方式提交时HTTP中没有消息体。
post方式：表单数据存放在HTTP协议的消息体中以实体的方式传送到服务器。
3、服务器获取数据方式
GET方式：服务器采用request.QueryString来获取变量的值。
POST方式：服务器采用request.Form来获取数据。
4、传送的数据量
GET方式：数据量长度有限制，一般不超过2kb。因为是参数传递，且在地址栏中，故数据量有限制。
POST方式：适合大规模的数据传送。因为是以实体的方式传送的。
5、安全性
GET方式：安全性差。因为是直接将数据显示在地址栏中，浏览器有缓冲，可记录用户信息。所以安全性低。
POST方式：安全性高。因为post方式提交数据时是采用的HTTP post机制，是将表单中的字段与值放置在HTTP HEADER内一起传送到ACTION所指的URL中，用户是看不见的。
6、在用户刷新时
GET方式：不会有任何提示、
POST方式：会弹出提示框，问用户是否重新提交

1. get是从服务器上获取数据，post是向服务器传送数据。
2. get是把参数数据队列加到提交表单的ACTION属性所指的URL中，值和表单内各个字段一一对应，在URL中可以看到。post是通过HTTP post机制，将表单内各个字段与其内容放置在HTML HEADER内一起传送到ACTION属性所指的URL地址。用户看不到这个过程。
3. 对于get方式，服务器端用Request.QueryString获取变量的值，对于post方式，服务器端用Request.Form获取提交的数据。
4. get传送的数据量较小，不能大于2KB。post传送的数据量较大，一般被默认为不受限制。但理论上，IIS4中最大量为80KB，IIS5中为100KB。
5. get安全性非常低，post安全性较高。但是执行效率却比Post方法好。 建议： 1、get方式的安全性较Post方式要差些，包含机密信息的话，建议用Post数据提交方式；
   2、在做数据查询时，建议用Get方式；而在做数据添加、修改或删除时，建议用Post方式；
6. Servlet的doGet/doPost 是在 javax.servlet.http.HttpServlet 中实现的
   doGet：处理GET请求
   doPost：处理POST请求
   当发出客户端请求的时候，调用service 方法并传递一个请求和响应对象。Servlet首先判断该请求是GET 操作还是POST 操作。然后它调用下面的一个方法：doGet 或 doPost。如果请求是GET就调用doGet方法，如果请求是POST就调用doPost方法。doGet和doPost都接受请求(HttpServletRequest)和响应(HttpServletResponse)。
   get只有一个流，参数附加在url后，地址行显示要传送的信息，大小个数有严格限制且只能是字符串，大小限制在1024KB。post的参数是通过另外的流传递的， 不通过url，所以可以很大，也可以传递二进制数据，如文件的上传。
   get通过URL提交的参数会显示在地址栏中，这在系统的安全方面可能带来问题；post提交的参数不会显示在地址栏中。这样post就可以提高get的安全性能，避免数据的泄露。
   当form框里面的method为get时，执行doGet方法，使用get提交就必须在服务器端用doGet()方法接收；当form框里面的method为post时，执行doPost方法，使用post提交就必须在服务器端用doPost()方法接收。
   在request请求里面，编码转换；get方法得到的内容每一个都要进行编码转换，而post方法则只要设置request.setCharacterEncoding("UTF-8")就可以，不要再从request得到的每个数据进行编码转换了。
7. 1、安全
   GET调用在URL里显示正传送给SERVLET的数据，这在系统的安全方面可能带来问题，例如用户名和密码等
   POST就可以在一定程度上解决此类问题
   2、服务器接收方式
   服务器随机接受GET方法的数据，一旦断电等原因，服务器也不知道信息是否发送完毕
   而POST方法，服务器先接受数据信息的长度，然后再接受数据
   3、form运行方式
   当form框里面的method为get时，执行doGet方法
   当form框里面的method为post时，执行doPost方法
   4、容量限制
   GET方法后面的信息量字节大小不要超过1.3K，而Post则没有限制
8. 最后说明的是：
9. 你可以用service()来实现，它包含了doget和dopost ；service方法是接口中的方法，servlet容器把所有请求发送到该方法，该方法默认行为是转发http请求到doXXX方法中，如果你重载了该方法，默认操作被覆盖，不再进行转发操作！
   service()是在javax.servlet.Servlet接口中定义的, 在 javax.servlet.GenericServlet
   中实现了这个接口, 而 doGet/doPost 则是在 javax.servlet.http.HttpServlet 中实现的, javax.servlet.http.HttpServlet 是 javax.servlet.GenericServlet 的子类.
10. 所有可以这样理解, 其实所有的请求均首先由 service() 进行处理, 而在 javax.servlet.http.HttpServlet 的 service() 方法中, 主要做的事情就是判断请求类型是 Get 还是 Post, 然后调用对应的 doGet/doPost 执行.

３：Struts1和Struts2的区别和对比

网址：http://blog.csdn.net/john2522/article/details/7436307/

struts2不是struts1的升级，而是继承的webwork的血统，它吸收了struts1和webwork的优势。

先看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的区别和对比:

**Action 类:
• Struts1要求Action类继承一个抽象基类。Struts1的一个普遍问题是使用抽象类编程而不是接口，而struts2的Action是接口。
• Struts 2 Action类可以实现一个Action接口，也可实现其他接口，使可选和定制的服务成为可能。Struts2提供一个ActionSupport基类去 实现 常用的接口。Action接口不是必须的，任何有execute标识的POJO对象都可以用作Struts2的Action对象。

线程模式:
• Struts1 Action是单例模式并且必须是线程安全的，因为仅有Action的一个实例来处理所有的请求。单例策略限制了Struts1 Action能作的事，并且要在开发时特别小心。Action资源必须是线程安全的或同步的。
• Struts2 Action对象为每一个请求产生一个实例，因此没有线程安全问题。（实际上，servlet容器给每个请求产生许多可丢弃的对象，并且不会导致性能和垃圾回收问题）

Servlet 依赖:
• Struts1 Action 依赖于Servlet API ,因为当一个Action被调用时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可以通过初始化、设置属性、调用方法来测试，"依赖注入"支持也使测试更容易。

捕获输入:
• Struts1 使用ActionForm对象捕获输入。所有的ActionForm必须继承一个基类。因为其他JavaBean不能用作ActionForm，开发者经常创建多余的类捕获输入。动态Bean（DynaBeans）可以作为创建传统ActionForm的选择，但是，开发者可能是在重新描述(创建)已经存 在的JavaBean（仍然会导致有冗余的javabean）。
• Struts 2直接使用Action属性作为输入属性，消除了对第二个输入对象的需求。输入属性可能是有自己(子)属性的rich对象类型。Action属性能够通过 web页面上的taglibs访问。Struts2也支持ActionForm模式。rich对象类型，包括业务对象，能够用作输入/输出对象。这种 ModelDriven 特性简化了taglib对POJO输入对象的引用。

表达式语言：
• Struts1 整合了JSTL，因此使用JSTL EL。这种EL有基本对象图遍历，但是对集合和索引属性的支持很弱。
• Struts2可以使用JSTL，但是也支持一个更强大和灵活的表达式语言－－"Object Graph Notation Language" (OGNL).

绑定值到页面（view）:
• Struts 1使用标准JSP机制把对象绑定到页面中来访问。
• Struts 2 使用 "ValueStack"技术，使taglib能够访问值而不需要把你的页面（view）和对象绑定起来。ValueStack策略允许通过一系列名称相同但类型不同的属性重用页面（view）。

类型转换：
• Struts 1 ActionForm 属性通常都是String类型。Struts1使用Commons-Beanutils进行类型转换。每个类一个转换器，对每一个实例来说是不可配置的。
• Struts2 使用OGNL进行类型转换。提供基本和常用对象的转换器。

校验：
• Struts 1支持在ActionForm的validate方法中手动校验，或者通过Commons Validator的扩展来校验。同一个类可以有不同的校验内容，但不能校验子对象。
• Struts2支持通过validate方法和XWork校验框架来进行校验。XWork校验框架使用为属性类类型定义的校验和内容校验，来支持chain校验子属性

Action执行的控制：
• Struts1支持每一个模块有单独的Request Processors（生命周期），但是模块中的所有Action必须共享相同的生命周期。
• Struts2支持通过拦截器堆栈（Interceptor Stacks）为每一个Action创建不同的生命周期。堆栈能够根据需要和不同的Action一起使用。

一、 引言Struts的第一个版本是在2001年5月份发布的。它的最初设想是通过结合JSP和Servlet，使Web应用的视图和业务/应用逻辑得以清晰地分离开来。在Struts之前，最常见的做法是在JSP中加入业务和应用逻辑，或者在Servlet中通过println()来生成视图。

自从第一版发布以来，Struts实际上已成为业界公认的Web应用标准。它的炙手可热也为自己带来了改进和变更，所以不但要跟上对Web应用框架不断变化的需求，而且要与日渐增多竞争激烈的众多框架的特性相融合。到最后，产生了几个下一代Struts的解决方案。其中两个最受瞩目的方案是Shale和Struts Ti。

Shale是一个基于构件的框架，并在最近成为Apache的顶级项目。而Struts Ti则是在Struts的成功经验基础上继续坚持对前端控制器（Front Controller）和MVC（model-view-controller）模式进行改进。WebWork项目是在2002年3月发布的，它对Struts式框架进行了革命性改进，引进了不少新的思想、概念和功能，但和原Struts代码并不兼容。WebWork是一个成熟的框架，经过了好几次重大的改进与发布。在2005年12月，WebWork与Struts Ti宣布合并。与此同时，Struts Ti改名为Struts Action Framework 2.0，成为Struts真正的继承者。最后要注意的是，并不是说Struts或WebWork项目已经停止开发了。由于人们对这两个项目的兴趣仍然很高，而且也有很多开发者仍然愿意使用它们，因此这两个项目还在继续开发中，继续修复Bug，改进功能和继续添加新功能。

二、 Action的区别对于有着丰富的Struts1.x开发经验的朋友来说，都十分的清楚Action是整个Struts框架的核心内容，当然Struts2也不例外。不过，Struts1.x与Struts2的Action模型很大的区别。Struts2和Struts1.x的差别，最明显的 就是Struts2是一个pull-MVC[架构]{.underline}。

这是什么意思呢？从开发者角度看，就是说需要显示给用户的数据可以直接从Action中获取，而不像 Struts1.x那样，必须把相应的Bean存到Page、Request或者Session中才能获取。Struts1.x 必须继承org.apache.struts.action.Action或者其子类，表单数据封装在FormBean中。

Struts 2无须继承任何类型或实现任何接口，表单数据包含在Action中，通过Getter和Setter获取（如下面的ActionForStruts2的代码示例）。虽然，在理论上Struts2的Action无须实现任何接口或者是继承任何的类，但是，在实际编程过程中，为了更加方便的实现Action，大多数情况下都会继承com.opensymphony.xwork2.ActionSupport类，并且重载（Override）此类里的String execute()方法。

首先，从ActionForStruts2可以看出，返回的对象不是ActionForward，而是String。如果你不喜欢以字符串的形式出现在你的代码中，有个Helper接口Action可以以常量方式提供常见结果，如"success"、"none"、"error"、"input"和"login"。

另外，按照惯例，在Struts1.x中只有"execute"方法能调用Action, 但在Struts2中并非必要，任何声明为public String methodName() 方法，都能通过配置来调用Action。

最后，和Struts1.x最大的革命性的不同是，Struts2处理Action过程中调用的方法（"execute"方法）是不带参数的。

那如何获取所需要的对象呢？答案是使用IoC（反转控制，Inversion of Control)，也叫"依赖注入（Dependency Injection）"的模式（想更多地了解这方面信息请看Martin Fowler的文章[http://www.martinfowler.com/articles/injection.html]{.underline}）。[spring]{.underline}框架使得这个模式流行起来，然而Struts2的前身（WebWork）也同时应用上了这个模式。

三、 IoCIoC(Inversion of Control，以下译为控制反转），随着[Java]{.underline}社区中轻量级容器（Lightweight Contianer）的推广而越来越为大家耳熟能详。在此，无需再多费唇舌来解释"什么是控制反转"和"为什么需要控制反转"。因为互联网上已经有非常多的文章对诸如此类的问题作了精彩而准确的回答。

读者可以去读一下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作为基础发展出来。而在Webwork 2.2之前的Webwork版本，其自身有一套控制反转的实现，Webwork 2.2在Spring 框架的如火如荼发展的背景下，决定放弃控制反转功能的开发，转由Spring实现。

值得一提的是，Spring确实是一个值得学习的框架，因为有越来越多的开源组件（如iBATIS等）都放弃与Spring重叠的功能的开发。因此，Struts2推荐大家通过Spring实现控制反转。

为了更好地了解反转控制，下面来看一个例子，如何利用IoC在Action处理过程中可以访问到当前请求HttpServerRequest对象。在例子中，使用的依赖注入机制是接口注入。就如其名称一样，接口注入需要的是已经被实现了的接口。

这个接口包含了相应属性的setter，为Action提供值。

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

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

当继承这个接口后，原本简单的Action看起来有点复杂了，但是这时可以获取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; }

}

看起来现在这些属性是类级别的，并不是线程安全的，会出现问题。

其实在Struts2里并没有问题，因为每个请求过来的时候都会产生一个新的Action对象实例，它并没有和其他请求共享一个对象，所以不需要考虑线程安全问题。

拦截器 Interceptor（以下译为拦截器），在AOP（Aspect-Oriented Programming）中用于在某个方法或字段被访问之前，进行拦截然后在之前或之后加入某些操作。

拦截是AOP的一种实现策略。在Webwork的中文文档的解释为------拦截器是动态拦截Action调用的对象。它提供了一种机制可以使开发者定义在一个action执行的前后执行的代码，也可以在一个action执行前阻止其执行。同时也提供了一种可以提取action中可重用的部分的方式。Struts1.x的标准框架中不提供任何形式的拦截器，虽一个名为SAIF的附加项目则实现了这样的功能，但它的适用的范围还很有限。

拦截器是Struts2的一个强有力的工具，有许多功能（feature）都是构建于它之上，如国际化、转换器，校验等。谈到拦截器，还有一个流行的词------拦截器链（Interceptor Chain，在Struts2中称为拦截器栈Interceptor Stack）。

拦截器链就是将拦截器按一定的顺序联结成一条链。在访问被拦截的方法或字段时，拦截器链中的拦截器就会按其之前定义的顺序被调用。

Struts 2的拦截器实现相对比较简单。当请求到达Struts2的ServletDispatcher时，Struts 2会查找配置文件，并根据其配置实例化相对的拦截器对象，然后串成一个列表（list），最后一一地调用列表中的拦截器，Struts 2已经提供丰富多样功能齐全的拦截器实现。

读者可以到struts2-all-2.0.6.jar或struts2-core-2.0.6.jar包的struts-default.xml查看关于默认的拦截器与拦截器链的配置。作为"框架（framework）"，可扩展性是不可缺少的，因为世上没有放之四海而皆准的东西。

虽然，Struts 2为我们提供如此丰富的拦截器实现，但是这并不意味我们失去创建自定义拦截器的能力，恰恰相反，在Struts 2自定义拦截器是相当容易的一件事。

前面已经简要介绍了 Struts2的起源，并详细对比了Struts2和Struts1.x的差异，读者应该对Struts2的基础有所了解了------包括高层的框架概念和基础 的请求流程，并理解Struts1.x和Struts2两者之间在Action方面的差别，Struts2加强了对拦截器与IoC的支持，而在 Struts1.x中，这些特性是很难想象的。

同时，读者应该明白： Struts2是WebWork的升级，而不是Struts 1.x的升级。虽然Struts 2提供了与Struts1.x的兼容，但已经不是Struts1.x的升级。对于已有Struts1.x开发经验的开发者而言，Struts1.x的开发 经验对于Struts2并没有太大的帮助；相反，对于已经有WebWork开发经验的开发者而言，WebWork的开发经验对Struts2的开发将有很 好的借鉴意义。

4：spring事务的传播特性

网址：http://blog.csdn.net/loadhai/article/details/17800537

所谓事务传播行为就是多个事务方法相互调用时，事务如何在这些方法间传播。Spring 支持 7 种事务传播行为：

• PROPAGATION_REQUIRED 如果当前没有事务，就新建一个事务，如果已经存在一个事务中，加入到这个事务中。这是最常见的选择。
• PROPAGATION_SUPPORTS 支持当前事务，如果当前没有事务，就以非事务方式执行。
• PROPAGATION_MANDATORY 使用当前的事务，如果当前没有事务，就抛出异常。
• PROPAGATION_REQUIRES_NEW 新建事务，如果当前存在事务，把当前事务挂起。
• PROPAGATION_NOT_SUPPORTED 以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。
• PROPAGATION_NEVER 以非事务方式执行，如果当前存在事务，则抛出异常。
• PROPAGATION_NESTED 如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则执行与 PROPAGATION_REQUIRED 类似的操作。

Spring 默认的事务传播行为是 PROPAGATION_REQUIRED，它适合于绝大多数的情况。假设 ServiveX#methodX() 都工作在事务环境下（即都被 Spring 事务增强了），假设程序中存在如下的调用链：Service1#method1()->Service2#method2()->Service3#method3()，那么这 3 个服务类的 3 个方法通过 Spring 的事务传播机制都工作在同一个事务中。

5： java中AWT和SWing的区别与联系

网址：http://blog.csdn.net/iamluole/article/details/8142257

AWT和Swing都是Java中的包。

AWT(Abstract Window Toolkit)：抽象窗口工具包，早期编写图形界面应用程序的包。

Swing ：为解决 AWT 存在的问题而新开发的图形界面包。Swing是对AWT的改良和扩展。

AWT和Swing的实现原理不同：
AWT的图形函数与操作系统提供的图形函数有着一一对应的关系。也就是说，当我们利用 AWT构件图形用户界面的时候，实际上是在利用操作系统的图形库。
不同的操作系统其图形库的功能可能不一样，在一个平台上存在的功能在另外一个平台上则可能不存在。为了实现Java语言所宣称的"一次编译，到处运行"的概念，AWT不得不通过牺牲功能来实现平台无关性。因此，AWT 的图形功能是各操作系统图形功能的"交集"。
因为AWT是依靠本地方法来实现功能的，所以AWT控件称为"重量级控件"。

   而Swing ，不仅提供了AWT 的所有功能，还用纯粹的Java代码对AWT的功能进行了大幅度的扩充。
   例如：并不是所有的操作系统都提供了对树形控件的支持， Swing则利用了AWT中所提供的基本作图方法模拟了一个树形控件。
   由于 Swing是用纯粹的Java代码来实现的，因此wing控件在各平台通用。
   因为Swing不使用本地方法，故Swing控件称为"轻量级控件"。 

   AWT和Swing之间的区别：
   1)AWT 是基于本地方法的C/C++程序，其运行速度比较快；Swing是基于AWT的Java程序，其运行速度比较慢。
   2)AWT的控件在不同的平台可能表现不同，而Swing在所有平台表现一致。

   在实际应用中，应该使用AWT还是Swing取决于应用程序所部署的平台类型。例如：
   1)对于一个嵌入式应用，目标平台的硬件资源往往非常有限，而应用程序的运行速度又是项目中至关重要因素。在这种矛盾的情况下，简单而高效的AWT当然成了嵌入式Java的第一选择。
   2)在普通的基于PC或者是工作站的标准Java应用中，硬件资源对应用程序所造成的限制往往不是项目中的关键因素。所以在标准版的Java中则提倡使用Swing， 也就是通过牺牲速度来实现应用程序的功能。

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

Swing组件按功能可分为如下几类:
　　1、顶层容器:JFrame, JApplet, JDialog和JWindow。
　　2、中间容器:JPanel, JScrollPane, JSplitPane, JTooIBar等。
　　3、特殊容器:在用户界面上具有特殊作用的中间容器，如JlnternalFrame、JRootPane、JLayeredPane和JDestopPane等。
　　4、基本组件:实现人机交互的组件，如Button、 JComboBox、Just, Menu、Mider等。
　　5、不可编辑信息的显示组件:向用户显示不可编辑信息的组件，如JLabel、JProgressBar和JTooITip等。
　　6、可编辑信息的显示组件:向用户显示能被编辑的格式化信息的组件，如JTable、JTextArea和JTextField等。
　　7、特殊对话框组件:可以直接产生特殊对话框的组件，如JColorChoosor和JFileChooser等。

Swing的4个顶层容器类直接继承了AWT组件，而不是从JComponent派生出来的，它们分别是：JFrame、JDialog、JApplet和JWindow。
顶层容器类并不是轻量级组件，而是重量级组件(需要部分委托给运行平台上GUI组件的对等体)。

顶层容器中：
1.JApplet可作为java小应用程序的窗体，但通常使用java.applet.Applet类来创建小应用程序。
2.JFrame集成自AWTFrame类，通常作为主窗体使用。
3.JDialog用于创建对话框的窗体。
4.JWindow与AWT中的Window相似，但几乎不用，因为没有太大的实用价值。

Swing组件的类名和对应AWT组件的类名基本一致，只要在原来的AWT组件类名前添加"J"即可，但有如下几个例外：
　　1、JComboBox:对应于AWT里的Choice组件，但比Choice组件功能更丰富。
　　2、JFileChooser:对位于AWT里的FileDialog组件。
　　3、JSrcoIIBar:对应AWT里的Scrollbar。注意两个组件类名中b字母的大小写差别。
　　4、JCheckBox:对应于AWT里的Checkbox。注意两个组件类名中b字母的大小写差别。
　　5、JCheckBoxMenuItem:对应于AWT里的CheckboxMenuItem，注意两个组件类名中b字母的大小写差别。

上面JCheckBox和JCheckBoxMenuItem与Checkbox和CheckboxMenuItem字母B的大小写差别，主要是因为早期Java命名不太规范造成的。