ThreadLocal的一次深入学习

ThreadLocal是什么

       ThreadLocal是什么？有些小伙伴喜欢把它和线程同步机制混为一谈，事实上ThreadLocal与线程同步无关。ThreadLocal虽然提供了一种解决多线程环境下成员变量的问题，但是它并不是解决多线程共享变量的问题。我们看下官方API对ThreadLocal的定义：

写道

This class provides thread-local variables. These variables differ from their normal counterparts in that each thread that accesses one (via its {@code get} or {@code set} method) has its own, independently initialized copy of the variable. {@code ThreadLocal} instances are typically private static fields in classes that wish to associate state with a thread (e.g.,a user ID or Transaction ID).

 

       中文的意思是：该类提供了线程局部 (thread-local) 变量。这些变量不同于它们的普通对应物，因为访问某个变量（通过其 get 或 set 方法）的每个线程都有自己的局部变量，它独立于变量的初始化副本。 ThreadLocal实例通常是类中的 private static 字段，它们希望将状态与某一个线程（例如，用户 ID 或事务 ID）相关联。

       所以ThreadLocal与线程同步机制不同，线程同步机制是多个线程共享同一个变量，而ThreadLocal是为每一个线程创建一个单独的变量副本，故而每个线程都可以独立地改变自己所拥有的变量副本，而不会影响其他线程所对应的副本。可以说ThreadLocal为多线程环境下变量问题提供了另外一种解决思路。

       ThreadLocal定义了四个方法：

• get()：返回此线程局部变量的当前线程副本中的值。
• initialValue()：返回此线程局部变量的当前线程的“初始值”。
• remove()：移除此线程局部变量当前线程的值。
• set(T value)：将此线程局部变量的当前线程副本中的值设置为指定值。

       除了这四个方法，ThreadLocal内部还有一个静态内部类ThreadLocalMap，该内部类才是实现线程隔离机制的关键，get()、set()、remove()都是基于该内部类操作。ThreadLocalMap提供了一种用键值对方式存储每一个线程的变量副本的方法，key为当前ThreadLocal对象，value则是对应线程的变量副本。

       对于ThreadLocal需要注意的有两点：

• ThreadLocal实例本身是不存储值，它只是提供了一个在当前线程中找到副本值得key。
• ThreadLocal是包含在Thread中的，而不是Thread包含在ThreadLocal中。

      下图是Thread、ThreadLocal、ThreadLocalMap的关系：

 

 

ThreadLocal使用示例

       我们的示例是为了证明ThreadLocal能够保证线程隔离及变量安全，先来看第一个示例。先提供一个基类，用于这两种实现方式的继承。

 

public abstract class SeqCount {
  protected abstract String invoke();

  protected abstract int nextSeq();
}

 

定义一个多线程的类

 

public class SeqThread extends Thread{
  private SeqCount seqCount;

  public SeqThread (SeqCount seqCount){
    this.seqCount = seqCount;
  }

  public void run() {
    for (int i=0; i<3;i++) {
      System.out.println("threadName：" + Thread.currentThread().getName() + ", seqCount :" + seqCount.nextSeq());
    }
  }
}

 

第一种方式直接用Integer类型，示例代码如下：

 

public class IntegerSeqCount extends SeqCount{
  private ThreadLocal<Integer> seqCount = ThreadLocal.withInitial(() -> 0);

  @Override
  protected int nextSeq() {
    seqCount.set(seqCount.get() + 1);
    return seqCount.get();
  }

  @Override
  protected String invoke() {
    return "IntegerSeqCount";
  }
}

 

测试类

 

public class ThreadLocalMain {
  public static void main(String[] args) {
    SeqCount integerSeqCount = new IntegerSeqCount();
    SeqThread intSeqThread1 = new SeqThread(integerSeqCount);
    SeqThread intSeqThread2 = new SeqThread(integerSeqCount);
    SeqThread intSeqThread3 = new SeqThread(integerSeqCount);
    SeqThread intSeqThread4 = new SeqThread(integerSeqCount);

    System.out.println(integerSeqCount.invoke() + " executing");

    intSeqThread1.start();
    intSeqThread2.start();
    intSeqThread3.start();
    intSeqThread4.start();
  }
}

 

