1. 面试场景还原与核心考察点拆解请先做个自我介绍然后谈谈你对JVM内存模型的理解。面试官推了推眼镜在我完成基础介绍后抛出了第一个技术问题。这是广州某中型互联网企业的Java实习岗技术面整个面试持续了约90分钟涉及JVM、并发编程、MySQL和消息队列四大核心模块。下面我将完整还原这场高密度技术追问的全过程并逐题解析其背后的考察逻辑。从面试官的问题设置来看明显遵循着基础概念→底层原理→实战应用→异常排查的递进式考察路径。比如在JVM环节问题从内存区域划分逐渐深入到GC调优实战并发部分则从synchronized实现原理延伸到线程池参数设计MySQL相关问题更是覆盖了索引优化、事务隔离和死锁处理全链路。这种问题编排方式非常考验候选人的知识体系完整性和问题解决能力。提示技术面试中面试官往往会用剥洋葱式的提问策略先确认基础概念理解是否准确再逐步深入到应用场景和问题排查。回答时要注意逻辑层次避免一开始就陷入细节而忽略整体框架。2. JVM深度追问与实战解析2.1 内存模型与GC机制能详细说明JVM各内存区域的作用及常见异常吗这个问题看似基础但面试官随后会通过追问来检验理解的深度。完整的回答应该包括运行时数据区划分程序计数器线程私有记录字节码执行位置虚拟机栈存储栈帧包含局部变量表、操作数栈等本地方法栈Native方法服务堆对象实例存储区域重点说明新生代/老年代划分方法区类信息、常量、静态变量JDK8后元空间替代典型异常场景StackOverflowError虚拟机栈深度超过限制递归调用常见OutOfMemoryError: Java heap space堆内存不足内存泄漏或配置不当OutOfMemoryError: Metaspace类元数据超过MaxMetaspaceSize面试官特别关注对G1收集器的理解G1如何处理大对象这需要明确大对象直接进入Humongous区域大小超过Region50%Full GC时会对Humongous区域进行压缩整理建议配置-XX:G1HeapRegionSize避免过多Humongous区域碎片化2.2 内存泄漏排查实战线上服务出现内存泄漏如何定位这是典型的实战问题。完整的排查链路应该是# 1. 使用jstat观察GC情况 jstat -gcutil pid 1000 # 2. 生成堆转储文件 jmap -dump:formatb,fileheap.hprof pid # 3. 使用MAT分析支配树 # 重点关注Retained Heap大的对象查看引用链我曾遇到一个案例缓存使用WeakHashMap但value强引用key导致无法自动回收。这类问题需要结合业务代码分析引用关系面试时最好能给出具体场景的排查过程。3. 并发编程核心考点剖析3.1 锁机制与线程同步synchronized和ReentrantLock的区别有哪些这个问题考察对并发控制的理解深度。可以从这些维度对比特性synchronizedReentrantLock实现机制JVM内置监视器锁AQS实现公平性非公平可配置公平/非公平条件变量仅wait/notify支持多个Condition锁中断不支持支持lockInterruptibly()性能JDK6后优化性能接近高竞争时表现更好面试官追问虚拟线程协程对并发编程有什么影响这是Java 19引入的重要特性轻量级线程由JVM调度上下文切换成本极低适合I/O密集型任务可创建数百万级虚拟线程仍需要使用synchronized或ReentrantLock保证线程安全3.2 线程池实战配置核心线程数设置为多少合适这个问题没有标准答案但可以给出决策思路CPU密集型任务核心数 CPU核数 1避免上下文切换开销I/O密集型任务核心数 CPU核数 * (1 平均等待时间/平均计算时间)混合型任务拆分线程池或使用动态调整策略// 最佳实践示例 ThreadPoolExecutor executor new ThreadPoolExecutor( 4, // corePoolSize 8, // maximumPoolSize 30, TimeUnit.SECONDS, // keepAliveTime new LinkedBlockingQueue(100), // workQueue new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝策略 );注意队列容量需要根据业务特点设置过小容易触发拒绝策略过大可能导致OOM。我曾遇到队列积压导致Full GC频繁的案例最终通过设置合理的队列容量和拒绝策略解决。4. MySQL优化与问题排查4.1 索引失效场景分析列举三个索引失效的场景并解释原因这是高频问题。典型场景包括隐式类型转换-- 假设user_id是varchar类型 SELECT * FROM users WHERE user_id 123; -- 失效前导模糊查询SELECT * FROM logs WHERE content LIKE %exception%;函数操作列SELECT * FROM orders WHERE YEAR(create_time) 2023;面试官进一步追问如何优化大表分页查询 这是实际开发中的痛点解决方案包括使用延迟关联SELECT * FROM items INNER JOIN (SELECT id FROM items WHERE status1 LIMIT 100000, 10) AS tmp USING(id);记录上次查询的ID边界SELECT * FROM items WHERE id 100000 ORDER BY id LIMIT 10;4.2 死锁排查与解决如何排查和解决MySQL死锁需要掌握完整的分析流程开启死锁日志SET GLOBAL innodb_print_all_deadlocks ON;查看最近死锁信息SHOW ENGINE INNODB STATUS\G分析输出中的LATEST DETECTED DEADLOCK部分重点关注事务等待的资源持有的锁类型执行的最后一条SQL我曾处理过一个经典案例两个事务以不同顺序更新多行记录通过统一修改顺序解决了问题。面试时最好能结合具体案例说明。5. 消息队列应用实践5.1 消息可靠性保障如何保证消息不丢失这个问题考察对MQ核心机制的理解。完整的保障体系包括生产者端开启confirm模式RabbitMQ或事务消息RocketMQ实现消息落库定时重试机制Broker端配置多副本同步刷盘避免使用异步刷盘模式消费者端关闭自动ack业务处理完成后手动提交实现幂等处理逻辑// RabbitMQ生产者确认示例 channel.confirmSelect(); channel.basicPublish(exchange, routingKey, new AMQP.BasicProperties.Builder() .deliveryMode(2) // 持久化消息 .build(), message.getBytes()); if(!channel.waitForConfirms(3000)) { // 消息重发或记录日志 }5.2 消息积压处理突然出现消息积压如何快速解决这是运维常见问题。应急方案包括临时扩容消费者实例注意分区数限制降级非核心业务集中处理关键消息编写临时消费程序将消息转存到数据库后续处理长期优化方向优化消费者处理逻辑批处理、异步化合理设置消费线程数和预取值prefetchCount监控消费延迟设置告警阈值在一次618大促中我们的订单系统曾遇到消息积压问题。最终通过预先压测确定合理的线程池参数并实现动态扩容机制来应对流量高峰。