一线大厂 Java 岗面试聚焦 “基础扎实性、原理理解深度、场景落地能力”，本文整理笔试阶段高频的选择 / 简答题，及面试阶段核心的原理 / 场景题，每道题均附答案解析与延伸考点，助力求职者高效备考，快速适配大厂考核要求。

以下面试题打包好的：https://github.com/encode-studio-fe/natural_traffic/wiki/scan_material3

---

一、笔试高频题（选择 + 简答）​

（一）Java 基础​

1. 选择题：以下关于 Java 容器的说法，错误的是（ ）​

A. ArrayList 底层基于动态数组，查询快、增删慢（尾部增删快）​

B. LinkedList 底层基于双向链表，增删快、查询慢​

C. HashSet 底层依赖 HashMap，元素存储在 HashMap 的 key 中，value 为固定空对象​

D. TreeMap 是线程安全的，默认按 key 升序排序​

答案：D​

解析：TreeMap 底层基于红黑树实现，线程不安全（JUC 包下的 ConcurrentSkipListMap 才是线程安全的有序 Map），默认按 key 自然升序排序（可自定义 Comparator），D 错误；A、B、C 均为容器类的正确特性描述。​

2. 简答题：Java 中 “==” 与 equals () 的区别？String 类的 equals () 方法有什么特殊实现？​

答案解析：​

1. 核心区别：​

• “==”：若比较基本数据类型，比较的是 “值”；若比较引用数据类型，比较的是 “对象内存地址”（是否为同一对象）。​

• equals ()：是 Object 类的方法，默认实现为 “==”（比较地址）；子类可重写，实现 “值相等” 比较（如 String、Integer）。​

1. String 类的 equals () 特殊实现：​

String 重写了 equals ()，先判断地址是否相同（相同则直接返回 true），若地址不同，再判断是否为 String 类型，最后逐字符比较内容是否一致，代码逻辑简化如下：​

public boolean equals(Object anObject) {
    if (this == anObject) return true;
    if (anObject instanceof String) {
        String anotherString = (String)anObject;
        int n = value.length;
        if (n == anotherString.value.length) {
            char v1[] = value;
            char v2[] = anotherString.value;
            int i = 0;
            while (n-- != 0) {
                if (v1[i] != v2[i]) return false;
                i++;
            }
            return true;
        }
    }
    return false;
}

延伸考点：String 常量池特性 ——String s1 = "abc"与String s2 = new String("abc")，s1 指向常量池对象，s2 指向堆内存对象，故s1 == s2为 false，s1.equals(s2)为 true。

​

（二）JVM​

1. 选择题：JDK 8 中，以下关于 GC 收集器的说法，正确的是（ ）​

A. G1 收集器仅负责老年代的垃圾回收​

B. Parallel Scavenge 收集器以 “低延迟” 为目标，适合互联网 Web 服务​

C. CMS 收集器采用 “标记 - 清除” 算法，会产生内存碎片​

D. Serial 收集器是多线程收集器，适合服务器端场景​

答案：C​

解析：CMS 收集器针对老年代，采用 “标记 - 清除” 算法，回收后会留下内存碎片（需通过 Full GC 整理），C 正确；G1 收集器负责整堆回收（年轻代 + 老年代），A 错误；Parallel Scavenge 以 “高吞吐量” 为目标，适合批量处理任务，B 错误；Serial 是单线程收集器，适合客户端 / 小型程序，D 错误。​

2. 简答题：什么是内存溢出（OOM）？常见的 OOM 类型有哪些？如何排查？​

答案解析：​

1. 内存溢出定义：JVM 内存区域无法满足对象分配需求时，抛出OutOfMemoryError，区别于 “内存泄漏”（内存泄漏是对象无用但无法回收，长期积累导致 OOM）。​
2. 常见 OOM 类型：​

• ① 堆 OOM（java.lang.OutOfMemoryError: Java heap space）：对象创建过多（如无限添加元素到集合），堆内存不足；​

• ② 元空间 OOM（java.lang.OutOfMemoryError: Metaspace）：类加载过多（如动态生成大量类），元空间（本地内存）不足；​

• ③ 栈 OOM（java.lang.OutOfMemoryError: StackOverflowError）：方法递归调用过深，栈帧溢出（栈深度超过虚拟机限制）。​

1. 排查流程：​

• ① 开启 JVM 参数：添加-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=./heapdump.hprof，OOM 时自动生成堆转储文件；​

