Java高频面试六模块复习：Spring、并发、MySQL、Redis与易错点

简介：面向 Java 后端求职者与初中级开发者的面试冲刺材料，按专题说明了 Spring Bean 生命周期、Spring MVC 执行流程与 Spring Boot 自动装配三条框架主线，并延伸到 SQL 执行计划各字段解读、索引失效的常见写法、MySQL 索引类型与 B+Tree 底层结构，以及线程池的四类创建方式与七个核心参数。整个资源包只有 1 个 PDF 文件，约 396KB，体量轻便，按知识点分节排版，便于通勤时碎片化翻阅，或面试前一天集中速览。已有 180 人学习下载，在同类复习资料中有一定参考度。内容以要点式梳理为主，把实例化、依赖注入、初始化、销毁等阶段讲清楚，也讲清 DispatcherServlet 各组件之间的职责对应关系；还给出 select_type、type、key_len 等执行计划字段的取值含义与优劣排序，并归纳了函数运算、前置模糊查询、or 连接导致索引失效的排查方向。适合需要快速串联知识脉络、查漏补缺后再深入源码的读者。

1. 知识地图：Java 高频面试题的六块拼图

Java 高频面试题的复习，最怕的不是题多，而是题散：Spring 问生命周期，并发问线程池，MySQL 问索引，Redis 问数据类型，彼此像孤岛。把一份高频题笔记摊开看，真正反复出现的其实只有六块——Spring 体系、并发与容器、MySQL 与 SQL、Redis 与缓存、Java 基础与设计模式、以及贯穿始终的易错点。这份地图适合已经系统学过一遍、正在二轮复习的人：先看模块之间怎么串，再回到每个模块抠参数和流程。最容易踩的坑是把每道题背成孤立答案，面试官换个问法就接不上；所以下面的顺序按「框架→并发→存储→基础→易错点→清单」铺开，每章只解决一个复习目标。

2. Spring 体系：Bean 生命周期、MVC 流程与自动装配的三条主线

Spring 相关的问题在 Java 高频题里占比很高，但真正被反复追问的只有三条主线：一个 Bean 从创建到销毁经历了什么、一次 HTTP 请求在 MVC 里怎么走、启动类上的注解到底干了什么。把这三条主线吃透，事务和循环依赖这类进阶题才有落脚点。

2.1 Bean 生命周期：四个阶段与两组扩展接口

Bean 的生命周期可以拆成四段：实例化、依赖注入、初始化、销毁。实例化阶段有两种常见方式，反射创建和工厂方法创建；依赖注入阶段负责把属性值和依赖的 Bean 塞进去；初始化阶段会先回调InitializingBean的afterPropertiesSet()，再调用配置里指定的init-method；销毁阶段则先回调DisposableBean的destroy()，再调用destroy-method。这四个阶段的顺序是固定的，面试里最常考的就是「哪个先哪个后」。

梳理下来会发现，真正完整的生命周期还夹着BeanPostProcessor的前置和后置处理，以及各类Aware接口的回调，它们分布在初始化前后，负责把容器能力注入 Bean。复习时可以把这张表当成骨架，遇到「Bean 什么时候能拿到其他 Bean」这类问题，就回到表里定位阶段，而不是死记文字。

2.2 Spring MVC 执行流程：九个组件谁负责什么

MVC 的流程题几乎每场必问，但很多人背到「前端控制器」就卡壳。把流程拆成九步，每一步只记「谁做、要不要回到 DispatcherServlet」，就不会乱。

1. 客户端通过浏览器或其他客户端发出 HTTP 请求。
2. 前端控制器DispatcherServlet接收请求，它是整个流程的核心，负责拦截所有进入系统的请求。
3. HandlerMapping把请求 URL 与某个处理器的方法建立映射关系。
4. HandlerAdapter找到合适的处理器后，负责调用控制器方法，确保业务逻辑顺利执行。
5. Controller根据请求参数执行业务逻辑、处理数据、准备模型数据，返回给处理器适配器。
6. DispatcherServlet使用ViewResolver找到实际要渲染的页面。
7. 视图解析完成后渲染模型数据，生成 HTML 等响应内容。
8. 渲染好的视图由前端控制器返回给客户端。
9. 客户端展示友好界面。

