13]ThreadLocal是什么？有哪些用途？你了解多少？_refelectthreadlocals

本次给大家介绍重要的工具ThreadLocal。讲解内容如下，同时介绍什么场景下发生内存泄漏，如何复现内存泄漏，如何正确使用它来避免内存泄漏。

带着问题，我们一起来看看，如果你有什么见解，可以评论分享哈。

• ThreadLocal是什么？有哪些用途？

• ThreadLocal如何使用。

• ThreadLocal原理。

• ThreadLocal使用有哪些坑及注意事项。

 1. ThreadLocal是什么？ 有哪些用途？

首先介绍Thread类中属性threadLocals: 我是这样理解的，他放在Thread，那是不是和线程有关联，什么关联，猜想共享，私有？

ThreadLocal.ThreadLocalMap threadLocals = null;

 看到源码，了解到是每个线程的实例 threadLocals

但是我们看没有操作threadLocals的方法，这个是个threadLocal就上场了，可以理解threadLocal是线程Thread中属性threadLocals的管理者。

也就是，我们操作threadLocal的get,set,remove的操作结果都是针对当前线程Thread实例的threadLocals存，取，删除操作。类次于一个开发者的任务，产品经理左右不了，产品经理只能通过技术leader来给开发者分配任务。

其实，我们看看threadLocal的源码，底层就是threadLocalMap组成，这不匹配上了 。

要了解到这个threadLocal的分配空间。

那ThreadLocal有哪些应用场景呢？

其实我们无意间已经时时刻刻在使用ThreadLocal提供的便利，如果说多数据源的切换你比较陌生，那么spring提供的声明式事务就再熟悉不过了，我们在研发过程中无时无刻不在使用，而spring声明式事务的重要实现基础就是ThreadLocal，只不过大家没有去深入研究spring声明式事务的实现机制。

原来ThreadLocal这么强大，但应用开发者使用较少，同时有些研发人员对于ThreadLocal内存泄漏，等潜在问题，不敢试用，恐怕这是对于ThreadLocal最大的误解，后面我们将会仔细分析，只要按照正确使用方式，就没什么问题。如果ThreadLocal存在问题，岂不是spring声明式事务是我们程序最大的潜在危险吗？

兄弟们，编程，先学习思想，但是发现，我了解一个ThreadLocal，里面涉及很多的知识点，这里就冒出了spring声明式事务的原理及实现机制，记在心思，可以自己学习，后面我也分我学习的。

2.ThreadLocal如何使用

为了更直观的体会ThreadLocal的使用我们假设如下场景

1. 我们给每个线程生成一个ID。

2. 一旦设置，线程生命周期内不可变化。

3. 容器活动期间不可以生成重复的ID

我们创建一个ThreadLocal管理类：

package demo.aqs;
 
import java.util.concurrent.atomic.AtomicBoolean;
import java.util.concurrent.atomic.AtomicInteger;
 
public class ThreadLocalId {
 
    private static final AtomicInteger nextId = new AtomicInteger(0);
 
    private static final ThreadLocal<Integer> threadId = new ThreadLocal<Integer>() {
        protected Integer initialValue()
        {
            return nextId.getAndIncrement();
        }
    };
 
 
    public static int get() {
        return threadId.get();
    }
 
    public static void remove() {
        threadId.remove();
    }
 
    private static void increamentSameThreadId() {
        try{
            for(int i = 0;i < 5; i++) {
                System.out.println(Thread.currentThread()+"_"+i+",threadId:"+ThreadLocalId.get());
            }
        } finally {
            ThreadLocalId.remove();
        }
    }
 
    public static void main(String[] args) {
        increamentSameThreadId();
 
        //在搞2个线程
        new Thread(new Runnable() {
            @Override
            public void run() {
                increamentSameThreadId();
            }
        }).start();
 
        new Thread(()->{
           increamentSameThreadId();
        }).start();
    }
}

 3.ThreadLocal原理

