1. 面试题准备的必要性作为有2-5年经验的Java后端开发者面试准备是职业发展的重要环节。这个阶段的开发者已经掌握了基础语法和框架使用但往往缺乏系统性的知识梳理。面试题整理不仅能帮助应对技术考察更能查漏补缺建立完整的知识体系。我在多次面试候选人时发现中级开发者最容易在底层原理和系统设计环节失分。比如能说出HashMap的用法但讲不清楚扩容机制能使用Spring注解但解释不清AOP的实现原理。这些问题恰恰反映了日常开发中知其然不知其所以然的普遍现象。2. Java基础核心考点解析2.1 集合框架深度剖析ArrayList和LinkedList的区别是高频考点但仅回答一个数组实现一个链表实现远远不够。面试官期待的是扩容成本ArrayList默认扩容50%涉及数组拷贝内存占用LinkedList每个元素多消耗24字节前后指针缓存友好性ArrayList更好的空间局部性实际场景选择读多写少用ArrayList频繁插入删除考虑LinkedList经验解释差异时要结合JVM内存模型比如提到ArrayList对CPU缓存更友好会加分2.2 HashMap底层原理这个问题要分层次回答基础结构数组链表/红黑树JDK8哈希计算h key.hashCode()) ^ (h 16)解决冲突拉链法→树化(链表长度8且数组长度64)扩容机制2倍扩容rehash时高位判断(e.hash oldCap) 0常见陷阱问题为什么重写equals必须重写hashCode 答案在于HashMap的get操作依赖hashCode定位桶再用equals比较key。3. 并发编程实战要点3.1 synchronized实现原理从三个层面解释字节码层面monitorenter/monitorexit指令JVM层面对象头Mark Word中的锁标志位系统调用层面依赖操作系统的mutex lock升级过程要讲清楚无锁→偏向锁→轻量级锁→重量级锁。可以画图说明Mark Word的变化。3.2 volatile关键字必须包含以下要点可见性通过内存屏障禁止指令重排序不保证原子性i操作仍需synchronized底层实现Lock前缀指令缓存一致性协议(MESI)典型场景状态标志位、双重检查锁踩坑记录曾遇到volatile修饰数组的情况实际上只能保证数组引用可见元素可见性仍需AtomicReferenceArray4. JVM调优实战4.1 内存区域划分重点区分线程私有程序计数器、虚拟机栈、本地方法栈线程共享堆、方法区元空间直接内存NIO使用的Native内存要能画出内存结构图并标注各区域可能出现的OOM情况。4.2 GC算法与回收器对比表格更直观回收器算法组合适用场景参数调整Serial复制标记整理客户端模式-XX:UseSerialGCParallel Scavenge复制标记整理吞吐量优先-XX:MaxGCPauseMillisCMS标记清除低延迟-XX:CMSInitiatingOccupancyFractionG1分区算法大堆内存-XX:MaxGCPauseMillis5. Spring框架深度问题5.1 Bean生命周期完整的回答应该包含实例化调用构造函数属性赋值populateBean()初始化Aware接口回调BeanPostProcessor前置处理InitializingBean.afterPropertiesSet()init-methodBeanPostProcessor后置处理销毁DisposableBean.destroy()建议用流程图辅助说明特别要强调BeanPostProcessor的扩展点。5.2 事务传播机制七种传播行为要分类记忆支持当前事务REQUIRED(默认)、SUPPORTS、MANDATORY非事务执行REQUIRES_NEW、NOT_SUPPORTED、NEVER嵌套事务NESTEDSavepoint机制实际案例在批量处理时REQUIRES_NEW适合每个子任务独立提交NESTED适合部分失败时回滚到保存点。6. 数据库与缓存6.1 MySQL索引优化B树索引要讲清楚三层B树可支撑2000万数据假设页大小16K主键8B最左前缀原则index(a,b,c)能优化a、a? and b?、a? and b? and c?索引失效场景函数操作、隐式转换、!判断给出实际案例某用户中心查询缓慢通过EXPLAIN发现未走联合索引调整查询顺序后性能提升10倍。6.2 Redis持久化策略对比RDB和AOF维度RDBAOF数据安全可能丢失最后一次快照后的数据最多丢失1秒数据(appendfsync everysec)恢复速度快慢文件体积小(二进制压缩)大(文本命令)性能影响子进程生成快照时CPU/内存开销持续写入的IO压力生产环境建议主节点关闭持久化从节点开启RDBAOF混合模式。7. 分布式系统核心7.1 CAP理论应用分区容错性(P)必须保证实际是在CP和AP间权衡CP系统ZooKeeper选举期间不可用AP系统Eureka允许短暂数据不一致常见误区认为可以同时满足CAP三要素实际上网络分区时只能选择CP或AP。7.2 分布式锁实现三种实现方式对比数据库乐观锁version字段适合冲突少的场景Redis SETNX需解决锁续期问题Redisson看门狗机制Zookeeper临时顺序节点实现公平锁避坑指南Redis锁要设置随机value防止其他线程误删解锁需保证原子性Lua脚本8. 系统设计方法论8.1 秒杀系统设计分层优化策略前端静态化按钮置灰验证码网关限流令牌桶算法服务缓存预热库存扣减Redis原子操作数据异步扣库存消息队列要强调库存扣减的原子性方案Redis DECRLua脚本或者CAS乐观锁。8.2 服务熔断设计三个状态转换关闭状态正常请求打开状态直接拒绝请求半开状态试探性放行部分请求参数配置建议滑动窗口大小10-20个请求错误阈值比例50%熔断持续时间5-10秒9. 编码能力考察9.1 手写单例模式给出双重检查锁实现并解释volatile防止指令重排序第一次判空避免不必要的同步第二次判空防止重复创建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; } }9.2 生产者消费者问题使用BlockingQueue的实现要点共享队列设置容量限制生产者put操作自动阻塞消费者take操作自动阻塞优雅停机方案毒丸对象class Producer implements Runnable { private final BlockingQueueInteger queue; public void run() { try { while (true) { queue.put(produce()); } } catch (InterruptedException e) { Thread.currentThread().interrupt(); } } }10. 项目经验梳理10.1 技术难点表述采用STAR法则Situation千万级订单的库存超卖问题Task保证扣减的准确性和高性能Action引入Redis分布式锁分段库存方案ResultTPS从200提升到5000零超卖10.2 架构设计思路常用表述框架现状痛点原有架构的瓶颈设计目标QPS、RT、可用性指标方案选型技术对比如Kafka vs RabbitMQ落地效果监控数据对比建议准备1-2个深度参与的项目能说清楚每个技术决策背后的权衡。