ThreadLocal 的原理、场景和内存泄漏坑

get() 也是同一套路：先拿当前线程，再去 map 里按 key 找值。

public T get() {
    Thread t = Thread.currentThread();
    ThreadLocalMap map = getMap(t);
    if (map != null) {
        ThreadLocalMap.Entry e = map.getEntry(this);
        if (e != null) {
            @SuppressWarnings("unchecked")
            T result = (T) e.value;
            return result;
        }
    }
    return setInitialValue(); // 返回初始值
}

看上去像是'线程私有变量'，但实现上更像'把值挂到线程对象上'。这也是它快的原因之一：查找路径短，边界也清楚。

四、哪些地方会用到

ThreadLocal 最常见的用途，其实不是'做缓存'，而是'放上下文'。

// 场景 1：线程上下文信息传递（如 Spring 的 RequestContextHolder）
public class RequestContextHolder {
    private static final ThreadLocal<HttpServletRequest> requestHolder = new ThreadLocal<>();
    public static void setRequest(HttpServletRequest request) {
        requestHolder.set(request);
    }
    public static HttpServletRequest getRequest() {
        return requestHolder.get();
    }
}

// 场景 2：数据库连接管理
public class ConnectionManager {
    private static ThreadLocal<Connection> connectionHolder = ThreadLocal.withInitial(() -> DriverManager.getConnection(url));
    public static Connection getConnection() {
        return connectionHolder.get();
    }
}

// 场景 3：用户会话信息
public class UserContext {
    private static ThreadLocal<UserInfo> userHolder = new ThreadLocal<>();
    public static void setUser(UserInfo user) {
        userHolder.set(user);
    }
    public static UserInfo getUser() {
        return userHolder.get();
    }
}

// 场景 4：避免参数传递
public class TransactionContext {
    private static ThreadLocal<Transaction> transactionHolder = new ThreadLocal<>();
    public static void beginTransaction() {
        transactionHolder.set(new Transaction());
    }
    public static Transaction getTransaction() {
        return transactionHolder.get();
    }
}

这些场景里，ThreadLocal 的价值都很直接：少传参数，少改方法签名，调用链再深也不用一路透传。尤其在框架代码里，这个收益很明显。

不过它也不是万能钥匙。能显式传参的地方，我一般还是更愿意传参；ThreadLocal 更适合'调用链很长、但数据本质上属于线程上下文'的情况。

五、几个比较稳妥的用法

public class SafeThreadLocalExample {
    // 1. 使用 static final 修饰
    private static final ThreadLocal<SimpleDateFormat> DATE_FORMAT = ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyy-MM-dd"));

    // 2. 包装为工具类
    public static Date parse(String dateStr) throws ParseException {
        SimpleDateFormat sdf = DATE_FORMAT.get();
        try {
            return sdf.parse(dateStr);
        } finally {
            // 注意：这里通常不需要 remove，因为要重用 SimpleDateFormat
            // 但如果是用完即弃的场景，应该 remove
        }
    }

    // 3. 线程池场景必须清理
    public void executeInThreadPool() {
        ExecutorService executor = Executors.newFixedThreadPool(5);
        for (int i = 0; i < 10; i++) {
            executor.submit(() -> {
                try {
                    UserContext.setUser(new UserInfo());
                    // ... 业务处理
                } finally {
                    UserContext.remove(); // 关键！
                }
            });
        }
    }
}

这里我比较建议把 ThreadLocal 做成 private static final。这样生命周期清晰，也不容易在代码里到处散落多个实例。withInitial() 也挺实用，至少能把'第一次取值时怎么初始化'这件事收口。

六、内存泄漏为什么会发生

ThreadLocal 的问题，核心在 弱引用 key + 强引用 value + 长生命周期线程 这个组合。

强引用链大概是这样：Thread → ThreadLocalMap → Entry[] → Entry → value

而 key 只是弱引用：Entry → key

所以会出现这种情况：

1. ThreadLocal 对象没别的强引用了，被 GC 回收
2. Entry 里的 key 变成 null
3. 但 value 还被 Entry 强引用着
4. 如果线程还活着，value 就一直留在 map 里

在线程池里尤其容易踩这个坑，因为线程会复用，不会像普通短生命周期线程那样很快结束。值没清掉，下一批任务还能继续用同一个线程，脏数据和内存占用就一起留下来了。

七、怎么避开这个坑

// 方案 1：手动 remove（推荐）
try {
    threadLocal.set(value);
    // ... 业务逻辑
} finally {
    threadLocal.remove(); // 必须执行！
}

// 方案 2：使用 InheritableThreadLocal（父子线程传递）
ThreadLocal<String> parent = new InheritableThreadLocal<>();
parent.set("parent value");
new Thread(() -> {
    // 子线程可以获取父线程的值
    System.out.println(parent.get()); // "parent value"
}).start();

// 方案 3：使用 FastThreadLocal（Netty 优化版）
// 适用于高并发场景，避免了哈希冲突

remove() 不是装饰动作，它是真正的清理动作。别指望 ThreadLocal 自己帮你兜底，它会做一些过期条目的清理，但那是顺手处理，不是可靠的资源回收策略。

八、实际使用时我会盯住这几件事

• 线程池里用 ThreadLocal，结束前一定清理
• get() 返回 null 时，别默认它'应该有值'
• 子线程默认拿不到父线程的 ThreadLocal 值，别想当然
• 线程本地对象如果是可复用的，ThreadLocal 很合适；如果只是临时中转，直接传参更省事

九、调试时怎么查看线程里的值

// 查看 ThreadLocalMap 内容（调试用）
public static void dumpThreadLocalMap(Thread thread) throws Exception {
    Field field = Thread.class.getDeclaredField("threadLocals");
    field.setAccessible(true);
    Object map = field.get(thread);
    if (map != null) {
        Field tableField = map.getClass().getDeclaredField("table");
        tableField.setAccessible(true);
        Object[] table = (Object[]) tableField.get(map);
        for (Object entry : table) {
            if (entry != null) {
                Field valueField = entry.getClass().getDeclaredField("value");
                valueField.setAccessible(true);
                System.out.println("Key: " + ((WeakReference<?>) entry).get() + ", Value: " + valueField.get(entry));
            }
        }
    }
}

这个方法适合排查问题，不适合放生产代码里长期保留。反射访问线程内部结构，本身就挺重，也容易受 JDK 版本变化影响。

十、整理一下

ThreadLocal 的本质是线程内的数据隔离，不是线程间共享。它在请求上下文、事务上下文、线程内对象复用这些地方很顺手，但一旦进入线程池场景，就必须把清理动作放在 finally 里。remove() 这一步省不了，省了往往不是性能问题，而是后面才冒出来的内存问题。