现在的位置: 首页 > 综合 > 正文

JDK ThreadLocal分析:

2018年03月29日 ⁄ 综合 ⁄ 共 3720字 ⁄ 字号 评论关闭

早在Java
1.2推出之时,Java平台中就引入了一个新的支持:java.lang.ThreadLocal,给我们在编写多线程程序时提供了一种新的选择。使用
这个工具类可以很简洁地编写出优美的多线程程序,虽然ThreadLocal非常有用,但是似乎现在了解它、使用它的朋友还不多。

   ThreadLocal是什么

   ThreadLocal是什么呢?其实ThreadLocal并非是一个线程的本地实现版本,它并不是一个Thread,而是thread
local
variable(线程局部变量)。也许把它命名为ThreadLocalVar更加合适。线程局部变量(ThreadLocal)其实的功用非常简单,
就是为每一个使用该变量的线程都提供一个变量值的副本,是每一个线程都可以独立地改变自己的副本,而不会和其它线程的副本冲突。从线程的角度看,就好像每
一个线程都完全拥有该变量。线程局部变量并不是Java的新发明,在其它的一些语言编译器实现(如IBM XL
FORTRAN)中,它在语言的层次提供了直接的支持。因为Java中没有提供在语言层次的直接支持,而是提供了一个ThreadLocal的类来提供支
持,所以,在Java中编写线程局部变量的代码相对比较笨拙,这也许是线程局部变量没有在Java中得到很好的普及的一个原因吧。

   ThreadLocal的设计

   首先看看ThreadLocal的接口:

    Object get() ; // 返回当前线程的线程局部变量副本 protected Object initialValue(); // 返回该线程局部变量的当前线程的初始值
    void set(Object value); // 设置当前线程的线程局部变量副本的值

  
ThreadLocal有3个方法,其中值得注意的是initialValue(),该方法是一个protected的方法,显然是为了子类重写而特意实
现的。该方法返回当前线程在该线程局部变量的初始值,这个方法是一个延迟调用方法,在一个线程第1次调用get()或者set(Object)时才执行,
并且仅执行1次。ThreadLocal中的确实实现直接返回一个null:

  protected Object initialValue() { return null; }

  ThreadLocal是如何做到为每一个线程维护变量的副本的呢?其实实现的思路很简单,在ThreadLocal类中有一个Map,用于存储每一个线程的变量的副本。比如下面的示例实现:

  public class ThreadLocal
  {
   private Map values = Collections.synchronizedMap(new HashMap());
   public Object get()
   {
   Thread curThread = Thread.currentThread();
   Object o = values.get(curThread);
   if (o == null && !values.containsKey(curThread))
   {
    o = initialValue();
    values.put(curThread, o);
   }
   return o;
   }

   public void set(Object newValue)
   {
   values.put(Thread.currentThread(), newValue);
   }

   public Object initialValue()
   {
   return null;
   }
  }

  当然,这并不是一个工业强度的实现,但JDK中的ThreadLocal的实现总体思路也类似于此。

   ThreadLocal的使用

   如果希望线程局部变量初始化其它值,那么需要自己实现ThreadLocal的子类并重写该方法,通常使用一个内部匿名类对ThreadLocal进行子类化,比如下面的例子,SerialNum类为每一个类分配一个序号:

  public class SerialNum
  {
   // The next serial number to be assigned

   private static int nextSerialNum = 0;
   private static ThreadLocal serialNum = new ThreadLocal()
   {
   protected synchronized Object initialValue()
   {
    return new Integer(nextSerialNum++);
   }
   };

   public static int get()
   {
   return ((Integer) (serialNum.get())).intValue();
   }
  }

  SerialNum类的使用将非常地简单,因为get()方法是static的,所以在需要获取当前线程的序号时,简单地调用:

  int serial = SerialNum.get();

  即可。

   在线程是活动的并且ThreadLocal对象是可访问的时,该线程就持有一个到该线程局部变量副本的隐含引用,当该线程运行结束后,该线程拥有的所以线程局部变量的副本都将失效,并等待垃圾收集器收集。

   ThreadLocal与其它同步机制的比较

  
ThreadLocal和其它同步机制相比有什么优势呢?ThreadLocal和其它所有的同步机制都是为了解决多线程中的对同一变量的访问冲突,在普
通的同步机制中,是通过对象加锁来实现多个线程对同一变量的安全访问的。这时该变量是多个线程共享的,使用这种同步机制需要很细致地分析在什么时候对变量
进行读写,什么时候需要锁定某个对象,什么时候释放该对象的锁等等很多。所有这些都是因为多个线程共享了资源造成的。ThreadLocal就从另一个角
度来解决多线程的并发访问,ThreadLocal会为每一个线程维护一个和该线程绑定的变量的副本,从而隔离了多个线程的数据,每一个线程都拥有自己的
变量副本,从而也就没有必要对该变量进行同步了。ThreadLocal提供了线程安全的共享对象,在编写多线程代码时,可以把不安全的整个变量封装进
ThreadLocal,或者把该对象的特定于线程的状态封装进ThreadLocal。

   由于ThreadLocal中可以持有任何类型的对象,所以使用ThreadLocal
get当前线程的值是需要进行强制类型转换。但随着新的Java版本(1.5)将模版的引入,新的支持模版参数的ThreadLocal类将从中受益。也
可以减少强制类型转换,并将一些错误检查提前到了编译期,将一定程度地简化ThreadLocal的使用。

   总结

  
当然ThreadLocal并不能替代同步机制,两者面向的问题领域不同。同步机制是为了同步多个线程对相同资源的并发访问,是为了多个线程之间进行通信
的有效方式;而ThreadLocal是隔离多个线程的数据共享,从根本上就不在多个线程之间共享资源(变量),这样当然不需要对多个线程进行同步了。所
以,如果你需要进行多个线程之间进行通信,则使用同步机制;如果需要隔离多个线程之间的共享冲突,可以使用ThreadLocal,这将极大地简化你的程
序,使程序更加易读、简洁。

令附:

hreadLocal, 我到目前还没正式用过这个东西,因为他更多的是被应用于基础架构的编写,在我理解看来, ThreadLocal就是存放Context的地方,这个地方只能是当前的Thread才能访问,他的生命周期是到这个Thread完毕.

文章[1]中的一段说明,我觉得说的很清楚:

So what's the difference between a thread-local variable and a
normal variable? When a thread accesses a thread-local variable it has
its own independently initialized copy of the variable. Each thread
holds an implicit reference to its copy as long as the thread is alive.
So when the thread goes away, all of its thread-local instances are
subject to gc.

You typically use an anonymous inner class to provide an initial
value (if any) using an appropriate constructor and return the newly
constructed object.

You can use this ThreadLocal in several situations:

To keep state with a thread (user-id, transaction-id, logging-id)

To cache objects which you need frequently

但是,同时你也要注意Context的cleanup,要不然,他就会变成evil.[2]

抱歉!评论已关闭.