| ThreadLocal弱引用与内存泄漏分析 | 您所在的位置：网站首页 › threadlocal为什么不用强引用 › ThreadLocal弱引用与内存泄漏分析 |
ThreadLocal弱引用与内存泄漏分析
|
本文对ThreadLocal弱引用进行一些解析，以及ThreadLocal使用注意事项。 ThreadLocal首先，简单回顾一下，ThreadLocal是一个线程本地变量，每个线程维护自己的变量副本，多个线程互相不可见，因此多线程操作该变量不必加锁，适合不同线程使用不同变量值的场景。 其实现原理这里就不做详细阐述，其数据结构是每个线程Thread类都有个属性ThreadLocalMap，用来维护该线程的多个ThreadLocal变量，该Map是自定义实现的Entry[]数组结构，并非继承自原生Map类，Entry其中Key即是ThreadLocal变量本身，Value则是具体该线程中的变量副本值。结构如图: 因此ThreadLocal其实只是个符号意义，本身不存储变量，仅仅是用来索引各个线程中的变量副本。 值得注意的是，Entry的Key即ThreadLocal对象是采用弱引用引入的，如源代码： static class ThreadLocalMap { /** * The entries in this hash map extend WeakReference, using * its main ref field as the key (which is always a * ThreadLocal object). Note that null keys (i.e. entry.get() * == null) mean that the key is no longer referenced, so the * entry can be expunged from table. Such entries are referred to * as "stale entries" in the code that follows. */ static class Entry extends WeakReference k = e.get(); if (k == null) { e.value = null; tab[i] = null; size--; } else { int h = k.threadLocalHashCode & (len - 1); if (h != i) { tab[i] = null; // Unlike Knuth 6.4 Algorithm R, we must scan until // null because multiple entries could have been stale. while (tab[h] != null) h = nextIndex(h, len); tab[h] = e; } } } return i; }private void set(ThreadLocal key, Object value) { // We don't use a fast path as with get() because it is at // least as common to use set() to create new entries as // it is to replace existing ones, in which case, a fast // path would fail more often than not. Entry[] tab = table; int len = tab.length; int i = key.threadLocalHashCode & (len-1); for (Entry e = tab[i]; e != null; e = tab[i = nextIndex(i, len)]) { ThreadLocal k = e.get(); if (k == key) { e.value = value; return; } if (k == null) { replaceStaleEntry(key, value, i); return; } } tab[i] = new Entry(key, value); int sz = ++size; if (!cleanSomeSlots(i, sz) && sz >= threshold) rehash(); } 复制代码
上述方法的作用是擦除某个下标的Entry（置为null，可以回收），同时检测整个Entry[]表中对key为null的Entry一并擦除，重新调整索引。 该方法，在每次调用ThreadLocal的get、set、remove方法时都会执行，即ThreadLocal内部已经帮我们做了对key为null的Entry的清理工作。 但是该工作是有触发条件的，需要调用相应方法，假如我们使用完之后不做任何处理是不会触发的。 在该方法中针对脏entry做了这样的处理： 如果当前table[i]！=null的话说明hash冲突就需要向后环形查找，若在查找过程中遇到脏entry就通过replaceStaleEntry进行处理；如果当前table[i]==null的话说明新的entry可以直接插入，但是插入后会调用cleanSomeSlots方法检测并清除脏entry 总结 （强制）在代码逻辑中使用完ThreadLocal，都要调用remove方法，及时清理。目前我们使用多线程都是通过线程池管理的，对于核心线程数之内的线程都是长期驻留池内的。显式调用remove，一方面是防止内存泄漏，最为重要的是，不及时清除有可能导致严重的业务逻辑问题，产生线上故障（使用了上次未清除的值）。 最佳实践：在ThreadLocal使用前后都调用remove清理，同时对异常情况也要在finally中清理。 （非规范）对ThreadLocal是否使用全局static修饰的讨论。在某些代码规范中遇到过这样一条要求：“尽量不要使用全局的ThreadLocal”。关于这点有两种解读。最初我的解读是，因为静态变量的生命周期和类的生命周期是一致的，而类的卸载时机可以说比较苛刻，这会导致静态ThreadLocal无法被垃圾回收，容易出现内存泄漏。另一个解读，我咨询了编写该规范的对方解释是，如果流程中改变了变量值，下次复用该流程可能导致获取到非预期的值。 但实际上，这两个解读都是不必要的，首先，静态ThreadLocal资源回收的问题，即使ThreadLocal本身无法回收，但线程中的Entry是可以通过remove清理掉的也就不会出现泄漏。第二种解读，多次复用值改变的问题，其实在调用remove后也不会出现。 而如果ThreadLocal不加static，则每次其所在类实例化时，都会有重复ThreadLocal创建。这样即使线程在访问时不出现错误也有资源浪费。 因此，ThreadLocal一般加static修饰，同时要遵循第一条及时清理。 notice JVM利用设置ThreadLocalMap的Key为弱引用，来避免内存泄露。JVM利用调用remove、get、set方法的时候，回收弱引用。当ThreadLocal存储很多Key为null的Entry的时候，而不再去调用remove、get、set方法，那么将导致内存泄漏。当使用static ThreadLocal的时候，延长ThreadLocal的生命周期，那也可能导致内存泄漏。因为，static变量在类未加载的时候，它就已经加载，当线程结束的时候，static变量不一定会回收。那么，比起普通成员变量使用的时候才加载，static的生命周期加长将更容易导致内存泄漏危机 |
【本文地址】
| 今日新闻 |
| 推荐新闻 |
| 专题文章 |