• ② 分析工具：用 JDK 自带jhat或可视化工具（MAT、VisualVM）打开堆文件，查看 “Leak Suspects”（内存泄漏疑点），定位大对象 / 冗余对象；​

• ③ 栈 OOM 排查：查看线程栈日志（如jstack命令），定位递归调用过深的方法，优化递归逻辑（如改为迭代）。

（三）并发编程​

1. 选择题：以下关于线程池的说法，错误的是（ ）​

A. 核心线程数（corePoolSize）是线程池中常驻的线程数量，即使空闲也不会销毁​

B. 当任务队列满且已创建的线程数达到最大线程数（maximumPoolSize）时，会触发拒绝策略​

C. Executors.newFixedThreadPool(5)创建的线程池，核心线程数 = 最大线程数 = 5，队列无界​

D. 线程池的shutdown()方法会立即终止所有线程，未执行的任务会被丢弃​

答案：D​

解析：shutdown()方法是 “平缓关闭”—— 不再接收新任务，等待已提交的任务执行完成后关闭线程；shutdownNow()才会立即终止线程，未执行任务被丢弃，D 错误；A、B、C 均为线程池的正确特性描述。​

2. 简答题：volatile 关键字的作用是什么？能保证原子性吗？为什么？​

答案解析：​

1. volatile 的核心作用：​

• ① 可见性：保证不同线程对 volatile 变量的修改 “立即可见”—— 禁止 CPU 缓存，变量修改后直接写入主内存，其他线程读取时从主内存加载；​

• ② 有序性：禁止指令重排序 —— 通过 “内存屏障”（Memory Barrier）确保 volatile 变量前后的指令不会被重排，避免多线程下的执行逻辑混乱。​

1. 不能保证原子性：​

原子性指 “操作不可分割”（如 i++ 包含 “读取 i、i+1、写入 i” 三步）。volatile 仅能保证可见性和有序性，无法保证多步操作的原子性。例如：

private volatile int i = 0;
// 多线程执行i++，最终结果可能小于预期值
public void increment() { i++; }

原因：多线程同时读取 i=0，各自执行 i+1=1，再写入主内存，会出现 “覆盖写”，导致最终结果小于线程执行次数。若需保证原子性，需结合synchronized、AtomicInteger（CAS 机制）或锁机制。​

二、面试深度题（原理 + 场景）​

（一）原理题：HashMap 的底层结构（JDK 8）与扩容机制？为什么数组长度必须是 2 的幂？​

解析思路：从 JDK 8 的结构优化（数组 + 链表 + 红黑树）切入，逐步拆解扩容触发条件、迁移逻辑，最后结合哈希计算原理解释数组长度的限制，体现对源码的深度理解。​

答案解析：​

1. 底层结构（JDK 8）：​

HashMap 采用 “数组（哈希桶）+ 链表 + 红黑树” 的混合结构：​

• 数组：存储链表 / 红黑树的头节点，默认初始长度 16（DEFAULT_INITIAL_CAPACITY），默认负载因子 0.75（DEFAULT_LOAD_FACTOR）；​

• 链表：哈希冲突（不同 key 计算出相同数组索引）时，元素以链表形式存储，链表长度超过 8 且数组长度≥64 时，转为红黑树（查询效率从 O (n) 提升至 O (logn)）；​

• 红黑树：链表长度小于 6 时，红黑树转回链表（避免红黑树维护成本过高）。​

1. 扩容机制：​

• ① 触发条件：当元素数量（size）> 数组长度 × 负载因子时，触发扩容，数组长度翻倍（新长度 = 原长度 ×2）；​

• ② 迁移逻辑：重新计算每个元素的哈希索引（(newCap - 1) & hash），将元素迁移到新数组；JDK 8 优化迁移逻辑 —— 通过 “哈希值的最高位是否为 1” 判断元素应放入新数组的 “原索引” 或 “原索引 + 原长度”，避免重复计算哈希。​

1. 数组长度必须是 2 的幂的原因：​

为了通过(n-1) & hash（n 为数组长度）高效计算哈希索引，且保证索引分布均匀：​

• 若 n 是 2 的幂，n-1 的二进制为 “全 1”（如 n=16 时，n-1=15→1111），(n-1) & hash能取到 hash 值的低 k 位（k 为 n 的二进制位数），索引范围在 [0, n-1]，无越界；​