除了控制器处理请求、视图渲染和响应客户端这三步，其余环节都需要把结果返回给前端控制器。这句话是流程题的分水岭，能说清「谁不回」比背全九个名字更有说服力。

拦截器和过滤器经常和 MVC 流程一起考，两者最容易混。过滤器基于 Servlet 规范，属于容器级别，能拦截所有进入容器的请求，包括静态资源；拦截器在框架层面，基于反射和动态代理，只作用于框架管理的请求。执行顺序上过滤器在前、拦截器在后；生命周期上过滤器随 Web 应用启动创建、随应用关闭销毁，拦截器随请求创建、随请求结束销毁。拦截器的preHandle返回 false 会中断后续流程，postHandle按逆序执行，afterCompletion无论目标方法是否成功都会调用。

2.3 Spring Boot 自动装配：三个注解与条件装配

自动装配的入口是启动类上的@SpringBootApplication，它由三个核心注解组成。@SpringBootConfiguration说明当前类是一个配置类；@ComponentScan默认扫描启动类所在包及其子包；@EnableAutoConfiguration开启自动配置，底层封装了@Import注解，指定AutoConfigurationImportSelector这个实现类。

真正干活的是选择器里的方法调用链：getAutoConfigurationEntry()负责组装自动配置条目，getCandidateConfigurations()负责读取候选配置类列表。候选配置类里通常定义带@Bean标识的方法，再配合@Conditional开头的条件注解；条件满足时，Spring 才会调用这些方法，并把返回值注册到 IOC 容器。复习时可以把这条链画成「注解→Import→Selector→候选配置→条件判断→注册 Bean」，比单独背注解名更稳。

提示：@Conditional系列是自动装配的开关，面试里常追问「为什么某些配置没生效」，答案往往落在条件不满足，而不是注解写错。

2.4 事务与循环依赖：两个最爱被追问的进阶点

事务部分先记 ACID 四个特性，再记隔离级别和传播行为。Spring 的隔离级别直接沿用数据库：ISOLATION_DEFAULT用底层数据库默认级别，多数数据库是 READ_COMMITTED；READ_UNCOMMITTED允许脏读、不可重复读和幻读，性能最好但并发问题最多；READ_COMMITTED避免脏读；REPEATABLE_READ避免脏读和不可重复读，MySQL 的 InnoDB 默认用这一级；SERIALIZABLE最高，锁住事务涉及的所有行，性能最差。

传播行为有七种，最常考的是REQUIRED（默认，有事务就加入、没有就新建）、REQUIRES_NEW（无论有没有都新建）、NESTED（有事务就在嵌套事务里执行）、SUPPORTS（有就加入、没有就非事务运行）、MANDATORY（没有事务就抛异常）、NOT_SUPPORTED（非事务运行并挂起当前事务）、NEVER（有事务就抛异常）。用@Transactional的propagation属性控制。

事务失效是高频追问点，常见场景包括：注解加在非 public 方法上、异常类型不匹配（默认只回滚运行时异常和 Error）、异常被 try-catch 吞掉、传播行为配置不当、方法被 final 修饰、方法内部自调用、多线程环境、表本身不支持事务。这些场景单看都简单，连起来问就容易漏。

循环依赖先分清三种注入方式：字段注入和 setter 注入，Spring 能自动处理；构造注入，Spring 无法自动处理。解决思路有两条，一是重构代码消除循环依赖，二是用@Lazy延迟注入，让 Bean 在需要时才创建。Spring 内部靠三级缓存兜底：

// 一级缓存：完整的单例 Bean Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256); // 二级缓存：实例化完成但未完成属性注入的半成品 Map<String, Object> earlySingletonObjects = new ConcurrentHashMap<>(16); // 三级缓存：Bean 的创建工厂，用于生成早期引用 Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>(16);