执行结果：

 

       从运行结果可以看出，ThreadLocal确实是可以达到线程隔离机制，确保变量的安全性。但是，这个示例真的能说明ThreadLocal保证线程隔离，变量安全么？

       我们将第一个示例做些调整，如下所示：

 

public class IntegerCount {
  private Integer number = 0;

  public Integer getNumber() {
    return number;
  }

  public void setNumber(final Integer number) {
    this.number = number;
  }
}

 

public class ObjectSeqCount extends SeqCount{
  private static IntegerCount integerCount = new IntegerCount();

  private static final ThreadLocal<IntegerCount> seqCount = ThreadLocal.withInitial(() -> integerCount);

  @Override
  protected String invoke() {
    return "ObjectSeqCount";
  }

  @Override
  protected int nextSeq() {
    IntegerCount integerCount = seqCount.get();
    return integerCount.getNumber() + 1;
  }
}

 

将测试类ThreadLocalMain做些调整，如下所示：

 

public class ThreadLocalMain {
  public static void main(String[] args) {
    SeqCount objectSeqCount = new ObjectSeqCount();
    SeqThread objSeqThread1 = new SeqThread(objectSeqCount);
    SeqThread objSeqThread2 = new SeqThread(objectSeqCount);
    SeqThread objSeqThread3 = new SeqThread(objectSeqCount);
    SeqThread objSeqThread4 = new SeqThread(objectSeqCount);

    System.out.println(objectSeqCount.invoke() + " executing");

    objSeqThread1.start();
    objSeqThread2.start();
    objSeqThread3.start();
    objSeqThread4.start();
  }
}

 

执行结果如下：

 

       很显然，在这里，并没有通过ThreadLocal达到线程隔离的机制，可是ThreadLocal不是保证线程安全的么？这会让很多小伙伴产生了疑惑。

       这里有个需要说明的地方，虽然，ThreadLocal让访问某个变量的线程都拥有自己的局部变量，但是如果这个局部变量都指向同一个对象呢，这个时候ThreadLocal就失效了。

       怎么理解这句话呢，可以看看上面的代码，ObjectSeqCount，这个类里面定义了一个成员变量integerCount，threadLocal在初始化时返回的都是同一个对象integerCount。下面我们从ThreadLocal的源码分析下这个事情。 

ThreadLocal源码分析

1. set源码

 

 

 

       set方法的实现源码中，set需要首先获得当前线程对象Thread；然后取出当前线程对象的成员变量ThreadLocalMap；如果ThreadLocalMap存在，那么进行KEY/VALUE设置，KEY就是ThreadLocal；如果ThreadLocalMap没有，那么创建一个。说白了，当前线程中存在一个Map变量，KEY是ThreadLocal，VALUE是你设置的值。

 

2. get

 

 

       get方法实现的源码中，其实揭示了ThreadLocalMap里面的数据存储结构，从上面的代码来看，ThreadLocalMap中存放的就是Entry，Entry的KEY就是ThreadLocal，VALUE就是值。而从Entry的源码，我们发现了弱引用（WeakReference）。那么，什么是弱引用，我们这里用一个图简单的说明下：

       

       在JAVA里面，存在强引用、弱引用、软引用、虚引用。至于这四个引用的概念，有兴趣的小伙伴，可以自己去查阅资料。这里，我们根据弱引用，可以想到一个问题：ThreadLocal使用到了弱引用，是否意味着不会存在内存泄露呢？

       首先来说，如果把ThreadLocal置为null，那么意味着Heap中的ThreadLocal实例不在有强引用指向，只有弱引用存在，因此GC是可以回收这部分空间的，也就是key是可以回收的。但是value却存在一条从Current Thread过来的强引用链。因此只有当Current Thread销毁时，value才能得到释放。因此，只要这个线程对象被gc回收，就不会出现内存泄露，但在threadLocal设为null和线程结束这段时间内不会被回收的，就发生了我们认为的内存泄露。最要命的是线程对象不被回收的情况，比如使用线程池的时候，线程结束是不会销毁的，再次使用的，就可能出现内存泄露。

      那么如何有效的避免内存溢出呢？事实上，在ThreadLocalMap中的set/getEntry方法中，会对key为null（也即是ThreadLocal为null）进行判断，如果为null的话，那么是会对value置为null的。我们也可以通过调用ThreadLocal的remove方法进行释放！