Java并发神器——ThreadLocal
定义
threadlocal是线程局部变量，不同线程的threadlocal相互独立。它是一种保存线程私有信息的机制，因为在现成的整个生命周期都有效，
所以可以方便地在一个线程关联的不同业务模块之间传递信息，比如事务id、cookie等上下文相关信息。
特点：
- 简单，开箱即用。
- 快速，无额外开销。
-
安全，线程安全。
threadlocal设计实现的优点：开箱即用，代码易读，符合经常阅读偶尔使用的原则
场景：资源持有、线程一致性、并发计算等多线程场景。
api
场景分析
如jdbc事务的请求，part i 代表不同事务，如更新用户信息、更新订单信息等，需要保证各事务资源的一致性。
每一个事务请求连接时，先去threadlocal map里找，如果不存在，到连接池中请求分配连接，并存入map。
总结，threadlocal的主要作用是：
- 持有线程资源，供线程的各个部分使用
- 帮助维护多线程共享资源的一致性
- 线程安全的一种方案
场景实验，观察spring框架在多线程场景的执行情况
压力测试工具，apache2-util
10000此请求，单线程
10000次请求，线程数加到100
虽然完成10000请求的速度变快了，但最终curl请求get到的数据会不一致。
原因是，多线程下，c是临界资源，c=c+1不具备原子性，要先读取c，在执行加1，再执行赋值。
对c的访问加锁
测试发现curl get到的结果是10000，但速度会很慢，原因是加锁导致排队，并发实质上变成了串行，性能被锁卡住。
解决方法就是使用threadlocal，让线程在自己的局部变量资源上运行。
把c设为threadlocal
测试发现，最终统计数据依然不准确。
原因是spring默认线程池有20多个线程，这些线程每一个都有自己的局部变量c，执行10000请求后，需要收集各个线程的数据。
收集多个threadlocal中的数据
虽然threadlocal是各个线程独占的数据，但也是进程持有的，不过java没有提供收集数据的接口，所以可以通过hashmap或hashset来存储threadlocal，最后一并收集。
改进，因为set访问需要同步，所以addset中加入同步锁，而且set访问次数最多是线程池的线程数，相对c的访问次数要少，属于低频访问，所以对总体性能影响小。
实验总结
- 基于线程池模型加同步锁很危险，可能因排队等锁，导致cpu使用不充分，从而严重拖慢性能。
- 虽然多线程不能完全避免同步问题，但使用threadlocal，可以把高频同步化为低频同步。
实现原理
自定义hashmap存放threadlocal弱引用
- 自定义的hashmap延续了lazy-load模式，初始容量16，门限2/3
- 弱引用解决了内存回收的问题，回收被内存回收的弱引用所占的槽
hash算法
散列更均匀，减少冲突
总结
解决一致性问题，除了排队（加锁）、投票（拜占庭将军）、cas+voilate外，threadlocal不失为一个更轻量级的优选方案。