获取 Bean 时先查一级缓存，没有再查二级，还没有再查三级；从三级拿到对象后，会把它放入二级缓存并从三级移除。这段代码的关键在于「缓存分层」：一级存成品，二级存半成品，三级存工厂。参数上 256 和 16 只是初始容量，真正决定行为的是查找顺序和对象状态。面试里如果只答「三级缓存」而不说清每级存什么，很容易被继续追问到卡住。

3. 并发与容器：线程池、三大特性与 HashMap 的交叉考点

并发模块的题有一个特点：单问参数谁都答得上，交叉问就露馅。比如线程池的队列满了之后走什么策略、HashMap扩容为什么在 1.7 会死循环、volatile能不能保证原子性。这一章按「线程池→特性与状态→容器→基础」的顺序把交叉点串起来。

3.1 线程池：七个参数、四种拒绝策略与五种状态

Executors提供了四种快捷线程池：newFixedThreadPool固定线程数；newCachedThreadPool线程数可动态调整、使用无界队列，适合大量短任务；newSingleThreadExecutor只有一个线程，保证任务顺序执行；newScheduledThreadPool支持定时和周期性任务。

真正要记的是ThreadPoolExecutor的七个核心参数：

四种拒绝策略要能对号入座：AbortPolicy直接抛RejectedExecutionException，是默认策略；CallerRunsPolicy用调用者所在线程执行任务；DiscardOldestPolicy丢弃队列里最靠前的任务，再执行当前任务；DiscardPolicy直接丢弃新任务。

线程池有五种状态：RUNNING正常接受并处理任务；SHUTDOWN不再接受新任务，但会处理完队列里的任务；STOP不再接受新任务，并尝试中断正在执行的任务；TIDYING所有任务执行完毕、正在回收资源；TERMINATED完全终止、资源释放完毕。监控时可以用getPoolSize()看当前线程数、getActiveCount()看正在执行任务的线程数、getTaskCount()看已提交但未执行的任务数；关闭时shutdown()等待已提交任务执行完，shutdownNow()立即停止并返回未执行的任务列表。

// 自定义线程池：核心 4、最大 8、队列容量 100、线程名可追踪 ThreadPoolExecutor executor = new ThreadPoolExecutor( 4, // corePoolSize 8, // maximumPoolSize 60L, // keepAliveTime TimeUnit.SECONDS, // unit new ArrayBlockingQueue<>(100), // 有界队列，队列满才创建救急线程 r -> new Thread(r, "biz-pool-" + r.hashCode()), new ThreadPoolExecutor.CallerRunsPolicy() // 满了让调用者自己跑 );

这段代码里最值得说的是队列：换成无界队列，maximumPoolSize和拒绝策略几乎不会触发，任务会一直堆在队列里，直到内存扛不住。有界队列加CallerRunsPolicy是一种常见的降级组合，让提交任务的线程自己执行，形成天然的反压。参数怎么改要看业务：CPU 密集型任务核心线程数接近核数，IO 密集型可以适当放大，但都要配合队列容量一起调。

3.2 三大特性、线程状态与死锁

多线程三大特性是原子性、可见性、有序性。原子性指一个或多个操作要么全部完成、要么都不完成，单一变量的读取赋值通常是原子的，但i++这种复合操作不是；可见性指一个线程修改变量后其他线程能立即看到；有序性指程序按代码顺序执行，但编译器和 CPU 的指令重排序可能打破它。

解决方式要能对应上：原子性用synchronized或Lock加锁；可见性用volatile修饰共享变量，或者用锁机制同步；有序性同样可以用synchronized、Lock，以及volatile的写-读顺序保证。

线程状态有六种：新建、可运行、运行中、阻塞、等待、超时等待、终止。容易混的是「可运行」和「运行中」——可运行表示线程可以运行，但不一定正在跑，可能已经就绪但 CPU 时间片还没轮到；等待状态需要其他线程通知才能继续，超时等待则会在指定时间后自动恢复。

死锁的四个必要条件（互斥、持有并等待、不可剥夺、循环等待）在原材料里没有展开，但按这个方向梳理时绕不开。避免手段包括：设计上避免循环依赖、多个锁统一获取顺序、设置锁超时时间、用资源分配图检测环路、引入抢占机制。前两条是成本最低的，后三条更多出现在排查场景。

