是否每一个Request都由一个不同的Thread来处理

关于Request和Thread的关系一直有一个疑问，一般的理解就是对应每一个Request会有一个Thread来处理，问题是每一个Request是否对应的Thread是否一样，如果是一样，那么程序中在用到ThreadLocal的时候，Thread.currentThread岂不是相同，如果不一样，web 服务器是怎样做到保证用不同的Thread来处理不同的Request？

为了减少这种创建和销毁Thread的开销，一般的Web服务器在内部都有一个线程池来维护所创建的Thread，并有一个限定值控制线程池中Thread的总量。如果服务器所接受的Request数量超过线程池中Thread限制，就一部分Request处于等待状态，直到有空闲Thread才开始处理。

现在假设有一个类维护一个ThreadLocal的静态变量，每一次请求时候，都会调用ThreadLocal.get()/set() 操作, 大家都知道这些操作实际上是以Thread.currentThread为Key，取得一个对象的，问题的关键就在这里，如果每一个Request对应的Thread是一样，那么这个地方返回的对象就会是一样的，是否就混乱了呢？

现在有一个系统部署在WebLogic10下面，在第一次打开一个页面的时候，会有一个Thread被创建来处理该请求，再次打开其他页面时候，系统并不一定会创建一个新的Thread来处理，两次请求的Thread是相同的，再打开多个其他页面（超过10个），在这10多次的请求中，系统只会创建4个Thread来处理，那就是说这10多次的请求中，有一部分请求是使用相同的Thread来处理的。如果是这样的情况，上面的问题该如何解释呢？

我想Tomcat， Jboss在处理Request和Thread的时候和WebLogic应该大同小异，那么上面的问题该如何解释呢？

评论

4 楼 Tyrion 2012-12-14  

remoteJavaSky 写道

我现在想想，是否是这样的，再每处理完一个request后，通常会清理掉ThreadLocal的变量，这通常会使用Filter来清理。也见到过这样做的，只是具体的原理还不是特别清楚

今天针对这个问题自己在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的值。

这样的话楼主应该解释了楼主的疑问了。

3 楼 remoteJavaSky 2012-12-13  

我现在想想，是否是这样的，再每处理完一个request后，通常会清理掉ThreadLocal的变量，这通常会使用Filter来清理。也见到过这样做的，只是具体的原理还不是特别清楚

2 楼 Tyrion 2012-12-13  

remoteJavaSky 写道

Hi 我现在活着已经有一段时间了，纠结此问题呢，你现在该找到答案了吧，分享下吧，我都被这个问题闷死了

同求该问题的答案。。。

1 楼 remoteJavaSky 2011-08-22  

Hi 我现在活着已经有一段时间了，纠结此问题呢，你现在该找到答案了吧，分享下吧，我都被这个问题闷死了