打怪升级系列之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的值都是一样的
    [图片上传失败...(image-17642-1612532513992)]
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();
        }
    }
}

[图片上传失败...(image-ac8905-1612532513992)]

  • 图片左边是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没有退出的情况下,确实存在有内存泄漏的风险
    两次GC之后堆数据差异
    - 解决方案:需要在线程执行退出之前在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的原理的读者可以自行搜索查阅,我这个也是班门弄斧,有不足还请指正!

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

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 220,492评论 6 513
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 94,048评论 3 396
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 166,927评论 0 358
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 59,293评论 1 295
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 68,309评论 6 397
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 52,024评论 1 308
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,638评论 3 420
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,546评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 46,073评论 1 319
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 38,188评论 3 340
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 40,321评论 1 352
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,998评论 5 347
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,678评论 3 331
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 32,186评论 0 23
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,303评论 1 272
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,663评论 3 375
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 45,330评论 2 358

推荐阅读更多精彩内容