• 若 n 不是 2 的幂，n-1 的二进制会有 0 位（如 n=15 时，n-1=14→1110），(n-1) & hash的结果会丢失某些位，导致索引分布不均，哈希冲突概率升高。​

（二）场景题：Spring 项目中，如何解决 “数据库事务不生效” 的问题？​

场景描述：某电商项目中，用户下单接口（createOrder()）调用库存扣减方法（deductStock()）和订单入库方法（saveOrder()），代码中添加了@Transactional注解，但测试时发现 “库存扣减成功，订单入库失败”，事务未回滚，需排查并解决。​

解析思路：从@Transactional注解的生效条件出发，逐一排查常见失效场景（如非 public 方法、自调用、异常被捕获、数据源未配置事务管理器等），结合代码示例给出解决方案。​

答案解析：​

1. 常见失效场景与排查步骤：​

• ① 方法非 public 修饰：@Transactional默认只对 public 方法生效，非 public 方法（如 private、protected）的注解会被 Spring 忽略；​

排查：检查createOrder()方法是否为 public，若为 private，改为 public 即可。​

• ② 自调用问题：若createOrder()内部直接调用deductStock()和saveOrder()（未通过 Spring 代理对象调用），事务上下文无法传递，导致子方法事务不生效；​

代码示例（失效）：

@Service
public class OrderService {
    @Transactional
    public void createOrder() {
        deductStock(); // 自调用，无代理，事务不生效
        saveOrder();
    }
    private void deductStock() { ... }
    private void saveOrder() { ... }
}

解决方案：通过 Spring 上下文获取代理对象调用，或注入自身代理对象：

@Service
public class OrderService {
    @Autowired
    private ApplicationContext context;
    
    @Transactional
    public void createOrder() {
        // 获取代理对象
        OrderService proxy = context.getBean(OrderService.class);
        proxy.deductStock();
        proxy.saveOrder();
    }
    @Transactional
    public void deductStock() { ... }
    @Transactional
    public void saveOrder() { ... }
}

• ③ 异常被捕获且未抛出：若saveOrder()中异常被 try-catch 捕获，未重新抛出，Spring 无法感知异常，不会触发回滚；​

排查：检查代码中是否有 “吞异常” 逻辑，需在 catch 块中重新抛出异常（如throw new RuntimeException(e)）。​

• ④ 事务管理器未配置：若 Spring 未配置DataSourceTransactionManager，@Transactional无对应的事务管理器支撑，事务不生效；​

排查：检查配置类是否有事务管理器 Bean：

@Configuration
@EnableTransactionManagement
public class TransactionConfig {
    @Autowired
    private DataSource dataSource;
    
    @Bean
    public PlatformTransactionManager transactionManager() {
        return new DataSourceTransactionManager(dataSource);
    }
}

• ⑤ 异常类型不匹配：@Transactional默认只对RuntimeException和Error类型异常回滚，若抛出 checked 异常（如IOException），需显式指定rollbackFor；​

解决方案：注解中添加rollbackFor = Exception.class，确保所有异常都触发回滚：

@Transactional(rollbackFor = Exception.class)
public void createOrder() { ... }

1. 通用排查工具：​

开启 Spring 事务日志，在 application.yml 中添加配置，查看事务的创建、提交 / 回滚日志，定位失效原因：

logging:
  level:
    org.springframework.transaction: DEBUG
    org.springframework.jdbc.datasource.DataSourceTransactionManager: DEBUG

（三）场景题：MySQL 分库分表后，如何处理 “跨库关联查询” 问题？​

场景描述：某电商平台将用户表（user）按 user_id 哈希分库（2 个库），订单表（order）按 create_time 分表（每月 1 张表），业务需查询 “用户近 3 个月的订单列表”，涉及 user 表和 order 表的跨库关联，需设计解决方案。​

解析思路：从分库分表的架构限制出发，提供 “业务层关联”“数据冗余”“中间件支持” 三种方案，对比各方案的优缺点与适用场景，结合实际业务选择最优解。​

答案解析：​

 1、方案 1：业务层关联（推荐，轻量级）：​

• 原理：将跨库关联拆分为两次单库查询，在业务代码中完成数据关联；​

• 步骤：​

① 根据 user_id 查询用户信息（确定用户所在库，如 user_id%2=0→库 1，user_id%2=1→库 2）；​

② 根据用户 id 和时间范围（近 3 个月），查询所有订单分表（如 order_202508、order_202509、order_202510），获取订单列表；​

