threadlocal为什么设计成弱引用,软引用和弱引用的区别

threadlocal为什么设计成弱引用,软引用和弱引用的区别

ThreadLocal的设计亮点之一是ThreadLocalMap中的Entry结构体的Key使用弱引用。 试想一下，如果使用强引用，就意味着ThreadLocalMap中的所有数据都会绑定到Thread的生命周期。这种情况很容易发生，因为ThreadLocal和对应的值不会被回收，从而导致内存泄漏。 SoEntry使用弱引用来避免

弱引用会被自动清理，也就是说：如果用户在执行方法时生成了threadlocalA的副本，然后threadlocalA长期不使用，作为弱引用，下次就会成为垃圾，因为ThreadLocalMap中的Entrykey持有对ThreadLocal对象的弱引用，当且仅当这个ThreadLocal对象被ThreadLocalMap中的Entry引用时，才会发生GC，这会导致当前ThreadLocal对象被回收;然后

?﹏? 而这个ThreadLocalMap实际上可以在任何地方访问。 因此，他实际上存储的是全局变量，但全局的答案是：ThreadLocal对象不会被垃圾收集器回收。 因为从thread对象开始，有一个指向threadlocalobj的强引用。 这时候就会违背用户的初衷，造成所谓的内存泄漏。 由于Th

其中：实线代表强引用，虚线代表弱引用（弱引用生命周期较短，在进行垃圾回收时，一旦发现只有弱引用的对象，无论当前内存空间是否充足，其内存都会被回收）。 看到这里，我们就明白了（1）由于ThreadLocalMap的生命周期和Thread一样长，如果不手动删除，可能会导致内存泄漏，而弱引用却多了一层保护：当使用弱引用时，ThreadLocal无论如何都不会被删除。 无罪

线程本地对象。 k，我们通过弱引用指出了这一点。 JVM使用虚拟引用来指向ThreadLocal。为什么要这样设计呢？ 因为如果使用强引用，可能会发生内存泄漏（tl生命周期结束后，ThreadLocal在垃圾回收时首先弱引用，即使有弱引用​​，引用的对象也会被回收。看过threadlocal源码的同学一定知道，threadlocal内部，在threadThread类中创建了一个新的类似map的结构。