Java秋招突击：高频考点与实战策略精讲

如果你正在准备2025年或2026年的Java秋招，面对海量的八股文、复杂的场景题和层出不穷的新技术，感到无从下手、时间紧迫，那么这篇文章就是为你准备的。这不是一篇常规的“面经汇总”，而是一套经过验证的“邪修”突击策略——它不追求面面俱到，而是通过精准的“降维打击”，在最短时间内构建起一个足以通过大多数中高级Java岗位面试的知识体系。

很多同学陷入的误区是：试图把《Java核心技术卷》、《深入理解Java虚拟机》等大部头从头到尾啃一遍。这在长期学习中是好事，但对于只剩一两个月甚至几周的秋招突击，这无异于自杀。真正的“邪修”思路是：以面试题为导向，以高频考点为核心，以理解代替死记，用实战串联知识。本文将围绕Java基础、并发编程、JVM、MySQL、Spring等核心模块，拆解一套最高效的突击路径、核心知识图谱和实战应对技巧。

1. 这篇文章真正要解决的问题：如何在有限时间内实现面试突围？

秋招面试，尤其是大厂面试，本质上是一场在有限时间内展示你技术深度、广度以及解决问题能力的“表演”。面试官手中的问题库是庞大的，但每个人的面试时间通常只有45-60分钟。这意味着，他只能抽取这个庞大知识体系中的几个点来考察你。我们的核心策略，就是通过分析历年高频考点，大幅提高你被问到的知识点恰好是你精心准备过的概率。

“邪修版”的核心思想在于三个转变：

1. 从“学习知识”到“应对考察”：不再追求体系的完美，而是搞清楚面试官到底想听什么。同一个知识点，在书本上和面试中的回答侧重点完全不同。
2. 从“零散记忆”到“网状关联”：孤立地背八股文很容易遗忘且无法应对场景题。你需要把JVM内存模型、垃圾回收、线程池原理、Spring Bean生命周期、MySQL索引、事务隔离级别这些点，用一条“应用执行链路”串联起来。
3. 从“被动回答”到“主动引导”：通过你回答的深度和广度，巧妙地将面试官的问题引导到你熟悉的“预设战场”上。比如被问到synchronized，在讲完基础后，可以自然延伸到锁升级、AQS、以及你在项目中如何根据场景选择ReentrantLock。

本文将解决的具体痛点包括：

• 时间焦虑：提供一份优先级明确的学习清单，告诉你先学什么、后学什么，什么可以暂时放弃。
• 知识零散：将Java基础、并发、JVM、MySQL、Spring等模块的核心知识点，用“一次HTTP请求的生命周期”这样的主线串联起来，帮你形成整体认知。
• 场景题恐惧：提供场景题的通用拆解框架和经典例题的答题思路，让你面对“如何设计一个秒杀系统”时不再大脑空白。
• 背书困境：给出关键知识点的“记忆锚点”和“理解口诀”，告别死记硬背。

2. 核心突击策略：降维打击与优先级划分

在开始具体知识点前，我们必须统一作战思想。将剩余时间（例如4周）进行划分：

• 第一周（构建核心骨架）：全力攻克Java并发和JVM。这是区分“普通开发者”和“有深度的开发者”最关键的两座大山，也是面试中追问最深、最易出彩（或露怯）的领域。本周目标不是全部掌握，而是建立核心概念模型。
• 第二周（打通应用脉络）：深入Spring框架（尤其是Spring Boot）和MySQL。这是日常开发最直接的体现。重点在于理解原理（如IOC/AOP、事务管理）和优化（如索引、慢查询）。
• 第三周（夯实基础与扩展）：回顾Java基础（集合、IO、新特性），并扩展到中间件（Redis、消息队列）和系统设计基础。基础是地基，中间件是高频加分项。
• 第四周（综合模拟与复盘）：大量进行模拟面试，练习场景题，针对薄弱环节查漏补缺。整理自己的“面试宝典”，将知识内化为自己的语言。

“邪修”精髓：每个模块，按照“高频面试题 -> 核心原理深度理解 -> 常见场景应用 -> 关联知识扩展”的路径进行学习。放弃那些生僻的、过于底层的细节（比如CMS垃圾回收器的全部实现步骤），抓住主干。

3. Java并发编程：从synchronized到AQS的深度突击

并发是面试的重灾区，也是最能体现编程功底的部分。不要一上来就扎进Thread类的源码里。

3.1 必须吃透的三大核心基石

