Java线程本地变量导致的缓存问题解决方法

更新时间：2024年08月30日 10:53:28 作者：从零开始的-CodeNinja之路

使用缓存可以缓解大流量压力,显著提高程序的性能,我们在使用缓存系统时,尤其是大并发情况下,经常会遇到一些疑难杂症,这篇文章主要给大家介绍了关于Java线程本地变量导致的缓存问题的解决方法,需要的朋友可以参考下,

一、前言

前些时间看别人写的一段关于锁的（对象缓存+线程本地变量）的一段代码，这段代码大致描述了这么一个功能：

外部传入一个key，需要根据这个key去全局变量里面找是否存在，如有有则表示有人对这个key加锁了，往下就不执行具体业务代码，同时，同时哦还要判断这个key是不是当前线程持有的，如果不是当前线程持有的也不能往下执行业务代码～

然后哦还要在业务代码执行完成后释放这个key锁，也就是要从 ThreadLocal 里面移除这个key。

当然需求不仅于此，就是业务的特殊性需要 ThreadLocal 同时持有多个不同的key，这就表明 ThreadLocal 的泛型肯定是个List或Set。

然后再说下代码，为了演示问题代码写的比较简略，以下我再一一说明可能存在的问题🎈

二、基本逻辑

功能大致包含两个函数:

lock : 主要是查找公共缓存还有线程本地变量是否包含传入的指定key，若无则尝试写入全局变量及 ThreadLocal 并返回true以示获取到锁

release ：业务逻辑处理完成后调用此，此函数内主要是做全局缓存以及 ThreadLocal 内的key的移除并返回状态(true/false)

contains : 公共方法，供以上两个方法使用，逻辑：判断全局变量或 ThreadLocal 里面有否有指定的key，此方法用 private 修饰
好了，准备看代码 😂

代码如下：

public class CacheObjectLock {
    // 全局对象缓存
    private static List<Object> GLOBAL_CACHE = new ArrayList<Object>(8);
    // 线程本地变量
    private static ThreadLocal<List<Object>> THREAD_CACHE = new ThreadLocal<List<Object>>();
 
    // 尝试加锁
    public synchronized boolean lock(Object obj){
        if(this.contains(obj)){
            return false;
        }
        List al = null;
        if((al=THREAD_CACHE.get())==null){
            al = new ArrayList(2);
            THREAD_CACHE.set(al);
        }
        al.add(obj);
        GLOBAL_CACHE.add(obj);
        return true;
 
    }
    // 判断是否存在key
    public boolean contains(Object obj){
        List<Object> objs;
        return GLOBAL_CACHE.contains(obj)?true:(objs=THREAD_CACHE.get())==null?false:objs.contains(obj);
    }
 
    // 释放key锁，与上面的 lock 方法对应 
    public boolean release(Object obj){
        if( this.contains(obj) ){
            List<Object> objs = THREAD_CACHE.get();
            if(null!=objs){
                objs.remove(obj);
                GLOBAL_CACHE.remove(obj);
            }
            return true;
        }
        return false;
    }
}

三、测试代码

因为是锁，所以必须要使用多线程测试，这里我简单使用 parallel stream +多轮循环去测试:

public class CacheObjectLockTest {
    private CacheObjectLock LOCK = new CacheObjectLock();
 
    public void test1(){
        IntStream.range(0,10000).parallel().forEach(i->{
            if(i%3==0){
                i-=2;
            }
            Boolean b = null;
            if((b=LOCK.lock(i))==false ){
                return ;
            }
            Boolean c = null;
            try {
                // do something ...
//                TimeUnit.MILLISECONDS.sleep(1);
            } catch (Exception e) {
                throw new RuntimeException(e);
            }finally {
                c = LOCK.release(i);
            }
            if(b!=c){
                System.out.println("b:"+b+" c:"+c+" => "+Thread.currentThread().getName());
            }
        });
//        LOCK.contains(9);
    }
 
