系列五、为什么不用线程id作为ThreadLocalMap的key

一、为什么不用线程id作为ThreadLocalMap的key

1.1、案例代码

/**
 * @Author : 一叶浮萍归大海
 * @Date: 2024/2/26 11:40
 * @Model Description:
 * @Description: 为什么不用线程id作为ThreadLocalMap的key案例
 * 需求:
 *      如果当前线程是线程1,那么设置书名和作者分别为 三国演义 罗贯中
 *      如果当前线程是线程2,那么设置书名和作者分别为 西游记 吴承恩
 *      如果当前线程是线程3,那么设置书名和作者分别为 水浒传 施耐庵
 *      如果当前线程是线程4,那么设置书名和作者分别为 红楼梦 曹雪芹
 *      其他线程,那么设置书名和作者分别为 朝花夕拾 鲁迅
 *
 * 原则:
 *      在多线程并发的场景下,每个线程中的变量都是互相独立的
 *      线程A:    设置(变量1)     获取(变量1)
 *      线程B:    设置(变量2)     获取(变量2)
 *
 * ThreadLocal:
 *      1、set():将变量绑定到当前线程中
 *      2、get():获取当前线程绑定的变量
 */
public class ThreadLocalDemo4MainApp {

    private ThreadLocal<String> nameThreadLocal = new ThreadLocal<>();
    private ThreadLocal<String> authorThreadLocal = new ThreadLocal<>();

    /**
     * 书名
     */
    private String name;
    /**
     * 作者
     */
    private String author;

    public String getName() {
        return nameThreadLocal.get();
    }

    public void setName(String name) {
        nameThreadLocal.set(name);
    }

    public String getAuthor() {
        return authorThreadLocal.get();
    }

    public void setAuthor(String author) {
        authorThreadLocal.set(author);
    }

    public static void main(String[] args) {
        ThreadLocalDemo4MainApp demo4 = new ThreadLocalDemo4MainApp();
        for (int i = 1; i <= 6; i++) {
            new Thread(() -> {
                switch (Thread.currentThread().getName()) {
                    case "线程1":
                        demo4.setName("三国演义");
                        demo4.setAuthor("罗贯中");
                        break;
                    case "线程2":
                        demo4.setName("西游记");
                        demo4.setAuthor("吴承恩");
                        break;
                    case "线程3":
                        demo4.setName("水浒传");
                        demo4.setAuthor("施耐庵");
                        break;
                    case "线程4":
                        demo4.setName("红楼梦");
                        demo4.setAuthor("曹雪芹");
                        break;
                    default:
                        demo4.setName("朝花夕拾");
                        demo4.setAuthor("鲁迅");
                        break;
                }
                System.out.println("================================");
                System.out.println("当前线程:" + Thread.currentThread().getName() + ",线程id:" + Thread.currentThread().getId() + "===>书名:" + demo4.getName() + ",作者:" + demo4.getAuthor());
            }, "线程" + String.valueOf(i)).start();
        }
    }

}

1.2、原因

        如上案例所示,当一个资源类中有2个或者多个共享变量,即有多个ThreadLocal<T>时,如果使用线程id作为ThreadLocalMap的key,由于id是唯一的,往map里面put值时,相同的id,后边的值会把前边的值覆盖掉,即作者会把书名覆盖掉,那么我们再从ThreadLocalMap中取值的时候就取不到书名信息了,因此使用线程id作为ThreadLocalMap的key是不合适的。

