打怪升级系列之ThreadLocal

ThreadLocal

定义

• 网上很多说ThreadLocal是处理并发多线程的，根据官方定义：

This class provides thread-local variables. These variables differ from their normal counterparts in that each thread that accesses one (via its get or set method) has its own, independently initialized copy of the variable. 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).
For example, the class below generates unique identifiers local to each thread. A thread’s id is assigned the first time it invokes ThreadId.get() and remains unchanged on subsequent calls

• 简单的说ThreadLocal是个线程局部变量，每个线程都保持有这个变量的副本，在线程的各个方法调用之间传递数据，重要的事情说三遍传递数据、传递数据、传递数据，下面就从几个常用的方式来说明ThreadLocal在日常编程中的使用和常见的哪些坑

基本使用

• 线程方法之间传递数据，下面例子中的两个线程中的每个方法中获取的ThreadLocal的值都是一样的
  

Thread-0 m1 threadLocal value = 1
Thread-1 m1 threadLocal value = 1
Thread-0 m2 threadLocal value = 1
Thread-1 m2 threadLocal value = 1

• 两个线程中执行m1和m2，ThreadLocal的值都是一样的，说明确实可以在方法中间传递数据

坑一、格式化时间问题

• 通过SimpleDateFormat在并发访问格式化时间的时候会出现时间错乱，因为SimpleDateFormat方法不是线程安全的。解决方法可以通过ThreadLocal保存副本，每个线程之间变量隔离，也可以采用java8的DateTimeFormatter来格式化时间
• 下面这段代码执行两次，一次是执行SimpleDateFormat来格式化时间，另外一次是通过把SimpleDateFormat放在ThreadLocal来执行结果如何？？

public class ThreadLocalFormatDemo {
     

    private static SimpleDateFormat format = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");

    private final static ThreadLocal<SimpleDateFormat> THREAD_LOCAL =
            ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"));

    public static void main(String[] args) {
     
        for (int i = 0; i < 100; i++) {
     
            // 多线程时间格式化问题
            /*new Thread(()->{
                try {
                    Date date = new Date();
                    String dateStr1 = ThreadLocalFormatDemo.format.format(date);
                    Date date1 = format.parse(dateStr1);
                    String dateStr2 = ThreadLocalFormatDemo.format.format(date1);
                    System.out.println(dateStr1.equals(dateStr2));
                } catch (ParseException e) {
                    e.printStackTrace();
                }
            }).start();*/
            // 多线程ThreadLocal 避免时间格式化的问题
            new Thread(()->{
     
                try {
     
                    Date date = new Date();
                    String dateStr1 = ThreadLocalFormatDemo.THREAD_LOCAL.get().format(date);
                    Date date1 = THREAD_LOCAL.get().parse(dateStr1);
                    String dateStr2 = ThreadLocalFormatDemo.THREAD_LOCAL.get().format(date1);
                    System.out.println(dateStr1.equals(dateStr2));
                } catch (ParseException e) {
     
                    e.printStackTrace();
                }
            }).start();
        }
    }
}

• 图片左边是SimpleDateFormat结果，出现false说明时间出现不一致，右边是ThreadLocal，返回的都是true，结果符合预期，可以看出右边的明显是线程安全的
• java8 中的代码注解，看得出来类是线程安全的，建议使用

/**...
 * @implSpec
 * This class is immutable and thread-safe.
 *
 * @since 1.8
 */
