JAVA高并发——人手一支笔:ThreadLocal

2024-02-20 16:28

本文主要是介绍JAVA高并发——人手一支笔:ThreadLocal,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

文章目录

  • 1、ThreadLocal的简单使用
  • 2、ThreadLocal的实现原理
  • 3、对性能有何帮助
  • 4、线程私有的随机数发生器ThreadLocalRandom
    • 4.1、反射的高效替代方案
    • 4.2、随机数种子
    • 4.3、探针Probe的作用

除了控制资源的访问,我们还可以通过增加资源来保证所有对象的线程安全。比如,让100个人填写个人信息表,如果只有一支笔,那么大家就得挨个填写,对于管理人员来说,必须保证大家不会去哄抢这仅有的一支笔,否则,谁也填不完。从另一个角度出发,我们可以准备100支笔,人手一支,那么所有人很快就能完成表格的填写工作。

如果说锁使用的是第一种思路,那么ThreadLocal使用的就是第二种思路。

1、ThreadLocal的简单使用

从ThreadLocal这一名字上可以看出,这是一个线程的局部变量。也就是说,只有当前线程可以访问。既然是只有当前线程可以访问的数据,那么自然是线程安全的。

下面来看一个简单的示例:

import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;/*** @title ThreadLocalDemo* @description ThreadLocal测试* @author: yangyongbing* @date: 2024/2/20 12:22*/
public class ThreadLocalDemo implements Runnable{private  static final SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");int i=0;public ThreadLocalDemo(int i) {this.i = i;}@Overridepublic void run() {try {Date t = sdf.parse("2024-02-20 19:29:" + i % 60);System.out.println(i+":"+t);} catch (ParseException e) {e.printStackTrace();}}public static void main(String[] args) {ExecutorService executorService = Executors.newFixedThreadPool(10);for (int i = 0; i < 1000; i++) {executorService.execute(new ThreadLocalDemo(i));}}
}

在这里插入图片描述
上述代码在多线程中使用SimpleDateFormat对象实例来解析字符串类型的日期。执行上述代码,一般来说,很可能出现一些异常(篇幅有限不再给出堆栈,只给出异常名称):
在这里插入图片描述

在这里插入图片描述
一种可行的解决方案是在sdf.parse()方法前后加锁,这也是我们一般的处理思路。这里不这么做,我们使用ThreadLocal为每一个线程创造一个SimpleDateformat对象实例:
在这里插入图片描述
在上述代码第7~9行中,如果当前线程不持有SimpleDateformat对象实例,那么就新建一个对象实例并把它置于当前线程中,如果已经持有,则直接使用。

从这里也可以看到,为每一个线程分配一个对象的工作并不是由ThreadLocal来完成的,而是需要在应用层面保证的。如果在应用中为每一个线程分配相同的对象实例,那么ThreadLocal也不能保证线程安全,这一点也需要大家注意。

**注意:**为每一个线程分配不同的对象,需要在应用层面保证ThreadLocal只起到了简单的容器作用。

2、ThreadLocal的实现原理

ThreadLocal如何保证对象实例只被当前线程访问呢?下面让我们一起深入ThreadLocal的内部实现。

我们需要关注的自然是ThreadLocal的set()方法和get()方法。先从set()方法说起:
在这里插入图片描述
在set()方法中,首先获得当前线程对象,然后通过getMap()方法获取线程的ThreadLocalMap,并将值存入ThreadLocalMap中。而ThreadLocalMap可以理解为一个Map(虽然不是,但是你可以把它简单地理解成HashMap),它是定义在Thread内部的成员。注意下面的定义是从Thread类中摘出来的:
在这里插入图片描述
设置到ThreadLocal中的数据,也就是写入了threadLocals的这个Map。其中,key为ThreadLocal当前对象,value就是我们需要的值。而threadLocals本身保存了当前自己所在线程的所有“局部变量”,也就是一个ThreadLocal变量的集合。

在get()方法中,自然就要将这个Map中的数据拿出来:
在这里插入图片描述
get()方法先取得当前线程的ThreadLocalMap对象,然后将自己作为key来取得内部的实际数据。

在了解了ThreadLocal的内部实现后,我们自然会引出一个问题:这些变量是维护在Thread类内部的(ThreadLocalMap定义所在类),这也意味着只要线程不退出,对象的引用将一直存在。