1. synchronized关键字：

   • 怎么答：不要说“它是重量级锁”。从Java 6开始，它经过了彻底的优化。
   • 回答主线：synchronized是JVM层面的内置锁 -> 通过monitorenter/monitorexit指令实现 -> 锁信息记录在对象头的Mark Word中 -> 锁状态会随着竞争情况升级：无锁 -> 偏向锁 -> 轻量级锁（自旋锁） -> 重量级锁。
   • 记忆锚点：记住“偏轻重”三个字，以及升级是不可逆的。能说清楚为什么要有偏向锁（减少同一线程重复获取锁的开销）和轻量级锁（短时间自旋等待，避免线程挂起的开销）。

2. volatile关键字：

   • 怎么答：它解决的是可见性和禁止指令重排序，不保证原子性。
   • 核心原理：底层通过CPU的内存屏障（Memory Barrier）实现。写volatile变量时，会插入StoreStore和StoreLoad屏障；读的时候会插入LoadLoad和LoadStore屏障。这导致对volatile变量的写操作会立即刷新到主内存，且读操作总是从主内存读取。
   • 经典场景：单例模式的双重检查锁定（DCL）中，实例变量必须用volatile修饰，防止初始化对象时的指令重排序导致其他线程拿到未初始化完全的对象。

3. J.U.C包与AQS：

   • AQS（AbstractQueuedSynchronizer）：这是整个J.U.C包的灵魂。你必须理解它是一个同步器框架，内部维护了一个FIFO双向队列（CLH队列的变种）和一个state状态变量。
   • 怎么答：ReentrantLock、Semaphore、CountDownLatch等工具类都是基于AQS实现的。以ReentrantLock为例，它的公平锁和非公平锁，区别就在于尝试获取锁时，是否先检查队列里是否有等待的线程。
   • 关键源码切入点：不需要背全部源码，但要知道tryAcquire、tryRelease、acquireQueued、addWaiter这些核心方法的作用。面试时能画出AQS队列和state的关系图就是极大的加分项。

3.2 线程池：7个参数与4种拒绝策略

这是必考题，必须倒背如流，并理解其工作原理。

// 线程池的完整创建方式，7个参数必须牢记 ThreadPoolExecutor executor = new ThreadPoolExecutor( corePoolSize, // 核心线程数：即使空闲也会保留的线程数量 maximumPoolSize, // 最大线程数：允许创建的最大线程数 keepAliveTime, // 空闲线程存活时间（针对超过核心线程数的部分） unit, // 存活时间单位 workQueue, // 工作队列：用于存放提交但未执行的任务 threadFactory, // 线程工厂：用于创建新线程 handler // 拒绝策略：当线程池和队列都满了，如何处理新任务 ); // 四种内置拒绝策略： // 1. AbortPolicy（默认）: 直接抛出RejectedExecutionException异常。 // 2. CallerRunsPolicy: 让提交任务的线程自己去执行该任务。 // 3. DiscardPolicy: 直接丢弃新任务，不做任何通知。 // 4. DiscardOldestPolicy: 丢弃队列中最老的任务，然后尝试提交新任务。

工作原理（高频考点）：

1. 提交任务。
2. 如果当前运行线程数 <corePoolSize，则创建新线程执行任务。
3. 如果达到corePoolSize，则将任务放入workQueue。
4. 如果队列已满，且当前线程数 <maximumPoolSize，则创建新线程执行任务。
5. 如果队列已满，且线程数达到maximumPoolSize，则触发拒绝策略。

场景题：“线上服务的线程池突然报RejectedExecutionException，可能是什么原因？如何排查和解决？”

• 答：原因可能是瞬时流量高峰，任务堆积速度超过处理速度，导致队列和最大线程数都满了。排查：查看线程池监控（队列大小、活跃线程数、完成任务数）。解决：短期可以适当调大maximumPoolSize和队列容量，但根本方案是优化任务执行逻辑、限流或引入更强大的队列（如LinkedBlockingQueuevsSynchronousQueue的选择）。

3.3 并发容器：ConcurrentHashMap的演进

HashMap线程不安全，Hashtable性能差，所以有了ConcurrentHashMap。

