ThreadLocal能解决线程安全问题？胡扯！本文教你正确的使用姿势

转自 腾讯云：https://cloud.tencent.com/developer/article/1600714

---

ThreadLocal使用的正确姿势

说了这么多，那使用它的正确姿势是什么呢？正确姿势用文字无法表达，请以如下使用示例为参照。

众所周知，SimpleDateFomat是线程不安全的，所以若我们这样定义一个全局模版：

public static final DateFormat DATE_FORMAT = new SimpleDateFormat("yyyy-MM-dd");

在多线程访问的情况下，那必然会有多线程安全问题。

而通过如上表述，这么做也依旧是不靠谱的，依旧解决不了多线程安全问题。

public static final ThreadLocal<DateFormat> DATE_FORMAT_THREAD_LOCAL = new InheritableThreadLocal<>();
static {
    DATE_FORMAT_THREAD_LOCAL.set(new SimpleDateFormat("yyyy-MM-dd"));
}

其实关于它的使用，阿里巴巴已经在它的规范手册里给出了使用示范：

public static final ThreadLocal<DateFormat> DATE_FORMAT_THREAD_LOCAL = new InheritableThreadLocal<DateFormat>() {
    @Override
    protected DateFormat initialValue() {
        return new SimpleDateFormat("yyyy-MM-dd");
    }
};

这么处理后再使用DateFormat这个实例，就是绝对安全的。理由是每次调用set方法进行和线程绑定的时候，都是new一个新的SimpleDateFormat实例，而并非全局共享一个，不存在了数据共享那必然就线程安全喽。

当然你可能会说，这和自己在线程里面每次你自己new一个出来用有什么区别呢？答案是：效果上没任何区别，但是这样方便。比如：可以保持线程里面只有唯一一个SimpleDateFormat对象，你要手动new的话，一不小心就new多个了，消耗内存不说还不好管理。

可能你还会说，那只new一个实例，然后哪个方法要用就通过参数传给它就行。答案还是一样的：不嫌麻烦的话，这样做也是能达到效果的。

然而，对于这种全局通用的变量，使用ThreadLocal管理和维护一份即可，大大的降低了维护成本和他人的使用成本。so，只要你使用它的姿势正确了，它能让你事半功倍，特别是如果你是写中间件的小伙伴的话，跟它打交道会更为频繁。

---

总结

本文总体上算是一篇纠错文章，希望更多人能够看到，多多转发，为社区献上微薄之力。

ThreadLocal并不是为了解决线程安全问题，而是提供了一种将变量绑定到当前线程的机制，类似于隔离的效果。ThreadLocal跟线程安全基本不搭边：线程安全or不安全取决于绑上去的实例是怎样的：

• 每个线程独享一份new出来的实例 -> 线程安全
• 多个线程共享一份“引用类型”实例 -> 线程不安全

ThreadLocal最大的用处就是用来把实例变量共享成全局变量，在程序的任何方法中都可以访问到该实例变量而已。网上很多人说ThreadLocal是解决了线程安全问题，大都是望文生义，二者完全非同类问题，读者需要有自己的思考呀。