3.3 HashMap 与集合框架：结构演进与选型

HashMap实现了Map接口，提供键到值的映射，特点是高效、非线程安全、允许一个 null 键和多个 null 值。存储结构在 JDK 1.7 及以前是数组加链表，1.8 之后是数组加链表加红黑树。1.7 的链表用头插法，扩容迁移时可能形成环，导致死循环；1.8 改成尾插法，并引入红黑树优化长链表查询，死循环问题随之解决。

集合框架按接口分四类，选型时先看「要不要顺序、要不要去重、要不要键值对」：

Vector是线程安全的动态数组，但性能通常不如ArrayList，多线程场景下也不一定是最优解，复习时知道它「已不推荐」即可。

3.4 面向对象、单例与 Stream：基础题里的送分与送命

基础数据类型分四类：数值型（byte1 字节、short2 字节、int4 字节、long8 字节、float4 字节、double8 字节）、布尔型（true/false，实际内存占用依 JVM 实现而定）、字符型（char2 字节）。引用数据类型包括类、接口、数组、枚举、字符串，特点是共享性（多个引用指向同一对象）、空值性（可以为 null）、动态性（生命周期内可指向不同对象）。

面向对象三大特征要能举例：继承让子类获得父类的非私有属性和方法，支持「is-a」建模；封装把状态和行为捆绑并隐藏内部实现，只暴露公共接口；多态让同一接口有多种实现，主要通过方法重写和接口实现完成。接口和抽象类的区别集中在继承规则：接口支持多实现，抽象类遵循单一继承；接口是纯抽象类型，抽象类可以包含抽象方法和具体实现。

单例模式有五种写法：饿汉式在类加载时就创建，线程安全但可能浪费资源；懒汉式在第一次请求时创建，要考虑线程安全，可以用同步方法、同步代码块或双重检查锁定；静态内部类利用类加载机制保证线程安全并实现懒加载；枚举类自动支持序列化、绝对防止多次实例化。四大原则是构造方法私有、用静态方法或枚举返回实例、确保只有一个实例、确保反序列化时不会重新构建对象。

Stream 的常用 API 按「中间操作」和「终端操作」分：filter、map、flatMap、sorted、distinct、limit、skip是中间操作；reduce、collect、forEach、count、anyMatch、allMatch、noneMatch、findFirst、findAny是终端操作。面试里常问map和flatMap的区别：前者一对一映射，后者一对多再合并成一个流。

4. 存储层：MySQL 执行计划、索引与 Redis 的复习重点

存储层的题最容易被当成「背命令」，但面试官真正想听的是「你怎么判断一条 SQL 慢在哪」。执行计划、索引结构、失效场景、缓存配合，四块连起来才是一条完整的排查链。

4.1 执行计划：explain 十个字段怎么读

在 MySQL 里查看执行计划，就是在查询语句前加explain关键字。它的作用是看索引有没有被用到、表的读取顺序和操作类型、表之间的引用关系、有多少行记录被优化器查询。

-- 在查询前加 explain，查看优化器选择的执行路径 explain select id, name, status from order_info where user_id = 10086 and status = 1 order by create_time desc limit 20;

这段 SQL 的重点不在语法，而在输出列。id是查询序列号，id 相同则从上到下执行，id 不同则值大的优先级高；select_type是查询类型；table是数据涉及的表；type是访问类型，性能由好到坏大致是system、const、eq_ref、ref、range、index、all；possible_keys是可能用到的索引，为空说明没有相关索引；key是实际用到的索引，为 null 表示没走索引；key_len是索引宽度，不损失精度的情况下越短越好；ref显示哪个列或常数与索引一起筛选；rows是估计扫描行数；Extra是额外执行信息。

type里有几个容易混的值：const/primary表示查询条件精确匹配唯一索引的单一值，立即返回对应行；eq_ref表示一个索引被用来搜索另一个表的行且索引唯一，常见于 join；ref是非唯一索引；ref_or_null在匹配索引值之外还会查找 null；index_merge表示多个索引合并使用；unique_subquery和index_subquery分别对应子查询返回唯一行和普通索引行；range是范围扫描；index是全索引扫描；all是全表扫描。

