最近面了个Java高级岗，技术面聊得挺顺，面试官突然说：“我们聊得差不多了，最后做几道笔试题巩固一下吧。”然后直接甩过来10道题。我扫了一眼，心里咯噔一下——全是那种看起来基础，但稍微想偏一点就掉坑里的“高频送命题”。

这些题有个共同特点：它们不考你死记硬背的API，而是考你对Java核心机制最底层、最细微的理解。你以为知道答案，但面试官追问“为什么”时，如果底层原理说不清，高级岗的offer基本就悬了。

这篇文章，我就把这10道题及其背后的深度考点彻底拆解一遍。这不是一份简单的“答案列表”，而是一份“避坑指南”和“原理溯源手册”。无论你是正在备战面试，还是想巩固Java根基，搞懂这些题，你就能真正理解面试官在高级岗考察的到底是什么——不是你会用多少框架，而是你能否驾驭Java这门语言本身。

1. 这10道题为什么是“送命题”？高级岗到底在考什么？

很多开发者有个误区，认为Java高级开发就是“Spring全家桶玩得熟、微服务架构搭得快”。这当然重要，但只是“应用层”的能力。面试官出这些看似基础的笔试题，真正想穿透的是你的“原理层”认知。

这些题“送命”的点在于：

1. 陷阱伪装成常识：题目描述往往简单直白，诱导你用“直觉”或“日常经验”去回答，而直觉和经验恰恰是错的。
2. 答案在语言规范里：正确答案通常由《Java语言规范》或JVM的行为定义，而非某个IDE的运行结果（结果可能因环境而异）。
3. 一题多坑，环环相扣：一道题可能同时考察内存模型、类加载机制、方法分派等多个知识点，答对第一个空可能掉进第二个坑。
4. 考察深度而非广度：不要求你列举所有集合类，但要求你准确说出HashMap在JDK8中链表转红黑树的具体阈值和扩容后的元素迁移细节。

所以，面对这些题，正确的姿势不是背诵答案，而是建立一条从代码表面到JVM内部执行逻辑的清晰追溯路径。下面我们开始逐题拆解。

2. 试题一：String的“相等”陷阱

题目：

String s1 = new String("Hello"); String s2 = "Hello"; String s3 = s1.intern(); System.out.println(s1 == s2); // 输出？ System.out.println(s2 == s3); // 输出？ System.out.println(s1.equals(s2)); // 输出？

考点：String对象的内存分配、字符串常量池、intern()方法机制。

逐行分析：

1. String s1 = new String("Hello");
   • 这行代码创建了两个对象（如果常量池中没有"Hello"）。
   • "Hello"字面量：JVM会先在字符串常量池中查找是否存在该字符串。如果不存在，则在常量池中创建一个String对象。
   • new String(...)：在堆内存中创建一个新的String对象，这个对象的内容指向（或拷贝）常量池中的那个"Hello"。所以s1引用指向堆中的这个新对象。
2. String s2 = "Hello";
   • 字面量赋值。JVM会直接去字符串常量池中查找"Hello"。由于上一步已经在常量池中创建了，所以s2直接指向常量池中的那个String对象。
3. String s3 = s1.intern();
   • intern()方法：如果常量池中已经包含一个等于此String对象（内容相等）的字符串，则返回常量池中字符串的引用；否则，将此String对象添加到常量池中，并返回此对象的引用。
   • 此时常量池中已有"Hello"，所以s3返回的是常量池中那个对象的引用，即和s2指向同一个对象。

内存关系图：

堆内存 (Heap) 字符串常量池 (String Table) s1 -> [String对象A] --内容--> ["Hello"] <-- s2, s3

答案与解析：

• System.out.println(s1 == s2); // false
  • ==比较的是引用地址。s1指向堆中的对象A，s2指向常量池中的对象。地址不同。
• System.out.println(s2 == s3); // true
  • s2和s3都指向常量池中的同一个"Hello"对象。
• System.out.println(s1.equals(s2)); // true
  • equals比较的是字符串内容，两者内容都是"Hello"。

