threadlocalmap 扩容由 size ≥ threshold 触发，threshold 初始为数组长度的 2/3；扩容前先清理过期 entry，清理后若 size ≥ threshold×3/4 再 resize；其斐波那契散列保障哈希均匀，减少假性扩容；实际容量瓶颈多源于 threadlocal 使用不当而非机制缺陷。
ThreadLocalMap 的扩容不是靠“预估够不够用”，而是由明确的阈值条件触发，核心是控制哈希冲突率与空间利用率之间的平衡。只要遵循它的设计逻辑，容量自然能动态适配——关键不在“手动保证够用”，而在理解它何时、为何、如何扩容。
扩容触发条件：size ≥ threshold
ThreadLocalMap 维护一个 threshold（阈值），初始值为数组长度的 2/3（即 threshold = len * 2 / 3）。每次成功调用 set() 插入新 Entry 后，会递增 size 计数器，并立即判断：
- 若
size >= threshold，则触发rehash() -
rehash()内部先尝试启发式清理（expungeStaleEntries），若清理后size仍 ≥threshold * 3/4，才真正执行resize()
扩容不是简单翻倍，而是有清理前置动作
直接扩容前，ThreadLocalMap 会先做一次主动清理，这是它和 HashMap 的关键区别：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 遍历整个 table，清除所有 key == null 的过期 Entry（因 ThreadLocal 是弱引用，GC 后 key 可能为 null）
- 清理过程还会顺带压缩有效 Entry，可能使 size 显著下降
- 只有清理后剩余元素仍“太挤”，才会新建长度为原数组 2 倍的新表，并重新散列所有存活 Entry
哈希分布质量直接影响扩容频率
ThreadLocalMap 使用斐波那契散列（key.threadLocalHashCode & (len - 1)），配合固定增量 0x61c88647，让不同 ThreadLocal 实例的 hash 值在数组索引上高度均匀。这意味着：
- 相同数组长度下，冲突更少 → 更少探测 → 更少无效占位 → 实际可用容量更高
- 不会因为个别 key 聚堆而提前触发扩容，避免了假性“容量不足”
- 所以你无需干预 hash 算法，只要不滥用 ThreadLocal（比如在循环中反复 new），分布天然可靠
实际开发中真正影响容量是否“够用”的，往往是使用方式
扩容机制本身很稳健，但以下行为会让 threshold 很快被突破，导致频繁 rehash 或内存浪费：
- 在线程生命周期内持续
set()大量不同 ThreadLocal 实例（尤其未remove()） - 在长生命周期线程（如线程池中的 Worker）中泄漏 ThreadLocal，过期 key 积压，清理不及时
- 误以为 ThreadLocal 可复用 key，反复用同一个 ThreadLocal 存不同业务对象，但没意识到每个 set 都是新 Entry（除非覆盖同一槽位）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
