设计模式（Design pattern）是经过程序员反复实践后形成的一套代码设计经验的总结。设计模式随着编程语言的发展，也由最初的“编程惯例”逐步发展成为被反复使用、并为绝大多数程序员所知晓的、完善的理论体系。我们使用设计模式（Design pattern）的初衷，是使代码的重用度提高、让代码能够更容易被别人理解以及保证代码的可靠性。毫无疑问，在程序中使用设计模式无论是对于程序员自身还是对于应用程序都是双赢的结果。正确地使用设计模式，能够使我们编程真正实现工程化和规范化，并且在一定程度上指导着框架的设计和实现。 

       在深入探讨Struts2所依赖的核心技术之前，我们将首先带领读者领略一下在整个Struts2框架之中所使用到的一些最常用的设计模式。理解这些设计模式的运用场景和内部机理，也将为日后我们对这些核心技术的分析打下坚实的基础。 

4.1 ThreadLocal模式 

           ThreadLocal模式，严格意义上来说并不能称之为一种设计模式，因为它只是一个用来解决多线程程序中数据共享问题的一个解决方案。尽管如此，ThreadLocal模式却贯穿了整个Struts2和XWork框架，成为Struts2框架进行“解耦”设计的核心依赖技术。那么，为什么要在Struts2中引入ThreadLocal模式呢？这不得不从Web开发中的线程安全问题谈起。 

4.1.1线程安全问题的由来 

          在传统的Web开发中，我们处理Http请求最常用的方式是通过实现Servlet对象来进行Http请求的响应。Servlet是J2EE的重要标准之一，规定了Java如何响应Http请求的规范。通过HttpServletRequest和HttpServletResponse对象，我们能够轻松地与Web容器交互。 

            当Web容器收到一个Http请求时，Web容器中的一个主调度线程会从事先定义好的线程池中分配一个当前工作线程，将请求分配给当前的工作线程，由该线程来执行对应的Servlet对象中的service方法。如果这个工作线程正在执行的时候，Web容器收到另外一个请求，主调度线程会同样从线程池中选择另一个工作线程来服务新的请求。Web容器本身并不关心这个新的请求是否访问的是同一个Servlet实例。因此，我们可以得出一个结论：对于同一个Servlet对象的多个请求，Servlet的service方法将在一个多线程的环境中并发执行。 

            所以，Web容器默认采用单实例（单Servlet实例）多线程的方式来处理Http请求。这种处理方式能够减少新建Servlet实例的开销，从而缩短了对Http请求的响应时间。但是，这样的处理方式会导致变量访问的线程安全问题。也就是说，Servlet对象并不是一个线程安全的对象。下面的测试代码将证实这一点： 