当线程退出时,Thread类会进行一些清理工作,其中就包括清理ThreadLocalMap,注意下述代码的加粗部分:
在这里插入图片描述
因此,使用线程池就意味着当前线程未必会退出(比如固定大小的线程池,线程总是存在)。如果这样,将一些大的对象设置到ThreadLocal中(它实际保存在线程持有的threadLocalMap内),可能会使系统出现内存泄漏(这里的意思是:你设置了对象到ThreadLocal中,但是不清理它,在你使用几次后,这个对象也不再有用了,但是它却无法被回收)。

此时,如果你希望及时回收对象,最好使用ThreadLocal.remove()方法将这个变量移除。就像我们习惯性地关闭数据库连接一样,如果你确实不需要这个对象了,就应该告诉虚拟机把它回收,防止内存泄漏。

另外一种有趣的情况是,JDK也可能允许你像释放普通变量一样释放ThreadLocal。比如,我们有时候为了加速垃圾回收,会特意写出类似obj=null的代码。如果这么做,obj所指向的对象就会更容易地被垃圾回收器发现,从而加速回收。

同理,对于ThreadLocal的变量,如果我们也手动将其设置为null,比如tl=null,那么这个ThreadLocal对应的所有线程的局部变量都有可能被回收。这里面的奥秘是什么呢?先来看一个简单的例子:
在这里插入图片描述
在这里插入图片描述
上述案例是为了跟踪ThreadLocal对象及内部SimpleDateFormat对象的垃圾回收情况,我们在第3行代码和第17行代码中重载了finalize()方法。这样,在对象被回收时,我们就可以看到它们的踪迹。

在主函数main()中,先后进行了两次任务提交,每次10000个任务。在第一次任务提交后,在代码的第39行,我们将tl设置为null,并执行一次GC。接着,我们进行第二次任务提交,完成后,在代码的第50行再执行一次GC。
在这里插入图片描述
注意这些输出所代表的含义。首先,线程池中的10个线程都各自创建了一个SimpleDateFormat对象实例。接着执行第一次GC,可以看到ThreadLocal对象被回收了(这里使用了匿名类,所以类名看起来有点怪,这个类就是第2行创建的tl对象)。然后提交第2次任务,这次一样创建了10个SimpleDateFormat对象,接着执行第二次GC。在第二次GC后,第一次创建的10个SimpleDateFormat的子类实例全部被回收。虽然我们没有手动移除这些对象,但是系统依然有可能回收它们。

要了解这里的回收机制,我们需要更进一步了解Thread.ThreadLocalMap的实现。我们之前说过,ThreadLocalMap类似HashMap,准确地说,它更加类似WeakHashMap。

ThreadLocalMap的实现使用了弱引用。弱引用是比强引用弱得多的引用。Java虚拟机在进行垃圾回收时,如果发现弱引用,就会立即回收。ThreadLocalMap内部由一系列entry构成,每一个entry都是WeakReference。
在这里插入图片描述
这里的参数k就是Map的key, v就是Map的value,其中k也是ThreadLocal实例,作为弱引用使用(super(k)就是调用了WeakReference的构造函数)。虽然这里使用ThreadLocal作为Map的key,但是实际上,它并不真的持有ThreadLocal的引用。而当ThreadLocal的外部强引用被回收时,ThreadLocalMap中的key就会变成null。当系统进行ThreadLocalMap清理时(比如将新的变量加入表中,就会自动执行一次清理,虽然JDK不一定会进行一次彻底的扫描,但显然在这个案例中,它奏效了),就会将这些垃圾数据回收。ThreadLocal的回收机制如下图所示:
在这里插入图片描述

3、对性能有何帮助

为每一个线程分配一个独立的对象对系统性能也许是有帮助的。当然,这也不一定,这完全取决于共享对象的内部逻辑。如果共享对象对于竞争的处理容易引起性能损失,我们还是应该考虑使用ThreadLocal为每个线程分配单独的对象。一个典型的案例就是在多线程下产生随机数。

这里,让我们简单测试一下在多线程下产生随机数的性能问题。首先,定义一些全局变量:
在这里插入图片描述
代码第1行定义了每个线程要产生的随机数数量;第2行定义了参与工作的线程数量;第3行定义了线程池;第4行定义了被多线程共享的Random实例,用于产生随机数;第6~11行定义了由ThreadLocal封装的Random。

定义一个工作线程的内部逻辑,它可以工作在两种模式下:

  • 第一种是多个线程共享一个Random(mode=0)。
  • 第二种是为多个线程各分配一个Random(mode=1)。
    在这里插入图片描述
    上述代码的第19~27行定义了线程的工作内容。每个线程都会产生若干个随机数,完成工作后,记录并返回所消耗的时间。