• JDK 7 vs JDK 8：这是经典问题。JDK 7采用分段锁（Segment），相当于把整个Map分成多个小HashTable。JDK 8抛弃了分段锁，改用Node + synchronized + CAS的实现。锁的粒度从Segment级别细化到了链表头节点（或红黑树根节点），并发度大大提高。
• 关键点：JDK 8中，put操作时，如果桶是空的，直接用CAS插入；如果桶不为空，则用synchronized锁住桶的头节点再进行操作。同时，引入了红黑树来处理过长的链表（阈值是8），防止哈希碰撞攻击导致性能退化。

4. JVM：围绕“内存”与“GC”构建知识体系

JVM问题通常围绕“你的应用出过内存溢出吗？怎么排查的？”展开。

4.1 运行时数据区：记住一张图

务必能画出来并解释每个部分的作用。

[线程私有] ┌── 程序计数器 (PC Register) - 指向当前线程正在执行的字节码指令地址 ├── Java虚拟机栈 (JVM Stack) - 存储栈帧，每个方法调用对应一个栈帧（局部变量表、操作数栈、动态链接、方法出口） └── 本地方法栈 (Native Method Stack) - 为Native方法服务 [线程共享] ┌── 堆 (Heap) - 存放对象实例，GC主要区域。分为新生代（Eden, S0, S1）和老年代。 └── 方法区 (Method Area) - 存储类信息、常量、静态变量等。JDK 8后称为“元空间”(Metaspace)，使用本地内存。

高频问题：

• 堆和栈的区别？堆存对象，栈存局部变量和引用；堆线程共享，栈线程私有；堆GC管理，栈自动分配释放。
• 方法区/元空间溢出？可能由于动态生成大量类（如CGLib）、加载过多Jar包、常量池过大引起。

4.2 垃圾回收：掌握两种主流算法

重点掌握G1和ZGC（或Shenandoah），因为它们是当下和未来的主流。Parallel Scavenge + Parallel Old组合可以作为对比。

• G1 (Garbage-First)：

  • 核心思想：将堆划分为多个大小相等的Region，不再是物理上的新生代/老年代。它跟踪每个Region的“垃圾价值”（回收所需时间与获得空间大小），优先回收价值最大的Region（Garbage-First名称由来）。
  • 回收过程：分为Young GC（回收Eden和Survivor区）和Mixed GC（不仅回收年轻代，还会回收一部分价值高的老年代Region）。最终会进行Full GC（Serial Old），这是要尽量避免的。
  • 适用场景：大内存、低延迟要求的应用。通过-XX:MaxGCPauseMillis参数设置期望的最大停顿时间。

• ZGC (Z Garbage Collector)：

  • 目标：实现亚毫秒级（<10ms）的停顿时间，且停顿时间不随堆大小增长而显著增加。
  • 核心技术：染色指针（Colored Pointers）和读屏障（Load Barrier）。染色指针将GC相关的元数据存储在指针本身，而不是对象头。读屏障是ZGC在并发转移阶段，当应用线程访问对象时，能感知到对象已被移动，并自动更新引用。
  • 怎么答：强调ZGC的“并发”能力极强，几乎所有阶段（标记、转移、重定位）都是并发的，只有短暂的Start Pause和Relocate Pause。

记忆口诀：问GC，先分代（新生代/老年代），再说算法（复制/标记-清除/标记-整理），最后聊收集器（Serial, Parallel, CMS, G1, ZGC）。重点准备G1和ZGC的原理和调优参数（如-Xmx,-Xms,-XX:+UseG1GC,-XX:MaxGCPauseMillis）。

4.3 实战排查：OOM与CPU飙升

这是体现你实战能力的关键。

• OOM (OutOfMemoryError) 排查：

  1. 立刻保存现场：使用jmap -dump:live,format=b,file=heap.hprof <pid>命令导出堆转储文件。
  2. 分析工具：用MAT或JVisualVM加载heap.hprof文件。
  3. 分析思路：查看“Histogram”或“Dominator Tree”，找到占用内存最大的对象类。查看其GC Roots引用链，找到是谁在持有这些对象导致无法回收。常见原因：内存泄漏（如静态Map持续增长）、大对象（如一次性加载超大文件）、过小的堆设置。

• CPU 100% 排查：

  1. 定位线程：top -Hp <pid>找到占用CPU高的线程ID。
  2. 线程转栈：将线程ID转为16进制，然后jstack <pid> | grep -A 20 <nid>查看该线程的堆栈信息。
  3. 分析原因：常见原因：死循环、频繁GC、锁竞争激烈（大量线程处于BLOCKED状态）。

5. MySQL：索引、事务与锁的连环问

MySQL问题通常一环扣一环，从SQL优化问到事务隔离，再问到锁机制。

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