①ThreadLocal类结构及方法解析：

 上图可知：ThreadLocal三个方法get, set , remove以及内部类ThreadLocalMap

从这张图我们可以直观的看到Thread中属性threadLocals，作为一个特殊的Map，它的key值就是我们ThreadLocal实例，而value值这是我们设置的值。

③ThreadLocal的操作过程：

 其中getMap(t) 返回的就是当前线程的threadlocals,如下图，然后根据当前ThreadLocal实例对象作为key获取ThreadLocalMap中的value,如果首次进来调用setInitialValue();

set的过程也类似:

4.ThreadLocal使用有哪些坑及注意事项

我经常在网上看到骇人听闻的标题，ThreadLocal导致内存泄漏，这通常让一些刚开始对ThreadLocal理解不透彻的开发者，不敢贸然使用。越不用，越陌生。这样就让我们错失了更好的实现方案，所以敢于引入新技术，敢于踩坑，才能不断进步。

我们来看下为什么说ThreadLocal会引起内存泄漏，什么场景下会导致内存泄漏？

先回顾下什么叫内存泄漏，对应的什么叫内存溢出

• Memory overflow:内存溢出，没有足够的内存提供申请者使用。

• Memory leak:内存泄漏，程序申请内存后，无法释放已申请的内存空间，内存泄漏的堆积终将导致内存溢出。

显然是TreadLocal在不规范使用的情况下导致了内存没有释放。

 

 看到ThreadLocalMap的Entry继承了WeakReference（弱引用）

知识点来了：

 既然WeakReference在下一次gc即将被回收，那么我们的程序为什么没有出问题呢？

①所以我们测试下弱引用的回收机制：

package demo;
 
import java.lang.ref.WeakReference;
 
/**
 * 弱引用测试
 */
public class ThreadLocalLeakTest {
 
    public static void main(String[] args) {
        String str = new String("weakReference1");
        //弱应用回收
        WeakReference<String> weakReference = new WeakReference<String>(str);
        System.gc();
 
        if(weakReference.get() == null) {
            System.out.println("weak1已被回收");
        } else {
            System.out.println(weakReference.get());
        }
 
        //存在强引用
        WeakReference<String> weakReference2 = new WeakReference<String>(new String("weakReference1"));
        System.gc();
        if(weakReference2.get() == null) {
            System.out.println("weak2已被回收");
        } else {
            System.out.println(weakReference2.get());
        }
    }
}

weakReference1
weak2已被回收

上面演示了弱引用的回收情况，下面我们看下ThreadLocal的弱引用回收情况。

②ThreadLocal的弱引用回收情况

 如上图所示，我们在作为key的ThreadLocal对象没有外部强引用，下一次gc必将产生key值为null的数据，若线程没有及时结束必然出现，一条强引用链Threadref–>Thread–>ThreadLocalMap–>Entry，所以这将导致内存泄漏。

下面我们模拟复现ThreadLocal导致内存泄漏：

package com.example.demo.threadLoclLeak;
 
import java.lang.reflect.Field;
import java.util.ArrayList;
import java.util.List;
 
import org.springframework.util.ReflectionUtils;
 
public class TestThreadLoclLeak {
 
	public static void main(String[] args) throws InterruptedException {
 
		// 为了复现key被回收的场景，我们使用临时变量
		ThreadLocalMemory memeory = new ThreadLocalMemory();
 
		// 调用
		incrementSameThreadId(memeory);
 
		System.out.println("GC前：key:" + memeory.threadId);
		System.out.println("GC前：value-size:" + refelectThreadLocals(Thread.currentThread()));
 
		// 设置为null，调用gc并不一定触发垃圾回收，但是可以通过java提供的一些工具进行手工触发gc回收。
		memeory.threadId = null;
		System.gc();
 
		System.out.println("GC后：key:" + memeory.threadId);
		System.out.println("GC后：value-size:" + refelectThreadLocals(Thread.currentThread()));
 
		// 进一步回收，保证ThreadLocal实例被回收
		memeory = null;
		System.gc();
 
		// 模拟线程一直运行
		while (true) {
		}
	}
 
