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

Java面试核心知识体系全景解析

在当今企业级开发领域，Java依然是不可撼动的主流语言。无论是电商大促时每秒数万订单的高并发处理，还是金融系统中毫秒级响应的稳定性要求，背后都离不开Java强大而成熟的生态支撑。但真正让开发者在技术浪潮中脱颖而出的，不是对Spring Boot的熟练使用，而是对语言本质、运行机制和底层原理的深刻理解。

你有没有遇到过这样的场景？——明明写的代码逻辑没问题，上线后却偶发性地出现数据不一致；或者在面试官面前侃侃而谈“我用过Redis做缓存”，却被一句“那你知道volatile关键字怎么防止指令重排吗”问得哑口无言。这正是许多中高级工程师面临的困境： 会用框架，但不懂根基 。

今天我们就来打破这种表层认知，从一个看似简单的单例模式说起，揭开Java世界里那些藏在语法糖背后的真相。

public class Singleton {
    private static volatile Singleton instance;
    private Singleton() {}

    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

别小看这几行代码，它就像一面镜子，照出了Java程序员的真实水平。你能说出这里面涉及多少个核心技术点吗？类加载机制、线程安全、JVM内存模型、对象初始化顺序……没错，这就是我们常说的“ 基础为根、并发为骨、JVM为魂、架构为翼 ”四维能力模型的集中体现。

---

一、语言基石：你以为了解的数据类型，其实远不止表面那么简单 🧱

很多人觉得Java基础很简单，八种基本类型、面向对象三大特性，背一背就完事了。可现实是，生产环境里90%的隐蔽Bug，恰恰出在这些“简单”的地方。

1.1 自动装箱的甜蜜陷阱：为什么100 == 100为true，而200 == 200却是false？

来看这段代码：

Integer a = 100;
Integer b = 100;
Integer c = 200;
Integer d = 200;

System.out.println(a == b); // true 😲
System.out.println(c == d); // false 😳

是不是有点懵？别急，我们一步步拆解。

当你写下 Integer a = 100; 这一行时，编译器其实在背后悄悄调用了 Integer.valueOf(100) 。这个方法可不是每次都新建对象，它内部有个静态缓存池，预存了 -128 到 127 范围内的所有 Integer 实例。所以当两个变量都在这个范围内赋值时，它们指向的是同一个对象，自然 == 成立。

但一旦超出这个范围，比如200，每次都会通过 new Integer(200) 创建新实例，引用不同，结果自然是 false 。

💡 小贴士：这个缓存范围可以通过 JVM 参数 -Djava.lang.Integer.IntegerCache.high=256 扩展上限（不能改下限），但在实际项目中并不推荐这么做——毕竟内存不是大风刮来的。

包装类	是否缓存	缓存范围	可配置
Byte	✅	-128 ~ 127	❌
Short	✅	-128 ~ 127	❌
Integer	✅	-128 ~ 127	⚠️ 只能扩展上限
Long	✅	-128 ~ 127	❌
Character	✅	0 ~ 127 (ASCII)	❌
Boolean	✅	TRUE , FALSE 常量	❌

看到没？除了 Float 和 Double 没有缓存（连续值太多，缓存意义不大），其他都有类似的优化策略。设计初衷是为了减少频繁创建小整数对象带来的GC压力，尤其在循环计数、集合索引等高频场景下效果显著。

但这把双刃剑也带来了风险。特别是在高并发环境下，如果大量使用自动装箱，会导致短生命周期对象激增，引发Young GC风暴。不信？咱们做个实验看看。

1.2 性能实测：一次装箱操作到底有多贵？

假设我们要往列表里添加一百万个整数，分别用标准 ArrayList<Integer> 和 Trove 的 TIntArrayList 来对比：

import gnu.trove.list.array.TIntArrayList;
import java.util.ArrayList;

public class BoxingPerformanceTest {
    private static final int COUNT = 1_000_000;

    public static void testWithStandardList() {
        ArrayList<Integer> list = new ArrayList<>();
        long start = System.nanoTime();
        for (int i = 0; i < COUNT; i++) {
            list.add(i); // 自动装箱 → Integer.valueOf(i)
        }
        long mid = System.nanoTime();

        int sum = 0;
        for (Integer n : list) {
            sum += n; // 自动拆箱 → n.intValue()
        }
        long end = System.nanoTime();

        System.out.printf("标准List: 添加耗时=%.2fms, 遍历耗时=%.2fms%n",
                (mid - start) / 1e6, (end - mid) / 1e6);
    }