• 为什么是B+树，不是B树或哈希？

  • B树：节点既存数据也存键值，范围查询不如B+树高效。
  • B+树：非叶子节点只存键值和指针，叶子节点存所有数据且形成有序链表。这使得范围查询、排序查询和全表扫描（顺序读盘）效率极高，且树的高度更低，IO次数更少。
  • 哈希：等值查询快，但不支持范围查询和排序。

• 聚簇索引 vs 非聚簇索引：

  • 聚簇索引：叶子节点直接存储行数据。InnoDB中，主键索引就是聚簇索引。一张表只有一个聚簇索引。
  • 非聚簇索引：叶子节点存储的是主键值。根据非聚簇索引查到主键后，需要回表查询聚簇索引才能拿到完整数据。

• 最左前缀原则：对于联合索引(a, b, c)，它可以用于查询(a),(a,b),(a,b,c)，但不能用于(b),(c),(b,c)。因为B+树是先按a排序，再按b排序，再按c排序。

示例与排查：

-- 创建联合索引 CREATE INDEX idx_name_age ON user(name, age); -- 能使用索引的查询 SELECT * FROM user WHERE name = '张三'; -- 使用索引 SELECT * FROM user WHERE name = '张三' AND age = 25; -- 使用索引 SELECT * FROM user WHERE age = 25 AND name = '张三'; -- 优化器会调整顺序，也能使用索引 -- 不能使用索引或索引失效的查询 SELECT * FROM user WHERE age = 25; -- 违反最左前缀原则 SELECT * FROM user WHERE name LIKE '%三'; -- 前导通配符导致索引失效 SELECT * FROM user WHERE name = '张三' OR age = 25; -- OR条件可能导致失效

5.2 事务：ACID与隔离级别

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

• 隔离级别与问题：

  • 读未提交：脏读、不可重复读、幻读。
  • 读已提交：解决脏读。
  • 可重复读（MySQL InnoDB默认）：解决脏读、不可重复读，通过MVCC部分解决幻读（快照读解决，当前读需加锁）。
  • 串行化：解决所有问题，性能最低。

• MVCC（多版本并发控制）：InnoDB实现高并发的关键。核心是ReadView和Undo Log。每个事务启动时（或第一条SELECT时）生成一个ReadView，里面记录了当前活跃事务ID列表。通过比较数据行上的事务ID（DB_TRX_ID）和ReadView，来决定当前事务能看到哪个版本的数据（可能是当前行，也可能是Undo Log中的历史版本）。

5.3 锁：行锁、间隙锁、临键锁

• 行锁：锁住某一行。UPDATE、DELETE、SELECT ... FOR UPDATE会对涉及的行加锁。
• 间隙锁：锁住一个索引区间，但不包括记录本身。用于解决幻读问题。例如，SELECT * FROM t WHERE id > 10 FOR UPDATE，会锁住(10, +∞)这个间隙，防止其他事务插入id>10的记录。
• 临键锁：行锁 + 间隙锁的组合，锁住一条记录及其前面的间隙。是InnoDB默认的加锁单位。

死锁场景与分析：

-- 事务A BEGIN; UPDATE account SET balance = balance - 100 WHERE id = 1; -- 锁住id=1的行 UPDATE account SET balance = balance + 100 WHERE id = 2; -- 尝试锁住id=2的行，但被B持有 -- 事务B BEGIN; UPDATE account SET balance = balance - 100 WHERE id = 2; -- 锁住id=2的行 UPDATE account SET balance = balance + 100 WHERE id = 1; -- 尝试锁住id=1的行，但被A持有 -- 死锁发生！

如何排查：查看SHOW ENGINE INNODB STATUS命令输出中的LATEST DETECTED DEADLOCK部分。

6. Spring框架：IOC、AOP与Spring Boot自动装配

Spring的问题往往从应用层面深入到设计思想。

6.1 IOC与AOP：Spring的两大基石

• IOC（控制反转）：将对象的创建、依赖注入的控制权从程序代码中转移到容器（Spring IOC Container）。DI（依赖注入）是IOC的一种实现方式。

  • 怎么答：以前我们new Object()，现在是容器创建好对象，并通过构造器、Setter或字段注入给我们。好处是解耦，便于管理和测试。
  • Bean的生命周期（高频）：实例化 -> 属性填充 -> 初始化（Aware接口、BeanPostProcessor前置处理、@PostConstruct、InitializingBean、init-method、BeanPostProcessor后置处理）-> 使用 -> 销毁。能说出几个关键扩展点（如BeanPostProcessor）及其用途就是亮点。

