(转载)Threadlocal的几种误区（尤为线程池中使用时注意）

最近因为须要用到ThreadLocal，在网上搜索了一些相关资料，发现对ThreadLocal常常会有下面几种误解

 1、ThreadLocal是java线程的一个实现
      ThreadLocal的确是和java线程有关，不过它并非java线程的一个实现，它只是用来维护本地变量。针对每一个线程，提供本身的变量版本，主要是为了不线程冲突，每一个线程维护本身的版本。彼此独立，修改不会影响到对方。

 2、ThreadLocal是相对于每一个session的

        ThreadLocal顾名思义，是针对线程。在java web编程上，每一个用户从开始到会话结束，都有本身的一个session标识。可是ThreadLocal并非在会话层上。其实，Threadlocal是独立于用户session的。它是一种服务器端行为，当服务器每生成一个新的线程时，就会维护本身的ThreadLocal。对于这个误解，我的认为应该是开发人员在本地基于一些应用服务器测试的结果。众所周知，通常的应用服务器都会维护一套线程池，也就是说，对于每次访问，并不必定就新生成一个线程。而是本身有一个线程缓存池。对于访问，先从缓存池里面找到已有的线程，若是已经用光，才去新生成新的线程。因此，因为开发人员本身在测试时，通常只有他本身在测，这样服务器的负担很小，这样致使每次访问多是共用一样一个线程，致使会有这样的误解：每一个session有一个ThreadLocal

 3、ThreadLocal是相对于每一个线程的，用户每次访问会有新的ThreadLocal

  理论上来讲，ThreadLocal是的确是相对于每一个线程，每一个线程会有本身的ThreadLocal。可是上面已经讲到，通常的应用服务器都会维护一套线程池。所以，不一样用户访问，可能会接受到一样的线程。所以，在作基于TheadLocal时，须要谨慎，避免出现ThreadLocal变量的缓存，致使其余线程访问到本线程变量

 4、对每一个用户访问，ThreadLocal能够多用
        能够说，ThreadLocal是一把双刃剑，用得来的话能够起到很是好的效果。可是，ThreadLocal若是用得很差，就会跟全局变量同样。代码不能重用，不能独立测试。由于，一些原本能够重用的类，如今依赖于ThreadLocal变量。若是在其余没有ThreadLocal场合，这些类就变得不可用了。我的以为ThreadLocal用得很好的几个应用场合，值得参考

  一、存放当前session用户：quake want的jert

  二、存放一些context变量，好比webwork的ActionContext

  三、存放session，好比Spring hibernate orm的session