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是解决了线程安全问题，大都是望文生义，二者完全非同类问题，读者需要有自己的思考呀。