注意：type为index不代表走对了索引，它仍然是全索引扫描，和all只差「扫索引树还是扫数据页」，别看到 index 就以为没问题。

4.2 索引体系与 B+Tree

MySQL 常见索引按结构分 B-Tree（默认）、R-Tree（空间索引）、Hash、Full-text；按用途分主键索引、普通索引（非唯一）、唯一索引、组合索引（联合索引）、覆盖索引、逆序索引。组合索引要理解最左前缀，覆盖索引要理解「查询列全在索引里，不用回表」。

B+Tree 是多路平衡查找树，采用平衡树思想，能高效支持增删改查。它的关键特征是：所有数据都存在叶子节点，叶子节点之间用指针连成链表，便于范围查询；非叶子节点只存索引、不存实际数据，所以能存更多索引项。按常见估算，一个非叶子节点 16KB，一个 key 约 8 字节，指针约 6 字节，一个节点大约能存 1000 条索引，第二层就能到百万级，第三层到千万级，所以 B+Tree 一般是 2 到 4 层。这个估算的意义在于解释「为什么千万级表查一次只要几次磁盘 IO」，而不是让你背数字。

4.3 索引失效与 SQL 优化清单

索引失效的典型场景：查询列上使用函数或表达式、使用NOT或!=、使用or且两侧条件不一致、对索引列进行运算、like以%开头、多个索引查询时只有第一个有效。这些场景的共同点是「索引列被加工过」或「优化器判断全表扫描更便宜」。

SQL 优化可以按这份清单逐条对照：查询时指明具体字段，避免select *；in的值不宜过多；分页只有一页时用limit 1；能用inner join就尽量不用left join和right join；排序字段没有索引时尽量不排序；限制条件里其他字段没有索引时少用or；避免在where子句里对 null 做判断；不建议用%前缀模糊查询；用union all代替union减少去重开销。

数据库约束也常被顺带问：主键约束、唯一约束、外键约束（建立表之间的关联）、非空约束、默认约束。默认约束的价值在于没指定值时自动补默认值，减少数据输入量，同时避免字段因忘记赋值出现 null。

4.4 Redis 五大数据类型与防重复提交

Redis 的五种数据类型要能对应场景：字符串可以存文本、数字、序列化对象，支持追加和过期时间；哈希存字段-值对，适合存对象；列表可以做队列和栈，常用于消息队列、任务队列；集合无序不重复，支持并集、交集、差集，适合去重和集合运算；有序集合给每个成员关联分数并按分数排序，适合排行榜和带权重的队列。

防重复提交是 Redis 的经典应用题，思路是拦截器或过滤器加 Redis：拿到请求对象，取请求路径、请求参数和登录用户 id，拼成 key；用字符串的incr命令自增，根据返回值判断。返回 1 说明是第一次提交，给这个 key 设置 15 秒过期；返回值大于 1 说明之前已经提交过，直接拦截。incr的原子性保证每次操作后的值一定不同，过期时间保证 15 秒后用户可以再次提交。

# 以「路径+参数+用户id」为 key，第一次提交返回 1 并设置过期时间 INCR submit:order:create:10086:sku_123 EXPIRE submit:order:create:10086:sku_123 15

这两条命令的顺序不能反：先incr拿到返回值，判断为 1 时再expire。参数上 15 秒是业务容忍的重复窗口，太长会误伤正常重试，太短起不到防重作用，需要按接口耗时调整。

5. 易漏易错点：五处最容易在面试里翻车的地方

这一章只做一件事：把那些「看答案觉得会、被追问就露馅」的点单独拎出来。每条按「易漏点→为什么漏→怎么补」写，复习时可以直接当自检清单用。

5.1 事务失效与传播行为上的三个想当然

易漏点一：以为加了@Transactional就一定回滚。为什么漏：默认只对运行时异常和 Error 回滚，受检异常不会触发回滚，很多人写业务代码时抛的是受检异常。怎么补：明确异常类型，必要时用rollbackFor指定，同时确认异常没有被 try-catch 吞掉。