③ 业务代码中，将用户信息与订单列表按 user_id 关联，返回结果；​

• 优点：无需修改分库分表架构，实现简单；​

• 缺点：需两次查询，若订单表数据量大，查询效率受影响；适合关联数据量较小的场景。​

  2、方案 2：数据冗余（性能最优，适合高频查询）：​

• 原理：在订单表中冗余用户核心信息（如 user_name、user_phone），避免跨库关联；​

• 实现：order 表添加 user_name、user_phone 字段，用户信息修改时（如改手机号），通过消息队列（MQ）同步更新所有关联的订单表冗余字段；​

• 优点：查询时仅需访问订单表，无需跨库，性能高；​

• 缺点：数据冗余，需维护数据一致性（如 MQ 保证消息不丢失）；适合用户信息修改频率低、订单查询频率高的场景。​

 3、方案 3：中间件支持（重量级，适合复杂关联）：​

• 原理：使用分库分表中间件（如 Sharding-JDBC、MyCat）的 “联邦查询” 功能，由中间件自动处理跨库关联；​

• 实现：Sharding-JDBC 通过SQLHint指定分库分表规则，或配置关联表的分片策略，中间件底层执行多库查询并聚合结果；​

示例（Sharding-JDBC SQL）：

-- 通过Hint指定user表的分库规则
/* SHARDING_JDBC_HINT: t_user=0 */
SELECT o.*, u.user_name 
FROM t_order o 
JOIN t_user u ON o.user_id = u.user_id 
WHERE o.create_time >= '2025-08-01' AND u.user_id = 123;

• 优点：支持复杂跨库关联，无需业务层改造；​

• 缺点：中间件配置复杂，关联查询性能依赖中间件优化；适合多表复杂关联的场景。​

三、总结与面试建议​

文章给大家梳理的 Java 基础、JVM、并发编程、Spring 生态、数据库五大领域，是一线大厂 Java 岗面试的核心锚点 —— 笔试侧重基础概念的准确性（如容器特性、线程池参数），面试则聚焦原理深度（如 HashMap 扩容逻辑）与场景落地能力（如事务失效排查、跨库关联解决），二者共同构成大厂对 “技术硬实力” 的考核标准。​

针对备考与面试，可参考以下建议：​

1. 知识巩固：从 “记结论” 到 “懂原理”​

避免死记硬背，需深挖技术底层逻辑 —— 例如理解 volatile 时，不仅要记住 “保证可见性和有序性”，更要清楚 “内存屏障如何禁止指令重排”；学习 HashMap 时，需结合源码分析红黑树转换阈值（8）的设计原因（泊松分布下链表长度超 8 的概率极低），这种 “原理级认知” 是区分普通求职者与优秀候选人的关键。​

     2. 场景演练：把技术 “嵌入业务”​

大厂面试常以真实业务场景提问（如电商下单、分库分表查询），备考时可主动将技术与场景绑定 —— 例如思考 “秒杀场景下如何用线程池控制并发量”“订单表分表后如何保证用户订单查询的完整性”，通过 “技术方案 + 业务适配性分析” 的思路，展现解决实际问题的能力。​

     3. 面试表达：用 “结构化” 传递逻辑​

回答问题时遵循 “结论→分层解析→延伸思考” 的结构 —— 例如被问 “ThreadLocal 内存泄漏”，可先明确 “核心原因是 ThreadLocalMap 的 key 弱引用与 Thread 强引用的矛盾”，再分步骤拆解引用关系，最后给出 “手动 remove ()” 的解决方案及 “线程池场景下的特殊注意事项”，让面试官清晰感知你的逻辑链条。​

      4. 细节把控：规避 “高频踩坑点”​

笔试中需注意基础细节（如 String 常量池、Integer 缓存），面试时警惕 “经验盲区”（如 Spring 事务自调用问题、MySQL 索引失效场景），这些 “看似基础” 的考点往往是大厂筛选候选人的 “隐性门槛”，提前梳理并规避，能大幅提升面试通过率。​

---

总之，大厂 Java 岗面试不是 “技术背诵大赛”，而是对 “基础扎实度、原理理解力、场景创造力” 的综合考察。通过针对性巩固核心知识、强化场景落地训练，才能在面试中脱颖而出，拿到理想 Offer。以上面试：https://github.com/encode-studio-fe/natural_traffic/wiki/scan_material3