    public static void testWithTroveList() {
        TIntArrayList list = new TIntArrayList();
        long start = System.nanoTime();
        for (int i = 0; i < COUNT; i++) {
            list.add(i); // 直接存int，无装箱
        }
        long mid = System.nanoTime();

        int sum = 0;
        for (int i = 0; i < list.size(); i++) {
            sum += list.get(i); // 直接取int，无拆箱
        }
        long end = System.nanoTime();

        System.out.printf("Trove List: 添加耗时=%.2fms, 遍历耗时=%.2fms%n",
                (mid - start) / 1e6, (end - mid) / 1e6);
    }
}

某次运行结果如下：

标准List: 添加耗时=45.23ms, 遍历耗时=8.76ms
Trove List: 添加耗时=12.45ms, 遍历耗时=2.11ms

差距惊人！Trove版本快了近4倍！

为什么？因为每个 Integer 对象在64位JVM上至少占用16字节（对象头+value），而原始 int 只需要4字节。空间效率提升75%，加上避免了对象分配和GC回收开销，性能优势自然凸显。

🚨 特别提醒：在Stream API中也要小心NPE！
java List<Integer> nums = Arrays.asList(1, 2, null, 4); nums.stream().mapToInt(Integer::intValue).sum(); // NPE!

所以记住这几个原则：
- 对象比较优先用 equals() ；
- 循环中避免频繁装箱；
- 明确可能为null的包装类要提前判空；
- 大数据量整数操作考虑用 FastUtil 或 Trove 替代标准集合。

---

二、面向对象的本质：多态不只是语法，更是JVM的魔法 🪄

封装、继承、多态——这三个词你可能已经听腻了。但你知道多态是怎么在JVM层面实现的吗？为什么父类引用可以指向子类对象？这一切的背后，是一个叫 虚方法表（vtable） 的黑科技。

2.1 多态是如何工作的？

来看个经典例子：

class Animal {
    public void makeSound() {
        System.out.println("Animal makes sound");
    }
}

class Dog extends Animal {
    @Override
    public void makeSound() {
        System.out.println("Dog barks");
    }
}

public class PolymorphismDemo {
    public static void main(String[] args) {
        Animal a = new Dog();
        a.makeSound(); // 输出：Dog barks
    }
}

这里的关键在于：方法调用不是在编译期决定的，而是在运行时根据对象的实际类型动态绑定的。

具体流程是这样的：
1. a.makeSound() 触发 invokevirtual 指令；
2. JVM读取 a 指向的对象头中的类指针 → 发现是 Dog.class ；
3. 查找 Dog 类的虚方法表；
4. 找到 makeSound 方法对应的实现地址；
5. 跳转执行。

每个类在类加载阶段都会生成一张vtable，记录所有可被重写的方法入口。子类继承父类的方法表，并替换已被重写的方法条目。这就实现了“同一操作，不同行为”。

类型	方法名	vtable条目	实现地址
Animal	makeSound	0	Animal.makeSound()
Dog	makeSound	0	Dog.makeSound()（覆盖）

注意⚠️：以下几种方法不会进入vtable，调用方式为静态绑定：
- private 方法
- static 方法
- final 方法
- 构造器

这也是为什么你不能重写 private 方法的原因——它根本就没打算参与多态。

2.2 策略模式实战：支付系统的优雅设计

多态最强大的应用场景之一就是 策略模式 。想象一下你的电商平台要接入微信、支付宝、银联等多种支付方式，难道要用一堆if-else判断？

当然不是！我们可以这样设计：

interface PaymentStrategy {
    void pay(double amount);
}

class WeChatPay implements PaymentStrategy {
    public void pay(double amount) {
        System.out.println("微信支付: ¥" + amount);
    }
}

class AliPay implements PaymentStrategy {
    public void pay(double amount) {
        System.out.println("支付宝支付: ¥" + amount);
    }
}

class PaymentContext {
    private PaymentStrategy strategy;

    public void setStrategy(PaymentStrategy strategy) {
        this.strategy = strategy;
    }

    public void executePayment(double amount) {
        strategy.pay(amount); // 多态调用
    }
}

客户端代码简洁明了：

PaymentContext context = new PaymentContext();

context.setStrategy(new WeChatPay());
context.executePayment(99.9);

context.setStrategy(new AliPay());
context.executePayment(199.0);

输出：

微信支付: ¥99.9
支付宝支付: ¥199.0

新增支付方式？只需新增类并实现接口即可，完全符合开闭原则。这才是真正的可扩展架构！

---

三、对象比较的艺术：equals、hashCode与集合性能密不可分 🔐

在Java中， == 和 equals() 的区别几乎是必考题。但真正考验功力的，是你是否理解它们与 hashCode() 之间的契约关系。

3.1 正确重写 equals 与 hashCode

先看一个典型的实体类：

public class Person {
    private String name;
    private int age;

