Java 最新面试题（2026 年版 · 全网最全、最细、附答案）
以下内容基于 2025 下半年 ~ 2026 年初 真实大厂（字节、阿里、腾讯、美团、华为、京东、快手、小米等）面经 + JDK 21/22/23 新特性趋势整理。
答案力求准确、简洁、可背诵、可展开，适合三面、四面、技术终面使用。
分为八大模块，按面试出现频率从高到低排序。
一、Java 基础 & JDK 新特性（2026 年常考 JDK 21–23）
- JDK 21 / 22 / 23 最值得关注的特性有哪些？生产中你会用哪些？
答案参考优先级（2026 年真实使用率排序）： 优先级 JEP / 特性 稳定状态 生产使用场景举例 面试加分点回答 ★★★★★ 虚拟线程（Virtual Threads） JDK 21 正式 高并发 HTTP、消息消费、爬虫、数据库连接池 “替换 tomcat 线程池，QPS 提升 5–20 倍” ★★★★☆ 结构化并发（Structured Concurrency） JDK 23 预览 批量任务编排、超时控制、资源自动关闭 “替代 CompletableFuture 的混乱回调地狱” ★★★★☆ Scoped Values（范围值） JDK 21 预览→22 正式 线程局部变量的现代化替代（轻量、无继承） “比 ThreadLocal 更安全、更高效” ★★★★ String Templates（字符串模板） 多次预览中 日志、SQL、JSON 构建（防注入） “替代 String.format + 占位符混乱” ★★★☆ Sequenced Collections JDK 21 正式 List / Deque / SortedSet 统一首尾操作 “first() / last() / getFirst() 等方法” ★★★ Record Patterns + switch 模式匹配增强 JDK 21–23 逐步正式 简化 instanceof + 强制转换 + 解构 “替代繁琐的类型判断 + 强制转换” ★★☆ 分代 ZGC（Generational ZGC） JDK 21 正式 大堆低延迟 GC（<1ms STW） “生产环境开启 -XX:+UseZGC -XX:+ZGenerational” ★★ Foreign Function & Memory API JDK 22–23 JNI 现代化替代、直接操作 off-heap 内存 “调用 C++ 库、Zero-Copy 网络” 一句话总结（面试常背）：
“2026 年最值得上生产的是虚拟线程 + 结构化并发 + Scoped Values 这套组合，基本可以取代传统的线程池 + ThreadLocal 模式，极大简化高并发代码。” - 虚拟线程（Virtual Threads）与平台线程（Platform Threads）对比？使用场景？
核心对比表： 维度 平台线程（传统 Thread） 虚拟线程（JDK 21+） 备注 内存开销 1–2 MB / 线程 ~几百字节 ~ 几 KB 百万级无压力 上下文切换 操作系统内核态切换 用户态调度（轻量） 快 10–100 倍 创建/销毁成本 高 极低 阻塞不贵 适合场景 CPU 密集、少量长任务 IO 密集、高并发短任务 — 线程池是否还需要 需要（控制并发数） 一般不需要，可直接 new Thread() 推荐 Thread.ofVirtual().start() 生产建议（常考追问）：
- Tomcat / Spring WebFlux → 直接用虚拟线程线程池
- JDBC / Redis / MQ 客户端 → 配合虚拟线程使用可大幅提升吞吐
- 不要在虚拟线程里跑长时间 CPU 计算（会饿死 carrier thread）
二、并发 & 多线程（2026 年仍是重灾区）
- JDK 21+ 虚拟线程下，synchronized 还有性能问题吗？
答案：几乎没有。
虚拟线程的阻塞不再占用 carrier thread（平台线程），所以 synchronized 导致的阻塞成本大幅降低。
但仍建议：高竞争场景优先用 ReentrantLock + Condition，因为 synchronized 在虚拟线程时代优化了很多，但锁升级（偏向 → 轻量 → 重量）过程仍然存在。 - ThreadLocal 在虚拟线程下还有必要吗？
答案：基本没必要了，推荐用 Scoped Value（JDK 21+）。
ThreadLocal 在虚拟线程中会导致内存泄漏风险（因为虚拟线程数量巨大且频繁创建销毁），而 Scoped Value 是结构化的、不可变的值传递，生命周期自动跟随作用域，天然避免泄漏。 - 说说 AQS 的核心思想？ReentrantLock / CountDownLatch / Semaphore 的实现都依赖它吗？
核心：一个 volatile int state + 一个 CLH 变种的双向链表队列。
- state：表示锁状态 / 剩余资源数 / 计数等
- 队列：存放等待线程（Node 节点）
- CAS 修改 state + park/unpark 阻塞唤醒 大部分 JUC 工具类都基于 AQS：ReentrantLock、ReentrantReadWriteLock、CountDownLatch、Semaphore、CyclicBarrier、FutureTask 等。
三、集合 & 容器（高频 + 细节）
- ConcurrentHashMap 1.8 相对于 1.7 做了哪些优化？为什么放弃分段锁？
核心变化：
- 放弃分段锁 → 用 CAS + synchronized（只锁链表头 / 红黑树根）
- size() / isEmpty() 等操作不再加锁，而是用 baseCount + CounterCells 累加（类似 LongAdder）
- 扩容时多线程协助（transfer 方法）
- 链表转红黑树阈值 8 + 数组长度 ≥64 放弃分段锁原因：1.7 最大并发 = segment 数量（默认 16），1.8 理论并发更高 + 内存利用率更好。
- HashMap 在 JDK 17/21 有哪些新变化？
几乎没有大的 API 变化，但内部有微优化：
- 更好的树化 / 退化逻辑（JDK 16+）
- 配合虚拟线程使用时，迭代器更安全（fail-fast 机制不变）
四、JVM & GC（2026 年依然是三面、四面杀手）
- 分代 ZGC（JDK 21）与普通 ZGC 的区别？生产中怎么开启？
普通 ZGC：非分代，所有对象都用统一处理方式
分代 ZGC：引入年轻代（Eden + Survivor），小对象回收更快
开启方式（生产推荐）：
-XX:+UseZGC -XX:+ZGenerational -Xmx32g -Xms32g- Shenandoah GC、ZGC、Epsilon GC、ZGC 分代各自适用场景？
GC 类型 最大暂停时间 吞吐量牺牲 适用场景 是否分代
Shenandoah <10ms 中等 对延迟敏感、中等堆 是
ZGC <1ms 中等 大堆、低延迟 否（21前）
ZGC 分代 <1ms 较小 大堆 + 高吞吐 是
Epsilon 无 GC 最高 内存充足、短期任务 — 五、Spring / Spring Boot（框架层高频）- Spring Boot 3.x（JDK 17+）有哪些重大变化？
- 最低要求 JDK 17
- Jakarta EE 9+（javax.* → jakarta.*）
- AOT 编译支持（GraalVM Native Image 更友好）
- Observability 增强（Micrometer + Tracing）
- 虚拟线程原生支持（Tomcat / WebFlux）
- 设计一个支持 10w QPS 的秒杀系统，缓存 + 数据库怎么配合？
典型回答框架：- 前置限流（Sentinel / Nginx）
- Redis + Lua 脚本原子扣库存
- 异步落库（MQ 削峰）
- 缓存预热 + 热点 key 缓存
- 虚拟线程处理请求（JDK 21+）
- 幂等 + 防超卖（唯一订单号 + 去重）
- 如何设计一个分布式 Session 方案？
主流三种：- Spring Session + Redis（最常用）
- JWT（无状态，前后端分离首选）
- 粘性 Session（Nginx ip_hash）
- GraalVM Native Image 优缺点？（启动快、内存低，但反射/动态代理受限）
- Project Loom 生态现状？（很多框架 2025–2026 年已适配虚拟线程）
- Java 23 / 24 预览特性了解多少？（关注 Class-File API、Vector API 等）
- Spring Boot 3.x（JDK 17+）有哪些重大变化？
