JVM on Coder_Studio

【面试真题拆解】你知道ThreadLocal是什么吗

Sat, 21 Mar 2026 17:34:29 +0000

ThreadLocal 是线程专属的本地变量，它的设计是给每个线程创建一份独立的变量副本，线程之间完全不共享数据，天然实现线程隔离，全程无锁竞争，性能远高于加锁保证线程安全的方案。

每个 Thread 内部都有一个专属的成员变量 ThreadLocalMap（不是 ThreadLocal 的！），Key 是 ThreadLocal 实例本身（弱引用），Value 是存的变量（强引用）。

官话太多，直接上例子。

以用户上下文传递举个例子

/**
 * 用户上下文工具类
 * 用ThreadLocal存当前登录用户的ID，避免层层传参
 */
public class UserContextHolder {
    // 定义ThreadLocal，存用户ID
    private static final ThreadLocal<Long> USER_ID_THREAD_LOCAL = new ThreadLocal<>();

    /**
     * 设置用户ID
     */
    public static void setUserId(Long userId) {
        USER_ID_THREAD_LOCAL.set(userId);
    }

    /**
     * 获取用户ID
     */
    public static Long getUserId() {
        return USER_ID_THREAD_LOCAL.get();
    }

    /**
     * 必须手动调用！清理ThreadLocal，防止内存泄漏
     */
    public static void clear() {
        USER_ID_THREAD_LOCAL.remove();
    }
}

和加锁保证线程安全的区别

对比项	加锁	ThreadLocal
思想	多线程排队用同一个变量，保证同一时间只有一个线程能访问	每个线程用自己的专属变量，完全不共享
性能	有锁竞争，高并发下性能差	无锁竞争，性能高
适用场景	多线程必须共享同一个变量的场景（比如共享计数器、共享资源修改）	每个线程需要独立变量副本的场景（比如用户上下文、SimpleDateFormat 线程安全）

小贴士

很多人以为ThreadLocalMap的Key是“线程ID”，其实Key是ThreadLocal实例本身，而不是线程ID。

一个线程可以有多个ThreadLocal实例，每个实例对应一个Value，存到同一个ThreadLocalMap里，Key不同，互不干扰。

ThreadLocal内存泄漏问题

Java中的4种引用强度

强引用

我们平时写的 Object obj = new Object() 就是强引用，只要强引用还在，GC就不会回收这个对象。

软引用

用 SoftReference 包装的引用，只有当内存不够用的时候，GC 才会回收这个对象。

弱引用

用 WeakReference 包装的引用，只要GC一运行，不管内存够不够，都会回收这个对象。

虚引用

用 PhantomReference 包装的引用，完全不影响对象的生命周期，只是用来在对象被 GC 回收前收到一个通知，做一些收尾工作。

ThreadLocalMap的Entry结构

ThreadLocalMap的Entry是继承自WeakReference的，结构如下：

static class Entry extends WeakReference<ThreadLocal<?>> {
    Object value;
    Entry(ThreadLocal<?> k, Object v) {
        super(k); // Key是弱引用
        value = v; // Value是强引用
    }
}

假设创建了一个 ThreadLocal 实例，有外部强引用指向它，同时把它作为 Key 存到了线程的 ThreadLocalMap 里；

当用完 ThreadLocal 后，没有手动 remove，而且外部的强引用也没了（比如 threadLocal = null），因为 Key 是弱引用，GC 一运行，Key 就被回收了，变成了 null。

但是， Value 是强引用，只要线程还活着，Value 就不会被 GC 回收，这就导致了内存泄漏。

更严重的还有，如果用了线程池，线程会被长期复用，不仅内存泄漏，还会导致用户信息串号、数据错误等严重的业务问题。

怎么避免内存泄漏

使用完ThreadLocal后，手动调用 remove() 方法。

举个例子，在Spring Boot的拦截器里：

@Component
public class UserInterceptor implements HandlerInterceptor {
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
        // 从Token里解析出用户ID，存到ThreadLocal
        Long userId = parseUserIdFromToken(request.getHeader("Authorization"));
        UserContextHolder.setUserId(userId);
        return true;
    }

    @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) {
        // 在这里清理，不管请求成功失败，都要清理。
        UserContextHolder.clear();
    }
}

【面试真题】讲讲JVM的垃圾回收机制？

Sat, 14 Mar 2026 19:26:46 +0000

为什么需要垃圾回收？

首先得说清楚，JVM的垃圾回收（GC）到底是干嘛的。

其实就像租房子住，时间长了会产生垃圾，要是不打扫，房子就没法住了。

在Java里，我们写代码会创建很多对象（比如new Person()、new ArrayList()），这些对象都存在堆内存里。