    public Person(String name, int age) {
        this.name = name;
        this.age = age;
    }

    @Override
    public boolean equals(Object obj) {
        if (this == obj) return true;                    // 快速路径
        if (obj == null || getClass() != obj.getClass()) return false;
        Person person = (Person) obj;
        return age == person.age && Objects.equals(name, person.name);
    }

    @Override
    public int hashCode() {
        return Objects.hash(name, age);
    }
}

这里有几个细节要注意：
- getClass() != obj.getClass() 保证类型严格匹配（比 instanceof 更安全）；
- Objects.equals() 安全处理null字符串；
- Objects.hash() 自动生成基于字段的哈希码。

3.2 HashMap中的致命陷阱

如果不重写 hashCode() 会发生什么？来看这个例子：

Person p1 = new Person("Alice", 25);
Person p2 = new Person("Alice", 25);

Map<Person, String> map = new HashMap<>();
map.put(p1, "Engineer");

System.out.println(map.get(p2)); // null！😱

即使 p1.equals(p2) 为 true ， get(p2) 也可能返回 null 。原因很简单： HashMap 先用 hashCode() 定位桶位置，再用 equals() 确认键是否相等。如果两个对象哈希码不同，压根不会进同一个桶，怎么可能找到？

✅ 正确做法：只要重写了 equals() ，就必须重写 hashCode() ！

IDEA 提供一键生成功能，Lombok 也有 @EqualsAndHashCode 注解帮你省事：

@Data
@EqualsAndHashCode(of = {"name", "age"})
public class Person {
    private String name;
    private int age;
}

不过建议在作为Map键或Set元素的类上保持不可变性（immutable），否则修改字段会导致哈希码变化，对象直接“丢失”在集合中。

---

四、并发世界的秩序守护者：JMM、volatile与synchronized 🔐

如果说Java基础是地基，那么并发编程就是高楼大厦的骨架。没有扎实的并发功底，别说应对双十一流量洪峰，就连日常业务都可能埋下定时炸弹。

4.1 JMM：主内存 vs 工作内存

JVM规定所有变量都存在 主内存 中，每个线程有自己的 工作内存 ，保存变量副本。线程不能直接操作主内存，必须通过一系列原子操作同步：

操作	含义
read	主内存 → 工作内存
load	加载到工作内存变量
use	传递给执行引擎
assign	接收值并赋给变量
store	工作内存 → 主内存
write	写入主内存变量
lock	锁定主内存变量
unlock	释放锁

听起来很美，但问题来了：线程A改了变量，线程B可能根本看不到！

public class VisibilityExample {
    private boolean running = true;

    public void run() {
        new Thread(() -> {
            while (running) { /* busy loop */ }
            System.out.println("Stopped");
        }).start();
    }

    public void stop() throws InterruptedException {
        Thread.sleep(1000);
        running = false;
        System.out.println("Set to false");
    }
}

预期是一秒后停止，但某些JVM可能永远卡住——因为子线程一直在用自己工作内存里的旧值！

解决办法？加 volatile ！

private volatile boolean running = true;

volatile 保证两点：
1. 可见性 ：写操作立即刷回主内存，读操作强制重新加载；
2. 有序性 ：禁止指令重排，插入内存屏障。

但它不保证原子性！像 count++ 这种复合操作仍需 synchronized 或 AtomicInteger 。

4.2 单例模式的终极形态：DCL + volatile

还记得开头那个双重检查锁定单例吗？为什么需要 volatile ？

private static volatile Singleton instance;

public static Singleton getInstance() {
    if (instance == null) {
        synchronized (Singleton.class) {
            if (instance == null) {
                instance = new Singleton(); // 可能发生重排！
            }
        }
    }
    return instance;
}

new Singleton() 实际包含三步：
1. 分配内存；
2. 初始化对象；
3. instance 指向该地址。

由于指令重排，第2步和第3步可能交换。此时另一个线程进来发现 instance != null ，就会拿到一个还没初始化完成的对象，后果不堪设想！

加上 volatile 后，内存屏障阻止了重排，确保安全性。

---

五、synchronized的进化之路：从无锁到重量级锁 🔄

synchronized 并非一成不变，HotSpot虚拟机为其设计了一套精妙的 锁升级机制 ，尽量减少竞争不激烈时的性能损耗。

5.1 锁的四个阶段

阶段	触发条件	性能表现
无锁	刚创建对象	无开销
偏向锁	同一线程重复进入	几乎无开销
轻量级锁	多线程交替获取	CAS切换
重量级锁	高并发争抢	OS互斥量，阻塞唤醒

对象头结构（64位JVM）

区域	大小	说明
Mark Word	64bit	存储哈希码、锁状态等
Class Pointer	32bit	类元数据指针
Array Length	32bit	数组特有

其中 Mark Word 会根据锁状态动态调整格式：

• 无锁 ：hash(31) | age(4) | biased_lock(1) | lock(2)
• 偏向锁 ：thread_id(54) | epoch(2) | age(4) | lock(2)
• 轻量级锁 ：ptr_to_lock_record(62) | lock(2)
• 重量级锁 ：ptr_to_monitor(62) | lock(2)

5.2 锁升级全过程演示

public class SynchronizedUpgradeDemo {
    static final Object lock = new Object();

