synchronized + volatile + ThreadLocal

线程的共享 synchronized  +  volatile + ThreadLocal

<1> synchronized 锁住的是对象，当用它来锁住一个类时，实际上也是锁的一个对象。 用了synchronized 就没必要用 volatile， 对于 synchronized 锁住的对象。

<2>最轻量的同步机制 volatile：
特性：只保证可见性。 如定义一个static变量，在主线程中改变了它，分线程不能感知到主线程修改了它。
适用场景：大量读，少量写。

<3>ThreadLocal: 为每一个线程提供变量的副本，实现线程的隔离，每个线程只访问自己的数据。 如：spring在实现事务的时候，TransactionManager, @Transactional.
为什么spring在实现事务的时候要引入ThreadLocal? 答案：每个线程保存自己的连接, 可能调用多次dao, 避免每次调dao都要传递参数connection。
那么是不是可以考虑把 连接 绑定到这个线程上面？？ 这就是spring在实现事务的时候使用 ThreadLocal 的原因。 一般用到的方法有： set(T) get() remove()
Thread 类中有一个成员变量， ThreadLocalMap threadLocals。 ThreadLocalMap 以 ThreadLocal<>为键，里面定义了一个 Entry[]数组。 因为一个线程拥有的副本可能有多个，初始大小为16.

class ThreadLocalMap{ static class Entry{} private Entry[] entry; } 通过位运算取到自己的副本。当我们set到ThreadLocal时，实际上是赋值给我们自己的ThreadLocalMap。
当有重复的时候，它会用nextHashCode()再计算。 ThreadLocal不保证变量同步

强引用：Object obj = new Object();
SoftRefence 要发生内存溢出了，强制回收;
弱引用：只要发生gc，就一定会回收； Entry extends WeakRefence. 可以看出ThreadLocal是软引用。
虚引用：最弱。

引发的内存泄露分析：
Stack Heap

ThreadLocalRef ---- ThreadLocal -- [key, value]
/
CurrentThreadRef ---- CurrentThread -- Map

当我们发生gc时，threadLocal被回收，value就无法被引用到了。即发生内存泄漏。 解决办法： threadLocal.remove();

get/set方法中都有调清除，但是不保证一定清除。 但是remove一定清除。 没内存泄露是可能一直在调用 set/get 方法

那它为什么要用弱引用？ 如果用强引用，发生内存泄漏就是必然的。因为Map指向的必然。。。。

ThreadLocal 线程不安全？？？ 因为它可以存共享变量，虽然是不同的引用，但是实例是一个。