	/**
	 * 使用threadlocal
	 * 
	 * @param memeory
	 */
	private static void incrementSameThreadId(final ThreadLocalMemory memeory) {
		try {
			for (int i = 0; i < 5; i++) {
				System.out.println(Thread.currentThread() + "_" + i + ",threadId:" + memeory.get().size());
			}
		} finally {
			// 使用后请清除，这里为了复现内存泄漏，故意不回收
			// ThreadLocalMemory.remove();
		}
	}
 
	/**
	 * 利用反射获取ThreadLocal对应的值
	 *
	 * @param t
	 * @return
	 */
	public static Object refelectThreadLocals(Thread t) {
		try {
			// Thread
			Field field = ReflectionUtils.findField(Thread.class, "threadLocals");
			field.setAccessible(true);
			Object localmap = ReflectionUtils.getField(field, t);
 
			// ThreadLocalMap.Entry[]
			Field entryField = ReflectionUtils.findField(localmap.getClass(), "table");
			entryField.setAccessible(true);
			Object[] entry = (Object[]) ReflectionUtils.getField(entryField, localmap);
 
			List<Object> list = new ArrayList<>();
			for (Object o : entry) {
				if (o != null)
					list.add(o);
			}
 
			List<Object> result = new ArrayList<>();
			for (Object o : list) {
 
				// Entry.value
				Field entryValue = ReflectionUtils.findField(o.getClass(), "value");
				entryValue.setAccessible(true);
				Object keyvalue = ReflectionUtils.getField(entryValue, o);
				if (keyvalue instanceof ArrayList) {
					result.add(keyvalue);
				}
			}
			return ((ArrayList<?>) result.get(0)).size();
		} catch (Exception e) {
			e.printStackTrace();
			return null;
		}
	}
}
 
class ThreadLocalMemory {
	// Thread local variable containing each thread's ID
	public ThreadLocal<List<Object>> threadId = new ThreadLocal<List<Object>>() {
		@Override
		protected List<Object> initialValue() {
			List<Object> list = new ArrayList<Object>();
			for (int i = 0; i < 10000; i++) {
				list.add(String.valueOf(i));
			}
			return list;
		}
	};
	// Returns the current thread's unique ID, assigning it if necessary
	public List<Object> get() {
		return threadId.get();
	}
 
	// remove currentid
	public void remove() {
		threadId.remove();
	}
}

此时我们如何知道内存中存在memory leak呢？

我们可以借助jdk提供的一些命令dump当前堆内存，命令如下：

jmap -dump:live,format=b,file=heap.bin <pid>

然后我们借助MAT可视化分析工具，来查看对内存，分析对象实例的存活状态：

首先打开我们工具提示我们的内存泄漏分析：

这里我们可以确定的是ThreadLocalMap实例的Entry.value是没有被回收的。

最后我们要确定Entry.key是否还在？打开Dominator Tree，搜索我们的ThreadLocalMemory，发现并没有存活的实例。

以上我们复现了ThreadLocal不正当使用，引起的内存泄漏。

所以我们总结了使用ThreadLocal时会发生内存泄漏的前提条件

• ThreadLocal引用被设置为null，且后面没有set，get,remove操作。

• 线程一直运行，不停止。（线程池）

• 触发了垃圾回收。（Minor GC或Full GC）

我们看到ThreadLocal出现内存泄漏条件还是很苛刻的，所以我们只要破坏其中一个条件就可以避免内存泄漏，单但为了更好的避免这种情况的发生我们使用ThreadLocal时遵守以下两个小原则:

①ThreadLocal申明为private static final。

• Private与final 尽可能不让他人修改变更引用，

• Static 表示为类属性，只有在程序结束才会被回收。

②ThreadLocal使用后务必调用remove方法。

• 最简单有效的方法是使用后将其移除。

以上。