Java面试突击：从八股文到场景题的解题框架与知识连接

最近跟几个技术面试官朋友聊天，发现一个挺有意思的现象：很多候选人简历上项目经验写得天花乱坠，但一轮到基础八股和场景题，回答就变得支支吾吾。更关键的是，他们普遍反映，现在面试官问的“场景题”越来越刁钻，不再是背背“Redis缓存雪崩”的定义就能过关，而是会追问：“如果让你设计一个短链接系统，你怎么保证生成的短码不重复且高性能？”

这恰恰点出了当前Java面试的核心矛盾：知识体系庞杂（八股文），但考察方式却极度场景化（活学活用）。对于准备“金九银十”跳槽季的开发者来说，最大的痛点不是“学什么”，而是“如何在最短时间内，把零散的知识点串联成能解决实际问题的能力”，并且能清晰、有条理地表达出来。

传统的复习方式是线性的：看面经→背答案→刷算法。这种方法效率极低，因为你背的是“点”，而面试官考的是“网”——他抛出一个业务场景，你需要瞬间从JVM内存模型、MySQL索引、Spring事务、并发编程等多个“点”中抽取线索，编织成解决方案。

所以，这篇文章要解决的真正问题是：在时间有限的“突击”状态下，如何最高效地构建一个“可随时调用”的Java知识网络，并掌握一套应对场景题的“解题框架”。这不是另一份面经清单，而是一套以“输出”和“连接”为核心的方法论。如果你正为Java基础、并发、JVM、MySQL、Spring这一大摊子东西发愁，感觉每个都懂点，但连起来就懵，那么接下来的内容，就是为你准备的。

1. 面试突击的本质：从“知识背诵”到“问题解决”的范式转换

在开始具体技术点之前，我们必须先统一思想：突击面试，突击的不是知识，而是解决问题的能力和表达的框架。

面试官通过场景题考察什么？

1. 知识广度与深度：你是否真的理解技术原理，而非死记硬背。
2. 系统设计能力：能否将多个技术组件有机组合，解决一个复杂问题。
3. 逻辑思维与沟通：思考是否缜密，表达是否清晰有层次。
4. 经验与判断：面对权衡取舍（如一致性与性能）时，能否做出合理决策。

因此，最高效的突击路径不是“更多”，而是“更透”。你需要做两件事：

• 构建知识图谱：将分散的知识点（八股）连接成网。例如，“线程安全”这个概念，要能连接到sychronized/ReentrantLock（并发）、Spring Bean作用域（Spring）、单例模式（设计模式）、ThreadLocal（JVM）等多个节点。
• 掌握场景题框架：面对任何场景题，都有一个通用的分析套路，让你不至于大脑空白。

接下来的内容，将围绕这条主线，拆解Java核心领域的突击重点和连接方法。

2. Java基础：深入理解“对象”与“并发”两大基石

Java基础是面试的起跑线，这里失分非常致命。突击时，不要纠缠于final、static的语法细节，而要聚焦于它们如何影响对象的行为和内存的生命周期。

2.1 对象核心：内存、相等性与不可变性

核心连接：这里的基础概念直接通向JVM（内存布局）、并发（线程安全）和设计模式。

• equals()与hashCode()：这不仅是重写规则。要能说清楚为什么重写equals()必须重写hashCode()？因为基于哈希的集合（HashMap,HashSet）依赖这两个方法维持一致性。可以现场画一下HashMap的put流程，说明hashCode定位桶，equals比较链上节点。

  // 一个典型错误示例 public class User { private String id; // 只重写了equals，没重写hashCode @Override public boolean equals(Object o) { ... } } // 当把两个equals为true的User对象放入HashSet，会存在两个，破坏集合契约。

• String的不可变性：这不仅是“安全”。要连接到字符串常量池（JVM方法区）、intern()方法的性能影响，以及为何它是线程安全的天然典范。可以对比StringBuilder（非线程安全，性能高）和StringBuffer（线程安全，性能低）的应用场景。

• 浅拷贝与深拷贝：理解Object.clone()的默认行为（浅拷贝）。深拷贝的实现方式（序列化、手动复制、工具库）。这里可以连接到原型模式，并思考在分布式缓存中，从Redis取出的对象若被多处修改，浅拷贝可能带来的副作用。

2.2 集合框架：数据结构与并发安全的实战选择

突击集合，关键在于理解底层数据结构和并发安全实现，而不是API列表。