这里参阅了网络上一段著名的对Servlet线程安全性进行测试的代码(http://zwchen.iteye.com/blog/91088)。运行之后，我们可以看一下这个例子的输出： 

通过上面的输出，我们可以得出以下三个Servlet对象的运行特性： 

1. Servlet对象是一个无状态的单例对象（Singleton），因为我们看到多次请求的this指针所打印出来的hashcode值都相同 

2. Servlet在不同的线程（线程池）中运行，如http-8081-Processor22和http-8081-Processor23等输出值可以明显区分出不同的线程执行了同一段Servlet逻辑代码。 

3. Counter变量在不同的线程中共享，而且它的值被不同的线程修改，输出时已经不是顺序输出。也就是说，其他的线程会篡改当前线程中实例变量的值，针对这些对象的访问不是线程安全的。 

【有关线程安全的概念范畴】 

          谈到线程安全，对于许多初学者来说很容易引起概念上的混淆。线程安全，指的是在多线程环境下，一个类在执行某个方法时，对类的内部实例变量的访问安全与否。因此，对于下面列出来的2类变量，不存在任何线程安全的说法： 1）方法签名中的任何参数变量。 
2）处于方法内部的局部变量。 

任何针对上述形式的变量的访问都是线程安全的，因为它们都处于方法体的内部，由当前的执行线程独自管理。 
     这就是线程安全问题的由来：在传统的基于Servlet的开发模式中，Servlet对象内部的实例变量不是线程安全的。在多线程环境中，这些变量的访问需要通过特殊的手段进行访问控制。 

         解决线程安全访问的方法很多，比较容易想到的一种方案是使用同步机制，但是出于对Web应用效率的考虑，这种机制在Web开发中的可行性很低，也违背了Servlet的设计初衷。因此，我们需要另辟蹊径来解决这一困扰我们的问题。 

4.1.2 ThreadLocal模式的实现机理 

  在JDK的早期版本中，提供了一种解决多线程并发问题的方案： java.lang.ThreadLocal类。ThreadLocal类在维护变量时，实际使用了当前线程（Thread）中的一个叫做ThreadLocalMap的独立副本，每个线程可以独立修改属于自己的副本而不会互相影响，从而隔离了线程和线程，避免了线程访问实例变量发生冲突的问题。 

         ThreadLocal本身并不是一个线程，而是通过操作当前线程（Thread）中的一个内部变量来达到与其他线程隔离的目的。之所以取名为ThreadLocal，所期望表达的含义是其操作的对象是线程（Thread）的一个本地变量。如果我们看一下Thread的源码实现，就会发现这一变量，如代码清单4-2所示： 

  

这是JDK中Thread源码的一部分，从中我们可以看出ThreadLocalMap跟随着当前的线程而存在。不同的线程Thread，拥有不同的ThreadLocalMap的本地实例变量，这也就是“副本”的含义。接下来我们再来看看ThreadLocal.ThreadLocalMap是如何定义的，以及ThreadLocal如何来操作它，如代码清单4-3所示： 

        从上述代码中，我们看到了ThreadLocal类的大致结构和进行ThreadLocalMap的操作。我们可以从中得出以下的结论： 

1. ThreadLocalMap变量属于线程（Thread）的内部属性，不同的线程（Thread）拥有完全不同的ThreadLocalMap变量。 

2. 线程（Thread）中的ThreadLocalMap变量的值是在ThreadLocal对象进行set或者get操作时创建的。 

3. 在创建ThreadLocalMap之前，会首先检查当前线程（Thread）中的ThreadLocalMap变量是否已经存在，如果不存在则创建一个；如果已经存在，则使用当前线程（Thread）已创建的ThreadLocalMap。 

4. 使用当前线程（Thread）的ThreadLocalMap的关键在于使用当前的ThreadLocal的实例作为key进行存储。 

ThreadLocal模式，至少从两个方面完成了数据访问隔离，有了横向和纵向的两种不同的隔离方式，ThreadLocal模式就能真正地做到线程安全： 

纵向隔离 —— 线程（Thread）与线程（Thread）之间的数据访问隔离。这一点由线程（Thread）的数据结构保证。因为每个线程（Thread）在进行对象访问时，访问的都是各自线程自己的ThreadLocalMap。 

横向隔离 —— 同一个线程中，不同的ThreadLocal实例操作的对象之间的相互隔离。这一点由ThreadLocalMap在存储时，采用当前ThreadLocal的实例作为key来保证。

 

 

深入比较TheadLocal模式与synchronized关键字

　　ThreadLocal模式synchronized关键字都用于处理多线程并发访问变量的问题，只是二者处理问题的角度和思路不同。

　　1）ThreadLocal是一个java类，通过对当前线程中的局部变量的操作来解决不同线程的变量访问的冲突问题。所以，ThreadLocal提供了线程安全的共享对象机制，每个线程都拥有其副本。

　　2）Java中的synchronized是一个保留字，它依靠JVM的锁机制来实现临界区的函数或者变量的访问中的原子性。在同步机制中，通过对象的锁机制保证同一时间只有一个线程访问变量。此时，被用作“锁机制”的变量时多个线程共享的。

　　同步机制(synchronized关键字)采用了“以时间换空间”的方式，提供一份变量，让不同的线程排队访问。而ThreadLocal采用了“以空间换时间”的方式，为每一个线程都提供一份变量的副本，从而实现同时访问而互不影响。

ThreadLocal模式并不是什么高深的学问，它甚至从JDK1.2开始就存在于Java世界中。由此可见，我们掌握一种知识的最终目的是熟练而合理地运用它。 

4.1.3 ThreadLocal模式的应用场景 

在分析了ThreadLocal的源码之后，我们来看看ThreadLocal模式最合适的业务场景。在一个完整的“请求-响应”过程中，主线程的执行过程总是贯穿始终。当这个主线程的执行过程中被加入了ThreadLocal的读写时，会对整个过程产生怎样的影响呢？我们根据之前源码分析的结果，并结合分层开发模式，把整个流程画下来，如图4-1所示： 



       从上面图中我们可以看到，由于ThreadLocal所操作的是维持于整个Thread生命周期的副本（ThreadLocalMap），所以无论在J2EE程序程序的哪个层次（表示层、业务逻辑层或者持久层），只要在一个Thread的生命周期之内，存储于ThreadLocalMap中的对象都是线程安全的（因为ThreadLocalMap本身仅仅隶属于当前的执行线程，是执行线程内部的一个属性变量。我们用图中的阴影部分来表示这个变量的存储空间）。而这一点，正是被我们用于来解决多线程环境中的变量共享问题的核心技术。ThreadLocal的这一特性也使其能够被广泛地应用于J2EE开发中的许多业务场景。 

【数据共享 OR 数据传递？】 

       ThreadLocal模式由于利用了Java自身的语法特性而显得异常简单和便利，因而被广泛应用于J2EE开发，尤其是应对跨层次的资源共享，例如在Spring中，就有使用ThreadLocal模式来管理数据库连接或者Hibernate的Session的范例。 
在一些比较著名的论坛中，有着很多关于使用ThreadLocal模式来做数据传递的讨论。事实上，这是对ThreadLocal模式的一个极大的误解。读者需要注意的是，ThreadLocal模式解决的是同一线程中隶属于不同开发层次的数据共享问题，而不是在不同的开发层次中进行数据传递。 

1）ThreadLocal模式的核心在于实现一个共享环境（类的内部封装了ThreadLocal的静态实例）。所以，在操作ThreadLocal时，这一共享环境会跨越多个开发层次而随处存在。 

2）随处存在的共享环境造成了所有的开发层次的共同依赖，从而使得所有的开发层次都耦合在了一起，从而变得无法独立测试。 

3）数据传递应该通过接口函数的签名显式声明，这样才能够从接口声明中表达接口所表达的真正含义。ThreadLocal模式位于实现的内部，从而使得接口与接口之间无法达成一致的声明契约。 

          Struts2的解耦合的设计理念使得Struts2的MVC实现成为了使用ThreadLocal模式的天然场所。在第三章中，我们已经介绍了一些基本概念，Struts2通过引入XWork框架，将整个Http请求的过程拆分成为与Web容器有关和与Web容器无关的两个执行阶段。而这两个阶段的数据交互就是通过ThreadLocal模式中的线程共享副本安全地进行。在其中，我们没有看到数据传递，存在的只是整个执行线程的数据共享。 

4.1.4 ThreadLocal模式的核心元素 

仔细分析上一节的示意图（图4-1），我们可以发现，要完成ThreadLocal模式，其中最关键的地方就是创建一个任何地方都可以访问到的ThreadLocal实例（也就是执行示意图中的菱形部分）。而这一点，我们可以通过类的静态实例变量来实现，这个用于承载静态实例变量的类就被视作是一个共享环境。我们来看一个例子，如代码清单4-4所示： 

            在这个Counter类中，我们实现了一个静态的ThreadLocal变量，并通过get方法将ThreadLocal中存储的值暴露出来。我们还封装了一个带有业务逻辑的方法getNextCounter，操作ThreadLocal中的值，将其加1，并返回计算后的值。 

                此时，Counter类就变成了一个数据共享环境，我们也拥有了实现ThreadLocal模式的关键要素。有了它，我们来编写一个简单的测试，如代码清单4-5所示： 

          这是一个简单的线程类，循环输出当前线程的名称和getNextCounter的结果，由于getNextCounter中的逻辑所操作的是ThreadLocal中的变量，所以无论同时有多少个线程在运行，返回的值将仅与当前线程的变量值有关，也就是说，在同一个线程中，变量值会被连续累加。这一点可以通过如下的测试代码证实： 

我们来运行一下上面的代码，并看看输出结果： 

上面的输出结果也证实了，counter的值在多线程环境中的访问是线程安全的。从对例子的分析中我们可以再次体会到，ThreadLocal模式最合适的使用场景：在同一个线程（Thread）的不同开发层次中共享数据。 

从上面的例子中，我们可以简单总结出实现ThreadLocal模式的两个主要步骤： 

1. 建立一个类，并在其中封装一个静态的ThreadLocal变量，使其成为一个共享数据环境。 

2. 在类中实现访问静态ThreadLocal变量的静态方法（设值和取值）。 

建立在ThreadLocal模式的实现步骤之上，ThreadLocal的使用则更加简单。在线程执行的任何地方，我们都可以通过访问共享数据类中所提供的ThreadLocal变量的设值和取值方法安全地获得当前线程中安全的变量值。 

这两个步骤，我们之后会在Struts2的实现中多次提及，读者只要能充分理解ThreadLocal处理多线程访问的基本原理，就能对Struts2的数据访问和数据共享的设计有一个整体的认识。 

讲到这里，我们回过头来看看ThreadLocal模式的引入，到底对我们的编程模型有什么重要的意义呢？ 

这一点，是由ThreadLocal模式的实现机理决定的。因为实现ThreadLocal模式的一个重要步骤，就是构建一个静态的共享存储空间。从而使得任何对象在任何时刻都可以安全地对数据进行访问。 

这一点是ThreadLocal模式给我们带来的最为核心的一个影响。因为在一般情况下，Java对象之间的协作关系，主要通过参数和返回值来进行消息传递，这也是对象协作之间的一个重要依赖。而ThreadLocal模式彻底打破了这种依赖关系，通过线程安全的共享对象来进行数据共享，可以有效避免在编程层次之间形成数据依赖。这也成为了XWork事件处理体系设计的核心。

 

 

Struts2的线程安全 
一般情况，我们的ActionContext都是通过：ActionContext context = (ActionContext) actionContext.get();来获取的。我们再来看看这里的actionContext对象的创建：

 

static ThreadLocal actionContext=new ActionContextThreadLocal();，        

 

     ActionContextThreadLocal是实现ThreadLocal的一个内部类。ThreadLocal可以命名为“线程局部变量”，它为每一个使用该变量的线程都提供一个变量值的副本，使每一个线程都可以独立地改变自己的副本，而不会和其它线程的副本冲突。这样，我们ActionContext里的属性只会在对应的当前请求线程中可见，从而保证它是线程安全的。 

       Struts2的action中就像一个POJO一样，定义了很多的类变量。此时，就使用scope=prototype来指定是个原型模式，而不是单例，这样就解决了线程安全问题。每个线程都是一个新的实例

 

           在Struts2.0中,Action已经与Servlet API完全分离,这使得Struts2.0的Action具有了更加灵活和低耦合的特性,与Struts1.0相比较而言是个巨大的进步。虽然 Struts2.0的Action已经与Servlet API完全分离，但我们在实现业务逻辑处理时经常需要访问Servlet中的对象，如Session、Application等。Struts2.0 提供了一个名字为ActionContext的类，在Action中可以通过该类获得Servlet API。
　　   ActionContext是一个Action的上下文对象，Action运行期间所用到的数据都保存在ActionContext中（如Session,客户端提交的参数等信息）。
　　在Action中可以通过下面的代码来创建和使用ActionContext类，关于该类的方法介绍如下所示：
ActionContext ac=ActionContext.getContext();

以下是ActionContext类的常用方法
１．Object get(Object key) ：通过参数key来查找当前ActionContext中的值
２．Map getApplication() ：返回一个Application级的Map对象
３．Static ActionContext getContext() ：获得当前线程的ActionContext对象
４．Map getParameters() ：返回一个包含所有HttpServletRequest参数信息的Map对象
５．Map getSession() ：返回一个Map类型的HttpSession对象
６．Void put(Object key,Object value) ：向当前ActionContext对象中存入名值对信息
７．Void setApplication(Map application) ：设置Application上下文
８．Void setSession(Map session) ：设置一个Map类型的Session值