但是，堆内存是有限的，要是对象用完了不清理，内存就会被占满，最后报OutOfMemoryError（OOM），程序就挂了。

所以GC的作用就是：自动找到堆里那些“没人用的垃圾对象”，把它们清理掉，腾出内存空间。

堆内存划分

JVM把堆分成了新生代和老年代两大块：

新生代：刚创建的对象优先放在这里。就像“幼儿园”，大部分对象“朝生夕死”（比如方法里的临时变量，方法执行完就没用了）。
老年代：在新生代里“熬过好几次GC”的对象，会被放到这里。就像“养老院”，这里的对象大多活得比较久（比如Spring容器里的单例Bean）。

那为什么要这么划分呢？

主要还是因为不同生命周期的对象，用不同的回收算法，效率会更高一点。

各代用什么垃圾回收算法？

我当时面试的时候突然懵了，说的不知道，裂开。。。

对新生代来说，它的特点是：垃圾多，存活对象少（比如100个对象里，可能只有2个活着）。

采用的是复制算法。

JVM把新生代分成三块：

1个Eden区（占80%）和2个Survivor区（From和To，各占10%）。

平时只用Eden区和其中一个Survivor区（比如From）。

新对象先在Eden区分配，当Eden区满了，触发Minor GC（新生代GC），把Eden和From区里活着的对象，复制到To区，然后直接清空Eden和From区，From和To交换角色（下次用Eden和新的From区）。

对老年代来说，它的特点是：存活对象多，垃圾少，而且没有额外的大空间做复制担保，所以不用复制算法，采用的是**标记-清除 **或 标记-整理算法。

标记-清除算法（Mark-Sweep）

这种算法的实现逻辑是，从“GC Roots”（比如主线程、静态变量这些“根”）出发，找到所有活着的对象，做上标记，然后遍历堆内存，把没标记的对象（垃圾）清理掉。

优点是实现简单，但是会产生内存碎片（比如清理后剩下很多小空间，大对象可能放不下）。

标记-整理算法（Mark-Compact）

为了解决内存碎片问题，在“标记-清除”基础上加了个“整理”步骤。

实现逻辑和标记清除算法一样，先标记存活对象，把所有存活对象往内存的一端移动，按顺序排好，最后，直接清空边界以外的内存。

这种算法的优点是没有内存碎片，但缺点是需要移动对象，效率比“标记-清除”低。

常见的垃圾回收器

Serial：单线程回收，适合客户端应用（比如桌面软件）；
ParNew：Serial的多线程版，常和CMS配合用；
CMS（Concurrent Mark Sweep）：主打低延迟（垃圾回收时尽量不让程序停顿太久），适合互联网应用（比如电商后台），用的是“标记-清除”算法；
G1（Garbage-First）：把堆分成很多小区域，优先回收垃圾多的区域，平衡了吞吐量和延迟。

JIT编译后的代码存在哪

Sun, 11 Jan 2026 16:04:17 +0000

JIT（Just-In-Time）编译后的代码通常存放在代码缓存区（Code Cache）中。

JVM提供了如下参数用于调整Code Cache的大小和行为：

-XX:InitialCodeCacheSize	初始大小
-XX:ReservedCodeCacheSize	最大大小
-XX:+PrintCodeCache	打印Code Cache信息

Code Cache的默认大小依赖于JVM的版本和运行环境，通常有一个最大值。

Code Cache分为多个区域，分别存储不同级别的编译代码：

非方法代码	存储运行时的JVM调试代码或者模板代码
方法代码	存储普通JIT编译的代码
轮廓代码	存储优化级别更高的代码

说说编译执行和解释执行的区别

Thu, 01 Jan 2026 17:35:59 +0000

编译执行是程序在执行之前，先通过编译器将源代码编译为机器代码，然后直接在CPU上运行；

解释执行是源代码在不经过编译器编译的前提下，直接在运行的时候通过解释器逐行翻译并执行。

常见的编译性语言有C和C++，而常见的解释性语言有Python。

编译执行的语言因为编译后的程序不需要在运行的时候再进行翻译，所以运行速度快。

但是，程序需要针对每个平台重新编译，跨平台性会更差一点。

而解释执行的语言在每个平台上都是通过相应平台的解释器来运行的，跨平台性好。但是每次执行的时候都需要进行动态的翻译和解释，所以运行速度更慢。

严格来说，JVM是结合了编译执行和解释执行的。

正常情况下JVM是解释执行的，不过，如果JVM发现某段逻辑执行的特别频繁，那么它就会通过JIT（Just In Time）即时编译将其编译成机器码，这样就是编译执行了。