前言

　　如果开发者正开发或维护基于Servlet的Web应用，则Servlet规范建议最好能够看看。因为它含有的内容对于Web应用开发者理解Servlet容器的工作机理很有帮助。

　　其中，规范给出了Servlet容器是如何处理客户请求的。Servlet容器将会根据web.xml配置文件中定义的各个Servet而创建相应的单例。因此，多个客户请求可能同时访问这些单例，即多个线程同时访问它们。在Web应用中保证线程安全是很重要的。开发者应该对这个问题保持警惕，而且必须确保各自的代码必须以线程安全的方式运行。

　　温习线程安全

　　大部分Java开发者都应该听过synchronized关键字。在不采用任何第三方库的前提下，Java本身对线程提供了原生支持，而且synchronized关键字往往是Java应用中实现线程安全最重要的因素。Java中的同步提供了互斥支持。通过同步一块代码或整个方法能够保证同时最多只有单个线程执行它，从而实现了线程安全。引入同步具有副作用，即阻塞。比如，大公司或律师办公室的前台小姐同时需要处理电话、邮件、受访客户等等。这使得她的工作很繁忙，而且导致一些事情不能够及时处理。

　　在Web应用中需要警惕阻塞。受同步保护的代码块使得其同时处理客户请求的吞吐量降低，而且很多客户处于阻塞状态，除非某客户处理完成。而且互斥不仅会带来阻塞，还会带来死锁。通常，死锁是不可恢复的。如下条件将触发死锁的发生：线程A锁住了线程B等待的资源，而且线程B锁住了线程A等待的资源，即线程B一直在等待线程A释放锁，线程A也是如此。因此，对于多线程的应用而言，死锁的预防和处理通常都是很头疼的。

　　另外，synchronized关键字还使得大量的同步对象到处使用，从而引入了死锁的可能性。比如，java.util.Hashtable和java.util.Vector中提供的方法都是受互斥保护的，因此除非确实需要使用它们，否则尽量不用。开发者只需要使用java.util.HashMap和java.util.ArrayList即可。当然，java.util.Collections中的同步方法也使用了synchronized关键字。

　　尽管可重入更易于管理，但它引入了其他问题。可重入代码避免了线程间数据的共享。考虑如下代码（姑且认为Java中的方法是线程安全的）：

　　public Double pi() {
　　int a = 22;
　　int b = 7;
　　return new Double(a / b);
　　}

　　不管同时进入该方法的线程有多少，它总是线程安全的。各个线程都维护了属于各个线程的栈，并不同其他线程共享。其中，各个线程在当前方法（包括静态方法）中创建的方法变量仅属于当前线程，即存储在当前线程的栈中。因此，当线程A和B同时进入上述方法时，它们都将创建a和b。由于上述方法不存在数据共享，因此上述方法是线程安全的。请注意：22/7值同PI值较接近，但它们不相等。

　　接下来，看看如何优化上述代码吧。

　　private Double pi = null;

　　public Double pi() {
　　if (pi == null) {
　　pi = new Double(22 / 7);
　　}

　　return pi;
　　}

　　尽管改进后的方法能够提高性能，但并不是线程安全的。比如：如果pi为null，而且线程A和B同时进入第4行。因此，线程A和B会同时测试pi是否为空，它们都将返回true。接下来，如果线程A继续执行（线程B由于某种原因被暂挂），然后返回对内存地址的引用。其中，该内存地址含有22/7的结果，即pi值。最后，线程A退出方法。当线程B再次进入第5行时，新的内存地址将覆盖原先的内存地址（线程A提供的）。这太危险了，而且这种问题往往难于调试。

　　如果使用ThreadLocal，则不仅能够保证pi()方法是线程安全，而且能够提供性能的改善。 private static ThreadLocal pi = new ThreadLocal();

　　public Double pi() {
　　if (pi.get() == null) {
　　pi.set(new Double(22 / 7));
　　}
　　return (Double)pi.get();
　　}


　　ThreadLocal类能够包裹任何对象，而且能够将对象绑定到当前线程，使得它仅仅供当前线程使用。当线程初次执行pi()方法时，由于没有对象绑定到ThreadLocal实例pi上，因此get()方法返回null。借助于set()方法能够将对象绑定到当前线程，而且不供其它线程使用。因此，如果不同线程需要经常访问pi()方法，则借助于ThreadLocal不仅能够保证线程安全，而且能够提高性能。

　　目前，存在很多关于如何使用ThreadLocal的资源。在Java 1.4之前，ThreadLocal的性能确实很差，但是现已解决了这个问题。另外，由于对ThreadLocal的错误理解，使得很多开发者对它的误用。注意，上述实例使用ThreadLocal的方式是绝对没问题的。在引入ThreadLocal后，上述方法的行为并未发生改变，但是方法已经是线程安全的了。

　　通过可重入的方式开发线程安全的代码要求开发者谨慎使用实例变量或静态变量，尤其对于修改那些其

JavaBean实现多文件上传 基于Java的解释器设计模式