Struts2中的设计模式----ThreadLocal模式续

                              本文主要整理自----《Struts2技术内幕》      陆舟 著

　　ThreadLocal模式的应用场景

　　

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

                                              

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

　　数据共享，还是数据传递

　　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模式中的线程共享副本安全地进行。在其中，我们没有看到数据传递，存在的只是整个执行线程的数据共享。

 　　ThreadLocal模式的核心元素

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

public class Counter {
    //新建一个静态的ThreadLocal变量，并通过get方法将其变为一个可访问的对象 
    private static ThreadLocal<Integer> counterContext = new ThreadLocal<Integer>(){
        protected synchronized Integer initialValue(){
            return 10;
        }
    };
    // 通过静态的get方法访问ThreadLocal中存储的值
    public static Integer get(){
        return counterContext.get();
    }
    // 通过静态的set方法将变量值设置到ThreadLocal中
    public static void set(Integer value) {  
        counterContext.set(value);  
    } 
    // 封装业务逻辑，操作存储于ThreadLocal中的变量  
    public static Integer getNextCounter() {  
        counterContext.set(counterContext.get() + 1);  
        return counterContext.get();  
    }  
}

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

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

public class ThreadLocalTest extends Thread {
    public void run(){
        for(int i = 0; i < 3; i++){  
            System.out.println("Thread[" + Thread.currentThread().getName() + "],counter=" + Counter.getNextCounter());  
        }  
    }
}

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

 

public class Test {
    public static void main(String[] args) {
        ThreadLocalTest testThread1 = new ThreadLocalTest();  
        ThreadLocalTest testThread2 = new ThreadLocalTest();  
        ThreadLocalTest testThread3 = new ThreadLocalTest();  
        testThread1.start();  
        testThread2.start();  
        testThread3.start();
    }
}

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

　　Thread[Thread-2],counter=11
　　Thread[Thread-2],counter=12
　　Thread[Thread-2],counter=13
　　Thread[Thread-0],counter=11
　　Thread[Thread-0],counter=12
　　Thread[Thread-0],counter=13
　　Thread[Thread-1],counter=11
　　Thread[Thread-1],counter=12
　　Thread[Thread-1],counter=13

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

　　从上面的例子中，我们可以简单总结出实现ThreadLocal模式的两个主要步骤：
　　1. 建立一个类，并在其中封装一个静态的ThreadLocal变量，使其成为一个共享数据环境。
　　2. 在类中实现访问静态ThreadLocal变量的静态方法（设值和取值）。

　　建立在ThreadLocal模式的实现步骤之上，ThreadLocal的使用则更加简单。在线程执行的任何地方，我们都可以通过访问共享数据类中所提供的ThreadLocal变量的设值和取值方法安全地获得当前线程中安全的变量值。
　　这两个步骤，我们之后会在Struts2的实现中多次提及，读者只要能充分理解ThreadLocal处理多线程访问的基本原理，就能对Struts2的数据访问和数据共享的设计有一个整体的认识。

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

　　结论 ：使用ThreadLocal模式，可以使得数据在不同的编程层次得到有效地共享。

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

　　结论 使用ThreadLocal模式，可以对执行逻辑与执行数据进行有效解耦。

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

  

　　----完----