具体细节?浪院长 | spark streaming的使用心得
的作用是提供线程内的局部变量，这种变量在线程的生命周期内起作用，减少同一个线程内多个函数或者组件之间一些公共变量的传递的复杂度。但是如果滥用 ，就可能会导致内存泄漏。下面，我们将围绕三个方面来分析 内存泄漏的问题
ThreadLocal
的实现是这样的：每个 维护一个
映射表，这个映射表的 是 实例本身， 是真正需要存储的 。
也就是说 本身并不存储值，它只是作为一个 来让线程从 获取 。值得注意的是图中的虚线，表示 是使用 的弱引用作为 的，弱引用的对象在 GC 时会被回收。
使用的弱引用作为，如果一个没有外部强引用来引用它，那么系统 GC 的时候，这个势必会被回收，这样一来，中就会出现为的，就没有办法访问这些为的的，如果当前线程再迟迟不结束的话，这些为的的就会一直存在一条强引用链：永远无法回收，造成内存泄漏。
其实，的设计中已经考虑到这种情况，也加上了一些防护措施：在的,,的时候都会清除线程里所有为的。
但是这些被动的预防措施并不能保证不会内存泄漏：
从表面上看内存泄漏的根源在于使用了弱引用。网上的文章大多着重分析使用了弱引用会导致内存泄漏，但是另一个问题也同样值得思考：为什么使用弱引用而不是强引用？
我们先来看看官方文档的说法：
To help deal with very large and long-lived usages, the hash table entries use WeakReferences for keys.
为了应对非常大和长时间的用途，哈希表使用弱引用的 key。
下面我们分两种情况讨论：
比较两种情况，我们可以发现：由于的生命周期跟一样长，如果都没有手动删除对应，都会导致内存泄漏，但是使用弱引用可以多一层保障：弱引用不会内存泄漏，对应的在下一次调用,,的时候会被清除。
因此，内存泄漏的根源是：由于的生命周期跟一样长，托福考试报名费如果没有手动删除对应就会导致内存泄漏，而不是因为弱引用。
综合上面的分析，我们可以理解内存泄漏的前因后果，那么怎么避免内存泄漏呢？
在使用线程池的情况下，没有及时清理，不仅是内存泄漏的问题，更严重的是可能导致业务逻辑出现问题。所以，使用就跟加锁完要解锁一样，用完就清理。
原文地址：http://blog.xiaohansong.com/2016/08/06/ThreadLocal-memory-leak/
今天下午八点的分享，可以参与团购，然后联系 158570986.
或者点击阅读原文直接加入知识星球，获取更多教程。
文章来源：https://blog.csdn.net/rlnLo2pNEfx9c/article/details/82599223