ThreadLocal 与 Request 和 Session 之关联

转载：

最近看了robbin的《Web并发模型粗浅探讨V3.pptx》 介绍了当前各种技术关于并发处理的解决方案的优缺点，就我的角度实际上讲得是Request与进程、线程、纤程（具体是与那个需要看具体技术）之间的关系。一下子想起了前一阵子自己关于Request与Thread的关系问题，恰好在iteye里搜到一个人与我有同样的困惑 是否每一个Request都由一个不同的Thread来处理 看看评论好像没有给出详细的解释。

于是今天自己试验了一下，对该问题我自己的解释如下：

 

今天下午在我自己机子的Tomcat5.5.36下测试了一下，在Tomcat的默认配置下：一个Request对应一个Thread，但一个Thread一般会处理多个Request。
如何解释这个现象？我认为一般一个Request对象在JVM中的存活时间很短，几秒差不多了，很少有几十秒的情况。而web服务器中的线程对象在JVM中的存活时间很长，即便因为操作系统的调度会将该线程对象从running变成waiting，但目前各个商用服务器的策略是维护一个线程池，一段时间之后该线程对象还会变成waiting。
从物理时间上来说Thread生命周期远远大于Request。但从一个时间点上来看，假如一个Thread正在处理一个Request，那么该Thread不会同时还处理别的Request，即Request在Thread的生命周期内是一个一个串行执行的。

具体到ThreadLocal的使用情况来说：
我们一般使用ThreadLocal的模式是将该ThreadLocal对象作为一个类的静态变量（解决同一线程跨类跨方法访问的问题），先Set再Get，以两个Request与Thread的不同关系来说。假如这两个Request属于两个Thread则不存在问题，假如两个Request属于一个Thread，那么Request A在执行过程中先Set一个值，后再Get的是自己Set的值。Request B在执行过程中先Set一个值，此时Set的值将覆盖之前Request A已经Set的值（因为ThreadLocal的机制是在每一个线程内部以TheadLocal对象作为Key来存值，现在key没变，又塞了一个新值，所以会覆盖旧值），后Get的将是Request B的值。