FastThreadLocal 通过线程专属数组与固定下标实现零哈希、零探测的直接访问，提升缓存局部性与查找速度；需搭配 FastThreadLocalThread 使用，static final 复用实例避免索引爆炸。
FastThreadLocal 为什么能提升缓存局部性与索引查找速度
因为它的底层不是哈希表，而是线程专属的 InternalThreadLocalMap 数组，每个 FastThreadLocal 实例在创建时就通过 AtomicInteger 分配一个固定数组下标（index），后续 get()/set() 全部走直接数组访问 —— 零哈希计算、零线性探测、零对象遍历。
而 JDK ThreadLocal 的 ThreadLocalMap 是基于开放寻址法的哈希表，getEntry() 可能触发多次内存跳转（cache miss），尤其在高并发下哈希冲突升高时，性能会明显抖动。
缓存局部性提升的关键在于：同一个线程的多个 FastThreadLocal 值，都落在 InternalThreadLocalMap.values 这个连续数组里，CPU 预取友好；而 ThreadLocalMap.table 中的 Entry 对象分散堆内存，彼此无空间关联。
必须搭配 FastThreadLocalThread 才能发挥全部优势
FastThreadLocal 的高性能依赖线程对象自带 InternalThreadLocalMap 字段。普通 Thread 没有这个字段，此时 FastThreadLocal.get() 会 fallback 到内部一个备用的 ThreadLocal<internalthreadlocalmap></internalthreadlocalmap>（即 slowThreadLocalMap），多一层间接引用和同步开销，性能打七折。
所以实际使用中要确保线程类型是 FastThreadLocalThread：
- 显式创建：
new FastThreadLocalThread(() -> { /* ... */ }) - 更推荐用 Netty 的
DefaultThreadFactory，它默认返回FastThreadLocalThread，且自动包装Runnable为FastThreadLocalRunnable，任务结束时调用removeAll() - 若混用普通
Thread，get()日志里会出现slowGet警告，说明已降级
set/get/remove 的行为差异与清理时机
FastThreadLocal 不用弱引用 Key，不自动清理失效条目，但也不靠 GC 触发清理 —— 它把责任交还给使用者，同时提供更可控的释放路径：
-
set(null)不等价于remove()：前者只是把数组对应位置设为null，后者还会标记该FastThreadLocal实例为“已移除”，避免后续onRemoval()被重复调用 -
remove()必须显式调用，否则值残留；但若用FastThreadLocalRunnable包装的任务，会在run()结束后自动触发InternalThreadLocalMap.removeAll() - 如果重写了
onRemoval()，注意它只在remove()或removeAll()时被调用，不会在 GC 回收FastThreadLocal实例时触发（没弱引用）
索引复用与初始化成本的真实影响
每个 FastThreadLocal 实例首次 get() 或 set() 时，才会分配全局唯一 index（由 FAST_THREAD_LOCALS_COUNTER 自增）。这个 index 一旦分配，终身绑定该实例 —— 即使该实例被丢弃，index 也不会回收。
这意味着：
- 频繁 new
FastThreadLocal（如每次请求 new 一个）会导致 index 疯涨，InternalThreadLocalMap.values数组被迫不断扩容，反而降低局部性 - 正确做法是将
FastThreadLocal声明为static final，复用同一个实例，让所有线程都往同一 index 写/读 - 数组扩容本身是线程安全但非零成本的操作，
InternalThreadLocalMap默认初始容量为 32，负载因子 2/3，超限则翻倍复制
真正容易被忽略的是：索引分配不可逆，且不感知实例生命周期。写错一次 new，压测时可能看到 values 数组长度从 32 涨到 2048，cache line 利用率断崖下跌。
