多线程

一、使用JDK提供的线程池一般分为3步：

1.创建线程目标对象，可以是不同的，例如程序中的Runner;
2.使用Executors创建线程池，返回一个ExecutorService类型的对象；
3.使用线程池执行线程目标对象，exec.execute(run),最后，结束线程池中的线程，exec.shutdown();
参考：http://blog.sina.com.cn/s/blog_70bcd7c10101a24p.html

二、Servlet的线程安全性

Servlet的线程安全问题只有在大量的并发访问时才会显现出来，并且很难发现，因此在编写Servlet程序时要特别注意。线程安全问题主要是由实例变量造成的，因此在Servlet中应避免使用实例变量。如果应用程序设计无法避免使用实例变量，那么使用同步来保护要使用的实例变量，但为保证系统的最佳性能，应该同步可用性最小的代码路径。

三、活性

并发应用程序按照及时方式执行的能力称为活性（liveness）[2]。一般包括三种类型的问题死锁、饿死和活锁。
1.死锁
两个朋友可能同时向对方鞠躬，当朋友A和朋友B同时向对方鞠躬时，都在等待对方起身，进入阻塞状态。发生线程死锁。
2.饿死
饿死（starvation）描述这样的情况：一个线程不能获得对共享资源的常规访问，并且不能继续工作，当共享资源被贪婪线程长期占有而不可用时，就会发生这样的情况。
3.活锁
活锁可以比喻为两人在走廊中相遇。A避让的自己的左边让B通过，而B同时避让到自己的右边让A通过。发现他们仍然挡住了对方，A就避让到自己的右边，而B同时避让到了自己的左边，他们还是挡住了对方，所以就没完没了。

四、ThreadLocal变量

ThreadLocal和线程同步机制相比有什么优势呢？
ThreadLocal和线程同步机制都是为了解决多线程中相同变量的访问冲突问题。
在同步机制中，通过对象的锁机制保证同一时间只有一个线程访问变量。这时该变量是多个线程共享的，使用同步机制要求程序慎密地分析什么时候对变量进行读写，什么时候需要锁定某个对象，什么时候释放对象锁等繁杂的问题，程序设计和编写难度相对较大。
而ThreadLocal则从另一个角度来解决多线程的并发访问。ThreadLocal会为每一个线程提供一个独立的变量副本，从而隔离了多个线程对数据的访问冲突。因为每一个线程都拥有自己的变量副本，从而也就没有必要对该变量进行同步了。ThreadLocal提供了线程安全的共享对象，在编写多线程代码时，可以把不安全的变量封装进ThreadLocal。
概括起来说，对于多线程资源共享的问题，同步机制采用了“以时间换空间”的方式，而ThreadLocal采用了“以空间换时间”的方式。前者仅提供一份变量，让不同的线程排队访问，而后者为每一个线程都提供了一份变量，因此可以同时访问而互不影响。
需要注意的是ThreadLocal对象是一个本质上存在风险的工具，应该在完全理解将要使用的线程模型之后，再去使用ThreadLocal对象。这就引出了线程池（thread pooling）的问题，线程池是一种线程重用技术，有了线程池就不必为每个任务创建新的线程，一个线程可能会多次使用，用于这种环境的任何ThreadLocal对象包含的都是最后使用该线程的代码所设置的状态，而不是在开始执行新线程时所具有的未被初始化的状态。