深度追问（面试官可能接着问）：

• String的intern()方法在JDK6、JDK7/8中有什么行为差异？
  • JDK6及以前：常量池在永久代，调用intern()时，如果池中没有，会将此String对象复制一份到常量池，返回常量池中的引用。
  • JDK7及以后：常量池移到了堆中，调用intern()时，如果池中没有，则将此String对象的引用本身记录到常量池，并返回该引用。这意味着，对于new String("abc").intern()，在JDK7+中，返回的引用可能直接就是堆中那个new出来的对象的引用（如果池中之前没有）。
• 如何高效地拼接大量字符串？为什么？
  • 使用StringBuilder（单线程）或StringBuffer（多线程）。因为String是不可变的，每次拼接都会产生新的String对象，而StringBuilder直接操作内部的字符数组，避免了中间对象的频繁创建和销毁。

3. 试题二：Integer的缓存与==的玄机

题目：

Integer a = 100; Integer b = 100; Integer c = 200; Integer d = 200; System.out.println(a == b); // 输出？ System.out.println(c == d); // 输出？ System.out.println(a.equals(b)); // 输出？ System.out.println(c.equals(d)); // 输出？

考点：自动装箱、Integer缓存机制、==与equals的区别。

逐行分析：

1. Integer a = 100;这行代码发生了自动装箱，等价于Integer a = Integer.valueOf(100);。
2. 关键就在于Integer.valueOf(int i)方法。查看源码（以JDK8为例）：

   public static Integer valueOf(int i) { if (i >= IntegerCache.low && i <= IntegerCache.high) return IntegerCache.cache[i + (-IntegerCache.low)]; return new Integer(i); }

   • IntegerCache是Integer的一个静态内部类，它默认缓存了-128到127之间的整数对象。
   • 当i的值在这个范围内时，直接返回缓存池中预先创建好的Integer对象。
   • 当i的值超出此范围时，则new一个新的Integer对象。

答案与解析：

• System.out.println(a == b); // true
  • a和b的值都是100，在-128~127范围内，valueOf返回的是缓存中同一个对象的引用。==比较引用，故为true。
• System.out.println(c == d); // false
  • c和d的值都是200，超出了缓存范围，valueOf分别new了两个新的Integer对象。==比较的是两个不同对象的引用，故为false。
• System.out.println(a.equals(b)); // true
  • equals比较的是包装器对象内部的基本int值是否相等。100等于100。
• System.out.println(c.equals(d)); // true
  • 同理，equals比较的是int值200是否相等。

深度追问：

• 缓存范围可以修改吗？
  • 可以，但通常不推荐。通过JVM启动参数-XX:AutoBoxCacheMax=可以设置上限。下限-128不可修改。
• 其他包装类有缓存吗？
  • Byte,Short,Long有-128~127的缓存。
  • Character缓存了0~127的字符。
  • Boolean缓存了TRUE和FALSE。
  • Float和Double没有缓存。
• 在什么时候应该使用equals而不是==来比较包装类？
  • 永远使用equals来比较包装类对象的值是否相等。==仅在需要判断是否为同一个对象时才使用。由于缓存的存在，==在缓存范围内的比较结果具有不确定性（依赖于JVM实现和参数），是绝对的代码隐患。

4. 试题三：try-catch-finally的返回值谜题

题目：

