1. 为什么框架篇是Java面试的分水岭做了几年Java开发也面过不少人我发现一个很规律的现象简历上写的技术栈都差不多但一到框架问题就高下立判。很多人能熟练使用Spring、MyBatis写业务代码但被问到“Bean的完整生命周期有哪些阶段”“Spring Boot自动配置到底怎么生效的”“MyBatis的Mapper接口为什么没有实现类却能直接注入调用”一下子就答不上来。框架篇在Java面试里的地位恰恰就是用来区分“会用”和“懂原理”的分界线。业务代码写得多不代表你理解框架的设计思想能跑通Demo也不代表你能在团队里解决复杂的框架层面问题。面试官考察框架篇核心目的不是考背诵而是看三件事第一你有没有主动读过源码和官方文档第二遇到问题时能不能从原理层面定位和分析第三有没有全局视角知道框架在整体架构中扮演什么角色。这篇内容适合准备中级和高级Java岗位面试的同学也适合那些写了两三年业务代码、想系统补一补框架原理的开发。我会结合自己的面试经历和实际工作里踩过的坑把Spring、Spring Boot、MyBatis、Spring MVC这几个最常考的框架逐一拆开讲每个部分都会从“面试官为什么要问”出发再讲核心原理和常见追问最后给一些实操层面的准备建议。文章偏长但都是干货建议收藏后分段看。2. Spring框架面试中的绝对重头戏2.1 IoC容器和Bean的生命周期考官真正想听什么IoC控制反转这个概念几乎每个面试者都能说上两句但大多数人的回答停在“把对象的创建交给Spring管理”这句话上。说实话这句话放十年前还算新鲜放在现在只是基本功。面试官追问的深度往往远超这个层面。我遇到过很多次这样的对话我先说IoC把对象的创建和依赖关系交给容器管理面试官点点头然后紧接着问“那容器什么时候创建对象Bean的完整生命周期从哪一步开始”如果你平时只用过注解没读过AbstractApplicationContext的refresh方法这里很容易卡壳。Bean生命周期其实可以拆成几个关键阶段实例化前、实例化、属性填充、初始化前、初始化、初始化后、使用、销毁。Spring在实例化Bean之前会先通过BeanDefinition读取配置包括XML里的bean标签、注解配置的扫描结果然后封装成BeanDefinition对象。之后经过合并处理、类加载、实例化策略等步骤才真正new出对象。实例化完成后Spring会做属性填充也就是我们常说的依赖注入环节。接着是Aware接口回调比如BeanNameAware、BeanFactoryAware再往后是BeanPostProcessor的before方法、InitializingBean或init-method、BeanPostProcessor的after方法这时Bean才算准备完毕可以被业务代码使用了。这里有个很多人忽略的细节AOP代理对象的生成通常发生在BeanPostProcessor的after阶段。所以你在应用里拿到的Bean很可能不是原始对象而是一个代理对象。面试中如果能主动提到“Spring通过AbstractAutoProxyCreator在Bean初始化后阶段完成AOP代理的创建”会明显拉开和普通候选人的差距。还有一个高频考点是Bean的作用域。singleton和prototype的区别大多数人都知道但问到“singleton Bean里注入prototype Bean会有什么问题”“怎么解决”就暴露水平了。默认情况下singleton Bean只创建一次如果直接注入一个prototype Bean那这个prototype Bean实际上只有一个实例每次调用都是同一个对象失去了prototype的意义。解决办法通常是使用ObjectProvider、Lookup方法注入或者通过ApplicationContext手动获取。注意BeanFactory和FactoryBean是两个完全不同的概念很多面试者混为一谈。BeanFactory是IoC容器的顶层接口而FactoryBean是一个特殊的Bean它本身是个工厂通过getObject方法产出另一个对象。比如MyBatis的MapperFactoryBean就是通过FactoryBean机制把Mapper接口变成可注入的Bean。这个区别至少遇到三次面试官特意追问过。2.2 Spring AOP的工作原理与切面失效场景AOP这块面试官最喜欢从“动态代理的两种方式区别”问起。JDK动态代理基于接口使用Proxy类在运行时生成代理对象CGLIB基于继承通过生成子类来代理目标类。Spring默认策略是目标类实现了接口就用JDK动态代理没有实现接口就用CGLIB。Spring Boot 2.x之后默认开启了proxyTargetClasstrue所以即使有接口默认也用CGLIB。有个细节值得留意CGLIB不能代理final类和非public方法。如果你写了一个final的Service类或者某个方法被final修饰切面是织入不进去的因为CGLIB无法继承和覆写。这个点可以作为面试中的加分项提出来说明你确实踩过类似的坑。很多人在业务代码里用Transactional事务失效了不知道怎么排查。其实事务失效常见原因就那么几类方法不是public的、异常被catch住没有抛出、自调用导致代理失效、数据库表不支持事务、传播行为配置错误。自调用这个问题最常见比如同一个类里一个方法调用另一个被Transactional标注的方法由于调用发生在对象内部没有经过代理对象事务注解就完全失效了。解决办法可以是拆分到不同Bean中或者使用AopContext.currentProxy()获取当前代理对象。还有一个切入点Spring AOP是运行时增强通过代理实现AspectJ是编译期增强或类加载期增强通过字节码操作实现。交易系统或高性能场景中如果需要更细粒度的切面控制AspectJ可能更适合。但普通业务项目里Spring AOP已经足够。2.3 Spring事务传播行为、隔离级别与失效场景事务传播行为有七种面试中至少要被追问三种以上。REQUIRED、REQUIRES_NEW、NESTED这三个是重点。REQUIRED是默认传播行为如果当前存在事务就加入不存在就新建REQUIRES_NEW会挂起当前事务新建一个独立事务NESTED是嵌套事务依赖于JDBC的savepoint机制回滚时可以只回滚到savepoint位置而不影响外层事务。实际开发里我用REQUIRES_NEW处理过一个场景某个任务执行过程中要写操作日志日志写入失败不能影响主流程事务回滚所以日志方法用了REQUIRES_NEW。但后续遇到性能问题每次主流程提交前都会额外产生一次数据库连接连接池压力明显变大。后来改成异步写日志把事务问题也规避掉了。这个例子说明事务设计不能只盯着正确性还要考虑连接占用和吞吐量。隔离级别方面MySQL默认是REPEATABLE_READ面试里通常考READ_COMMITTED和REPEATABLE_READ的区别以及幻读问题。InnoDB引擎通过MVCC解决快照读下的幻读问题但当前读带锁的select如select...for update还是可能产生幻读。面试时能把“快照读和当前读”分开讲就比只说“MySQL默认隔离级别”高明得多。2.4 循环依赖三级缓存机制最容易被问到源码细节的问题循环依赖是Spring的经典考点也是最能看出候选人源码阅读深度的问题。场景很简单A依赖BB也依赖A两者同时作为singleton Bean被创建时就会形成循环依赖。Spring解决循环依赖依赖三个缓存容器常被称为三级缓存。一级缓存存放已经完成初始化的成品Bean二级缓存存放早期暴露的原始Bean引用此时Bean还没完成属性填充和初始化三级缓存存放的是ObjectFactory也就是一个回调工厂用来在需要时生成早期引用并且可以返回代理对象。创建A时A实例化后放入三级缓存接着填充属性B发现B还没有创建就去创建B。B实例化后放入三级缓存填充属性A时从三级缓存里拿到A的ObjectFactory并调用getObject此时A被提升到二级缓存B拿到A的早期引用完成属性填充然后B完成后续初始化并放入一级缓存。A再继续执行属性填充从一级缓存拿到B完成后续初始化也放入一级缓存。注意一个关键限制三级缓存解决的是singleton Bean的循环依赖而且必须是setter注入或字段注入。构造器注入无法解决循环依赖因为Bean在new的时候就必须传入完整依赖此时Bean还没实例化完无法提前暴露。Spring Boot 2.6之后默认禁止了循环依赖如果你在项目中遇到循环依赖报错说明代码设计本身有问题优先考虑重构而不是把允许循环依赖开关打开。提示面试时能把三级缓存的演进原因讲清楚的人很少。一级缓存为了拿成品二级缓存为了提前暴露早期引用那三级缓存又解决了什么答案是解决了代理对象的生成时机问题——AOP代理必须在Bean初始化后阶段才能生成但循环依赖中的早期引用在生命周期更早的时候就被拿走了。如果不加三级缓存直接用二级缓存暴露原始对象那AOP的代理就错过了织入时机。三级缓存通过延迟生成代理的方式让需要提前暴露时也能返回正确的代理对象。这个理解讲出来面试官基本会认为你真正读懂了Spring。3. Spring Boot框架自动配置与启动原理3.1 自动配置到底自动了什么Spring Boot最核心的能力是自动配置它让开发者不用再写大量XML配置也不用自己拼装各种Bean。但很多人用了一年Spring Boot也没完全搞懂为什么引入一个starter依赖相关的Bean就自动注册到了容器里。自动配置的核心机制在SpringBootApplication这个复合注解里它组合了SpringBootConfiguration、EnableAutoConfiguration和ComponentScan。其中EnableAutoConfiguration通过Import引入AutoConfigurationImportSelector这个Selector会读取META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件Spring Boot 2.7之前的版本读取spring.factories文件拿到所有自动配置类的类名然后根据条件注解逐个判断是否需要装配。条件注解是自动配置的灵魂。ConditionalOnClass判断classpath下是否存在某个类ConditionalOnMissingBean判断容器里是否已经有某个BeanConditionalOnProperty判断配置项是否满足条件。实际工作里最常见的翻车现场就是自己定义了一个Bean但自动配置也创建了一个启动时因为类型冲突报错或者自己定义了一个数据源配置类结果自动配置的数据源优先级更高把你覆盖了。理解了条件注解这类问题就很好定位先看目标自动配置类上的ConditionalOnMissingBean条件再调整自己的配置方式。3.2 面试必问的启动流程与SpringApplication.run执行过程面试官问“Spring Boot启动过程做了什么”其实是想确认你是否看过SpringApplication的源码。直接背步骤没有意义但你可以用一条主线把过程串起来先推断应用类型是Web应用还是非Web应用然后加载ApplicationContextInitializer和ApplicationListener接着准备好环境变量和配置再创建ApplicationContext最后执行refresh方法加载所有Bean启动Web容器。有个细节容易被忽略Spring Boot默认使用ConfigurableApplicationContext的子类型Web应用对应ServletWebServerApplicationContext响应式应用对应ReactiveWebServerApplicationContext。通过WebApplicationType.deduceFromClasspath判断classpath里是否有特定类来决定上下文类型。如果classpath里同时有Spring MVC和WebFlux的类应用会有一个默认优先级。3.3 starter机制与自定义starter实战思路starter的设计逻辑并不复杂把某个场景需要的依赖和自动配置打包在一起让使用者通过一条依赖引入整个能力。比如引入spring-boot-starter-web就能获得内嵌Tomcat、Spring MVC、Jackson等一组依赖。面试进阶问题通常是“如何自己写一个starter”。这个问题很实操一般分四步第一创建一个自动配置类用Configuration和ConditionalOnClass等注解控制生效条件第二在META-INF目录下创建AutoConfiguration.imports文件写入自动配置类的全类名第三定义属性类用ConfigurationProperties绑定application.yml里的配置项第四需要时提供一个spring.factories里的自动配置排序配置控制装配顺序。我做过一个公司内部的短信发送starter把不同厂商的短信渠道实现封装好业务方只需要配置channelsmsA或channelsmsB自动配置类会根据配置创建对应的发送实现Bean。这个方案让三个业务部门接入短信功能时改动量从几百行配置降到了十几行。自定义starter是体现工程化能力的好素材面试时如果能讲清楚“为什么用条件注解控制实现选择”以及“如何保证多个starter的配置不冲突”会很加分。3.4 Spring Boot配置文件加载顺序与配置覆盖规则配置文件这块很多候选人只知道application.yml不知道profile配置、命令行参数和外部配置文件的优先级。Spring Boot的配置加载优先级从高到低大致是命令行参数、Java系统属性、操作系统环境变量、application-{profile}.yml、application.yml、classpath内的默认配置。实际工作中踩过的坑是本地开发时一切正常测试环境部署后发现数据库地址不对排查很久发现是运维在环境变量里配了JDBC_URL环境变量的优先级高于application.yml覆盖了配置文件里的值。从此养成了习惯先打印环境变量里所有的DB相关配置再怀疑自己代码。面试时提到这个经历不仅能说明你懂配置优先级还能展示排障思路。4. 框架面试中的核心疑难与设计思想4.1 从面试官视角看框架学习如何展现源码级理解面试官评估候选人的框架能力通常不是问你“用过没有”而是从三个层次递进使用层、原理层、设计层。使用层是你能说出某个功能怎么配置原理层是你能解释这个功能底层是怎么工作的设计层是你能分析框架为什么要这么设计对比其他方案的优劣。比如提到MyBatis的一级缓存和二级缓存使用层回答是“一级缓存是SqlSession级别的默认开启二级缓存是Mapper级别的需要手动开启”。原理层回答是“一级缓存在BaseExecutor中通过PerpetualCache实现key是CacheKey对象包含SQL语句、参数、RowBounds等信息二级缓存通过CachingExecutor装饰器实现内部有一个装饰器链”。设计层回答则是“一级缓存生命周期太短只在同一个SqlSession内有效并发场景下意义有限二级缓存要解决跨SqlSession共享的问题但要考虑脏数据问题因为MyBatis对缓存更新策略是粗粒度的任何一个更新操作都会清空该Mapper的整个缓存区域”。能递进到设计层的人很少。这类回答背后的积累不是背题能解决的而是靠平时深入源码、思考为什么这样实现。建议准备框架面试时每个核心知识点都用“是什么、为什么、源码怎么实现、有什么局限”四个维度梳理一遍比刷题效果好得多。4.2 MyBatis核心原理与高频追问MyBatis是Java面试中实际出现频率相当高的框架尤其是业务系统用得多。哪怕你简历里写的是Spring Data JPA面试官也有可能会问MyBatis因为它更贴近SQL控制。MyBatis的启动流程是必问的SqlSessionFactoryBuilder读取配置文件通过XMLConfigBuilder解析成Configuration对象再通过SqlSessionFactoryBuilder.build方法创建DefaultSqlSessionFactory。MapperRegistry负责注册Mapper接口和其对应的MapperProxyFactory。面试官最常追问的问题是“Mapper接口没有实现类为什么可以直接调用方法”。这是典型的动态代理应用场景。MyBatis在解析Mapper时会为每个Mapper接口创建MapperProxyFactory这个工厂在获取Mapper时生成MapperProxy对象。MapperProxy是一个InvocationHandler所有对Mapper接口方法的调用都会走它的invoke方法。invoke方法里会判断调用的是不是Object类的方法然后通过MapperMethod对象执行SQL。MapperMethod里封装了SqlCommand和MethodSignatureSqlCommand记录SQL语句的类型和IDMethodSignature解析方法参数和返回类型。执行时通过SqlSession找到对应语句处理参数后交给Executor执行。这里有个容易卡壳的追问点如果Mapper接口里的方法在XML里找不到对应的statement会报什么错。答案是在MapperMethod初始化时会尝试从Configuration的mappedStatements集合中获取MappedStatement找不到就抛出IllegalArgumentException提示Invalid bound statement。如果项目里出现“Invalid bound statement (not found)”报错基本思路有三个XML文件的namespace没对应接口全限定名、方法ID没对上、XML文件没有被扫描到。MyBatis的SQL参数处理机制也值得准备。简单类型参数用#{value}直接取多个参数时如果不加Param注解MyBatis会把参数包装成param1、param2这样的命名同时也能用arg0、arg1这种命名。实际开发中强烈建议显式加Param注解避免传参逻辑混乱也让SQL可读性更好。4.3 Spring MVC请求处理链路与DispatcherServletSpring MVC整个请求处理链路是面试中必背的内容但死记硬背并不可取。用一个请求从进入到离开的过程来叙述更自然也更完整。请求到达Servlet容器后被DispatcherServlet接收。DispatcherServlet的doDispatch方法拿到请求后先通过HandlerMapping找到对应的HandlerExecutionChain也就是找到能处理这个请求的Controller方法以及执行链上挂的拦截器。然后通过HandlerAdapter适配器调用Controller方法。Controller方法返回ModelAndView或者通过ResponseBody直接返回数据再经过HandlerMethodReturnValueHandler处理最后通过MessageConverter将对象序列化成JSON。如果配置了视图解析器会解析视图名称成真正的View对象并渲染。整个流程中还会执行拦截器的preHandle、postHandle、afterCompletion。面试官通常会在讲完链路后追问“拦截器和过滤器有什么区别”。过滤器是Servlet规范里的组件在DispatcherServlet之前执行能处理request和response但不能访问Spring MVC的Handler相关对象。拦截器是Spring MVC提供的在HandlerMapping找到处理器之后、Controller方法执行之前后执行可以访问HandlerMethod适合做登录校验、权限控制、日志记录。还有个实战细节一个Controller方法的参数是如何被绑定的。比如前端传了一个JSON对象后端用一个DTO接收这个过程涉及HandlerMethodArgumentResolver。其中最关键的是RequestResponseBodyMethodProcessor它先读取请求体交给HttpMessageConverter反序列化成Java对象。如果类型转换失败会抛出HttpMessageNotReadableExceptionSpring Boot默认把它映射成400错误。理解了这条线就能很快定位“接口参数解析失败”这类问题。4.4 微服务与分布式框架面试考点整理现在很多招聘岗位要求掌握微服务相关框架这部分在框架篇里比重越来越大。常见考点包括服务注册发现、服务调用、负载均衡、配置中心、服务熔断与降级、分布式事务、分布式链路追踪等以及网关相关的内容。针对微服务框架面试官最爱问的问题大致可以分成两类。一类是概念类比如“服务熔断和服务降级的区别是什么”标准回答是熔断是provider端出现故障时的自我保护机制降级是consumer端在provider不可用时主动提供降级方案两者有交集但视角不同。另一类是实践类“你在项目中是怎么做服务划分的”“订单服务和库存服务之间调用失败怎么处理”。准备这部分时最好结合自己项目的真实场景来梳理单纯背概念没有意义。比如我曾经负责过一个支付相关的系统调用下游回调接口超时时参考了常见的熔断降级方案把回调处理设计成重试加补偿的模式结合消息队列削峰填谷而不是同步等待超时。这种基于真实场景的经验比任何概念背诵都更能打动面试官。JVM调优、线上问题排查、分布式事务方案选择这类问题经常和框架题交叉出现建议一并准备。比如面试官问“你们系统怎么做分布式事务的”很多人直接说用了Seata但要能解释清楚AT模式、TCC模式、Saga模式的区别以及为什么你的项目选AT模式而不是TCC模式才更有说服力。5. 面试中的表达技巧与避坑建议5.1 如何用“先说结论再讲原理”的方式回答框架题框架题容易长篇大论很多候选人一上来就从底层原理开始讲讲了五分钟还没说到面试官想问的重点结果被打断。比较稳妥的回答方式是“结论先行再展开原理最后给一个实际例子”。比如被问到“Spring Boot自动配置原理”先一句话给结论“自动配置通过EnableAutoConfiguration导入AutoConfigurationImportSelector读取自动配置文件中的配置类类名再通过条件注解按需装配。”然后展开讲具体流程提到读取什么文件、关键条件注解有哪些、常见Bean覆盖冲突怎么解决。最后抛一个自己项目里自定义starter的例子。这样的回答结构面试官可以快速判断你懂不懂也能顺着你的节奏深挖细节。另一个技巧是主动暴露“知识边界”。如果某个问题你只知道大概不知道细节不要硬编。面试官追问两轮就会被识破比直接说“这块我没有深入看过”要糟糕得多。诚实地说“这里我了解原理但没有实际在项目里应用过我讲讲我的理解可能没有实战那么深”反而更能获得认可。5.2 候选人在框架篇中常见的概念混淆点见过不少候选人在几个概念上翻车这里集中整理一下。第一个是Component、Service、Repository、Controller之间的区别。从IoC角度来说它们的功能基本一样都是把类注册为BeanService、Repository只是在不同分层语义上做区分。但有一些面试官会追问是否有特殊处理比如Repository的异常会被转换成DataAccessExceptionController能和Spring MVC的HandlerMapping配合。所以不要回答“完全一样”应该说“核心功能相同但Spring在某些场景下会做额外处理”。第二个是Autowired和Resource的区别。Autowired是Spring的注解默认按类型注入配合Qualifier可以按名称注入Resource是JSR-250规范里的注解默认按名称注入找不到再按类型。很多人只答出“一个按类型一个按名称”其实还要说出最终默认行为、是否支持强制注入、以及构造器注入场景。第三个是BeanFactory和ApplicationContext的区别。ApplicationContext是BeanFactory的子接口两者不仅仅是“更强大的BeanFactory”这么简单。ApplicationContext在启动时默认完成所有singleton Bean的实例化而BeanFactory是在第一次getBean时才实例化。ApplicationContext还提供了事件发布、国际化支持、资源加载等能力。5.3 框架源码学习的“最小可行路径”源码学习最怕贪多嚼不烂。我的经验是不要从头到尾读Spring源码而是从一条主链路切入。比如读Bean创建流程就盯着AbstractApplicationContext.refresh方法顺藤摸瓜进入finishBeanFactoryInitialization、preInstantiateSingletons、AbstractBeanFactory.getBean一路到AbstractAutowireCapableBeanFactory.createBean。这个过程中不要纠结每个分支核心主线看完一遍再回看具体环节。阅读源码时需要带着问题读。比如看循环依赖三级缓存源码时可以带着“一级缓存什么时候放成品”这个问题去翻代码在DefaultSingletonBeanRegistry里找到addSingleton方法理解它是在最后一步写入这样就清楚“成品”和“早期引用”的区别了。对于时间有限的准备者我的建议是优先保障Spring IoC和Bean生命周期、Spring Boot自动配置、MyBatis动态代理这几块内容它们性价比最高。AOP原理、Spring事务、Spring MVC请求链路其次。微服务部分根据自己的项目情况取舍完全没接触过就不要硬答否则容易露馅。6. 框架篇高频问题速查与实战经验总结问题回答核心容易忽略的细节Bean生命周期有哪些阶段实例化、属性填充、初始化、使用、销毁BeanPostProcessor在初始化前后执行AOP代理在初始化后阶段通过AbstractAutoProxyCreator生成构造器注入和setter注入的循环依赖处理有什么区别构造器注入无法解决循环依赖setter注入可以通过三级缓存提前暴露Spring Boot 2.6后默认禁止循环依赖Transactional为什么有时候失效代理失效、异常被吞、方法非public、传播行为配置错误自调用是最大元凶可以拆分Bean或使用AopContext.currentProxy()Spring Boot自动配置原理EnableAutoConfiguration加载自动配置类条件注解控制装配2.7前后配置文件路径不同Mapper接口没有实现类为什么能用MapperProxy动态代理MapperMethod封装SQL和参数Invalid bound statement先查namespace、方法ID、XML扫描路径拦截器和过滤器区别过滤器是Servlet规范拦截器是Spring MVC组件过滤器和拦截器的执行时机不同一级缓存和二级缓存区别一级缓存SqlSession级别默认开启二级缓存Mapper级别需开启二级缓存要注意脏数据问题更新操作会清空整个缓存区域结合我个人的几次面试经历来看框架篇的题目有个共同特点面试官不太关心你用过什么更关心你遇到问题时的分析路径。有一次面试中我被问到“如果一个接口偶尔超时但改一下数据库索引就好了这说明什么问题”看起来很偏但背后考的其实是数据库性能、SQL执行计划、连接池配置这些综合能力再结合框架中数据源配置和MyBatis SQL执行的链路才能给出系统性的分析。准备框架篇面试与其刷一百道题不如把核心框架的源码主链路认真过一遍同时把每个知识点连接到自己的项目实践中。面试中真正出彩的回答往往不是单纯背诵而是能讲出“我在某个项目里遇到了这个报错我是如何根据原理一步步排查出来的”这样的具体故事。这才是框架篇考察的终极目标通过你对框架的理解判断你在真实工作中解决问题能力的高低。最后再分享一个实用的准备方法找一张白纸试着不参考任何资料画一遍Spring请求从启动到处理完成的全流程以及一个Bean从注册到销毁的完整生命周期。如果能顺畅画出来并解释每个环节的类名和触发条件说明框架底子已经过关了。画不出来的部分就是你接下来要重点补的短板。每次面试前用这个方法自查一遍比临时翻书管用得多。
1. 为什么框架篇是Java面试的分水岭做了几年Java开发也面过不少人我发现一个很规律的现象简历上写的技术栈都差不多但一到框架问题就高下立判。很多人能熟练使用Spring、MyBatis写业务代码但被问到“Bean的完整生命周期有哪些阶段”“Spring Boot自动配置到底怎么生效的”“MyBatis的Mapper接口为什么没有实现类却能直接注入调用”一下子就答不上来。框架篇在Java面试里的地位恰恰就是用来区分“会用”和“懂原理”的分界线。业务代码写得多不代表你理解框架的设计思想能跑通Demo也不代表你能在团队里解决复杂的框架层面问题。面试官考察框架篇核心目的不是考背诵而是看三件事第一你有没有主动读过源码和官方文档第二遇到问题时能不能从原理层面定位和分析第三有没有全局视角知道框架在整体架构中扮演什么角色。这篇内容适合准备中级和高级Java岗位面试的同学也适合那些写了两三年业务代码、想系统补一补框架原理的开发。我会结合自己的面试经历和实际工作里踩过的坑把Spring、Spring Boot、MyBatis、Spring MVC这几个最常考的框架逐一拆开讲每个部分都会从“面试官为什么要问”出发再讲核心原理和常见追问最后给一些实操层面的准备建议。文章偏长但都是干货建议收藏后分段看。2. Spring框架面试中的绝对重头戏2.1 IoC容器和Bean的生命周期考官真正想听什么IoC控制反转这个概念几乎每个面试者都能说上两句但大多数人的回答停在“把对象的创建交给Spring管理”这句话上。说实话这句话放十年前还算新鲜放在现在只是基本功。面试官追问的深度往往远超这个层面。我遇到过很多次这样的对话我先说IoC把对象的创建和依赖关系交给容器管理面试官点点头然后紧接着问“那容器什么时候创建对象Bean的完整生命周期从哪一步开始”如果你平时只用过注解没读过AbstractApplicationContext的refresh方法这里很容易卡壳。Bean生命周期其实可以拆成几个关键阶段实例化前、实例化、属性填充、初始化前、初始化、初始化后、使用、销毁。Spring在实例化Bean之前会先通过BeanDefinition读取配置包括XML里的bean标签、注解配置的扫描结果然后封装成BeanDefinition对象。之后经过合并处理、类加载、实例化策略等步骤才真正new出对象。实例化完成后Spring会做属性填充也就是我们常说的依赖注入环节。接着是Aware接口回调比如BeanNameAware、BeanFactoryAware再往后是BeanPostProcessor的before方法、InitializingBean或init-method、BeanPostProcessor的after方法这时Bean才算准备完毕可以被业务代码使用了。这里有个很多人忽略的细节AOP代理对象的生成通常发生在BeanPostProcessor的after阶段。所以你在应用里拿到的Bean很可能不是原始对象而是一个代理对象。面试中如果能主动提到“Spring通过AbstractAutoProxyCreator在Bean初始化后阶段完成AOP代理的创建”会明显拉开和普通候选人的差距。还有一个高频考点是Bean的作用域。singleton和prototype的区别大多数人都知道但问到“singleton Bean里注入prototype Bean会有什么问题”“怎么解决”就暴露水平了。默认情况下singleton Bean只创建一次如果直接注入一个prototype Bean那这个prototype Bean实际上只有一个实例每次调用都是同一个对象失去了prototype的意义。解决办法通常是使用ObjectProvider、Lookup方法注入或者通过ApplicationContext手动获取。注意BeanFactory和FactoryBean是两个完全不同的概念很多面试者混为一谈。BeanFactory是IoC容器的顶层接口而FactoryBean是一个特殊的Bean它本身是个工厂通过getObject方法产出另一个对象。比如MyBatis的MapperFactoryBean就是通过FactoryBean机制把Mapper接口变成可注入的Bean。这个区别至少遇到三次面试官特意追问过。2.2 Spring AOP的工作原理与切面失效场景AOP这块面试官最喜欢从“动态代理的两种方式区别”问起。JDK动态代理基于接口使用Proxy类在运行时生成代理对象CGLIB基于继承通过生成子类来代理目标类。Spring默认策略是目标类实现了接口就用JDK动态代理没有实现接口就用CGLIB。Spring Boot 2.x之后默认开启了proxyTargetClasstrue所以即使有接口默认也用CGLIB。有个细节值得留意CGLIB不能代理final类和非public方法。如果你写了一个final的Service类或者某个方法被final修饰切面是织入不进去的因为CGLIB无法继承和覆写。这个点可以作为面试中的加分项提出来说明你确实踩过类似的坑。很多人在业务代码里用Transactional事务失效了不知道怎么排查。其实事务失效常见原因就那么几类方法不是public的、异常被catch住没有抛出、自调用导致代理失效、数据库表不支持事务、传播行为配置错误。自调用这个问题最常见比如同一个类里一个方法调用另一个被Transactional标注的方法由于调用发生在对象内部没有经过代理对象事务注解就完全失效了。解决办法可以是拆分到不同Bean中或者使用AopContext.currentProxy()获取当前代理对象。还有一个切入点Spring AOP是运行时增强通过代理实现AspectJ是编译期增强或类加载期增强通过字节码操作实现。交易系统或高性能场景中如果需要更细粒度的切面控制AspectJ可能更适合。但普通业务项目里Spring AOP已经足够。2.3 Spring事务传播行为、隔离级别与失效场景事务传播行为有七种面试中至少要被追问三种以上。REQUIRED、REQUIRES_NEW、NESTED这三个是重点。REQUIRED是默认传播行为如果当前存在事务就加入不存在就新建REQUIRES_NEW会挂起当前事务新建一个独立事务NESTED是嵌套事务依赖于JDBC的savepoint机制回滚时可以只回滚到savepoint位置而不影响外层事务。实际开发里我用REQUIRES_NEW处理过一个场景某个任务执行过程中要写操作日志日志写入失败不能影响主流程事务回滚所以日志方法用了REQUIRES_NEW。但后续遇到性能问题每次主流程提交前都会额外产生一次数据库连接连接池压力明显变大。后来改成异步写日志把事务问题也规避掉了。这个例子说明事务设计不能只盯着正确性还要考虑连接占用和吞吐量。隔离级别方面MySQL默认是REPEATABLE_READ面试里通常考READ_COMMITTED和REPEATABLE_READ的区别以及幻读问题。InnoDB引擎通过MVCC解决快照读下的幻读问题但当前读带锁的select如select...for update还是可能产生幻读。面试时能把“快照读和当前读”分开讲就比只说“MySQL默认隔离级别”高明得多。2.4 循环依赖三级缓存机制最容易被问到源码细节的问题循环依赖是Spring的经典考点也是最能看出候选人源码阅读深度的问题。场景很简单A依赖BB也依赖A两者同时作为singleton Bean被创建时就会形成循环依赖。Spring解决循环依赖依赖三个缓存容器常被称为三级缓存。一级缓存存放已经完成初始化的成品Bean二级缓存存放早期暴露的原始Bean引用此时Bean还没完成属性填充和初始化三级缓存存放的是ObjectFactory也就是一个回调工厂用来在需要时生成早期引用并且可以返回代理对象。创建A时A实例化后放入三级缓存接着填充属性B发现B还没有创建就去创建B。B实例化后放入三级缓存填充属性A时从三级缓存里拿到A的ObjectFactory并调用getObject此时A被提升到二级缓存B拿到A的早期引用完成属性填充然后B完成后续初始化并放入一级缓存。A再继续执行属性填充从一级缓存拿到B完成后续初始化也放入一级缓存。注意一个关键限制三级缓存解决的是singleton Bean的循环依赖而且必须是setter注入或字段注入。构造器注入无法解决循环依赖因为Bean在new的时候就必须传入完整依赖此时Bean还没实例化完无法提前暴露。Spring Boot 2.6之后默认禁止了循环依赖如果你在项目中遇到循环依赖报错说明代码设计本身有问题优先考虑重构而不是把允许循环依赖开关打开。提示面试时能把三级缓存的演进原因讲清楚的人很少。一级缓存为了拿成品二级缓存为了提前暴露早期引用那三级缓存又解决了什么答案是解决了代理对象的生成时机问题——AOP代理必须在Bean初始化后阶段才能生成但循环依赖中的早期引用在生命周期更早的时候就被拿走了。如果不加三级缓存直接用二级缓存暴露原始对象那AOP的代理就错过了织入时机。三级缓存通过延迟生成代理的方式让需要提前暴露时也能返回正确的代理对象。这个理解讲出来面试官基本会认为你真正读懂了Spring。3. Spring Boot框架自动配置与启动原理3.1 自动配置到底自动了什么Spring Boot最核心的能力是自动配置它让开发者不用再写大量XML配置也不用自己拼装各种Bean。但很多人用了一年Spring Boot也没完全搞懂为什么引入一个starter依赖相关的Bean就自动注册到了容器里。自动配置的核心机制在SpringBootApplication这个复合注解里它组合了SpringBootConfiguration、EnableAutoConfiguration和ComponentScan。其中EnableAutoConfiguration通过Import引入AutoConfigurationImportSelector这个Selector会读取META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件Spring Boot 2.7之前的版本读取spring.factories文件拿到所有自动配置类的类名然后根据条件注解逐个判断是否需要装配。条件注解是自动配置的灵魂。ConditionalOnClass判断classpath下是否存在某个类ConditionalOnMissingBean判断容器里是否已经有某个BeanConditionalOnProperty判断配置项是否满足条件。实际工作里最常见的翻车现场就是自己定义了一个Bean但自动配置也创建了一个启动时因为类型冲突报错或者自己定义了一个数据源配置类结果自动配置的数据源优先级更高把你覆盖了。理解了条件注解这类问题就很好定位先看目标自动配置类上的ConditionalOnMissingBean条件再调整自己的配置方式。3.2 面试必问的启动流程与SpringApplication.run执行过程面试官问“Spring Boot启动过程做了什么”其实是想确认你是否看过SpringApplication的源码。直接背步骤没有意义但你可以用一条主线把过程串起来先推断应用类型是Web应用还是非Web应用然后加载ApplicationContextInitializer和ApplicationListener接着准备好环境变量和配置再创建ApplicationContext最后执行refresh方法加载所有Bean启动Web容器。有个细节容易被忽略Spring Boot默认使用ConfigurableApplicationContext的子类型Web应用对应ServletWebServerApplicationContext响应式应用对应ReactiveWebServerApplicationContext。通过WebApplicationType.deduceFromClasspath判断classpath里是否有特定类来决定上下文类型。如果classpath里同时有Spring MVC和WebFlux的类应用会有一个默认优先级。3.3 starter机制与自定义starter实战思路starter的设计逻辑并不复杂把某个场景需要的依赖和自动配置打包在一起让使用者通过一条依赖引入整个能力。比如引入spring-boot-starter-web就能获得内嵌Tomcat、Spring MVC、Jackson等一组依赖。面试进阶问题通常是“如何自己写一个starter”。这个问题很实操一般分四步第一创建一个自动配置类用Configuration和ConditionalOnClass等注解控制生效条件第二在META-INF目录下创建AutoConfiguration.imports文件写入自动配置类的全类名第三定义属性类用ConfigurationProperties绑定application.yml里的配置项第四需要时提供一个spring.factories里的自动配置排序配置控制装配顺序。我做过一个公司内部的短信发送starter把不同厂商的短信渠道实现封装好业务方只需要配置channelsmsA或channelsmsB自动配置类会根据配置创建对应的发送实现Bean。这个方案让三个业务部门接入短信功能时改动量从几百行配置降到了十几行。自定义starter是体现工程化能力的好素材面试时如果能讲清楚“为什么用条件注解控制实现选择”以及“如何保证多个starter的配置不冲突”会很加分。3.4 Spring Boot配置文件加载顺序与配置覆盖规则配置文件这块很多候选人只知道application.yml不知道profile配置、命令行参数和外部配置文件的优先级。Spring Boot的配置加载优先级从高到低大致是命令行参数、Java系统属性、操作系统环境变量、application-{profile}.yml、application.yml、classpath内的默认配置。实际工作中踩过的坑是本地开发时一切正常测试环境部署后发现数据库地址不对排查很久发现是运维在环境变量里配了JDBC_URL环境变量的优先级高于application.yml覆盖了配置文件里的值。从此养成了习惯先打印环境变量里所有的DB相关配置再怀疑自己代码。面试时提到这个经历不仅能说明你懂配置优先级还能展示排障思路。4. 框架面试中的核心疑难与设计思想4.1 从面试官视角看框架学习如何展现源码级理解面试官评估候选人的框架能力通常不是问你“用过没有”而是从三个层次递进使用层、原理层、设计层。使用层是你能说出某个功能怎么配置原理层是你能解释这个功能底层是怎么工作的设计层是你能分析框架为什么要这么设计对比其他方案的优劣。比如提到MyBatis的一级缓存和二级缓存使用层回答是“一级缓存是SqlSession级别的默认开启二级缓存是Mapper级别的需要手动开启”。原理层回答是“一级缓存在BaseExecutor中通过PerpetualCache实现key是CacheKey对象包含SQL语句、参数、RowBounds等信息二级缓存通过CachingExecutor装饰器实现内部有一个装饰器链”。设计层回答则是“一级缓存生命周期太短只在同一个SqlSession内有效并发场景下意义有限二级缓存要解决跨SqlSession共享的问题但要考虑脏数据问题因为MyBatis对缓存更新策略是粗粒度的任何一个更新操作都会清空该Mapper的整个缓存区域”。能递进到设计层的人很少。这类回答背后的积累不是背题能解决的而是靠平时深入源码、思考为什么这样实现。建议准备框架面试时每个核心知识点都用“是什么、为什么、源码怎么实现、有什么局限”四个维度梳理一遍比刷题效果好得多。4.2 MyBatis核心原理与高频追问MyBatis是Java面试中实际出现频率相当高的框架尤其是业务系统用得多。哪怕你简历里写的是Spring Data JPA面试官也有可能会问MyBatis因为它更贴近SQL控制。MyBatis的启动流程是必问的SqlSessionFactoryBuilder读取配置文件通过XMLConfigBuilder解析成Configuration对象再通过SqlSessionFactoryBuilder.build方法创建DefaultSqlSessionFactory。MapperRegistry负责注册Mapper接口和其对应的MapperProxyFactory。面试官最常追问的问题是“Mapper接口没有实现类为什么可以直接调用方法”。这是典型的动态代理应用场景。MyBatis在解析Mapper时会为每个Mapper接口创建MapperProxyFactory这个工厂在获取Mapper时生成MapperProxy对象。MapperProxy是一个InvocationHandler所有对Mapper接口方法的调用都会走它的invoke方法。invoke方法里会判断调用的是不是Object类的方法然后通过MapperMethod对象执行SQL。MapperMethod里封装了SqlCommand和MethodSignatureSqlCommand记录SQL语句的类型和IDMethodSignature解析方法参数和返回类型。执行时通过SqlSession找到对应语句处理参数后交给Executor执行。这里有个容易卡壳的追问点如果Mapper接口里的方法在XML里找不到对应的statement会报什么错。答案是在MapperMethod初始化时会尝试从Configuration的mappedStatements集合中获取MappedStatement找不到就抛出IllegalArgumentException提示Invalid bound statement。如果项目里出现“Invalid bound statement (not found)”报错基本思路有三个XML文件的namespace没对应接口全限定名、方法ID没对上、XML文件没有被扫描到。MyBatis的SQL参数处理机制也值得准备。简单类型参数用#{value}直接取多个参数时如果不加Param注解MyBatis会把参数包装成param1、param2这样的命名同时也能用arg0、arg1这种命名。实际开发中强烈建议显式加Param注解避免传参逻辑混乱也让SQL可读性更好。4.3 Spring MVC请求处理链路与DispatcherServletSpring MVC整个请求处理链路是面试中必背的内容但死记硬背并不可取。用一个请求从进入到离开的过程来叙述更自然也更完整。请求到达Servlet容器后被DispatcherServlet接收。DispatcherServlet的doDispatch方法拿到请求后先通过HandlerMapping找到对应的HandlerExecutionChain也就是找到能处理这个请求的Controller方法以及执行链上挂的拦截器。然后通过HandlerAdapter适配器调用Controller方法。Controller方法返回ModelAndView或者通过ResponseBody直接返回数据再经过HandlerMethodReturnValueHandler处理最后通过MessageConverter将对象序列化成JSON。如果配置了视图解析器会解析视图名称成真正的View对象并渲染。整个流程中还会执行拦截器的preHandle、postHandle、afterCompletion。面试官通常会在讲完链路后追问“拦截器和过滤器有什么区别”。过滤器是Servlet规范里的组件在DispatcherServlet之前执行能处理request和response但不能访问Spring MVC的Handler相关对象。拦截器是Spring MVC提供的在HandlerMapping找到处理器之后、Controller方法执行之前后执行可以访问HandlerMethod适合做登录校验、权限控制、日志记录。还有个实战细节一个Controller方法的参数是如何被绑定的。比如前端传了一个JSON对象后端用一个DTO接收这个过程涉及HandlerMethodArgumentResolver。其中最关键的是RequestResponseBodyMethodProcessor它先读取请求体交给HttpMessageConverter反序列化成Java对象。如果类型转换失败会抛出HttpMessageNotReadableExceptionSpring Boot默认把它映射成400错误。理解了这条线就能很快定位“接口参数解析失败”这类问题。4.4 微服务与分布式框架面试考点整理现在很多招聘岗位要求掌握微服务相关框架这部分在框架篇里比重越来越大。常见考点包括服务注册发现、服务调用、负载均衡、配置中心、服务熔断与降级、分布式事务、分布式链路追踪等以及网关相关的内容。针对微服务框架面试官最爱问的问题大致可以分成两类。一类是概念类比如“服务熔断和服务降级的区别是什么”标准回答是熔断是provider端出现故障时的自我保护机制降级是consumer端在provider不可用时主动提供降级方案两者有交集但视角不同。另一类是实践类“你在项目中是怎么做服务划分的”“订单服务和库存服务之间调用失败怎么处理”。准备这部分时最好结合自己项目的真实场景来梳理单纯背概念没有意义。比如我曾经负责过一个支付相关的系统调用下游回调接口超时时参考了常见的熔断降级方案把回调处理设计成重试加补偿的模式结合消息队列削峰填谷而不是同步等待超时。这种基于真实场景的经验比任何概念背诵都更能打动面试官。JVM调优、线上问题排查、分布式事务方案选择这类问题经常和框架题交叉出现建议一并准备。比如面试官问“你们系统怎么做分布式事务的”很多人直接说用了Seata但要能解释清楚AT模式、TCC模式、Saga模式的区别以及为什么你的项目选AT模式而不是TCC模式才更有说服力。5. 面试中的表达技巧与避坑建议5.1 如何用“先说结论再讲原理”的方式回答框架题框架题容易长篇大论很多候选人一上来就从底层原理开始讲讲了五分钟还没说到面试官想问的重点结果被打断。比较稳妥的回答方式是“结论先行再展开原理最后给一个实际例子”。比如被问到“Spring Boot自动配置原理”先一句话给结论“自动配置通过EnableAutoConfiguration导入AutoConfigurationImportSelector读取自动配置文件中的配置类类名再通过条件注解按需装配。”然后展开讲具体流程提到读取什么文件、关键条件注解有哪些、常见Bean覆盖冲突怎么解决。最后抛一个自己项目里自定义starter的例子。这样的回答结构面试官可以快速判断你懂不懂也能顺着你的节奏深挖细节。另一个技巧是主动暴露“知识边界”。如果某个问题你只知道大概不知道细节不要硬编。面试官追问两轮就会被识破比直接说“这块我没有深入看过”要糟糕得多。诚实地说“这里我了解原理但没有实际在项目里应用过我讲讲我的理解可能没有实战那么深”反而更能获得认可。5.2 候选人在框架篇中常见的概念混淆点见过不少候选人在几个概念上翻车这里集中整理一下。第一个是Component、Service、Repository、Controller之间的区别。从IoC角度来说它们的功能基本一样都是把类注册为BeanService、Repository只是在不同分层语义上做区分。但有一些面试官会追问是否有特殊处理比如Repository的异常会被转换成DataAccessExceptionController能和Spring MVC的HandlerMapping配合。所以不要回答“完全一样”应该说“核心功能相同但Spring在某些场景下会做额外处理”。第二个是Autowired和Resource的区别。Autowired是Spring的注解默认按类型注入配合Qualifier可以按名称注入Resource是JSR-250规范里的注解默认按名称注入找不到再按类型。很多人只答出“一个按类型一个按名称”其实还要说出最终默认行为、是否支持强制注入、以及构造器注入场景。第三个是BeanFactory和ApplicationContext的区别。ApplicationContext是BeanFactory的子接口两者不仅仅是“更强大的BeanFactory”这么简单。ApplicationContext在启动时默认完成所有singleton Bean的实例化而BeanFactory是在第一次getBean时才实例化。ApplicationContext还提供了事件发布、国际化支持、资源加载等能力。5.3 框架源码学习的“最小可行路径”源码学习最怕贪多嚼不烂。我的经验是不要从头到尾读Spring源码而是从一条主链路切入。比如读Bean创建流程就盯着AbstractApplicationContext.refresh方法顺藤摸瓜进入finishBeanFactoryInitialization、preInstantiateSingletons、AbstractBeanFactory.getBean一路到AbstractAutowireCapableBeanFactory.createBean。这个过程中不要纠结每个分支核心主线看完一遍再回看具体环节。阅读源码时需要带着问题读。比如看循环依赖三级缓存源码时可以带着“一级缓存什么时候放成品”这个问题去翻代码在DefaultSingletonBeanRegistry里找到addSingleton方法理解它是在最后一步写入这样就清楚“成品”和“早期引用”的区别了。对于时间有限的准备者我的建议是优先保障Spring IoC和Bean生命周期、Spring Boot自动配置、MyBatis动态代理这几块内容它们性价比最高。AOP原理、Spring事务、Spring MVC请求链路其次。微服务部分根据自己的项目情况取舍完全没接触过就不要硬答否则容易露馅。6. 框架篇高频问题速查与实战经验总结问题回答核心容易忽略的细节Bean生命周期有哪些阶段实例化、属性填充、初始化、使用、销毁BeanPostProcessor在初始化前后执行AOP代理在初始化后阶段通过AbstractAutoProxyCreator生成构造器注入和setter注入的循环依赖处理有什么区别构造器注入无法解决循环依赖setter注入可以通过三级缓存提前暴露Spring Boot 2.6后默认禁止循环依赖Transactional为什么有时候失效代理失效、异常被吞、方法非public、传播行为配置错误自调用是最大元凶可以拆分Bean或使用AopContext.currentProxy()Spring Boot自动配置原理EnableAutoConfiguration加载自动配置类条件注解控制装配2.7前后配置文件路径不同Mapper接口没有实现类为什么能用MapperProxy动态代理MapperMethod封装SQL和参数Invalid bound statement先查namespace、方法ID、XML扫描路径拦截器和过滤器区别过滤器是Servlet规范拦截器是Spring MVC组件过滤器和拦截器的执行时机不同一级缓存和二级缓存区别一级缓存SqlSession级别默认开启二级缓存Mapper级别需开启二级缓存要注意脏数据问题更新操作会清空整个缓存区域结合我个人的几次面试经历来看框架篇的题目有个共同特点面试官不太关心你用过什么更关心你遇到问题时的分析路径。有一次面试中我被问到“如果一个接口偶尔超时但改一下数据库索引就好了这说明什么问题”看起来很偏但背后考的其实是数据库性能、SQL执行计划、连接池配置这些综合能力再结合框架中数据源配置和MyBatis SQL执行的链路才能给出系统性的分析。准备框架篇面试与其刷一百道题不如把核心框架的源码主链路认真过一遍同时把每个知识点连接到自己的项目实践中。面试中真正出彩的回答往往不是单纯背诵而是能讲出“我在某个项目里遇到了这个报错我是如何根据原理一步步排查出来的”这样的具体故事。这才是框架篇考察的终极目标通过你对框架的理解判断你在真实工作中解决问题能力的高低。最后再分享一个实用的准备方法找一张白纸试着不参考任何资料画一遍Spring请求从启动到处理完成的全流程以及一个Bean从注册到销毁的完整生命周期。如果能顺畅画出来并解释每个环节的类名和触发条件说明框架底子已经过关了。画不出来的部分就是你接下来要重点补的短板。每次面试前用这个方法自查一遍比临时翻书管用得多。