• ArrayListvsLinkedList：别再只说“一个数组一个链表”。要能说：

  • ArrayList的随机访问O(1)，但中间插入/删除可能触发System.arraycopy，成本O(n)。
  • LinkedList插入删除O(1)，但随机访问需要遍历，O(n)。
  • 实战场景：ArrayList适用于读多写少，且操作多在末尾的场景（如日志收集）。LinkedList适用于频繁在中间插入删除的场景（如实现LRU缓存的双向链表）。

• HashMap：这是必考题中的必考。必须能清晰说出JDK1.8之后的优化：数组+链表/红黑树。

  1. 插入流程：计算hashCode→高位运算取模定位桶→遍历链表（或树）→遇到相同key则覆盖→否则尾插（链表）或插入树中→判断是否树化（链表长度>=8且数组长度>=64）→判断是否扩容。
  2. 扩容机制：负载因子（默认0.75）、扩容时机、扩容时如何重新哈希（JDK1.8优化：元素要么在原位置，要么在原位置+旧容量）。
  3. 线程不安全：体现在扩容时的环形链表（JDK1.7）和数据覆盖（JDK1.8）。解决方案：ConcurrentHashMap。
  4. 连接点：这里直接通向ConcurrentHashMap（并发）、LinkedHashMap（实现LRU）、TreeMap（红黑树排序）。

• ConcurrentHashMap：如何实现高效并发？

  • JDK1.7：分段锁（Segment），降低锁粒度。
  • JDK1.8：摒弃分段锁，采用synchronized+CAS+volatile。锁的粒度是每个桶的头节点，并发度更高。
  • 关键方法：putVal中使用CAS初始化头节点，使用synchronized锁定头节点后进行链表/树操作。
  • 场景题连接：当被问到“如何设计一个高性能的全局计数器？”时，除了AtomicLong，可以提到ConcurrentHashMap的compute方法也能用于分片计数。

3. 并发编程：理解“可见性、有序性、原子性”与锁的升级

并发是区分初中高级工程师的关键。突击时，死记AQS源码不如理解Java内存模型（JMM）和锁的升级过程。

3.1 Java内存模型（JMM）与volatile

• 核心问题：多线程下，为什么一个线程修改了变量，另一个线程看不到？（可见性问题）
• JMM抽象：每个线程有自己的工作内存（缓存抽象），与主内存交互。普通变量的修改可能仅停留在工作内存。
• volatile的作用：
  1. 保证可见性：写操作立即刷新到主内存，并使其他线程的缓存行无效。
  2. 禁止指令重排序：通过内存屏障实现。