public static int test() { try { int i = 1 / 0; // 抛出 ArithmeticException return 1; } catch (Exception e) { return 2; } finally { return 3; } } System.out.println(test()); // 输出？

考点：finally块的执行时机及其对返回值的影响。

答案与解析：

• System.out.println(test()); // 输出 3
• 执行流程：
  1. try块中int i = 1 / 0;抛出ArithmeticException。
  2. 异常被catch块捕获，catch块准备返回2。注意：此时return 2的指令已执行，返回值2已被暂存（存储在一个临时变量中），但方法并未立即返回。
  3. 无论是否发生异常，finally块都必须执行。
  4. finally块中执行了return 3;。这会覆盖掉之前暂存的返回值2。
  5. 方法最终返回3。

关键原理：JVM通过异常表和返回值暂存区来处理try-catch-finally。当finally块中包含return语句时，它会“吞噬”掉try或catch块中的return（以及可能抛出的异常），使方法的最终行为和返回值完全由finally块决定。

深度追问与最佳实践：

• 如果在finally块中修改了try或catch中要返回的引用类型变量，结果会怎样？

  public static List<String> test() { List<String> list = new ArrayList<>(); try { list.add("try"); return list; // 返回的是引用list的副本（地址值） } finally { list.add("finally"); // 修改了list指向的对象内容 // list = null; // 如果加上这句，不会影响返回值，因为返回的是副本 } } // 输出：[“try”, “finally”]

  • 返回的是引用地址的副本。finally中对对象内容的修改会生效，但对引用变量本身的重新赋值（如list = null）不会影响已暂存的返回地址。
• 最佳实践：
  • 绝对避免在finally块中使用return语句。这会导致异常丢失（catch块中的异常被覆盖）和返回结果不可预测，代码逻辑极其晦涩。
  • finally块应该只用于释放资源（关闭流、连接等），确保资源的确定性释放。

5. 试题四：静态分派与重载的优先级

题目：

public class OverloadDemo { static class Human {} static class Man extends Human {} static class Woman extends Human {} public void sayHello(Human human) { System.out.println("Hello, human!"); } public void sayHello(Man man) { System.out.println("Hello, man!"); } public void sayHello(Woman woman) { System.out.println("Hello, woman!"); } public static void main(String[] args) { Human man = new Man(); Human woman = new Woman(); OverloadDemo demo = new OverloadDemo(); demo.sayHello(man); // 输出？ demo.sayHello(woman); // 输出？ } }

考点：方法重载的静态分派、编译期类型 vs 运行期类型。

答案与解析：

• demo.sayHello(man); // 输出 “Hello, human!”
• demo.sayHello(woman); // 输出 “Hello, human!”

原理分析：

1. 方法重载（Overload）是静态多态，也叫做编译期多态。调用哪个重载方法，是在程序编译期就确定下来的，依据是参数的静态类型（声明类型）。
2. 在代码中：
   • man的静态类型是Human，运行期类型是Man。
   • woman的静态类型是Human，运行期类型是Woman。
3. 编译器在编译demo.sayHello(man)时，只看man的静态类型Human，因此它确定调用的是sayHello(Human human)这个方法。编译完成后，这个调用关系就写死在字节码里了。
4. 运行时，JVM根据字节码指令直接调用sayHello(Human human)，不会因为实际传入的是Man或Woman对象而改变。

深度追问：

• 那什么情况下才会根据运行期类型调用方法？
  • 方法重写（Override）是动态多态，也叫做运行期多态。调用哪个重写方法，是根据对象的实际类型（运行期类型）在运行时动态决定的。这是通过JVM的虚方法表机制实现的。
  • 将上面的例子改为重写：

  static class Human { public void sayHello() { System.out.println("Hello, human!"); } } static class Man extends Human { @Override public void sayHello() { System.out.println("Hello, man!"); } } public static void main(String[] args) { Human man = new Man(); man.sayHello(); // 输出 “Hello, man!”，因为运行期类型是Man }

• 如何记住这个区别？
  • 重载看类型，编译定乾坤；重写看对象，运行才分明。这里的“类型”指参数的静态类型，“对象”指方法调用者的实际对象类型。

6. 试题五：HashMap并发修改的“幽灵”异常

题目：

Map<String, String> map = new HashMap<>(); map.put("key1", "value1"); for (String key : map.keySet()) { if ("key1".equals(key)) { map.remove(key); // 这行代码可能会抛出什么异常？ } }

考点：HashMap的快速失败机制、并发修改异常。

答案与解析：

• 这段代码可能会抛出ConcurrentModificationException。
• 原理分析：
  1. 增强for循环 (for (String key : map.keySet())) 本质上是通过Iterator来遍历的。
  2. HashMap的Iterator实现了快速失败机制。它内部维护了一个modCount变量，记录集合结构被修改的次数（如put,remove）。
  3. 在创建Iterator时，会将当前的modCount值赋给Iterator的expectedModCount。
  4. 在每次调用Iterator.next()时，会检查modCount == expectedModCount。如果不相等，说明集合在迭代期间被非迭代器自身的方法修改了结构，就会立即抛出ConcurrentModificationException。
  5. 在上面的代码中，map.remove(key)是直接通过Map的方法删除元素，修改了modCount，但Iterator的expectedModCount并未同步更新。因此，在下一次循环调用next()时，检查失败，抛出异常。

深度追问与解决方案：

• 一定会抛出异常吗？
  • 不一定。如果删除的是迭代器已经返回过的最后一个元素，且删除后迭代器判断没有下一个元素了（hasNext()返回false），就不会再调用next()，也就不会触发检查。但这属于未定义行为，强烈依赖实现细节，绝对不可依赖。
• 如何在遍历时安全地删除元素？
  1. 使用Iterator自身的remove()方法：

     Iterator<String> iterator = map.keySet().iterator(); while (iterator.hasNext()) { String key = iterator.next(); if ("key1".equals(key)) { iterator.remove(); // 安全删除，会同步更新expectedModCount } }

  2. Java 8+ 使用Collection.removeIf()：

     map.keySet().removeIf(key -> "key1".equals(key));

  3. 遍历前记录要删除的键，遍历后统一删除：

     List<String> keysToRemove = new ArrayList<>(); for (String key : map.keySet()) { if ("key1".equals(key)) { keysToRemove.add(key); } } keysToRemove.forEach(map::remove);

7. 试题六：volatile能保证原子性吗？

题目：

public class VolatileDemo { private volatile int count = 0; public void increment() { count++; // 这行操作是线程安全的吗？ } public int getCount() { return count; } }

考点：volatile关键字的语义（可见性、有序性）、原子性概念、复合操作。

答案与解析：

• count++不是线程安全的，即使count被volatile修饰。
• 原理分析：
  1. volatile关键字提供两大保障：
     • 可见性：对一个volatile变量的写，会立即刷新到主内存，并且会使其他线程中该变量的缓存行无效，从而保证其他线程能读到最新值。
     • 禁止指令重排序：通过内存屏障实现。
  2. volatile不保证原子性。原子性是指一个操作或多个操作要么全部执行且不被中断，要么都不执行。
  3. count++这个操作（读-改-写）在JVM层面并不是一个原子指令。它大致对应以下几步：

     1. 读取当前count的值到工作内存 (read) 2. 将值加1 (add) 3. 将新值写回主内存 (write)

     如果两个线程A和B同时执行increment()，它们可能同时读到相同的count值（比如都是5），各自加1后都写回6，最终结果就少加了一次。
  4. volatile保证了线程B能立即看到线程A写入后的新值，但无法阻止两个线程交错执行读-改-写的各个步骤。

深度追问与解决方案：

• 什么操作是原子性的？
  • 对基本类型（除long/double）的简单赋值和读取通常是原子的（由JLS保证）。但long/double在32位JVM上的非volatile读写可能不是原子的。
  • volatile变量的简单赋值和读取是原子的。
• 如何让count++变成线程安全的？
  1. 使用synchronized关键字：

     public synchronized void increment() { count++; }

  2. 使用java.util.concurrent.atomic包下的原子类：

     private AtomicInteger count = new AtomicInteger(0); public void increment() { count.incrementAndGet(); // 原子性的CAS操作 }

  3. 使用LongAdder（高并发场景推荐）：

     private LongAdder count = new LongAdder(); public void increment() { count.increment(); } public long getCount() { return count.sum(); }

• volatile的典型使用场景是什么？
  • 状态标志位：作为一个线程间可见的开关。

    volatile boolean shutdownRequested; public void shutdown() { shutdownRequested = true; } public void doWork() { while (!shutdownRequested) { // ... 工作 } }

  • 单例模式的双重检查锁定（DCL）：防止指令重排序导致返回未初始化完全的对象。
  • 观察者模式：保证观察者能立即看到被观察者的状态变化。

8. 试题七：synchronized锁住的是代码还是对象？

题目：

public class SyncDemo { public synchronized void methodA() { // 模拟耗时操作 try { Thread.sleep(5000); } catch (InterruptedException e) {} System.out.println("methodA finished"); } public synchronized void methodB() { System.out.println("methodB finished"); } public static synchronized void methodC() { System.out.println("methodC finished"); } public static void main(String[] args) throws InterruptedException { SyncDemo demo1 = new SyncDemo(); SyncDemo demo2 = new SyncDemo(); new Thread(() -> demo1.methodA()).start(); Thread.sleep(100); // 确保线程1先启动 new Thread(() -> demo1.methodB()).start(); // 线程2 new Thread(() -> demo2.methodB()).start(); // 线程3 new Thread(() -> SyncDemo.methodC()).start(); // 线程4 } }

问：线程1、2、3、4之间的执行是互斥的吗？为什么？

考点：synchronized的锁对象（实例锁 vs 类锁）、锁的粒度。

答案与解析：

• 线程1 (demo1.methodA) 和 线程2 (demo1.methodB)：互斥。因为它们竞争的是同一个对象 (demo1) 的实例锁。synchronized实例方法锁的是当前对象实例 (this)。
• 线程1/2 和 线程3 (demo2.methodB)：不互斥。因为线程3锁的是另一个对象 (demo2) 的实例锁。不同的对象实例，锁不同。
• 线程1/2/3 和 线程4 (SyncDemo.methodC)：不互斥。因为线程4锁的是类的Class对象锁(SyncDemo.class)。实例锁和类锁是两个不同的锁。

原理与内存关系：

• 每个Java对象都有一个内置锁（监视器锁，Monitor）。
• synchronized实例方法：锁是调用该方法的对象实例。
• synchronized静态方法：锁是该类的Class对象。
• synchronized(lockObject)代码块：锁是指定的lockObject。

深度追问：

• 如果methodB是一个普通非同步方法，线程1和线程2会互斥吗？
  • 不会。只有同步方法或同步块才会去获取锁。普通方法可以被任意线程同时调用。
• 锁的粒度对性能有什么影响？
  • 锁粒度粗（如锁整个对象或类）：安全性高，但并发度低，容易导致线程阻塞，性能差。
  • 锁粒度细（如锁某个独立的成员变量或代码块）：并发度高，性能好，但设计复杂，容易出错（如死锁）。
  • 最佳实践是在保证线程安全的前提下，使用尽可能细粒度的锁。例如，使用ConcurrentHashMap代替synchronized包装的HashMap，使用原子变量代替锁。

9. 试题八：ArrayList的迭代器与结构性修改

题目：

List<String> list = new ArrayList<>(); list.add("a"); list.add("b"); list.add("c"); Iterator<String> iterator = list.iterator(); while (iterator.hasNext()) { String item = iterator.next(); if ("b".equals(item)) { list.remove(item); // 使用list.remove // iterator.remove(); // 如果换成这行呢？ } } System.out.println(list);

考点：ArrayList的Iterator实现、快速失败机制、ConcurrentModificationException。

答案与解析：

• 使用list.remove(item)：会抛出ConcurrentModificationException。原因与HashMap的例子类似，list的结构性修改（remove）导致modCount增加，但iterator的expectedModCount未更新，下次调用next()时检查失败。
• 使用iterator.remove()：可以安全删除，输出[a, c]。iterator.remove()方法会在删除元素后，将expectedModCount更新为最新的modCount，从而保持一致性。

ArrayList.iterator()的源码简析：

private class Itr implements Iterator<E> { int expectedModCount = modCount; // 初始化时记录当前修改次数 public E next() { checkForComodification(); // 关键检查！ // ... 其他逻辑 } final void checkForComodification() { if (modCount != expectedModCount) throw new ConcurrentModificationException(); } public void remove() { // ... 调用ArrayList.this.remove(index) expectedModCount = modCount; // 删除后同步更新！ } }

深度追问：

• 使用for-each循环删除元素会怎样？
  • for-each循环底层也是使用Iterator。在循环中直接调用list.remove()同样会触发ConcurrentModificationException。安全做法是在循环内使用iterator.remove()，或者使用Java 8+的removeIf。
• CopyOnWriteArrayList为什么可以在迭代时修改？
  • CopyOnWriteArrayList在修改时（如add,remove）会复制底层数组，在副本上修改，然后将原数组引用指向新副本。它的Iterator遍历的是创建迭代器那一刻的数组快照。因此，在迭代过程中对容器的修改，不会影响正在进行的迭代，也不会抛出ConcurrentModificationException。它适用于读多写少的场景。

10. 试题九：static代码块、构造代码块、构造函数的执行顺序

题目：

public class InitOrderDemo { public static String staticField = "静态变量"; public String field = "实例变量"; static { System.out.println(staticField); System.out.println("静态初始化块"); } { System.out.println(field); System.out.println("普通初始化块"); } public InitOrderDemo() { System.out.println("构造函数"); } public static void main(String[] args) { new InitOrderDemo(); } }

考点：类初始化与实例初始化的顺序、JVM类加载机制。

答案与解析：输出顺序为：

静态变量 静态初始化块 实例变量 普通初始化块 构造函数

执行顺序原理（单次创建对象）：

1. 类加载阶段（第一次主动使用时触发，本例是main方法中new）：
   • 加载 -> 验证 -> 准备 -> 解析 -> 初始化。
   • 在初始化阶段，执行<clinit>()方法，该方法由编译器自动收集：
     • 所有类变量（static变量）的赋值动作。
     • 所有静态代码块（static{}）中的语句。
   • 收集顺序按在源文件中出现的顺序。所以先执行staticField赋值，再执行static块。
2. 对象实例化阶段（每次new时触发）：
   • 为新生对象分配堆内存。
   • 执行<init>()方法，该方法由编译器自动收集：
     • 调用父类<init>()（本例无显式父类，则调用Object的）。
     • 所有实例变量（非static）的赋值动作。
     • 所有普通代码块（{}）中的语句。
     • 最后执行构造函数体中的代码。
   • 同样按源文件出现顺序收集。所以先执行field赋值，再执行普通代码块，最后执行构造函数。

深度追问：

• 如果有父类呢？
  • 顺序是：父类静态 -> 子类静态 -> 父类实例 -> 父类构造 -> 子类实例 -> 子类构造。即先完成从父到子的类初始化，再完成从父到子的对象实例化。
• final static常量在什么时候赋值？
  • 如果常量是编译期常量（如public static final String CONST = "ABC"），其值在编译期就确定，并直接内联到使用它的代码中，不会触发类的初始化。
  • 如果常量需要运行时计算（如public static final int RANDOM = new Random().nextInt()），则赋值操作发生在类初始化阶段。

11. 试题十：ThreadLocal的内存泄漏隐患

题目：

public class ThreadLocalDemo { private static ThreadLocal<SimpleDateFormat> dateFormatHolder = new ThreadLocal<SimpleDateFormat>() { @Override protected SimpleDateFormat initialValue() { return new SimpleDateFormat("yyyy-MM-dd"); } }; public static void main(String[] args) throws InterruptedException { ExecutorService executor = Executors.newFixedThreadPool(10); for (int i = 0; i < 1000; i++) { executor.submit(() -> { try { // 使用dateFormatHolder.get()进行日期格式化 String date = dateFormatHolder.get().format(new Date()); System.out.println(Thread.currentThread().getName() + ": " + date); } finally { // 问题：这里缺少了什么？ } }); } executor.shutdown(); executor.awaitTermination(1, TimeUnit.HOURS); } }

考点：ThreadLocal的工作原理、内存泄漏的成因与预防。

答案与解析：

• 问题：代码在finally块中缺少了dateFormatHolder.remove()调用。
• 内存泄漏原理：
  1. ThreadLocal本身并不存储值，它只是一个键（Key）。值存储在每个线程自己的ThreadLocalMap中。
  2. ThreadLocalMap的Entry继承自WeakReference<ThreadLocal<?>>，这意味着ThreadLocal对象本身是弱引用。当外部强引用（如dateFormatHolder）消失后，ThreadLocal对象在下次GC时会被回收。
  3. 但是，Entry中的value（即SimpleDateFormat对象）是强引用。
  4. 在线程池场景下，核心线程会一直存活。如果线程执行完任务后，没有调用ThreadLocal.remove()，那么ThreadLocalMap中就会一直存在一个key为null（因为ThreadLocal被回收了），value为SimpleDateFormat的Entry。这个value由于被线程的ThreadLocalMap强引用，永远无法被GC回收，造成内存泄漏。

内存关系图（泄漏时）：

线程引用 (强) -> Thread对象 -> threadLocals (ThreadLocalMap) | v Entry数组 | v 某个Entry: key=null (弱引用，已被GC) | value=SimpleDateFormat对象 (强引用，无法回收)

解决方案：

• 务必在使用完ThreadLocal后，调用remove()方法清理当前线程的ThreadLocalMap中的对应Entry。这是编码规范。

  finally { dateFormatHolder.remove(); // 必须清理！ }

• 将ThreadLocal变量声明为static final，避免重复创建。
• 考虑使用ThreadLocal的withInitial方法（Java 8+）进行初始化。

深度追问：

• 为什么ThreadLocal的Key要设计成弱引用？
  • 这是一种防御性设计，为了防止因为ThreadLocal对象本身无法被回收（比如被缓存长期持有）而导致Thread和ThreadLocalMap也无法被回收。弱引用让Key的回收变得容易一些，但**value的回收责任转移给了开发者**，必须通过remove()来清理。
• 除了线程池，还有哪些场景要注意？
  • 任何可能复用线程的场景都需要注意，例如使用Servlet容器（如Tomcat），其工作线程也是复用的。如果在Servlet或Filter中使用了ThreadLocal，必须在请求处理结束时调用remove()。

12. 总结与面试准备建议

这10道题，从String常量池到ThreadLocal内存泄漏，几乎覆盖了Java高级面试中关于语言核心和并发基础最常被深挖的点。它们共同揭示了一个事实：高级岗位考察的深度，远不止于API的熟练使用，而是对JVM机制、内存模型、并发原理的透彻理解。

回顾核心要点：

1. 内存与对象：理解String常量池、包装类缓存、对象创建与引用的区别。
2. JVM执行：掌握类加载、初始化顺序、异常处理中finally的执行机制。
3. 多线程与并发：清晰区分volatile（可见性、有序性）与原子性的关系；理解synchronized的锁对象与粒度；掌握ThreadLocal的正确用法与内存泄漏预防。
4. 集合框架：深刻理解HashMap、ArrayList等集合的迭代器快速失败机制，以及如何在并发环境下安全使用和修改。
5. 方法调用：明确重载（静态分派）与重写（动态分派）的根本区别。

给面试者的最后建议：

• 不要死记答案：面试官稍加变通或追问“为什么”，死记的答案就会露馅。务必理解每道题背后的原理和规范。
• 善用工具验证：对于不确定的问题，可以写简单的测试代码，并结合javap -c反编译字节码、JConsole、VisualVM等工具进行观察和分析。
• 建立知识关联：例如，把HashMap的并发问题、volatile的可见性与Java内存模型（JMM）关联起来；把synchronized与对象头、锁升级过程关联起来。
• 关注官方文档：《Java语言规范》和《JVM规范》是终极裁判。对于有争议或模糊的点，回归规范是最可靠的。

把这些高频“送命题”变成你的“送分题”，不仅仅是为了通过一次面试，更是为了构建起坚实、系统的Java知识体系，让你在解决复杂的生产问题时，能够直指根源，游刃有余。