Shulou(Shulou.com)06/03 Report--

This article mainly introduces "what is the cause of memory leak". In daily operation, I believe that many people have doubts about the cause of memory leak. The editor consulted all kinds of data and sorted out simple and easy-to-use operation methods. I hope it will be helpful for you to answer the question of "what is the cause of memory leak?" Next, please follow the editor to study!

The use of ThreadLocal is not standard, two lines of tears from the master

There is an intern in the group. Seeing that this young man is full of spring, full of energy and little hair, I am delighted: it is definitely a potential stock. So I asked the manager to apply to bring him in person. In order to help the young man grow up quickly, I gave him a need. There was no need to have an online problem just a few days after being online. The background monitoring service found that memory has been rising slowly and is initially suspected to be a memory leak.

Find out the intern's PR and review carefully, and sure enough, found the problem. Since the company's internal code is confidential, here is a simple demo restore scenario (ignoring code style issues).

Public class ThreadPoolDemo {private static final ThreadPoolExecutor poolExecutor = new ThreadPoolExecutor (5,5,1, TimeUnit.MINUTES, new LinkedBlockingQueue ()); public static void main (String [] args) throws InterruptedException {for (int I = 0; I)

< 100; ++i) { poolExecutor.execute(new Runnable() { @Override public void run() { ThreadLocal threadLocal = new ThreadLocal(); threadLocal.set(new BigObject()); // 其他业务代码 } }); Thread.sleep(1000); } } static class BigObject { // 100M private byte[] bytes = new byte[100 * 1024 * 1024]; } } 代码分析： 创建一个核心线程数和最大线程数都为10的线程池，保证线程池里一直会有10个线程在运行。 使用for循环向线程池中提交了100个任务。 定义了一个ThreadLocal类型的变量，Value类型是大对象。 每个任务会向threadLocal变量里塞一个大对象，然后执行其他业务逻辑。 由于没有调用线程池的shutdown方法，线程池里的线程还是会在运行。 乍一看这代码好像没有什么问题，那为什么会导致服务GC后内存还高居不下呢? 代码中给threadLocal赋值了一个大的对象，但是执行完业务逻辑后没有调用remove方法，最后导致线程池中10个线程的threadLocals变量中包含的大对象没有被释放掉，出现了内存泄露。 大家说说这样的实习生还能留不? ThreadLocal的value值存在哪里? 实习生说他以为线程任务结束了threadLocal赋值的对象会被JVM垃圾回收，很疑惑为什么会出现内存泄露。作为师傅我肯定要给他把原理讲透呀。 ThreadLocal类提供set/get方法存储和获取value值，但实际上ThreadLocal类并不存储value值，真正存储是靠ThreadLocalMap这个类，ThreadLocalMap是ThreadLocal的一个静态内部类，它的key是ThreadLocal实例对象，value是任意Object对象。 ThreadLocalMap类的定义 static class ThreadLocalMap { // 定义一个table数组，存储多个threadLocal对象及其value值 private Entry[] table; ThreadLocalMap(ThreadLocal firstKey, Object firstValue) { table = new Entry[INITIAL_CAPACITY]; int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1); table[i] = new Entry(firstKey, firstValue); size = 1; setThreshold(INITIAL_CAPACITY); } // 定义一个Entry类，key是一个弱引用的ThreadLocal对象 // value是任意对象 static class Entry extends WeakReference>

{/ The value associated with this ThreadLocal. * / Object value; Entry (ThreadLocal k, Object v) {super (k); value = v;}} / / omit other}

Here are some common reference concepts.

Strong citation

Always alive: for references like "Object obj=new Object ()", the garbage collector will never recycle referenced object instances as long as strong references exist.

Weak reference

Collection will die: object instances associated with weak references can only survive until the next garbage collection occurs. When the garbage collector works, object instances associated with only weak references are recycled, regardless of whether the current memory is sufficient or not. After JDK 1.2, the WeakReference class is provided to implement weak references.

Soft reference

There is a living opportunity: soft references to associated objects will be reclaimed for a second time before a memory overflow exception is about to occur in the system. If there is not enough memory for this collection, a memory overflow exception will be thrown. After JDK 1.2, the SoftReference class is provided to implement soft references.

Virtual reference

Also known as ghost reference or phantom reference, it is the weakest kind of reference relationship. Whether an object instance has a virtual reference or not will not affect its survival time at all, and it is impossible to obtain an object instance through virtual reference. The only purpose of setting a virtual reference association for an object is to receive a system notification when the object instance is reclaimed by the collector. After JDK 1.2, the PhantomReference class is provided to implement virtual references.

Is memory leak a weak reference pot?

On the face of it, the root cause of memory leaks lies in the use of weak references, but another question is also worth thinking about: why does ThreadLocalMap use weak references instead of strong references?

Look at the official website documents:

To help deal with very large and long-lived usages, the hash table entries use WeakReferences for keys.

To handle very large and long-term uses, hash table entries use weakreference as the key.

The discussion is divided into two situations:

(1) key uses strong references

Objects that reference ThreadLocal are recycled, but ThreadLocalMap also holds a strong reference to ThreadLocal, and if it is not manually deleted, ThreadLocal will not be recycled, resulting in an Entry memory leak.

(2) key uses weak citation

Objects that reference ThreadLocal are recycled, and because ThreadLocalMap holds a weak reference to ThreadLocal, ThreadLocal is recycled even if it is not manually deleted. Value will be cleared the next time ThreadLocalMap calls set, get, or remove.

Comparing the two cases, we can find that since the life cycle of ThreadLocalMap is as long as that of Thread, memory leaks will occur if the corresponding key is not manually deleted, but the use of weak references can provide an additional layer of protection: after the weak reference ThreadLocal is cleaned, the key is null, and the corresponding value may be cleared the next time ThreadLocalMap calls set, get, or remove.

Therefore, the root cause of the ThreadLocal memory leak is that because the life cycle of ThreadLocalMap is as long as Thread, it will cause a memory leak if the corresponding key is not manually deleted, not because of weak references.

ThreadLocal best practices

Through the previous sections, we analyzed the class design and memory model of ThreadLocal, as well as the conditions and specific scenarios under which memory leaks occurred. Finally, combined with the experience in the project, the recommended scenarios for using ThreadLocal are given:

When you need to store thread private variables.

When you need to implement thread-safe variables.

When there is a need to reduce thread resource competition.

Based on the above analysis, we can understand the causes and consequences of ThreadLocal memory leaks, so how to avoid memory leaks?

The answer is: every time you finish using ThreadLocal, it is recommended that you call its remove () method to clear the data.

It is also important to emphasize that not all places that use ThreadLocal have to remove () at the end, because their life cycle may need to be as long as the life cycle of the project, so make appropriate choices to avoid business logic errors!

At this point, the study of "what is the cause of the memory leak" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.