以下是我和面试官的面试过程,请你指出不正确的地方:ThreadLocal使用场景 如果我们需要让变量在线程间是隔离的,在方法之间和模块之间是共享的,那就很适合使用ThreadLocal,它可以实现多个模块之间的解耦合,避免参数的直接传递。比如登录校验的时候,在拦截器中利用ThreadLocal保存用户id,在其它模块就可以取出来使用。 ThreadLocal原理? 首先ThreadLocal变量为每一个线程都创建了一个变量的副本,每个线程都会访问自己的这一份副本。ThreadLocal对象本身是不保存数据的,数据都是保存在线程对象的ThreadLocalMap中,ThreadLocalMap就是一个Hash表,Key就是ThreadLocal对象,只不过它是通过弱引用包装的,value就是我们设置的值。当我们往ThreadLocal对象中存放元素的时候,它会首先拿到当前对象,然后从中取出对象的ThreadLocalMap,然后里面存放键值对。 为什么要设置成弱引用? 设置为弱引用主要是为了保证ThreadLocal对象本身能够被正常回收。key 如果是强引用那么线程对象中的threadLocalMapThreadLocal的强引用会一直存在,这就会导致ThreadLocal对象无法被回收,除非我们手动释放。 ThreadLocal存在内存泄露问题吗? 存在,如果我们使用完ThreadLocal之后没有手动释放,那么虽然ThreadLocal对象只存在弱引用的情况下能够被回收,但是对应的Value无法被回收,这就导致在ThreadLocalMap中会出现Key为null但是Value不为null的Entry。如果我们的线程一直被复用那么这种脏Entry就会一直存在。但是ThreadLocalMap采用了线性探测法解决哈希冲突的,所以在进行get/set的时候如果出现哈希冲突那么它会扫描大量元素,如果扫到了脏Entry,它就会清除掉。 为什么ThreadLocalMap要使用线性探测法解决哈希冲突? 首先,线性探测法有一个好处就是cpu缓存命中率会高一些,因为哈希表就是一个数组,它是连续的内存空间,对cpu缓存更加友好。 然后线性探测法能够让ThreadLocalMap更好的清除key为null的脏Entry,避免内存泄露问题。因为他在get/set/remove的时候,如果出现了哈希冲突,那么它会继续往下扫描,如果这个过程中遇到了脏Entry,那么他就会清除掉脏Entry。
最新发布
07-09
### ThreadLocal使用场景分析 ThreadLocal适用于需要在线程内部共享数据,同时避免线程间数据竞争的场景。例如,在Web应用中为每个请求绑定一个数据库连接、事务上下文或用户信息等。这种机制可以有效避免多线程环境下的同步问题,提高程序性能[^4]。 然而,若在不恰当的场景下使用ThreadLocal,比如在线程池环境中未正确清理变量,则可能导致内存泄漏问题。这是因为线程池中的线程生命周期较长,若未及时调用`remove()`方法清除无用的ThreadLocal变量,那么这些变量将持续占用内存资源[^1]。 ### 实现原理与结构设计 ThreadLocal的实现依赖于每个线程内部维护的ThreadLocalMap对象。该Map的键是ThreadLocal实例本身(弱引用),值则是线程局部变量的实际内容。当线程结束时,ThreadLocalMap也会被回收。但由于线程池的存在,线程可能长时间运行而不终止,这就要求开发者手动管理ThreadLocal的生命周期[^2]。 #### 弱引用机制解析 将ThreadLocal作为键使用弱引用的主要目的是为了防止内存泄漏。如果键是强引用,则即使外部不再持有该ThreadLocal实例的引用,只要线程还在,这个键就不会被垃圾回收器回收,从而导致内存泄漏。而采用弱引用后,一旦外部没有强引用指向该ThreadLocal实例,它就可以被回收,进而其对应的Entry也可能被清理掉。 但需要注意的是,即便key被设置成了弱引用,value仍然由Entry持有强引用。因此,只有当整个Entry被移除时,value才能被GC回收。否则,即使key已经被回收,value依然存在,直到下一次访问该位置并触发清理操作为止[^3]。 ### 内存泄露问题详解 尽管key采用了弱引用,但在某些情况下仍可能发生内存泄漏: - **未调用remove()**:在线程池环境下,如果没有显式地调用`threadLocal.remove()`来删除不再使用的ThreadLocal变量,则这些变量会一直存在于ThreadLocalMap中。 - **线性探测法引发的问题**:ThreadLocalMap使用开放寻址法处理哈希冲突,具体来说就是线性探测。当插入新的Entry时,如果当前位置已被占用,则向后查找空位插入。这种方式可能导致旧的Entry无法被及时清理,尤其是在频繁创建和销毁ThreadLocal实例的情况下,容易造成大量无效Entry堆积,增加内存压力[^3]。 ### 线性探测法实现是否合理? 线性探测法本身是一种常见的解决哈希冲突的方法,其优点在于实现简单且效率较高。不过,在ThreadLocalMap的应用背景下,这种方法确实存在一定的局限性: - **哈希碰撞概率高**:由于ThreadLocal通常用于少量数据存储,每次新增或修改都可能引起重新哈希计算,增加了发生碰撞的可能性。 - **清理效率低下**:当某个Entry被标记为已删除(即key为null)时,后续查询操作可能会跳过这些位置继续搜索,这会导致一些实际已经失效的数据长期驻留在表中,影响整体性能并占用额外内存空间。 综上所述,虽然线性探测法在特定条件下能够满足需求,但对于ThreadLocalMap这样需要高效管理和释放资源的数据结构而言,并不是最优选择。更高效的替代方案可能是链地址法或其他改进型开放寻址策略,它们能够在一定程度上缓解上述问题。 --- ```java public class ThreadLocalExample { private static final ThreadLocal<String> threadLocal = new ThreadLocal<>(); public static void main(String[] args) { Runnable task = () -> { try { threadLocal.set(Thread.currentThread().getName()); System.out.println("Thread " + Thread.currentThread().getName() + ": " + threadLocal.get()); } finally { // 正确法:确保在线程结束前清理ThreadLocal变量 threadLocal.remove(); } }; Thread t1 = new Thread(task); Thread t2 = new Thread(task); t1.start(); t2.start(); } } ``` ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值