简单说就是，ThreadLocal 的 key 用的是“弱引用”，这样如果它没用了，
垃圾回收器可以及时把它清理掉，不会让它赖在内存里白白占地方，从而避免资源浪费。 🗑️💡

🧠 知识内容
🚀 1. 设计原因
如果 ThreadLocalMap 的键使用 强引用，会产生以下问题：

🧵 线程池问题：
线程池中的线程通常会长时间存在，而 ThreadLocal 的生命周期较短。如果使用强引用，ThreadLocal 即使不再使用，仍然无法被回收。

📈 引用链：
强引用会导致以下链条无法断开：

Thread -> ThreadLocalMap -> Entry (key: ThreadLocal, value)
即使 ThreadLocal 对象没有被使用，它仍然因为强引用的存在无法被回收，从而浪费内存资源。

解决方案：

使用 弱引用！
弱引用的特性是，当垃圾回收器发现没有其他强引用指向 ThreadLocal 对象时，会将其回收，从而断开引用链，避免内存泄漏。
🔗 2. 弱引用的引用链
当 ThreadLocal 对象不再被强引用时，以下情况发生：

🔄 GC 自动回收：
弱引用不会阻止垃圾回收器回收对象。此时，ThreadLocalMap 中的键会变为 null，但值仍然存在。

🧹 清理机制：
ThreadLocal 在每次 get 或 set 操作时，都会遍历其内部的 Entry 表，检查是否存在 key == null 的条目，并清理无用的 Entry。这减少了内存泄漏的风险。

🛠 3. 示例代码
public class WeakReferenceExample {
private static ThreadLocal threadLocal = new ThreadLocal<>();

public static void main(String[] args) {
    threadLocal.set("Hello, WeakReference!");

    Thread thread = new Thread(() -> {
        System.out.println("ThreadLocal value: " + threadLocal.get());
        threadLocal.remove(); // 主动清理，避免泄漏
    });

    thread.start();
}

}

🌍 知识拓展

  1. 值为什么不是弱引用？ 🤔
    如果值也使用弱引用，当 GC 回收时，值会丢失，导致业务逻辑异常。
    所以值必须是强引用，以确保正常使用期间不会被 GC 回收。
  2. 手动清理的重要性 🧹
    即使设计了弱引用机制，也需要通过 remove() 方法主动清理不需要的 ThreadLocal 数据。
    💡 建议：
    每次使用 ThreadLocal 后，尽量调用 remove() 方法进行清理，尤其是在线程池场景中。
  3. 内存泄漏防护机制 🛡️
    Java 的设计者意识到内存泄漏的风险，在多个场景中增加了清理机制，例如：
    get 和 set 操作时自动清理无用的条目。
    扩容时清理： 当 ThreadLocalMap 扩容时，会遍历并删除 key == null 的条目。
    💡 总结
    🌟 弱引用是避免 ThreadLocal 内存泄漏的关键设计。
    🧹 手动清理是良好的编码习惯，确保线程池中不会出现数据残留问题。
    🛠️ 合理使用 ThreadLocal，避免因过度依赖导致性能问题。