    @Test
    public void test2(){
        for(int i=0;i<10;i++){
            this.test1();
        }
    }
}

测试结果

分析

显而易见，这是没有对 release 加锁导致的，其实呢，这样说是不准确的…
首先要明白 lock 上加的 synchronized 的同步锁的范围是对当前实例的，而 release 是没有加 synchronized ，所以 release 是无视 lock 上加的 synchronized

再仔细看看 GLOBAL_CACHE 是什么？ArrayList ，明白了吧 ArrayList 不是线程安全的，因为 synchronized 的范围只是 lock 函数这一函数内，从测试代码可看到 LOCK.lock(i)

开始一直到 LOCK.release(i) 这中间是没有加同步锁的，所以到 LOCK.lock(i) 开始一直到 LOCK.release(i) 这中间是存在线程竞争的，恰好又碰到 ArrayList 这一不安全因素自然会抛错的！

因为存在不安全类，所以我们有理由怀疑 THREAD_CACHE 的泛型变量也是存在多线程异常的，因为它这个泛型也是 ArrayList ！

四、解决锁问题

好了，明白了问题之所在，自然解决办法也十分easy：

在 release 方法上添加 synchronized 声明，这样简单粗暴

分别对 objs.remove(obj); 以及 GLOBAL_CACHE.remove(obj); 加同步锁，这样颗粒度更细

因为 synchronized 是写独占的，所以无需在 contains 中单独加锁

代码 (这里仅有 release 变更)

    public synchronized boolean release(Object obj){
        if( this.contains(obj) ){
            List<Object> objs = THREAD_CACHE.get();
            if(null!=objs){
//                synchronized (objs){
                    objs.remove(obj);
//                }
//                synchronized (GLOBAL_CACHE){
                    GLOBAL_CACHE.remove(obj);
//                }
            }
            return true;
        }
        return false;
    }

测试结果

分析😂

测试了多轮都是成功的，没有任何异常，难道就一定没有异常了？？？

非也，非也~~~

为了让问题体现的的更清晰，先修改下测试用例并把 contains 方法置为 public,然后测试用例:

public class CacheObjectLockTest {
    private CacheObjectLock2 LOCK = new CacheObjectLock2();
 
    public void test1(){
        IntStream.range(0,10000).parallel().forEach(i->{
//            String it = "K"+i;
            if(i%3==0){
                i-=2;
            }
            Boolean b = null;
            if((b=LOCK.lock(i))==false ){
                return ;
            }
            Boolean c = null;
            try {
                // do something ...
//                TimeUnit.MILLISECONDS.sleep(1);
            } catch (Exception e) {
                throw new RuntimeException(e);
            }finally {
                c = LOCK.release(i);
            }
            if(b!=c){
                System.out.println("b:"+b+" c:"+c+" => "+Thread.currentThread().getName());
            }
        });
        LOCK.contains(9);
    }
 
    @Test
    public void test2(){
        for(int i=0;i<10;i++){
            this.test1();
        }
    }
}

在这一行打上断点 LOCK.contains(9); 然后逐步进入到 ThreadLocal 的 get() 方法中：

看到没，虽然key已经被移除的，但是 ThreadLocal 里面关联的是 key外层的 ArrayList , 因为开发机配置都较好，一旦导致 ThreadLocal 膨胀,则 OOM 是必然的事儿！

我们知道 ThreadLocal 的基本特性，它会根据线程分开存放各自线程的所 set 进来的对象，若没有调用其 remove 方法，变量会一直存在 ThreadLocal 这个 map 中，

若上述的测试代码放在线程池里面被管理，线程池会根据负载会增减线程，如果每一次执行上述代码用的线程都不是固定的 ThreadLocal 必然会导致 jvm OOM 😂

这就像 java 里面的文件读写，open 之后必须要要有 close 操作。

五、解决ThreadLocal问题