• 但volatile不保证原子性！经典例子：volatile int i = 0;然后多线程执行i++，结果仍然小于预期。因为i++是“读-改-写”三个操作。
• 连接场景：单例模式的双重检查锁（DCL）为什么需要volatile？

  public class Singleton { private static volatile Singleton instance; // 必须volatile public static Singleton getInstance() { if (instance == null) { // 第一次检查 synchronized (Singleton.class) { if (instance == null) { // 第二次检查 instance = new Singleton(); // 可能发生指令重排 } } } return instance; } }

  解释：instance = new Singleton()这行代码在JVM中分为三步：1.分配内存 2.初始化对象 3.将引用指向内存地址。步骤2和3可能被重排序。如果线程A执行了1和3，此时instance不为null但未初始化，线程B在第一次检查时直接返回了一个未初始化的对象，导致错误。volatile禁止了这种重排序。

3.2synchronized与锁升级

这是理解Java并发性能优化的关键。

• 锁的存在位置：在对象头中的Mark Word。
• 升级过程：
  1. 无锁：新对象的状态。
  2. 偏向锁：假设只有一个线程访问。Mark Word记录线程ID，以后该线程进入无需同步。适用于几乎没有竞争的场景。
  3. 轻量级锁：当有另一个线程来竞争，偏向锁升级为轻量级锁。线程通过CAS操作在栈帧中创建锁记录（Lock Record），尝试将对象头指向它。竞争不激烈时，通过自旋等待。
  4. 重量级锁：如果自旋等待超过一定次数（或等待线程多），升级为重量级锁。线程进入阻塞状态，依赖操作系统内核的互斥量（Mutex）进行调度，成本高。
• 面试回答要点：synchronized在JDK1.6后进行了大量优化，不再是纯粹的“重量级锁”。它的性能在低竞争下已经很好，高竞争下也有升级机制。选择synchronized还是ReentrantLock，取决于是否需要ReentrantLock提供的可中断、公平锁、条件变量等高级功能。

3.3ThreadLocal：线程隔离的魔法与内存泄漏陷阱

• 原理：每个Thread对象内部有一个ThreadLocalMap，以ThreadLocal自身为Key，存储线程私有变量。
• 内存泄漏根源：
  • ThreadLocalMap的Key是弱引用（WeakReference<ThreadLocal>），而Value是强引用。
  • 当ThreadLocal外部强引用被置为null后，由于Key是弱引用，在GC时会被回收，但Value依然存在强引用链（Thread -> ThreadLocalMap -> Entry -> Value），导致Value无法被回收，造成内存泄漏。
• 正确使用姿势：
  1. 将ThreadLocal变量声明为static final，延长其生命周期，避免被回收。
  2. 使用完毕后，必须调用remove()方法，显式清除Entry。

  private static final ThreadLocal<SimpleDateFormat> dateFormatHolder = ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyy-MM-dd")); // 使用后 try { dateFormatHolder.get().format(...); } finally { dateFormatHolder.remove(); // 关键！ }

• 连接场景：Spring如何用ThreadLocal实现事务管理？TransactionSynchronizationManager内部使用ThreadLocal来绑定当前线程的事务资源（如Connection），保证同一个事务内获取的是同一个连接。

4. JVM：从内存结构到GC调优，聚焦“线上问题定位”

JVM问题在面试中常以场景题形式出现：“线上CPU飙升怎么排查？”“应用频繁Full GC怎么办？”。

4.1 内存区域与OOM

必须能画图说明线程私有（程序计数器、虚拟机栈、本地方法栈）和线程共享（堆、方法区/元空间）的区域。

• 堆（Heap）：新生代（Eden, S0, S1）、老年代。对象优先在Eden分配，大对象直接进老年代，长期存活的对象（默认15次GC）进入老年代。
• 方法区（Method Area）：JDK1.8后称为元空间（Metaspace），使用本地内存。存储类信息、常量、静态变量等。
• OOM场景与排查：
  • java.lang.OutOfMemoryError: Java heap space：堆内存不足。可能原因：内存泄漏、堆大小设置过小、存在大对象。排查：jmap -heap看堆使用情况；jmap -histo:live看对象实例数；用Eclipse MAT或JProfiler分析堆转储文件。
  • java.lang.OutOfMemoryError: Metaspace：元空间不足。可能原因：动态生成大量类（如CGLib代理）、反射、OSGi应用。排查：-XX:MaxMetaspaceSize设置大小，用jstat -gc监控元空间使用。
  • java.lang.StackOverflowError：栈深度溢出。通常由无限递归引起。

4.2 垃圾回收器与GC日志分析

重点掌握G1和ZGC（如果面试公司用JDK11+）的思想。

• G1（Garbage-First）：
  • 核心思想：将堆划分为多个大小相等的Region，优先回收垃圾最多的Region（Garbage-First）。
  • 工作流程：Young GC（回收Eden和Survivor区）→ Mixed GC（回收部分Young和部分Old Region）→ 必要时Full GC（Serial Old）。
  • 关键参数：-XX:+UseG1GC,-XX:MaxGCPauseMillis=200（设置目标停顿时间）。
• 如何分析GC日志：开启-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:。
  • 关注点：GC频率、GC耗时、吞吐量（应用运行时间/总时间）、停顿时间。
  • 如果频繁Full GC且每次回收后老年代空间释放很少，很可能存在内存泄漏。

4.3 线上问题排查命令三板斧

这是实战能力的体现。

1. top -Hp：找到占用CPU最高的线程ID。
2. jstack：导出线程堆栈。将上一步的线程ID转换为16进制（printf “%x\n”），在jstack输出中搜索这个nid，找到对应的线程堆栈，看它在执行什么代码（通常是死循环、锁等待）。
3. jmap -dump:format=b,file=heap.hprof：生成堆转储文件，用于分析内存泄漏。
4. （附加）jstat -gc 1000 10：每1秒打印一次GC情况，共10次，用于观察GC动态。

5. MySQL：索引、事务与锁，三位一体的性能与一致性

MySQL问题几乎必问。突击核心是：索引怎么用、事务怎么玩、锁怎么加。

5.1 索引：B+树与最左前缀原则

• 为什么是B+树？对比B树：B+树非叶子节点只存键，不存数据，因此扇出更高，树更矮（通常3-4层就能存千万数据），IO次数少。叶子节点形成有序链表，适合范围查询。
• 聚簇索引 vs 非聚簇索引：
  • 聚簇索引：InnoDB中，表数据文件本身就是按主键组织的一颗B+树，叶子节点存放整行数据。一张表只有一个。
  • 非聚簇索引：叶子节点存储的是主键值。查询时需要回表：先查到主键，再用主键去聚簇索引查完整数据。
• 最左前缀原则：对于联合索引(a, b, c)，它能生效的查询条件是：
  • where a = ?
  • where a = ? and b = ?
  • where a = ? and b = ? and c = ?
  • where a = ? and c = ?（只会用到a，c不会走索引）
  • where b = ?用不到索引！
• 索引失效常见场景：
  • 对索引列进行函数操作（WHERE YEAR(create_time) = 2023）。
  • 类型隐式转换（WHERE user_id = ‘123’，user_id是int）。
  • 使用!=、<>、NOT IN、NOT EXISTS。
  • LIKE以通配符开头（‘%abc’）。
  • 联合索引违反最左前缀。
  • 在索引列上使用OR（有时优化器会合并，但需小心）。
• 覆盖索引：如果查询的字段都包含在某个索引中，则无需回表，性能极高。例如索引(a, b)，查询SELECT a, b FROM table WHERE a = ?。

5.2 事务：ACID与隔离级别

• ACID：原子性（Undo Log）、一致性（最终目标）、隔离性（锁/MVCC）、持久性（Redo Log）。
• 隔离级别与问题：

  隔离级别	脏读	不可重复读	幻读	实现方式
  读未提交	❌	❌	❌	无锁
  读已提交	✅	❌	❌	快照读（RC下每次SELECT生成ReadView）
  可重复读	✅	✅	❌（InnoDB通过间隙锁基本解决）	快照读（RR下第一次SELECT生成ReadView） + 间隙锁
  串行化	✅	✅	✅	读写锁

• MVCC（多版本并发控制）：InnoDB实现高并发读写的核心。
  • 每行数据有隐藏字段：DB_TRX_ID（最近修改的事务ID）、DB_ROLL_PTR（回滚指针，指向Undo Log）。
  • ReadView：事务在执行快照读时产生的读视图，包含当前活跃事务ID列表、最小事务ID、下一个事务ID。
  • 可见性判断：根据DB_TRX_ID和ReadView的规则判断当前事务能看到哪个版本的数据。这就解释了为什么在RR级别下，同一个事务内多次查询结果一致。

5.3 锁：行锁、间隙锁与死锁

• 行锁：锁住索引记录。如果查询没走索引，会升级为表锁。
• 间隙锁（Gap Lock）：锁住索引记录之间的间隙，防止其他事务在这个间隙插入新记录，从而解决幻读。只在RR隔离级别下生效。
• 临键锁（Next-Key Lock）：行锁 + 间隙锁，锁住一个左开右闭的区间。
• 死锁分析与排查：
  1. 开启死锁日志：innodb_print_all_deadlocks = ON。
  2. 发生死锁后，查看SHOW ENGINE INNODB STATUS的LATEST DETECTED DEADLOCK部分。
  3. 避免死锁的常见方法：事务中按固定顺序访问表和行、降低事务粒度、使用SELECT ... FOR UPDATE时尽量用主键或唯一索引。

6. Spring框架：IoC、AOP与事务传播的深度解析

Spring考察的是对“框架思维”的理解，即它如何简化开发。

6.1 IoC容器与Bean生命周期

• 核心：控制反转（IoC）是将对象创建和依赖注入的控制权从程序代码转移到容器（如ApplicationContext）。
• Bean生命周期（简述关键步骤）：
  1. 实例化（Instantiation）
  2. 属性填充（Populate properties）
  3. Aware接口回调（如BeanNameAware,BeanFactoryAware）
  4. BeanPostProcessor.postProcessBeforeInitialization
  5. 初始化（InitializingBean.afterPropertiesSet,init-method）
  6. BeanPostProcessor.postProcessAfterInitialization
  7. 使用
  8. 销毁（DisposableBean.destroy,destroy-method）
• 循环依赖：Spring通过三级缓存解决Setter注入的循环依赖。
  • 一级缓存singletonObjects：存放完整的单例Bean。
  • 二级缓存earlySingletonObjects：存放提前暴露的早期Bean（已实例化，未填充属性）。
  • 三级缓存singletonFactories：存放Bean工厂，用于生成早期Bean（可进行AOP代理）。
  • 流程：A创建→放入三级缓存→需要B→B创建→需要A→从三级缓存拿到A的工厂，获取早期A→B完成→A完成属性填充→A从二级/三级缓存升级到一级缓存。

6.2 AOP：动态代理与切面编程

• 实现方式：
  • JDK动态代理：基于接口。被代理类必须实现接口。Proxy.newProxyInstance生成代理对象。
  • CGLIB动态代理：基于继承。生成被代理类的子类作为代理。不能代理final类和方法。
  • Spring的选择：默认使用JDK动态代理。如果目标类没有实现接口，则使用CGLIB。可通过proxy-target-class=true强制使用CGLIB。
• 核心概念：连接点（Joinpoint）、切点（Pointcut）、通知（Advice：前置、后置、返回、异常、环绕）、切面（Aspect）、织入（Weaving）。
• 连接场景：Spring事务、声明式缓存（@Cacheable）、日志、权限校验，都是AOP的典型应用。

6.3 事务传播机制

这是Spring事务的难点，务必理解每种行为的含义。

• PROPAGATION_REQUIRED（默认）：如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务。
• PROPAGATION_REQUIRES_NEW：无论当前是否存在事务，都创建一个新的事务。新事务与旧事务独立，外层事务回滚不影响内层。
• PROPAGATION_NESTED：如果当前存在事务，则在嵌套事务内执行。嵌套事务是外层事务的子事务，外层回滚，内层一定回滚；内层回滚，外层可以捕获异常而不回滚（取决于配置）。InnoDB通过保存点（Savepoint）实现。
• PROPAGATION_SUPPORTS：支持当前事务，如果当前没有事务，就以非事务方式执行。
• PROPAGATION_NOT_SUPPORTED：以非事务方式执行操作，如果当前存在事务，则把当前事务挂起。
• PROPAGATION_NEVER：以非事务方式执行，如果当前存在事务，则抛出异常。
• PROPAGATION_MANDATORY：必须在一个已有的事务中执行，否则抛出异常。

经典陷阱：在同一个类中，一个非事务方法A调用另一个事务方法B，B的事务会失效。因为Spring事务基于AOP代理，自调用不走代理对象。解决方法：将方法B抽取到另一个Service中，或使用AopContext.currentProxy()获取代理对象再调用。

7. 场景题实战拆解：从“问题”到“答案”的思考框架

掌握了知识点，如何应对场景题？这里提供一个通用的四步框架：

第一步：澄清需求，圈定边界

• 面试官：“设计一个秒杀系统。”
• 你不能立刻开始说Redis。要先问：
  • “秒杀的商品数量是多少？预期QPS是多少？”
  • “需要保证‘不超卖’吗？库存扣减的强一致性要求有多高？”
  • “前端是H5还是App？用户登录状态如何？”
  • “是纯秒杀，还是包含普通商品下单流程？”
• 目的：避免过度设计或设计偏差。把模糊问题具体化。

第二步：分层设计，概览全貌

• 任何系统都可以从“客户端→网关→应用层→服务层→数据层”这个角度思考。
• 秒杀示例：
  • 客户端：静态资源CDN、按钮防重复点击、倒计时校准。
  • 网关层：限流（令牌桶/漏桶）、恶意请求过滤。
  • 应用层：业务逻辑、缓存读写、消息队列异步处理。
  • 服务层：用户服务、商品服务、订单服务。
  • 数据层：MySQL分库分表、Redis集群、MQ削峰填谷。

第三步：聚焦核心，深入细节

• 针对秒杀最核心的“库存扣减”和“订单创建”：
  1. 库存预热：活动开始前，将商品库存加载到Redis中（String或Hash结构）。
  2. 扣减库存：使用Redis的DECR或Lua脚本保证原子性。先扣缓存库存，避免直接打穿到DB。
  3. 订单处理：扣减成功后，发送消息到MQ（如RocketMQ）。订单服务消费消息，进行数据库的最终一致性操作（创建订单、扣减DB库存）。这里DB库存扣减需要加乐观锁（update stock set stock = stock - 1 where id = ? and stock > 0）。
  4. 限流与降级：在网关和业务层做多层限流。如果压力过大，可以降级为“下单后排队处理”的页面提示。

第四步：查漏补缺，考虑扩展

• 数据一致性：缓存和数据库的库存如何对账？可以定时任务补偿，或通过Binlog同步。
• 高可用：Redis集群、MQ集群、DB主从。
• 可监控：设计监控大盘，关注缓存命中率、MQ堆积、接口RT、错误率。
• 容灾：如果Redis挂了，是否有降级方案（如直接走DB，但性能下降）？

另一个经典场景题：如何实现分布式锁？

1. 基于Redis：SET key value NX PX timeout。注意锁续期（看门狗）和释放锁的原子性（Lua脚本判断再删除）。
2. 基于ZooKeeper：创建临时有序节点，最小节点获锁。利用Watch机制实现阻塞等待。天然解决锁释放和死锁问题。
3. 基于数据库：利用唯一索引或乐观锁。性能差，不推荐。
4. 对比选型：追求性能和高可用选Redis（需自己处理续期）；追求可靠性和简单性选ZooKeeper（性能稍低）。

8. 面试准备与表达技巧：让面试官听懂你的“厉害”

技术再强，说不出来也白搭。

• 自我介绍：不要复述简历。用1-2分钟讲一个故事：“我过去主要做XX系统，遇到了XX挑战（如高并发、数据一致性），通过采用了XX技术方案（如Redis集群、分库分表），最终达到了XX效果（如QPS提升X倍，延迟降低Y%）。” 突出问题-行动-结果。
• 回答问题时：采用“总-分-总”结构。
  • 总：先给结论或核心观点。“MySQL索引失效最常见的原因有五种，其中最容易忽略的是类型隐式转换。”
  • 分：分点阐述，逻辑清晰。“第一，……；第二，……；第三，……。”
  • 总：最后总结，并可以引申。“所以，在写SQL时，要特别注意WHERE条件两侧的数据类型。另外，EXPLAIN命令是排查索引问题的利器。”
• 遇到不会的问题：切忌不懂装懂。可以尝试：“这个问题我之前没有深入研究过，但我根据已有的知识推测，可能是……（给出合理的推理）。如果让我来解决，我会先去查阅XX官方文档或从XX角度入手分析。” 展现学习能力和解决问题的思路。
• 向面试官提问：准备2-3个有深度的问题，体现你的思考。例如：“团队目前面临的主要技术挑战是什么？”“这个岗位对新人的成长路径是如何规划的？”“项目中的技术选型，比如为什么用Kafka而不是RocketMQ？”

9. 最后一周冲刺计划与资源推荐

最后7天，每天聚焦一个主题，形成肌肉记忆。

• Day 1-2：Java核心与并发。刷完《Java并发编程实战》关键章节，手写生产者-消费者、线程池示例。理解HashMap、ConcurrentHashMap源码片段。
• Day 3：JVM与性能调优。整理一套自己的JVM问题排查命令清单。理解G1和ZGC的核心思想。看几个线上OOM/CPU高的案例分析文章。
• Day 4：MySQL。动手用EXPLAIN分析几条复杂SQL。理解不同隔离级别下的锁表现。设计一个简单的分库分表方案。
• Day 5：Spring。画一张Bean生命周期和循环依赖解决的流程图。搞懂事务传播行为的每一个场景，并写代码验证。
• Day 6：场景题与系统设计。找3-5个经典场景题（秒杀、微信朋友圈、短链接、抢红包），用前面的四步框架自己口述或写下来。学习DDD（领域驱动设计）和CAP理论的基础概念。
• Day 7：模拟面试与查漏补缺。找朋友模拟面试，或者自己对着镜子讲。复习前六天的笔记，重点看那些容易混淆的概念（如volatile和synchronized的区别，间隙锁和临键锁）。

资源推荐（求精不求多）：

• 书籍：《Java并发编程实战》、《深入理解Java虚拟机》、《MySQL技术内幕：InnoDB存储引擎》、《Spring源码深度解析》。
• 网站：官方文档（Spring.io, dev.mysql.com）、掘金/InfoQ技术社区。
• 视频：一些知名培训机构的高阶课程（用于快速建立知识框架）。

面试突击，本质是一场针对性的能力强化训练。它要求你在短时间内，将分散的知识点编织成网，并训练出快速提取、组织和表达的能力。记住，面试官想看到的不是一个行走的“八股文背诵机器”，而是一个能理解问题、分析问题、解决问题的思考者。带着这份“解题框架”和“知识连接图”去准备，你的“金九银十”之旅，一定会更加从容。