最后是main()函数,它分别对上述两种情况进行测试,并打印了耗时:
在这里插入图片描述
上述代码的运行结果可能如下:
在这里插入图片描述
很明显,在多线程共享一个Random实例的情况下,总耗时为13秒多(这里是指4个线程的耗时总和,不是程序执行经历的时间)。而在ThreadLocal模式下,仅耗时约1.7秒。

4、线程私有的随机数发生器ThreadLocalRandom

为了提高在高并发环境中随机数的产生效率,JDK提供了ThreadLocalRandom类。这是一个线程安全的随机数发生器。它让每个线程都维护一个自己的种子变量,每个线程生成随机数时都根据自己老的种子计算新的种子,再根据新的种子计算随机数,因此不存在竞争问题,从而提高了并发性能。

ThreadLocalRandom继承自Random,拥有Random的全部功能,只不过它运行更快、功能更强大。

在ThreadLocal的介绍中,我们已经知道,ThreadLocal的实现依赖于Thread对象中的’ThreadLocal.ThreadLocalMap threadLocals’成员字段。与之类似,为了让随机数发生器只访问本地线程数据,从而避免竞争,Thread中又增加了3个字段:
在这里插入图片描述
这3个字段作为Thread类的成员,便自然地和每一个Thread对象牢牢捆绑在一起,成了名副其实的ThreadLocal变量,而依赖这几个变量实现的随机数发生器,也就成了ThreadLocalRandom。

上述代码中,@sun.misc.Contended(“tlr”)表示这是一个消除伪共享的字段。消除伪共享可以提升字段的访问速度。

4.1、反射的高效替代方案

随机数的产生需要访问Thread的threadLocalRandomSeed等成员,但是考虑到类的封装性,这些成员只是包内可见的。很不幸,ThreadLocalRandom位于java.util.concurrent包,而Thread则位于java.lang包,因此,ThreadLocalRandom并没有办法访问Thread的threadLocalRandomSeed等变量。

这时,Java老鸟们可能就会跳出来说:“这算什么,看我的反射大法,不管啥都能抠出来访问一下。”说得没错,反射是一种可以绕过封装直接访问对象内部数据的方法,但是,反射的性能不太好,并不适合作为高性能的解决方案。有没有可以让ThreadLocalRandom访问Thread的内部成员,同时又远超于反射且无限接近于直接访问变量的方法呢?答案是肯定的,这就是使用Unsafe类。

这里简单介绍一下Unsafe类的两个方法:
在这里插入图片描述
其中getLong()方法会读取对象o的第offset字节偏移量的一个long型数据;putLong()方法则会将x写入对象o的第offset个字节的偏移量中。这种类似C语言的操作方法,带来了极大的性能提升,更重要的是,由于它避开了字段名,直接使用偏移量,可以轻松绕过成员的可见性限制。

性能问题解决了,下一个问题是:我怎么知道threadLocalRandomSeed成员在Thread中的偏移位置呢?这就需要用Unsafe类的objectFieldOffset()方法了,请看下面的代码:
在这里插入图片描述
上述这段代码,在ThreadLocalRandom类初始化的时候,就取得了Thread成员变量threadLocalRandomSeed、threadLocalRandomProbe和threadLocalRandomSecondarySeed在对象偏移中的位置。因此,只要ThreadLocalRandom需要使用这些变量,都可以通过Unsafe类的getLong()和putLong()方法来访问(也可能是getInt()和putInt()方法)。

比如像下面一样生成一个随机数的时候:
在这里插入图片描述
这种Unsafe类的方法到底能有多快呢?根据笔者的经验,这比传统的反射至少快3倍。这也是JDK内部大量使用Unsafe类的方法而非反射的一个重要原因。

4.2、随机数种子

伪随机数生成都需要一个种子,threadLocalRandomSeed和threadLocalRandomSecondary-Seed就是这里的种子。其中threadLocalRandomSeed是long型的,threadLocalRandomSecondary-Seed是int型的。threadLocalRandomSeed是使用最广泛的。大量的随机数其实都是基于threadLocalRandomSeed的。而threadLocalRandomSecondarySeed只在某些特定的JDK内部实现中使用,使用并不广泛。

初始种子默认使用的是系统时间:
在这里插入图片描述
上述代码完成了种子的初始化,并将初始化的种子通过UNSAFE储存在SEED的位置(即threadLocalRandomSeed)。

接着就可以使用nextInt()方法获得随机整数了:
在这里插入图片描述
每一次调用nextInt()方法都会使用nextSeed()方法更新threadLocalRandomSeed。由于这是一个线程独有的变量,因此完全不会有竞争,也不会有CAS重试,性能也就大大提高了。

