Android：ThreadLocal的简单理解和使用

原创

于 2023-03-26 14:54:59 发布 · 2.1k 阅读

2 ·

CC 4.0 BY-SA版权

文章标签：

#android #java

ThreadLocal提供线程局部变量，使得每个线程都有自己的副本，避免并发问题。其内部通过ThreadLocalMap存储数据，使用弱引用防止内存泄漏，但在使用时需要注意手动清理ThreadLocalMap中无用的Entry，以避免内存泄漏。文章通过示例解释了ThreadLocal的工作原理和最佳实践。

ThreadLocal的简单理解和使用

1、背景
2、ThreadLocal原理
3、ThreadLocal内存泄漏的问题
- 3.1、为什么使用弱引用
- 3.2、弱引用带来的问题
4、总结
参考

1、背景

对于ThreadLocal，日常开发中一般有两种使用场景：

每个线程需要一个独享的对象：比如Android中的Looper，后端中常用的工具类（如SimpleDateFormat）
每个线程内需要保存全局变量：都知道Java服务端Controller作为接口响应入口，Service处理业务逻辑，Repository提供数据库CRUD数据接口，类似在拦截器中获取的用户信息这类共享数据，就可以放置到ThreadLocal中，就不用一层一层的通过参数传递下去。

1.1、背景及问题

一般来说，当某些数据是以线程为作用域并且不同线程具有不同的数据副本的时候，就可以考虑采用ThreadLocal。

比如对于Handler来说，它需要获取当前线程的Looper，很显然Looper的作用域就是线程并且不同线程具有不同的Looper，这个时候通过ThreadLocal就可以轻松实现Looper在线程中的存。
- 如果不采用ThreadLocal，那么系统就必须提供一个全局的哈希表供Handler查找指定线程的Looper，这样一来就必须提供一个类似于LooperManager的类了，但是系统并没有这么做而是选择了ThreadLocal，这就是ThreadLocal的好处。
ThreadLocal另一个使用场景是复杂逻辑下的对象传递，比如监听器的传递，有些时候一个线程中的任务过于复杂，这可能表现为函数调用栈比较深以及代码入口的多样性，在这种情况下，我们又需要监听器能够贯穿整个线程的执行过程，这个时候可以怎么做呢？其实这时就可以采用ThreadLocal，采用ThreadLocal可以让监听器作为线程内的全局对象而存在，在线程内部只要通过get方法就可以获取到监听器。
- 如果不采用ThreadLocal，那么我们能想到的可能是如下两种方法：
  - 第一种方法是将监听器通过参数的形式在函数调用栈中进行传递，
  - 第二种方法就是将监听器作为静态变量供线程访问。

上述这两种方法都是有局限性的。

第一种方法的问题是当函数调用栈很深的时候，通过函数参数来传递监听器对象这几乎是不可接受的，这会让程序的设计看起来很糟糕。
第二种方法是可以接受的，但是这种状态是不具有可扩充性的，比如同时有两个线程在执行，那么就需要提供两个静态的监听器对象，如果有10个线程在并发执行呢？提供10个静态的监听器对象？这显然是不可思议的，而采用ThreadLocal，每个监听器对象都在自己的线程内部存储，根本就不会有方法2的这种问题。

1.2、每个线程需要一个独享的对象

对于拿到时间戳，我们通常需要通过SimpleDateFormat类来将其转换成相应的日期格式，假设我们有如下一个工具类：

public class DateUtils {
   
   

    public static String format(long milliSeconds) {
   
   
      	SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd hh:mm:ss");
        return dateFormat.format(new Date(milliSeconds));
    }
}

现在我们通过线程池来模拟多线程环境：

public class ThreadLocalTest2 {
   
   

    private static ExecutorService threadPool = Executors.newFixedThreadPool(5);

    public static void main(String[] args) {
   
   

        for (int i = 0; i < 10; i++) {
   
   
            int finalI = i;
            threadPool.submit(() -> {
   
   
                String result = DateUtils.format(finalI * 1000);
                System.out.println(result);
            });
        }

        threadPool.shutdown();
    }

}

运行后的输出结果如下：

1970-01-01 08:00:03
1970-01-01 08:00:00
1970-01-01 08:00:02
1970-01-01 08:00:04
1970-01-01 08:00:01
1970-01-01 08:00:05
1970-01-01 08:00:08
1970-01-01 08:00:06
1970-01-01 08:00:09
1970-01-01 08:00:07

现在一切都是正常的，但是由于每次调用format方法都是创建一个新的SimpleDateFormat对象，这样是没有必要的。我们可以有如下修改：

public class DateUtils {
   
   

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

    public static String format(long milliSeconds) {
   
   
        return dateFormat.format(new Date(milliSeconds));
    }
}

现在再运行代码：

1970-01-01 08:00:02
1970-01-01 08:00:02
1970-01-01 08:00:02
1970-01-01 08:00:02
1970-01-01 08:00:07
1970-01-01 08:00:02
1970-01-01 08:00:09
1970-01-01 08:00:09
1970-01-01 08:00:07
1970-01-01 08:00:07

从结果来看，明显这种写法已经出问题了，数据重复，并发问题。那么该怎么去解决这个问题呢？接下来，就轮到我们今天的主人公ThreadLocal登场啦！

class DateUtils {
   
   

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

    public static String format(long milli