线程安全问题的由来

在传统的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对象并不是一个线程安全的对象。


（题外话）此时还想到了面试经常谈起的HashMap和HashTable线程安全问题，在此也累赘的说上几句

HashMap是基于HashTable的一种Map实现，允许null values和null key（它跟HashTable的区别在于它是非同步的，而且允许null key和null values），HashMap不保证Map的顺序，甚至不能保证Map的顺序在运行过程中保持不变。


HashMap不是线程安全的

hastmap是一个接口是map接口的子接口，是将键映射到值的对象，其中键和值都是对象，并且不能包含重复键，但可以包含重复值。HashMap允许null key和null value，而hashtable不允许。


HashTable是线程安全的一个Collection。

HashMap是Hashtable的轻量级实现（非线程安全的实现），他们都完成了Map接口，主要区别在于HashMap允许空（null）键值（key）,由于非线程安全，效率上可能高于Hashtable。

HashMap允许将null作为一个entry的key或者value，而Hashtable不允许。

HashMap把Hashtable的contains方法去掉了，改成containsvalue和containsKey。因为contains方法容易让人引起误解。

Hashtable继承自Dictionary类，而HashMap是Java1.2引进的Map interface的一个实现。

最大的不同是，Hashtable的方法是Synchronize的，而HashMap不是，在多个线程访问Hashtable时，不需要自己为它的方法实现同步，而HashMap 就必须为之提供外同步。

Hashtable和HashMap采用的hash/rehash算法都大概一样，所以性能不会有很大的差异。

------------------------------------------------------继续上面的话题--------------------------------------------------

有关线程安全的概念范畴

概念：

如果你的代码所在的进程中有多个线程在同时运行，而这些线程可能会同时运行这段代码。如果每次运行结果和单线程运行的结果是一样的，而且其他的变量的值也和预期的是一样的，就是线程安全的。

线程安全问题都是由全局变量及静态变量引起的。若每个线程中对全局变量、静态变量只有读操作，而无写操作，一般来说，这个全局变量是线程安全的；若有多个线程同时执行写操作，一般都需要考虑线程同步，否则的话就可能影响线程安全。


线程安全，指的是在多线程环境下，一个类在执行某个方法时，对类的内部实例变量的访问是安全的。因此，对于下面列出来的2类变量，不存在任何线程安全的说法：

1）方法签名中的任何参数变量。

2）处于方法内部的局部变量。

　　任何针对上述形式的变量的访问都是线程安全的，因为他们都是处于方法的内部，由当前的执行线程独自管理。

这就是线程安全问题的由来：在传统的基于Servlet的开发模式中，Servlet对象内部的实例变量不是线程安全。在多线程环境中，这些变量的访问需要通过特殊的手段进行访问控制。

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

ThreadLocal

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

ThreadLocal本身并不是一个线程，而是通过操作当前线程中的一个内部变量来达到与其他线程隔离的目的。之所以取名为ThreadLocal，所期望表达的含义是其操作的对象是线程的一个本地变量。

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

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

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

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

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

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

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

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