易漏点二：以为同类内部调用也会走代理。为什么漏：事务靠 AOP 代理生效，同类方法自调用不经过代理，注解等于没加。怎么补：把事务方法拆到另一个 Bean，或者注入自身代理；同时检查方法是不是 public、是不是被 final 修饰。

易漏点三：以为REQUIRES_NEW总是安全的。为什么漏：子事务新开连接，外层事务还没提交时，内层可能读不到外层未提交的数据，配置不当还会导致整体事务行为不符合预期。怎么补：画一张调用链，标清每个方法的传播行为，确认「谁加入谁、谁挂起谁」。

5.2 循环依赖与三级缓存：构造注入为什么救不了

易漏点：以为三级缓存能解决所有循环依赖。为什么漏：三级缓存解决的是「实例化之后、属性注入之前」的提前引用问题，构造注入在实例化阶段就要求依赖对象存在，此时连半成品都还没有，缓存无从下手。怎么补：遇到构造注入的循环依赖，优先重构消除环，其次改用 setter 或字段注入，或者用@Lazy打破即时创建。还要能说清二级缓存的作用：它缓存的是已经生成好的早期引用，避免同一个 Bean 被多次调用工厂重复创建代理对象。

5.3 索引失效与执行计划误读

易漏点一：看到key有值就认为索引用对了。为什么漏：key有值只说明选了某个索引，rows很大、type是index时仍然可能是全索引扫描。怎么补：三个字段一起看，type看访问方式，key看实际索引，rows看扫描量，再结合Extra判断有没有文件排序或临时表。

易漏点二：忽略隐式类型转换。为什么漏：字符串列用数字查询、或数字列用字符串查询，都可能让索引失效，而这种写法在代码里很常见。怎么补：把参数类型和列类型对齐，联合索引还要检查最左前缀有没有断。

5.4 线程池参数与队列的连锁反应

易漏点：以为maximumPoolSize设大就能扛住突发流量。为什么漏：任务先入队列，队列满了才创建救急线程；如果用无界队列，最大线程数永远用不上，任务堆积到内存耗尽。怎么补：队列必须有界，并且和核心线程数、最大线程数一起算容量；拒绝策略按业务选，核心链路用CallerRunsPolicy做反压，非核心任务可以用丢弃策略并记录日志。监控上至少看活跃线程数和队列长度两个指标。

5.5 拦截器与过滤器的执行顺序

易漏点：以为拦截器的postHandle和afterCompletion也按注册顺序执行。为什么漏：前置处理按顺序，后置处理按逆序，afterCompletion无论目标方法成功与否都会执行，异常场景下的顺序更容易记反。怎么补：记住「先进后出」四个字，过滤器整体先于拦截器，拦截器内部前置正序、后置逆序；需要清理资源的逻辑放afterCompletion，不要放postHandle。

6. 复习清单：从「看过」到「答得出」的查漏补缺表

复习到这个阶段，最有效的动作不是再刷一遍题，而是拿一张表自测：每个模块只问自己三个问题——流程能不能按顺序说清、参数能不能说出默认值和边界、失效场景能不能举出两个例子。下面这张表可以直接当检查表用。

这张表的使用方法是「遮住右列自问」。能脱口而出的打勾，卡住的回到对应章节补，不要从头再读一遍。时间紧的时候优先补三类：流程类（Bean 生命周期、MVC、自动装配）、参数类（线程池七参数、执行计划字段）、失效类（事务失效、索引失效、循环依赖），这三类占了追问的大头。

我自己的血泪经验是：第一轮复习总想把每个答案背全，结果面试官一追问「为什么」就断片。后来改成每复习一个模块，强制用白纸默写一张流程图或参数表，写不出来的地方才是真正要补的地方。从那以后我每次复习任何模块，都强制走一遍「合上资料、白纸复述、对照补漏」的流程，比反复看十遍都管用。这份笔记如果你也在用，建议先挑一个最没底的模块试一遍，希望帮到你。

本文还有配套的精品资源，点击获取