“两个对象 equals 相等那么它们的 hashCode 必须相等吗”面试官抛出这个问题时往往不是要一个简单的“是”而是想看你能否在一秒内联想到 HashMap 的坑。基础问题之所以高频恰恰因为它们能瞬间折射出你的知识体系是否牢固。下面这十个问题几乎每一场 Java 面试都逃不掉但很多人只是背了答案却从未真正理解背后的设计哲学。一、 与 equals比的不是同一个“相等”很多人张口就说“比较地址equals比较内容”这句话对一半错一半。 在比较引用类型时确实比的是堆内存地址但 equals 的默认行为其实跟 一模一样——因为 Object.equals 就是用的 。只有当子类重写 equals 后它才可能比较内容。真正要命的是 String。String 有两个创建方式String a hello和String b new String(hello)。前者走常量池后者在堆中新建对象。所以a b是 false而a.equals(b)是 true。面试官接着问“那String c hello和 a 相等吗”这就是陷阱字符串字面量会先在常量池中找找到就直接复用所以 a c 是 true。深入一层你该理解equals 重写必须同时重写 hashCode。因为所有基于哈希的集合HashMap、HashSet都依赖 hashCode 先定位桶再用 equals 精确比较。如果你只重写 equals 不重写 hashCode就会导致两个逻辑相等的对象散落在不同桶里get 时永远查不到。这不仅是规范更是哈希表的底层逻辑决定的。更进一步面试官常问“为什么 String 重写了 equals”因为字符串在业务中大量用作唯一标识。你重写equals时要遵循自反性、对称性、传递性、一致性以及“非 null 对象 equals null 必须返回 false”。这些看似枯燥的细则恰恰是你在团队里写领域对象时最容易踩的坑。二、final 关键字修饰的不是“不能变”而是“引用不变”“final 数组可以修改吗”这个问题能过滤掉一大半只会背口诀的人。final 修饰基本类型意味着值不可变修饰引用类型意味着引用指向不可变但引用对象的内部状态完全可变。所以 final int[] arr 里你可以修改 arr[0]但不能再让 arr 指向新数组。final 真正的作用是“约束变化”。修饰类时禁止继承修饰方法时禁止重写修饰变量时保证初始化后不再重新赋值。但很多人忽略了 final 与并发内存语义的关系final 字段在构造器内初始化后其他线程无需同步就能看到该对象的安全发布。因为 JMM 对 final 提供了特殊的“冻结”语义。更实际的场景是String类本身被 final 修饰这保证了它的不可变性。不可变性是 String 可以安全作为 HashMap 键的基石——如果 String 可变哈希值会随内容变化HashMap 的查找就彻底乱套。所以面试官问你“为什么 String 被设计成 final”你不仅要回答安全、常量池复用、缓存哈希还要点出它与集合框架的协同关系。三、String / StringBuilder / StringBuffer别只看线程安全大多数人回答“StringBuffer 线程安全StringBuilder 线程不安全String 不可变”但这是教科书式的平庸答案。面试官想听到的差异在于“拼接字符串时到底发生了什么”。String s a b c在编译期会被优化为常量折叠直接生成 abc。但循环内拼接s i每次循环都会 new 一个 StringBuilder 执行 append 再 toString产生大量中间对象。性能灾难的根源不是 StringBuilder 比 StringBuffer 快而是循环拼接本身在反复创建对象。StringBuffer 的线程安全来自每个方法加 synchronized 锁但这意味着任何拼接操作都要走锁的获取与释放单线程下性能反而下降。所以现代 Java 面试中一个更锋利的回答是单线程环境坚决用 StringBuilder多线程环境下如果只是各自拼接各自的字符串仍然用 StringBuilder——因为局部变量天然线程隔离只有多个线程共享同一个 StringBuilder 对象时才需要 StringBuffer。另一个冷门考点是String.join和StringBuilder.append的区别前者要求所有元素是 String后者可以直接 append int、long 等基本类型。面试官可能追问“为什么 String 拼接 操作在 JDK9 后不是用 StringBuilder 了”答案是 JDK9 引入了 invokedynamic 动态拼接生成的字节码更智能。能讲到这个层次说明你关注语言演进而不是死背书。四、HashMap 底层从数组到红黑树的进化这是一个“逢面必问”的问题也是能区分初级和高级的分水岭。HashMap 的核心是“数组 链表 红黑树”但很多人说不清为什么链表转红黑树的阈值是 8。数组用来做哈希桶hash 后定位到桶下标当多个 key 哈希碰撞放到同一个桶里形成链表。链表长了之后查找效率降为 O(n)所以当链表长度达到 8 且数组容量不小于 64 时链表会转为红黑树查找效率升为 O(log n)。为什么是 8官方注释里解释过遵循泊松分布在随机哈希下链表长度达到 8 的概率约为千万分之六这是“空间与时间的权衡”。更深入一层HashMap 的扩容机制是“按位与”而不是取模。因为容量总是 2 的幂次方(n - 1) hash等价于hash % n但位运算更快。扩容时旧元素要么留在原索引要么移动到“原位置 旧容量”的新索引这个设计巧妙利用了容量翻倍后最高位的变化。面试官还会问“为什么 HashMap 允许 null 键而 Hashtable 不允许”因为 HashMap 对 null 做了特殊处理——null 键的 hash 值定为 0所以它总是放在数组第一个桶里。Hashtable 的设计是线程安全的旧类它不允许 null 是因为其contains方法语义模糊。可以说HashMap 对 null 的支持体现了“实用主义”而 Hashtable 的严格只是历史包袱。最后初始容量和负载因子直接影响性能。默认负载因子 0.75 是时间和空间的折中过高会降低空间浪费但增加查找成本过低则相反。如果你能预估数据量应该显式设置初始容量避免扩容时反复拷贝数组。面试官最反感的是那种“知道默认值是 0.75 但不知道为什么”的回答。五、重载和重写看起来是语法其实是多态的两种实现“重载是编译期多态重写是运行期多态”——这句话可以背但你要能解释“为什么”。重载发生在同一个类中多个方法同名但参数列表不同JVM 在编译时就能根据传入参数的类型确定调哪个方法这叫静态分派。重写发生在子类和父类之间方法签名完全一样JVM 运行时才根据对象的实际类型调用对应方法这叫动态分派。一个非常容易掉进去的坑是“重载时 null 参数调用哪个方法”。假设有两个方法f(String s)和f(Integer i)调用f(null)会编译报错吗不会。因为 null 可以匹配任何引用类型编译器会优先选择“最具体”的类型——String 和 Integer 都是 Object 的子类它们之间没有继承关系所以编译报歧义错误。这题考察的是你对“类型精度”的理解。重写需要注意的细节更多重写方法不能抛出比父类方法更宽泛的受检异常但可以抛出更窄的异常或运行时异常重写方法的访问权限不能比父类更严格——父类是 protected子类不能降级为 private。这些限制的本质都是为了保证“里氏替换”——子类对象必须能完全替代父类对象出现在任何代码中。面试官常问“重写是否必须保持返回类型一致”Java 5 以后引入了协变返回类型子类可以返回父类返回类型的子类型。比如父类返回 Animal子类可以返回 Dog。这也是符合里氏替换的。真正体现功底的是你说出“重写是运行时多态的实现基础而运行时多态又是设计模式如策略模式、模板方法的基石”——这会把问题从语法层面拉高到设计层面。六、接口和抽象类别再说“接口不能有实现”了“接口只能定义常量不能有方法体”——这句话在 Java 8 之后就已经过时了。默认方法和静态方法让接口可以携带具体实现。但面试官问这个问题核心不是考语法更新而是考“你如何做出设计选择”。抽象类捕捉的是“是什么”接口定义的是“能做什么”。抽象类代表的是类层次中的共性它有构造器、有属性可以维护状态接口则完全强调行为契约不能有实例字段只能有常量即便有默认方法也无法使用非静态字段。所以当你需要在一组类之间共享代码、且它们有明确的继承关系时用抽象类当你需要让完全不相关的类都能“做某件事”时用接口。另一个关键差异是“单继承与多实现”。Java 类只能继承一个抽象类但可以实现多个接口。接口的多实现让 Java 在保留类型安全的前提下实现了“多重继承”的能力这也是组合优于继承的一种体现。面试官可能追问“接口里的 default 方法会不会导致菱形问题”答案是如果一个类实现了两个接口且两个接口都有相同签名的方法那个类必须重写该方法消除歧义否则编译报错。更进阶的思考是抽象类很难在没有破坏封装的情况下演进而接口默认方法可以向后兼容。比如 JDK 在 Collection 接口中增加removeIf默认方法所有现有实现类无需修改就能获得新行为。这告诉我们在 API 设计时接口的演进策略比抽象类更灵活——但代价是接口不能持有状态许多需要状态的方法实现起来很别扭。七、线程创建的几种方式你以为四种其实只有一种教科书说线程创建有四种继承 Thread、实现 Runnable、实现 Callable配合 FutureTask、用线程池。面试官现在更爱问“你说这些底层都是什么”实际上所有方式的终点都是 new Thread()然后调用 start() 让内部的一个 Runnable target 启动。即使你用 ExecutorService它内部仍然是用 Thread 包装你的任务。继承 Thread 的坏处是Java 单继承一旦继承 Thread 就不能继承其他类且重写 run 方法把任务代码和线程生命周期耦合了。实现 Runnable 接口是更规范的方式因为它把“任务”和“执行”分离。Callable 的区别是它有返回值、能抛受检异常配合 FutureTask 可以获取异步计算结果。线程池作为“高级创建方式”本质是复用一堆 Thread。面试官常问“线程池内部是怎么触发的”ThreadPoolExecutor 的 execute 流程先检查核心线程数不足则新建核心线程满了进入阻塞队列队列也满了则创建非核心线程都满了执行拒绝策略。核心问题在于你是否理解“线程池里任务真正执行者仍是线程而池只是管理器的外壳”。更进一步聊聊虚拟线程JDK 21 正式落地了虚拟线程它不再绑定平台线程而是由 JVM 调度在载体线程上。那时候“创建线程”的成本变得极低但 IO 密集型的并发模型会被彻底颠覆。如果面试官问“你会怎么创建线程”你从传统方式讲到虚拟线程就说明你在持续跟踪 Java 的演进。八、synchronized 与 Lock锁的“重量”与“灵活”之争从 JDK 1.0 就有 synchronized而 Lock 是 JDK 5 引入的。一个常见的误区是“synchronized 是重量级锁Lock 是轻量级锁”。其实 synchronized 经过多次优化已经从不公平的悲观锁演进为偏向锁、轻量级锁、重量级锁的多级膨胀过程。而无竞争时synchronized 的开销可能比 Lock 还低。区别核心在于synchronized 是 JVM 级别的关键字退出同步块方法时自动释放锁线程等锁时不可中断、不可超时也不支持多条件队列。而 Lock指 ReentrantLock是 API 级别的锁必须手动 lock/unlock还要在 finally 中释放但带来了可中断等待、可设置公平锁、支持多个 Condition 和 tryLock 尝试非阻塞获取锁的能力。一个细节是 synchronized 是非公平锁ReentrantLock 默认也是非公平锁但可以构造时传 true 设为公平锁。公平锁保证线程按请求顺序获取锁避免了“线程饥饿”但也引入了上下文切换和排队开销。面试官可能追问“公平锁一定比非公平锁慢吗”不一定如果临界区极短非公平锁的“插队”反而减少了线程挂起的浪费。锁的选择永远是对并发强度、临界区长度和业务公平性需求的权衡。另一个深水区是“锁消除、锁粗化、偏向锁的机制”。比如 JIT 编译器发现局部对象锁不可能被其他线程访问就会自动去掉锁连续对同一个对象加锁解锁会合并成一次大锁。能说出这些名词说明你理解 synchronized 不是死的而是可以优化的活代码。九、JVM 内存区域哪些是线程私有哪些共享这个问题考的是你对运行时数据区的划分。JVM 内存分为线程私有和线程共享两大类。私有区域程序计数器、Java 虚拟机栈、本地方法栈。共享区域堆、方法区在 HotSpot 中通常称为元空间、运行时常量池逻辑上属于方法区。每个区域的“异常”也很关键虚拟机栈溢出会抛 StackOverflowError堆里无法再分配且无法扩展时抛 OutOfMemoryError。程序计数器是唯一不会 OOM 的区域。理解栈和堆的分工才能真正理解值传递与引用传递的悖论——方法参数是基本类型和引用变量的副本但引用所指向的对象住在堆里所以“改对象属性”在方法内生效而“换引用”不会传出方法。更有深度的点是“堆内对象的逃逸分析”。如果 JVM 确认一个局部对象没有逃逸出方法它会把这个对象分配到栈上随栈帧销毁而消失避免 GC。所以“new 的对象一定在堆上”这句话在技术上并不严谨。现代 JVM 在“空间分配”上越来越智能你需要知道这种优化存在才能在讨论性能时提到逃逸分析与标量替换。方法区在新版 JDK 中变成了元空间它不再使用堆内存而是使用本地内存。这意味着 PermGen 时代常见的“永久代 OOM”变成了可能的内存泄漏风险但调整参数也从-XX:MaxPermSize变成了-XX:MaxMetaspaceSize。面试官常问“常量池在哪”字符串常量池在堆中而类文件常量池静态常量池在方法区。这两个概念混淆是高频失误点。十、类加载过程从加载到初始化每一步都不是“刚刚好”类加载分为五个阶段加载、验证、准备、解析、初始化。很多人能背出顺序但说不清“准备”和“初始化”的区别。准备阶段为类变量分配内存并设置零值而初始化阶段才执行类构造器clinit方法此时才把显式赋值的常量和静态块真正放进去。一个经典考题private static int a 10;在准备阶段 a 是多少答案是 0不是 10。因为准备阶段只负责“零值”真正的 10 要等初始化阶段执行 putstatic 指令。除非变量被 static final 修饰而且类型是基本类型或 String那它会在准备阶段就变成常量直接写入类文件常量池——这也解释了为什么常量不需要等待初始化就能访问。双亲委派模型是本问题的重头戏。类加载器收到加载请求时先让父加载器尝试加载只有父加载器加载不到才自己加载。这样保证了核心 API 不会被用户自定义的类所篡改比如你自己写一个java.lang.String无法在应用层替换掉 JDK 的 String。破坏双亲委派的典型场景是 SPI服务提供者接口比如 JDBC 驱动管理器需要由根类加载器加载却要调用厂商提供的驱动类只能通过线程上下文类加载器反向委派。更深一层是“类在什么时候被加载”不是一编译就加载而是“主动使用”时触发初始化。主动使用包括 new 对象、访问静态字段、调用静态方法、反射、初始化子类导致父类初始化等。被动使用比如通过数组定义、引用父类静态变量但通过子类名引用不会触发子类初始化。面试官如果问“final 常量时子类会不会初始化”答案是不会因为常量被内联到了 Main 类里。如果你把类加载过程讲成“加载、验证、准备、解析、初始化”五个步骤那是及格讲出“准备阶段给零值初始化阶段给真值”那是良好再讲到“双亲委派如何防篡改、如何被 SPI 破坏”那就是优秀。面试官看重的不是你记住的名词而是你能不能把每个阶段的行为和后果串联起来。十道题目、十个层面真正的分水岭不在深度而在“每个点能否继续向下挖三层”。如果能在基础问题上主动暴露细节、主动连接上下文、主动给出反例你已经不是一个背答案的候选人而是一个有系统思维的程序员。下一次当面试官再问“String 的 equals 和 hashCode 有什么关系”试着从常量池讲到 HashMap再讲到重写约束——你会看到对方的眼神从平淡变成亮光。 Java面试官最常问的十个基础问题解析
“两个对象 equals 相等那么它们的 hashCode 必须相等吗”面试官抛出这个问题时往往不是要一个简单的“是”而是想看你能否在一秒内联想到 HashMap 的坑。基础问题之所以高频恰恰因为它们能瞬间折射出你的知识体系是否牢固。下面这十个问题几乎每一场 Java 面试都逃不掉但很多人只是背了答案却从未真正理解背后的设计哲学。一、 与 equals比的不是同一个“相等”很多人张口就说“比较地址equals比较内容”这句话对一半错一半。 在比较引用类型时确实比的是堆内存地址但 equals 的默认行为其实跟 一模一样——因为 Object.equals 就是用的 。只有当子类重写 equals 后它才可能比较内容。真正要命的是 String。String 有两个创建方式String a hello和String b new String(hello)。前者走常量池后者在堆中新建对象。所以a b是 false而a.equals(b)是 true。面试官接着问“那String c hello和 a 相等吗”这就是陷阱字符串字面量会先在常量池中找找到就直接复用所以 a c 是 true。深入一层你该理解equals 重写必须同时重写 hashCode。因为所有基于哈希的集合HashMap、HashSet都依赖 hashCode 先定位桶再用 equals 精确比较。如果你只重写 equals 不重写 hashCode就会导致两个逻辑相等的对象散落在不同桶里get 时永远查不到。这不仅是规范更是哈希表的底层逻辑决定的。更进一步面试官常问“为什么 String 重写了 equals”因为字符串在业务中大量用作唯一标识。你重写equals时要遵循自反性、对称性、传递性、一致性以及“非 null 对象 equals null 必须返回 false”。这些看似枯燥的细则恰恰是你在团队里写领域对象时最容易踩的坑。二、final 关键字修饰的不是“不能变”而是“引用不变”“final 数组可以修改吗”这个问题能过滤掉一大半只会背口诀的人。final 修饰基本类型意味着值不可变修饰引用类型意味着引用指向不可变但引用对象的内部状态完全可变。所以 final int[] arr 里你可以修改 arr[0]但不能再让 arr 指向新数组。final 真正的作用是“约束变化”。修饰类时禁止继承修饰方法时禁止重写修饰变量时保证初始化后不再重新赋值。但很多人忽略了 final 与并发内存语义的关系final 字段在构造器内初始化后其他线程无需同步就能看到该对象的安全发布。因为 JMM 对 final 提供了特殊的“冻结”语义。更实际的场景是String类本身被 final 修饰这保证了它的不可变性。不可变性是 String 可以安全作为 HashMap 键的基石——如果 String 可变哈希值会随内容变化HashMap 的查找就彻底乱套。所以面试官问你“为什么 String 被设计成 final”你不仅要回答安全、常量池复用、缓存哈希还要点出它与集合框架的协同关系。三、String / StringBuilder / StringBuffer别只看线程安全大多数人回答“StringBuffer 线程安全StringBuilder 线程不安全String 不可变”但这是教科书式的平庸答案。面试官想听到的差异在于“拼接字符串时到底发生了什么”。String s a b c在编译期会被优化为常量折叠直接生成 abc。但循环内拼接s i每次循环都会 new 一个 StringBuilder 执行 append 再 toString产生大量中间对象。性能灾难的根源不是 StringBuilder 比 StringBuffer 快而是循环拼接本身在反复创建对象。StringBuffer 的线程安全来自每个方法加 synchronized 锁但这意味着任何拼接操作都要走锁的获取与释放单线程下性能反而下降。所以现代 Java 面试中一个更锋利的回答是单线程环境坚决用 StringBuilder多线程环境下如果只是各自拼接各自的字符串仍然用 StringBuilder——因为局部变量天然线程隔离只有多个线程共享同一个 StringBuilder 对象时才需要 StringBuffer。另一个冷门考点是String.join和StringBuilder.append的区别前者要求所有元素是 String后者可以直接 append int、long 等基本类型。面试官可能追问“为什么 String 拼接 操作在 JDK9 后不是用 StringBuilder 了”答案是 JDK9 引入了 invokedynamic 动态拼接生成的字节码更智能。能讲到这个层次说明你关注语言演进而不是死背书。四、HashMap 底层从数组到红黑树的进化这是一个“逢面必问”的问题也是能区分初级和高级的分水岭。HashMap 的核心是“数组 链表 红黑树”但很多人说不清为什么链表转红黑树的阈值是 8。数组用来做哈希桶hash 后定位到桶下标当多个 key 哈希碰撞放到同一个桶里形成链表。链表长了之后查找效率降为 O(n)所以当链表长度达到 8 且数组容量不小于 64 时链表会转为红黑树查找效率升为 O(log n)。为什么是 8官方注释里解释过遵循泊松分布在随机哈希下链表长度达到 8 的概率约为千万分之六这是“空间与时间的权衡”。更深入一层HashMap 的扩容机制是“按位与”而不是取模。因为容量总是 2 的幂次方(n - 1) hash等价于hash % n但位运算更快。扩容时旧元素要么留在原索引要么移动到“原位置 旧容量”的新索引这个设计巧妙利用了容量翻倍后最高位的变化。面试官还会问“为什么 HashMap 允许 null 键而 Hashtable 不允许”因为 HashMap 对 null 做了特殊处理——null 键的 hash 值定为 0所以它总是放在数组第一个桶里。Hashtable 的设计是线程安全的旧类它不允许 null 是因为其contains方法语义模糊。可以说HashMap 对 null 的支持体现了“实用主义”而 Hashtable 的严格只是历史包袱。最后初始容量和负载因子直接影响性能。默认负载因子 0.75 是时间和空间的折中过高会降低空间浪费但增加查找成本过低则相反。如果你能预估数据量应该显式设置初始容量避免扩容时反复拷贝数组。面试官最反感的是那种“知道默认值是 0.75 但不知道为什么”的回答。五、重载和重写看起来是语法其实是多态的两种实现“重载是编译期多态重写是运行期多态”——这句话可以背但你要能解释“为什么”。重载发生在同一个类中多个方法同名但参数列表不同JVM 在编译时就能根据传入参数的类型确定调哪个方法这叫静态分派。重写发生在子类和父类之间方法签名完全一样JVM 运行时才根据对象的实际类型调用对应方法这叫动态分派。一个非常容易掉进去的坑是“重载时 null 参数调用哪个方法”。假设有两个方法f(String s)和f(Integer i)调用f(null)会编译报错吗不会。因为 null 可以匹配任何引用类型编译器会优先选择“最具体”的类型——String 和 Integer 都是 Object 的子类它们之间没有继承关系所以编译报歧义错误。这题考察的是你对“类型精度”的理解。重写需要注意的细节更多重写方法不能抛出比父类方法更宽泛的受检异常但可以抛出更窄的异常或运行时异常重写方法的访问权限不能比父类更严格——父类是 protected子类不能降级为 private。这些限制的本质都是为了保证“里氏替换”——子类对象必须能完全替代父类对象出现在任何代码中。面试官常问“重写是否必须保持返回类型一致”Java 5 以后引入了协变返回类型子类可以返回父类返回类型的子类型。比如父类返回 Animal子类可以返回 Dog。这也是符合里氏替换的。真正体现功底的是你说出“重写是运行时多态的实现基础而运行时多态又是设计模式如策略模式、模板方法的基石”——这会把问题从语法层面拉高到设计层面。六、接口和抽象类别再说“接口不能有实现”了“接口只能定义常量不能有方法体”——这句话在 Java 8 之后就已经过时了。默认方法和静态方法让接口可以携带具体实现。但面试官问这个问题核心不是考语法更新而是考“你如何做出设计选择”。抽象类捕捉的是“是什么”接口定义的是“能做什么”。抽象类代表的是类层次中的共性它有构造器、有属性可以维护状态接口则完全强调行为契约不能有实例字段只能有常量即便有默认方法也无法使用非静态字段。所以当你需要在一组类之间共享代码、且它们有明确的继承关系时用抽象类当你需要让完全不相关的类都能“做某件事”时用接口。另一个关键差异是“单继承与多实现”。Java 类只能继承一个抽象类但可以实现多个接口。接口的多实现让 Java 在保留类型安全的前提下实现了“多重继承”的能力这也是组合优于继承的一种体现。面试官可能追问“接口里的 default 方法会不会导致菱形问题”答案是如果一个类实现了两个接口且两个接口都有相同签名的方法那个类必须重写该方法消除歧义否则编译报错。更进阶的思考是抽象类很难在没有破坏封装的情况下演进而接口默认方法可以向后兼容。比如 JDK 在 Collection 接口中增加removeIf默认方法所有现有实现类无需修改就能获得新行为。这告诉我们在 API 设计时接口的演进策略比抽象类更灵活——但代价是接口不能持有状态许多需要状态的方法实现起来很别扭。七、线程创建的几种方式你以为四种其实只有一种教科书说线程创建有四种继承 Thread、实现 Runnable、实现 Callable配合 FutureTask、用线程池。面试官现在更爱问“你说这些底层都是什么”实际上所有方式的终点都是 new Thread()然后调用 start() 让内部的一个 Runnable target 启动。即使你用 ExecutorService它内部仍然是用 Thread 包装你的任务。继承 Thread 的坏处是Java 单继承一旦继承 Thread 就不能继承其他类且重写 run 方法把任务代码和线程生命周期耦合了。实现 Runnable 接口是更规范的方式因为它把“任务”和“执行”分离。Callable 的区别是它有返回值、能抛受检异常配合 FutureTask 可以获取异步计算结果。线程池作为“高级创建方式”本质是复用一堆 Thread。面试官常问“线程池内部是怎么触发的”ThreadPoolExecutor 的 execute 流程先检查核心线程数不足则新建核心线程满了进入阻塞队列队列也满了则创建非核心线程都满了执行拒绝策略。核心问题在于你是否理解“线程池里任务真正执行者仍是线程而池只是管理器的外壳”。更进一步聊聊虚拟线程JDK 21 正式落地了虚拟线程它不再绑定平台线程而是由 JVM 调度在载体线程上。那时候“创建线程”的成本变得极低但 IO 密集型的并发模型会被彻底颠覆。如果面试官问“你会怎么创建线程”你从传统方式讲到虚拟线程就说明你在持续跟踪 Java 的演进。八、synchronized 与 Lock锁的“重量”与“灵活”之争从 JDK 1.0 就有 synchronized而 Lock 是 JDK 5 引入的。一个常见的误区是“synchronized 是重量级锁Lock 是轻量级锁”。其实 synchronized 经过多次优化已经从不公平的悲观锁演进为偏向锁、轻量级锁、重量级锁的多级膨胀过程。而无竞争时synchronized 的开销可能比 Lock 还低。区别核心在于synchronized 是 JVM 级别的关键字退出同步块方法时自动释放锁线程等锁时不可中断、不可超时也不支持多条件队列。而 Lock指 ReentrantLock是 API 级别的锁必须手动 lock/unlock还要在 finally 中释放但带来了可中断等待、可设置公平锁、支持多个 Condition 和 tryLock 尝试非阻塞获取锁的能力。一个细节是 synchronized 是非公平锁ReentrantLock 默认也是非公平锁但可以构造时传 true 设为公平锁。公平锁保证线程按请求顺序获取锁避免了“线程饥饿”但也引入了上下文切换和排队开销。面试官可能追问“公平锁一定比非公平锁慢吗”不一定如果临界区极短非公平锁的“插队”反而减少了线程挂起的浪费。锁的选择永远是对并发强度、临界区长度和业务公平性需求的权衡。另一个深水区是“锁消除、锁粗化、偏向锁的机制”。比如 JIT 编译器发现局部对象锁不可能被其他线程访问就会自动去掉锁连续对同一个对象加锁解锁会合并成一次大锁。能说出这些名词说明你理解 synchronized 不是死的而是可以优化的活代码。九、JVM 内存区域哪些是线程私有哪些共享这个问题考的是你对运行时数据区的划分。JVM 内存分为线程私有和线程共享两大类。私有区域程序计数器、Java 虚拟机栈、本地方法栈。共享区域堆、方法区在 HotSpot 中通常称为元空间、运行时常量池逻辑上属于方法区。每个区域的“异常”也很关键虚拟机栈溢出会抛 StackOverflowError堆里无法再分配且无法扩展时抛 OutOfMemoryError。程序计数器是唯一不会 OOM 的区域。理解栈和堆的分工才能真正理解值传递与引用传递的悖论——方法参数是基本类型和引用变量的副本但引用所指向的对象住在堆里所以“改对象属性”在方法内生效而“换引用”不会传出方法。更有深度的点是“堆内对象的逃逸分析”。如果 JVM 确认一个局部对象没有逃逸出方法它会把这个对象分配到栈上随栈帧销毁而消失避免 GC。所以“new 的对象一定在堆上”这句话在技术上并不严谨。现代 JVM 在“空间分配”上越来越智能你需要知道这种优化存在才能在讨论性能时提到逃逸分析与标量替换。方法区在新版 JDK 中变成了元空间它不再使用堆内存而是使用本地内存。这意味着 PermGen 时代常见的“永久代 OOM”变成了可能的内存泄漏风险但调整参数也从-XX:MaxPermSize变成了-XX:MaxMetaspaceSize。面试官常问“常量池在哪”字符串常量池在堆中而类文件常量池静态常量池在方法区。这两个概念混淆是高频失误点。十、类加载过程从加载到初始化每一步都不是“刚刚好”类加载分为五个阶段加载、验证、准备、解析、初始化。很多人能背出顺序但说不清“准备”和“初始化”的区别。准备阶段为类变量分配内存并设置零值而初始化阶段才执行类构造器clinit方法此时才把显式赋值的常量和静态块真正放进去。一个经典考题private static int a 10;在准备阶段 a 是多少答案是 0不是 10。因为准备阶段只负责“零值”真正的 10 要等初始化阶段执行 putstatic 指令。除非变量被 static final 修饰而且类型是基本类型或 String那它会在准备阶段就变成常量直接写入类文件常量池——这也解释了为什么常量不需要等待初始化就能访问。双亲委派模型是本问题的重头戏。类加载器收到加载请求时先让父加载器尝试加载只有父加载器加载不到才自己加载。这样保证了核心 API 不会被用户自定义的类所篡改比如你自己写一个java.lang.String无法在应用层替换掉 JDK 的 String。破坏双亲委派的典型场景是 SPI服务提供者接口比如 JDBC 驱动管理器需要由根类加载器加载却要调用厂商提供的驱动类只能通过线程上下文类加载器反向委派。更深一层是“类在什么时候被加载”不是一编译就加载而是“主动使用”时触发初始化。主动使用包括 new 对象、访问静态字段、调用静态方法、反射、初始化子类导致父类初始化等。被动使用比如通过数组定义、引用父类静态变量但通过子类名引用不会触发子类初始化。面试官如果问“final 常量时子类会不会初始化”答案是不会因为常量被内联到了 Main 类里。如果你把类加载过程讲成“加载、验证、准备、解析、初始化”五个步骤那是及格讲出“准备阶段给零值初始化阶段给真值”那是良好再讲到“双亲委派如何防篡改、如何被 SPI 破坏”那就是优秀。面试官看重的不是你记住的名词而是你能不能把每个阶段的行为和后果串联起来。十道题目、十个层面真正的分水岭不在深度而在“每个点能否继续向下挖三层”。如果能在基础问题上主动暴露细节、主动连接上下文、主动给出反例你已经不是一个背答案的候选人而是一个有系统思维的程序员。下一次当面试官再问“String 的 equals 和 hashCode 有什么关系”试着从常量池讲到 HashMap再讲到重写约束——你会看到对方的眼神从平淡变成亮光。