一、背景介绍
小弟最近做了一个管理后台操作记录落DB的小需求，实现过程中需要获取操作用户的登陆信息，但是登陆信息需要从公司另一个AD服务系统中通过RPC方式进行查询，为了既达到判断用户的登陆状态，又能够在CRUD中使用到登陆信息。本人实现的思路是，在CRUD请求到达Controller层前，使用拦截器捕获到请求，调用AD服务验证请求携带的Cookie信息是否有效，并且获取到用户的"账号、UID、其他基本信息"，为了能够在Service层获取到这些基本信息，又不能再次去调用AD服务【调用过程比较耗时】，本人决定将用户态信息保存到ThreadLocal中，这样在同一个线程中的方法都可以访问到。、
实现起来没有问题，但是小弟突然想到，线程执行完毕后，这个线程对应的用户态信息还会存在吗，是否会被JVM自动回收，如果不被即时回收，大量的CRUD会不会影响服务器的内存。并且为了将之前粗略浏览过一遍的《深入理解JVM虚拟机》进行实践，引发了本题。即”ThreaLoacl的内存结构深入剖析“+”ThreadLocal的垃圾回收机制是怎样进行的”
二、ThreadLocal原理
2.1ThreadLocal概述
2.2ThreadLocal的结构
2.3ThreadLocal的回收策略
通过阅读源码，我们可以很清楚的了解它的垃圾回收方式。下面看一下源码的doc说明文档
Each thread holds an implicit reference to its copy of a thread-local
* variable as long as the thread is alive and the {@code ThreadLocal}
* instance is accessible; after a thread goes away, all of its copies of
* thread-local instances are subject to garbage collection (unless other
* references to these copies exist).
是不是很清楚了，“只要这个线程存在，并且ThreadLocal实例可访问，那么这个线程就持有对thread-local的隐式引用，但是当这个线程消失（即执行完毕），它所持有的thread_local备份就会进入垃圾回收中（除非还有其他的引用指向这个备份）”
当然如果只是止步于此的话，就没有必要写这篇文章了。下面继续剖析下它为什么可以随着线程的消失而将备份进行垃圾回收呢。
（1）虚引用
https://www.cnblogs.com/mfrank/p/9837070.html
https://www.jianshu.com/p/825cca41d962
软引用、弱引用、虚引用-他们的特点及应用场景
（2）软引用
(3) 弱引用
（4）强引用
三、关于引用的类型
四、关于垃圾的回收机制