最后更改代码如下：

public class CacheObjectLock3 {
    private static List<Object> GLOBAL_CACHE = new ArrayList<Object>(8);
    private static ThreadLocal<List<Object>> THREAD_CACHE = new ThreadLocal<List<Object>>();
    
    public synchronized boolean lock(Object obj){
        if(this.contains(obj)){
            return false;
        }
        List al = null;
        if((al=THREAD_CACHE.get())==null){
            al = new ArrayList(2);
            THREAD_CACHE.set(al);
        }
        al.add(obj);
        GLOBAL_CACHE.add(obj);
        return true;
 
    }
 
    public boolean contains(Object obj){
        List<Object> objs;
        return GLOBAL_CACHE.contains(obj)?true:(objs=THREAD_CACHE.get())==null?false:objs.contains(obj);
    }
 
    public synchronized boolean release(Object obj){
        if( this.contains(obj) ){
            List<Object> objs = THREAD_CACHE.get();
            if(null!=objs){
//                synchronized (objs){
                    objs.remove(obj);
                    if(objs.isEmpty()){
                        THREAD_CACHE.remove();
                    }
//                }
//                synchronized (GLOBAL_CACHE){
                    GLOBAL_CACHE.remove(obj);
//                }
            }
            return true;
        }
        return false;
    }
 
}

测试结果

测试 ok 通过 ~

总结

到此这篇关于Java线程本地变量导致的缓存问题解决方法的文章就介绍到这了,更多相关Java线程本地变量缓存问题内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

Mybatis的xml文件时间范围条件查询方式
这篇文章主要介绍了Mybatis的xml文件时间范围条件查询方式,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教
2024-03-03
Spring 缓存抽象示例详解
Spring框架自身并没有实现缓存解决方案，但是从3.1开始定义了org.springframework.cache.Cache和org.springframework.cache.CacheManager接口，提供对缓存功能的声明，能够与多种流行的缓存实现集成。这篇文章主要介绍了Spring 缓存抽象 ,需要的朋友可以参考下
2018-09-09
如何有效管理JVM中的垃圾?
今天给大家带来的是关于Java虚拟机的相关知识,文章围绕着如何有效管理JVM中的垃圾展开,文中有非常详细的介绍及代码示例,需要的朋友可以参考下
2021-06-06
Java魔法堂之调用外部程序的方法
这篇文章主要介绍了Java魔法堂：调用外部程序的相关知识，本文给大家介绍的非常详细，对大家的学习或工作具有一定的参考借鉴价值，需要的朋友参考下吧
2021-02-02
Java中Math类常用方法代码详解
本文是小编最新给大家整理的关于Java中Math类常用方法的知识，通过实例代码给大家介绍的非常详细，感兴趣的朋友一起看看吧
2017-07-07
java递归算法的实例详解
在本篇文章里小编给大家整理了关于java递归算法的实例内容，以及相关知识点总结，需要的朋友们可以学习下。
2020-02-02
关于kafka消费不到远程bootstrap-server 数据的问题
很多朋友遇到kafka消费不到远程bootstrap-server 数据的问题，怎么解决这个问题，很多朋友不知所措，下面小编给大家带来了关于kafka消费不到远程bootstrap-server 数据的问题及解决方法，感兴趣的朋友跟随小编一起看看吧
2021-11-11
Java加载JDBC驱动程序实例详解
这篇文章主要介绍了Java加载JDBC驱动程序的方法,需要的朋友可以参考下
2014-07-07
druid多数据源配置+Datasurce动态切换方式
这篇文章主要介绍了druid多数据源配置+Datasurce动态切换方式，具有很好的参考价值，希望对大家有所帮助。如有错误或未考虑完全的地方，望不吝赐教
2021-09-09
idea开启mybatis控制台SQL日志打印的代码示例
本文主要介绍了idea开启mybatis控制台SQL日志打印的方法,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧
2023-12-12