• AOP（面向切面编程）：将横切关注点（日志、事务、安全）与核心业务逻辑分离。

  • 核心概念：切面（Aspect）、连接点（Join Point）、通知（Advice）、切点（Pointcut）、引入（Introduction）、织入（Weaving）。
  • 实现原理：动态代理。如果目标类实现了接口，默认使用JDK动态代理；如果没有，则使用CGLIB生成子类代理。Spring AOP是在运行时织入。

6.2 Spring Boot：自动装配与启动流程

• 自动装配：核心是@SpringBootApplication注解，它组合了@SpringBootConfiguration、@EnableAutoConfiguration、@ComponentScan。

  • @EnableAutoConfiguration是关键，它利用spring.factories机制，从spring-boot-autoconfigure包的META-INF/spring.factories文件中加载大量的自动配置类（XXXAutoConfiguration）。
  • 每个自动配置类通常带有@ConditionalOnClass、@ConditionalOnMissingBean等条件注解，根据类路径下是否存在某个类、容器中是否已有某个Bean来决定是否生效。

• 启动流程（简化版）：

  1. 创建SpringApplication对象，初始化监听器（ApplicationListener）和初始化器（ApplicationContextInitializer）。
  2. 运行run方法，创建并准备环境（Environment）。
  3. 创建应用上下文（ApplicationContext），通常是AnnotationConfigServletWebServerApplicationContext。
  4. 刷新上下文（refresh()方法），这是最核心的一步，会完成Bean工厂创建、Bean定义加载、Bean实例化、初始化等所有IOC容器启动工作。
  5. 执行CommandLineRunner和ApplicationRunner。
  6. 启动内嵌的Web服务器（如Tomcat）。

6.3 事务管理：@Transactional的坑

这是面试常踩的坑。

• 失效场景：

  1. 方法非public：@Transactional只能用于public方法。
  2. 自调用：同一个类中，A方法（无事务）调用B方法（有@Transactional），事务不生效。因为事务基于AOP代理，自调用不走代理。
  3. 异常被捕获：默认只在抛出RuntimeException和Error时回滚。如果抛出受检异常（Exception）或被try-catch吞掉，事务不会回滚。
  4. 数据库引擎不支持：如MySQL的MyISAM引擎不支持事务。
  5. 传播行为设置不当：例如，在已有事务的方法中调用REQUIRES_NEW，但异常处理不当。

• 传播行为：至少要知道REQUIRED（默认，有则加入，无则新建）和REQUIRES_NEW（总是新建事务，挂起当前事务）的区别。

7. 场景题与系统设计：从秒杀到缓存一致性

场景题考察综合能力。回答要有结构化思维。

7.1 经典场景：如何设计一个秒杀系统？

不要一上来就谈具体技术，先搭框架。

1. 分析核心难点：瞬时超高并发、库存超卖、系统防刷、流量控制、后端服务保护。
2. 分层设计思路：
   • 前端：静态化页面、按钮防重复点击、倒计时校准。
   • 网关/接入层：限流（令牌桶、漏桶）、恶意请求过滤。
   • 服务层：
     • 缓存预热：将秒杀商品库存提前加载到Redis中。
     • 库存扣减：使用Redis的DECR或Lua脚本保证原子性，防止超卖。关键点：先在Redis中扣减，异步同步到数据库。
     • 请求队列化：使用消息队列（如RocketMQ）将瞬时流量削峰填谷，后端服务按能力消费。
     • 服务隔离：将秒杀业务与非秒杀业务在服务器、数据库层面进行隔离，避免相互影响。
   • 数据库层：最终库存一致性校验、订单创建。数据库操作要尽量简单，避免复杂事务。
3. 补充亮点：提到降级熔断（如Sentinel）、热点数据探测、CDN加速、答题/验证码防机器人。

7.2 缓存经典问题：缓存穿透、击穿、雪崩

• 缓存穿透：查询一个一定不存在的数据（如id=-1）。请求直达数据库。
  • 解决方案：1. 接口层增加校验（如id<=0直接拦截）。2. 缓存空对象（key-null，设置较短过期时间）。3. 使用布隆过滤器（Bloom Filter）快速判断数据是否存在。
