Java 面试高频 50 题：基础 + 进阶 + 架构（含答案）

Java核心技术的底层原理与实战优化

在智能家居设备日益复杂的今天，确保无线连接的稳定性已成为一大设计挑战。你有没有想过，为什么你的智能音箱偶尔会“失联”？或者，在高并发场景下，为何某些Java服务突然变得迟钝甚至崩溃？这些问题的背后，往往隐藏着对语言底层机制理解的缺失。

比如，面试官常问：“ 为什么HashMap在JDK 8要引入红黑树？ ” 或者 “ String为何设计为不可变？ ” 这些问题看似简单，实则直指Java的设计哲学——性能、安全与简洁之间的精妙权衡。

// 示例：String不可变性的体现
String s = "hello";
s.concat(" world"); // 产生新字符串，原对象不变
System.out.println(s); // 输出仍为 "hello" 😏

没错，这行代码不会改变 s 的值。但你知道吗？正是这种“顽固”的不可变性，让Java能在多线程环境下安全地共享字符串，避免了锁竞争带来的性能损耗。它还使得字符串可以被高效缓存（如字符串常量池），提升内存利用率。

理解这些高频考点的本质，不仅能帮你轻松应对面试，更能让你写出更健壮、更高效的代码。接下来，我们就从JVM内存模型讲起，一步步揭开Java核心机制的神秘面纱。

---

JVM内存结构：对象的一生究竟经历了什么？

想象一下，一个Java对象从诞生到消亡，就像一个人的一生。它的起点是 new 关键字，终点可能是GC回收。但中间这段旅程，充满了选择和挑战。

堆、栈、方法区：三驾马车如何协作？

我们先来认识三位主角：

• 堆（Heap） ：所有对象的“出生地”和“安息地”。它是线程共享的，也是GC的重点关照对象。
• 栈（Stack） ：每个线程私有的小天地，存放局部变量、方法调用信息等。方法执行完就自动清理，效率极高。
• 方法区（Metaspace） ：存储类的元数据、静态变量、常量池等。JDK 8之后，永久代被元空间取代，使用本地内存管理，再也不怕加载太多类而OOM了！

它们之间是怎么配合的呢？

当你写下：

Object obj = new Object();

JVM其实悄悄做了五件事：

1. 类加载检查 → 查看 Object.class 是否已加载，没加载就去方法区找；
2. 分配内存 → 在堆里划一块地给这个新对象；
3. 初始化零值 → 所有字段先设为0或null，保证安全性；
4. 设置对象头 → 写入哈希码、GC年龄、类型指针等“身份证信息”；
5. 执行构造函数 → 真正赋予业务意义。

最后，把堆中对象的引用地址写进栈里的 obj 变量，完成绑定 ✅

🤔 小思考：如果我把 obj = null; 会发生什么？
答案是：栈中的引用没了，堆里的对象就成了“孤儿”，等着被GC通过可达性分析标记并回收。

OOM不是一种病，而是四种“综合征”

OutOfMemoryError（OOM）听起来吓人，但它其实是个统称。不同类型的OOM，病因完全不同，治疗方法也千差万别。

🔴 场景一：堆溢出（Java heap space）

最常见的类型，通常是内存泄漏或大对象堆积导致。

List<byte[]> list = new ArrayList<>();
while (true) {
    list.add(new byte[1024 * 1024]); // 每次申请1MB，不释放
}

启动参数建议加个保险：

-Xms64m -Xmx64m -XX:+HeapDumpOnOutOfMemoryError

一旦触发OOM，系统会自动生成 .hprof 文件。这时候可以用 Eclipse MAT 或 JVisualVM 打开分析，看看谁占了最多内存。常见罪魁祸首包括：
- 缓存未设上限
- 监听器/回调未注销
- 静态集合持有强引用

💡 经验法则：任何缓存都要有容量限制 + 过期策略，否则迟早爆炸 💣

🟡 场景二：元空间溢出（Metaspace）

动态生成类太多？比如用了CGLIB、ASM、Groovy脚本引擎，或者微服务拆得太细，类加载器疯狂工作……

ClassPool pool = ClassPool.getDefault();
int i = 0;
while (true) {
    CtClass ct = pool.makeClass("DynamicClass" + i++);
    ct.writeFile(); // 触发类加载 → 元空间持续增长
}

解决办法：
- 设置 -XX:MaxMetaspaceSize=256m
- 使用 Arthas 查看类加载情况： classloader --list
- 考虑使用 Unsafe.defineClass() 替代动态生成（高级玩法⚠️）

🟢 场景三：栈溢出（StackOverflowError）

递归太深！最典型的例子就是无限递归：

void boom() { boom(); } // boom!

错误日志会长这样：

Exception in thread "main" java.lang.StackOverflowError
    at com.example.Test.boom(Test.java:5)
    at com.example.Test.boom(Test.java:5)
    ...

看到一堆重复调用栈，基本就能断定是递归问题。

解决方案：
- 改成迭代写法（能避免就避免递归）
- 增大栈大小： -Xss2m （默认约1M）
- 注意线程数过多也可能耗尽总内存（每个线程都有独立栈）

🔵 场景四：直接内存溢出（Direct buffer memory）

NIO玩得多的同学可能遇到过。 ByteBuffer.allocateDirect() 分配的是堆外内存，不受 -Xmx 控制！

while (true) {
    ByteBuffer.allocateDirect(100 * 1024 * 1024); // 每次100MB
}

虽然GC会在适当时候释放这部分内存（通过 Cleaner 机制），但如果分配速度远超回收速度，照样OOM。

诊断技巧：
- 启用 NMT（Native Memory Tracking）： -XX:NativeMemoryTracking=summary
- 使用 jcmd <pid> VM.native_memory summary 查看各区域内存使用
- 生产环境务必设置 -XX:MaxDirectMemo