四种常见的引用
强引用---不可回收
软引用---内存不足即回收
弱引用---发现即回收
虚引用---形同虚设，目的是用于对象回收跟踪
ThreadLocal
1、ThreadLoca 是什么
ThreadLocal并不是一个Thread，而是Thread的局部变量
在jdk解决并发问题上，threadLocal是一种使用空间换时间的思路，ThreadLocal为每个线程提供一个独立的变量副本 解决了变量并发访问的冲突问题。
我的项目中，运用了threadLocal保存用户信息，实现客户端请求会话的隔离，保证了多用户的多会话请求的线程安全。
同时，使用完threadLocal后，删除value，防止了threadLocal引起的内存泄漏
★ threadLocal 为什么会导致内存泄漏----强引用、弱引用
----（这面试说强引用。弱引用。不是明摆着让面试官间JVM嘛）
主要是涉及到对象的强应用、弱引用问题
- 强引用---不可回收
- 弱引用---发现即回收
查看源码发现，每个线程都有一个自己的ThreadLocalMap对象，ThreadLocalMap的 key 是存储threadLocal的引用，vaule存储变量的副本
2、ThreadLocal的原理
1．ThreadLocal是Java中所提供的线程本地存储机制，可以利用该机制将数据缓存在某个线程内部，该线程可以在任意时刻、任意方法中获取缓存的数据
2．ThreadLocal底层是通过ThreadLocalMap来实现的，每个Thread对象（注意不是ThreadLocal对象）中都存在一个ThreadLocalMap，Map的key为 ThreadLocal对象，Map的value为需要缓存的值
其中，threadLocal对象是弱引用，在GC的时候，会被自动回收。而value就是ThreadLocal类 set设置的数据。value是强引用，不会被GC。
3、为什么用ThreadLocal做key？
不知道你有没有思考过这样一个问题：ThreadLocalMap为什么要用ThreadLocal做key，而不是用Thread做key？
确实，jdk早期的设计，是 threadLocal 维护 threadLocalMap，而线程作为key，
但是这种设计在 jdk8 之后，就被取代了，变成 thread 维护 threadLocalMap，而 threadLocal 作为 key
是因为我们知道线程的数量往往比threadLocal 多，jdk8的设计就可以使得 threadLocalMap 存储的 entry 数量变少。
也更加的节省了内存，当 thread 销毁了， 对应 threadLocalMap 也会被销毁
4、为什么把ThreadLocal设计成弱引用？
是最大程度的解决内存泄露问题，因为threadLocal 设计成弱引用，GC 的时候，发现它即可回收。
- 使用get、set或remove方法清理key为null的value值
5、为什么内存泄露
- 涉及到强引用和弱引用。因为我的项目为了查看文章详情同时更新阅读浏览数，引入了线程池。
- 线程池中使用ThreadLocal会造成内存泄漏，因为当ThreadLocal对象使用完之后，应该要把设置的key，value，也就是Entry对象进行回收，
但线程池中的线程不会回收，而线程对象是通过强引用指向ThreadLocalMap，ThreadLocalMap也是通过强引用指向Entry对象，线程不被回收，Entry对象也就不会被回收，从而出现内存泄漏 - 解决办法是，在使用了ThreadLocal对象之后，手动调用ThreadLocal的remove方法，手动清除Entry对象
★ 项目细节：
使用一个拦截器拦截请求，从cookie中获取token字符串与redis中的token进行匹配，获取用户信息，将用户信息存储到ThreadLocal中，在本次请求中持有用户信息，即可在后续操作中使用到用户信息。
★ 项目细节：在登录拦截器中prehandle方法中：验证token成功后，将用户信息存储到threadLocal；在afterCompletion方法中：对threadLocal做了value的删除，防止内存泄漏。