• 缓存击穿：某个热点key过期瞬间，大量请求同时击穿到数据库。
  • 解决方案：1.互斥锁（Mutex Lock）：第一个请求查数据库时加锁（如Redis的SETNX），其他请求等待。2.逻辑过期：不给key设置TTL，而是在value中存储一个过期时间。发现逻辑过期后，异步更新缓存，当前线程返回旧数据。
• 缓存雪崩：大量key同时过期或Redis服务宕机，导致所有请求涌向数据库。
  • 解决方案：1. 过期时间随机化（如基础时间+随机值）。2. 热点数据永不过期，后台异步更新。3. 保证Redis高可用（主从、哨兵、集群）。4. 服务降级和熔断。

7.3 数据库与缓存一致性

这是分布式系统经典难题。没有银弹，只有权衡。

• 先更新数据库，再删除缓存（Cache-Aside Pattern）：
  • 问题：更新数据库成功，删除缓存失败，导致脏数据。
  • 优化：引入重试机制（如将删除操作放入消息队列，消费失败重试）。
• 先删除缓存，再更新数据库：
  • 问题：并发下，A删缓存 -> B读缓存未命中 -> B读旧库 -> B写旧数据到缓存 -> A更新新数据到库，导致缓存是旧数据。
• 延迟双删：先删缓存 -> 更新数据库 -> 休眠一段时间（如几百毫秒）-> 再删缓存。用于解决上述并发问题，但休眠时间难以确定。
• 最终一致性方案：通过订阅数据库Binlog（如使用Canal、Maxwell），将数据变更发送到消息队列，再由消费者异步更新/删除缓存。这是目前比较成熟的方案，对业务代码侵入小。

8. 面试实战技巧与避坑指南

8.1 回答问题的“STAR-R”法则

对于项目经历和场景题，使用结构化表达：

• S（Situation）：背景。当时是什么情况？
• T（Task）：任务。你需要完成什么目标？
• A（Action）：行动。你个人采取了哪些具体行动？（用“我”，而不是“我们”）
• R（Result）：结果。取得了什么可量化的成果？（如性能提升50%，延迟降低30ms）
• R（Reflection）：反思。有什么经验教训？如何改进？（体现你的思考深度）

8.2 遇到不会的问题怎么办？

1. 不要直接说“我不会”。可以尝试：“这个问题我之前没有深入研究过，但我根据我的理解尝试分析一下……”
2. 关联已知知识。例如，被问到一个陌生的中间件，可以类比你知道的Redis或Kafka，从通用设计原则（高可用、持久化、集群）去推测。
3. 展现学习能力。可以说：“这是我知识的盲区，面试后我会立刻去学习。我猜测它的原理可能是……”

8.3 最后的“你还有什么问题吗？”

这是一个展示你主动性和思考深度的重要环节。不要问薪资、加班（可以后续谈），要问团队和业务。

• 好问题：“我应聘的这个岗位，在团队中主要负责的业务方向和技术挑战是什么？”“团队目前的技术栈和未来的技术规划是怎样的？”“公司对于新人的培养和成长路径有什么样的支持？”
• 进阶问题（如果面试官是技术负责人）：“我们团队在微服务治理/高并发场景下，遇到过最有挑战性的技术问题是什么？是如何解决的？”

9. 短期冲刺资源与每日计划示例

核心资源：

• JavaGuide：涵盖大部分八股文，用于查漏补缺。
• 牛客网/力扣：刷面试真题和算法题（至少Hot 100）。
• 《深入理解Java虚拟机》（第3版）：重点看第2、3、13章。
• 《MySQL是怎样运行的》：图文并茂，讲透原理。
• Spring官方文档：重点看Core、Boot、Data部分的介绍。

最后一周每日计划示例：

• 上午（3小时）：模拟面试（录音自检），深挖1-2个技术点（如今天专攻G1 GC和线上OOM排查全流程）。
• 下午（3小时）：刷算法题（保持手感），整理并背诵自己的“面试宝典”中的薄弱环节。
• 晚上（2小时）：回顾项目经历，用STAR-R法则重新梳理每个项目，准备3-5个能体现你技术深度和解决问题能力的“亮点故事”。

这套“邪修”打法，其精髓不在于覆盖全部，而在于在有限时间内，将高频、高价值的知识点打透、串联，并形成条件反射式的回答思路。它不能让你成为所有领域的专家，但足以让你在秋招的面试战场上，展现出远超平均水平的准备度和技术深度。记住，面试是展示，不是考试。带着你的知识图谱和解决问题的思路，自信地去交流。