4.3、探针Probe的作用

除了种子,还有一个threadLocalRandomProbe探针变量,这个变量是用来做什么的呢?我们可以把threadLocalRandomProbe理解为针对每个Thread的Hash值(不为0),它可以作为一个线程的特征值,基于这个值可以为线程在数组中找到一个特定的位置:
在这里插入图片描述
来看下面的代码片段:
在这里插入图片描述
在具体的实现中,如果上述代码发生了冲突,还可以使用ThreadLocalRandom.advance-Probe()方法来修改一个线程的探针值,这样可以进一步避免未来可能出现的冲突,从而减少竞争,提高并发性能。
在这里插入图片描述

这篇关于JAVA高并发——人手一支笔:ThreadLocal的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/728816

相关文章

SpringBoot UserAgentUtils获取用户浏览器的用法

《SpringBootUserAgentUtils获取用户浏览器的用法》UserAgentUtils是于处理用户代理(User-Agent)字符串的工具类,一般用于解析和处理浏览器、操作系统以及设备... 目录介绍效果图依赖封装客户端工具封装IP工具实体类获取设备信息入库介绍UserAgentUtils

Spring 中的循环引用问题解决方法

《Spring中的循环引用问题解决方法》:本文主要介绍Spring中的循环引用问题解决方法,本文给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要的朋友参考下吧... 目录什么是循环引用?循环依赖三级缓存解决循环依赖二级缓存三级缓存本章来聊聊Spring 中的循环引用问题该如何解决。这里聊

Java学习手册之Filter和Listener使用方法

《Java学习手册之Filter和Listener使用方法》:本文主要介绍Java学习手册之Filter和Listener使用方法的相关资料,Filter是一种拦截器,可以在请求到达Servl... 目录一、Filter(过滤器)1. Filter 的工作原理2. Filter 的配置与使用二、Listen

Spring Boot中JSON数值溢出问题从报错到优雅解决办法

《SpringBoot中JSON数值溢出问题从报错到优雅解决办法》:本文主要介绍SpringBoot中JSON数值溢出问题从报错到优雅的解决办法,通过修改字段类型为Long、添加全局异常处理和... 目录一、问题背景:为什么我的接口突然报错了?二、为什么会发生这个错误?1. Java 数据类型的“容量”限制

Java对象转换的实现方式汇总

《Java对象转换的实现方式汇总》:本文主要介绍Java对象转换的多种实现方式,本文通过实例代码给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要的朋友参考下吧... 目录Java对象转换的多种实现方式1. 手动映射(Manual Mapping)2. Builder模式3. 工具类辅助映

SpringBoot请求参数接收控制指南分享

《SpringBoot请求参数接收控制指南分享》:本文主要介绍SpringBoot请求参数接收控制指南,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录Spring Boot 请求参数接收控制指南1. 概述2. 有注解时参数接收方式对比3. 无注解时接收参数默认位置

SpringBoot基于配置实现短信服务策略的动态切换

《SpringBoot基于配置实现短信服务策略的动态切换》这篇文章主要为大家详细介绍了SpringBoot在接入多个短信服务商(如阿里云、腾讯云、华为云)后,如何根据配置或环境切换使用不同的服务商,需... 目录目标功能示例配置(application.yml)配置类绑定短信发送策略接口示例:阿里云 & 腾

SpringBoot项目中报错The field screenShot exceeds its maximum permitted size of 1048576 bytes.的问题及解决

《SpringBoot项目中报错ThefieldscreenShotexceedsitsmaximumpermittedsizeof1048576bytes.的问题及解决》这篇文章... 目录项目场景问题描述原因分析解决方案总结项目场景javascript提示:项目相关背景:项目场景:基于Spring

Spring Boot 整合 SSE的高级实践(Server-Sent Events)

《SpringBoot整合SSE的高级实践(Server-SentEvents)》SSE(Server-SentEvents)是一种基于HTTP协议的单向通信机制,允许服务器向浏览器持续发送实... 目录1、简述2、Spring Boot 中的SSE实现2.1 添加依赖2.2 实现后端接口2.3 配置超时时

Spring Boot读取配置文件的五种方式小结

《SpringBoot读取配置文件的五种方式小结》SpringBoot提供了灵活多样的方式来读取配置文件,这篇文章为大家介绍了5种常见的读取方式,文中的示例代码简洁易懂,大家可以根据自己的需要进... 目录1. 配置文件位置与加载顺序2. 读取配置文件的方式汇总方式一:使用 @Value 注解读取配置方式二