public final class DateTimeFormatter {
     

坑二、内存泄漏

• Thread中TheadLocal的定义为：ThreadLocal.ThreadLocalMap threadLocals = null;，说明在Thread中初始化后真正保存的是ThreadLocal.ThreadLocalMap，也就是一个Map，该Map中的key指向的是代码中自己定义的ThreadLocal静态变量，关键是这个引用是一个弱引用，而弱引用在发生GC的时候会被清理掉(画外音：强引用，软引用，弱引用…可以自行查阅)，那么如果key的引用在GC被清理掉的话而此时调用的线程没有停止或者是线程池，会出现线程引用了该Map而Map中的key的引用已经被GC掉，根据GC Root原则由于Map被Thread引用不会被清理掉，也就是说，如果Thread一直存在，而且ThreadLocalMap中可以set值，最终可能导致内存泄漏(画外音：个人见解)。直接上代码
• 执行代码如下：

public class ThreadlocalLeakDemo {
     
private static ThreadLocal<List<String>> listThreadLocal =
         ThreadLocal.withInitial(ArrayList::new);
 /**
  * 一个线程不停胡添加数据，后台打开jvisualvm执行gc，查看内存是否有内存泄漏风险
  * @param args
  */
 public static void main(String[] args) throws InterruptedException {
     
     new Thread(()->{
     
         for (int j = 0; j < Integer.MAX_VALUE; j++) {
     
             try {
     
                 listThreadLocal.get().add("我是ThreadLocal变量，查看在GC之后是否存在内存泄漏的风险" + j);
                 TimeUnit.MILLISECONDS.sleep(3L);
                 if (j == 20000) {
     
                     System.out.printf("j = %d,执行60秒之后退出循环\n", j);
                     // 第一次手动执行gc并执行dump操作
                     TimeUnit.SECONDS.sleep(60L);
                     System.out.println("退出循环");
                     // 打印上述日志之后第二次执行gc并执行dump操作
                     break;
                 }
             } catch (InterruptedException e) {
     
                 e.printStackTrace();
             }
         }
     },"threadlocal").start();
     System.out.println("main 等待中...");
     TimeUnit.SECONDS.sleep(Long.MAX_VALUE);
 }
}

• 根据上述的代码执行之后截取两次的dump如下图，可以明显的看出来在线程退出之前即使执行GC还是有对象(读者可以在自己的机器执行，在没有执行上述代码的System.out.printf("j = %d,执行60秒之后退出循环\n", j);之前)增加，而在Thread退出之后执行GC之后则堆内存显著下降，可以看出在Thread没有退出的情况下，确实存在有内存泄漏的风险
  - 解决方案：需要在线程执行退出之前在finally执行ThreadLocal的remove方法，删除map中的数据

坑三、数据上下文错乱

• 如果是线程池来执行任务，对ThreadLocal的操作会造成数据错乱

public class ThreadLocalDataMix {
     

    private static ThreadLocal<AtomicInteger> threadLocal =
            ThreadLocal.withInitial(() -> new AtomicInteger(0));

    public static void main(String[] args) {
     
        ExecutorService executorService = Executors.newFixedThreadPool(2);
        for (int i = 0; i < 4; i++) {
     
            executorService.submit(()->{
     
                try {
     
                    threadLocal.get().getAndIncrement();
                    System.out.printf("当前线程%s, threadLocal value = %d\n", Thread.currentThread().getName(), threadLocal.get().get());
                } finally {
     
                    // 执行该代码删除ThreadLocalMap中的数据，不执行则跟线程绑定一直存在
                    threadLocal.remove();
                }
            });
        }
        executorService.shutdown();
    }
}

• 结果1：注释threadLocal.remove();改代码

当前线程pool-1-thread-1, threadLocal value = 1
当前线程pool-1-thread-2, threadLocal value = 1
当前线程pool-1-thread-2, threadLocal value = 2
当前线程pool-1-thread-1, threadLocal value = 2

• 结果2：执行threadLocal.remove();代码

当前线程pool-1-thread-2, threadLocal value = 1
当前线程pool-1-thread-1, threadLocal value = 1
当前线程pool-1-thread-1, threadLocal value = 1
当前线程pool-1-thread-1, threadLocal value = 1

• 可以看出结果2是正常执行返回结果，结果1原因是在线程池中的Map对象没有被清空造成了下次继续执行造成的数据错乱

总结

• ThreadLocal是Thread的好搭档，好多框架都用它在方法之间来传递变量，但是一定要注意它隐蔽的坑，总而言之可以在程序中的拦截器、过滤器或者其它地方使用finally执行threadLocal.remove方法
• 网上有很多关于ThreadLocal的原理的读者可以自行搜索查阅，我这个也是班门弄斧，有不足还请指正！

你们的点赞和关注是我创作的最大动力，有什么不足和错误的地方欢迎留言，微信搜索关注小二说码，定期分享干货！