    public static void main(String[] args) throws InterruptedException {
        // 查看对象布局（需引入 jol-core）
        System.out.println(ClassLayout.parseInstance(lock).toPrintable());

        // 1. 偏向锁
        synchronized (lock) {
            System.out.println("偏向锁：" + ClassLayout.parseInstance(lock).toPrintable());
        }

        // 2. 轻量级锁（两线程交替）
        Thread t1 = new Thread(() -> {
            synchronized (lock) {
                System.out.println("t1 获取锁");
            }
        });

        Thread t2 = new Thread(() -> {
            synchronized (lock) {
                System.out.println("t2 获取锁");
            }
        });

        t1.start(); t2.start();
        t1.join(); t2.join();

        // 3. 重量级锁（高并发）
        ExecutorService es = Executors.newFixedThreadPool(10);
        for (int i = 0; i < 100; i++) {
            es.submit(() -> {
                synchronized (lock) {
                    try { Thread.sleep(1); } catch (InterruptedException e) {}
                }
            });
        }
        es.shutdown();
        es.awaitTermination(10, TimeUnit.SECONDS);
    }
}

📦 依赖：
xml <dependency> <groupId>org.openjdk.jol</groupId> <artifactId>jol-core</artifactId> <version>0.16</version> </dependency>

5.3 实战调优建议

场景	建议
Web应用，低竞争	保留偏向锁
微服务高频调用	关闭偏向锁 -XX:-UseBiasedLocking
高频短临界区	使用 ReentrantLock 或无锁结构
查看锁状态	jstack 观察 waiting on monitor

---

六、Spring的灵魂：IOC、AOP与事务控制 🌀

当我们谈论Spring时，其实是在谈论一套完整的软件工程哲学：控制反转、依赖注入、横切关注分离……

6.1 Bean生命周期与三级缓存破局循环依赖

Spring如何解决A依赖B、B又依赖A的问题？答案是—— 三级缓存 ！

缓存层级	名称	作用
一级	singletonObjects	成熟的单例对象
二级	earlySingletonObjects	提前曝光的原始对象
三级	singletonFactories	ObjectFactory 工厂

流程如下：
1. A开始创建 → 放入三级缓存
2. A注入B → B开始创建
3. B注入A → 从三级缓存获取工厂，生成早期引用放入二级缓存
4. B创建完成 → 注入A完成
5. A继续初始化 → 完成后移至一级缓存

⚠️ 注意：仅适用于单例 + setter注入，构造器注入无法解决。

6.2 AOP代理机制：JDK Proxy vs CGLIB

对比项	JDK Proxy	CGLIB
基于	接口	类继承
性能	快（JVM原生）	稍慢（ASM字节码）
限制	必须有接口	final类/方法无法代理
内存	低	高（生成新类）

Spring默认优先用JDK Proxy，可通过 proxyTargetClass=true 强制CGLIB。

6.3 @Transactional失效的五大坑

1. 私有方法加注解 → 代理无法拦截
2. 自调用（this.method） → 绕过代理
3. 异常被捕获未抛出 → 不触发回滚
4. 非运行时异常未指定rollbackFor
5. 非Spring管理类

修复示例：

@Service
public class OrderService {

    @Autowired
    private OrderService self; // 自注入获取代理对象

    public void placeOrder() {
        self.placeWithTx(); // 走代理链
    }

    @Transactional(rollbackFor = Exception.class)
    public void placeWithTx() throws Exception {
        // 数据库操作
        throw new Exception("业务异常");
    }
}

---

结语：技术深度决定职业高度 🚀

你看，同样是写Java，有人只能堆CRUD，有人却能在关键时刻定位线上死锁、优化GC停顿、设计高可用架构。差距在哪？就在这些看似“冷门”的底层知识里。

掌握这些内容，不仅能让你在面试中从容应对各种刁钻问题，更重要的是，它会让你写出更健壮、更高性能、更容易维护的代码。而这，才是一个优秀工程师的核心竞争力。

下次当你再看到 volatile 、 synchronized 或 @Transactional 时，希望你能想起今天聊过的每一个细节——因为正是这些点滴积累，构成了你通往技术巅峰的阶梯。✨