大厂后端高频面试题及详细答案（实战向）

大厂后端高频面试题及详细答案（实战向）本套面试题汇总一线互联网大厂后端高频考点，覆盖基础、框架、中间件、分布式、性能排查、场景设计六大模块，答案贴合真实面试沟通口吻，侧重工程实践，摒弃书面化套话，适配Java后端主流技术栈，校招、社招均可直接复用。一、Java基础核心（必问）1.说一说线程池核心参数、拒绝策略，以及工作中如何配置线程池核心参数一共7个，日常开发重点关注5个核心参数：核心线程数、最大线程数、阻塞队列、拒绝策略、线程空闲时间。核心线程数是常驻线程，即使空闲也不会被回收，是线程池常态化处理任务的核心；最大线程数限定了线程池能创建的总线程上限；阻塞队列用于缓存来不及处理的任务；空闲时间是非核心线程的闲置超时时间，超时后会被回收；拒绝策略是线程池满负荷（线程数达最大值、队列已满）时的兜底处理逻辑。JDK自带四种拒绝策略：AbortPolicy直接抛异常，是默认策略；CallerRunsPolicy让调用者线程自己执行任务，不丢弃、不报错；DiscardPolicy直接丢弃最新任务，无日志无异常；DiscardOldestPolicy丢弃队列中最旧的未执行任务，替换为新任务。工作中配置原则：高并发短耗时接口，核心线程数不宜过大，队列设置合理长度，避免任务堆积导致响应超时；长耗时业务任务，适当调大最大线程数，缩小队列，防止任务长时间排队。线上优先使用CallerRunsPolicy或自定义拒绝策略，记录异常日志，避免静默丢数据。绝对不使用Executors创建线程池，防止出现无界队列、线程数无上限导致的OOM问题。2.Synchronized和Lock的区别，什么时候用Lock第一，底层机制不同。Synchronized是JVM原生锁，基于对象头的MarkWord实现，属于隐式锁，加锁释放锁由虚拟机自动完成；Lock是JDK层面的接口，基于AQS队列实现，属于显式锁，需要手动加锁、手动释放锁，必须在finally中释放，避免死锁。第二，功能粒度不同。Synchronized只支持非公平锁、可重入锁，不支持超时锁、中断锁；Lock可以实现公平锁、非公平锁，支持锁超时、可中断锁，同时支持读写分离锁（ReentrantReadWriteLock），读多写少场景性能优势明显。第三，性能差异。低并发场景下两者性能差距很小；高并发竞争激烈场景下，Lock的CAS自旋机制效率更高，Synchronized在JDK1.6优化后（偏向锁、轻量级锁、重量级锁）性能大幅提升，但高竞争场景仍不如Lock。实际使用场景：简单同步逻辑、代码块同步，优先用Synchronized，代码简洁不易出错；需要公平锁、读写分离、锁超时、可中断锁的复杂并发场景，必须用Lock。3.线程的生命周期及状态流转Java线程一共6种状态：新建、就绪、运行、阻塞、等待、超时等待、终止。新建状态是线程创建后未调用start方法；调用start后进入就绪状态，等待CPU调度；获取CPU时间片后进入运行状态，执行run方法。运行状态下，调用sleep、wait、join会进入阻塞类状态：sleep、带超时的wait、join进入超时等待；无参wait、LockSupport.park进入无限等待；等待锁资源时进入阻塞状态。二、JVM性能与调优（高频面试+实操）1.JVM内存区域划分，哪些是线程私有、哪些是共享线程私有区域：程序计数器、虚拟机栈、本地方法栈。每个线程独立拥有，线程销毁后内存自动释放，不存在内存溢出问题。程序计数器是唯一没有OOM的内存区域，记录当前线程执行的字节码行号。虚拟机栈存储栈帧，包含局部变量表、操作数栈、方法出口等，方法调用和执行对应栈帧的入栈出栈。线程共享区域：堆、元空间。堆是所有线程共享，存放对象实例和数组，是GC的主要回收区域，会发生OOM；元空间替代JDK1.8之前的永久代，存储类元数据、方法、常量池等，默认不受堆内存限制，受系统物理内存限制。2.CMS和G1收集器的区别，线上如何选择CMS是老年代专属收集器，核心是并发标记、并发清除，主打低停顿，减少用户线程暂停时间。缺点是存在内存碎片、无法处理浮动垃圾，高并发场景容易出现ConcurrentModeFailure，退化为STW的FullGC，吞吐量较低。G1是一款面向大内存、低延迟的分代收集器，将堆内存划分为多个大小相等的Region，不再固定划分新生代和老年代，可动态调整区域比例。核心优势是可预测停顿时间，支持用户设置最大停顿阈值，优先回收垃圾最多的Region，回收效率更高。同时整合了分代回收、空间整合，几乎没有内存碎片。线上选型：堆内存小于8G、追求极致低延迟的老年代回收场景，可用CMS；堆内存大于8G、大内存服务、需要可控GC停顿、减少内存碎片的场景，优先使用G1。目前新版JDK基本推荐G1作为默认垃圾收集器。3.线上CPU飙高、OOM的完整排查思路CPU飙高排查步骤：首先通过top命令定位CPU占用最高的Java进程；再通过top-H-p进程ID找到占用CPU最高的线程；将线程ID转为16进制，通过jstack进程ID|grep十六进制线程号，定位卡死、死循环、频繁自旋的代码行数；最后结合业务代码排查是否存在死循环、大量空循环、锁竞争激烈、频繁GC等问题。OOM排查步骤：先查看日志区分OOM类型，是堆内存溢出、元空间溢出，还是栈溢出；使用jmap-dump导出堆快照，通过MAT工具分析大对象、内存泄漏对象、无效常驻集合；重点排查静态集合无限累加、线程池任务堆积、未关闭的流和连接、循环创建对象等问题；最后优化代码，调整JVM参数，增大对应内存区域或修复内存泄漏bug。日常线上排查优先使用Arthas工具，无需重启服务，可实时监控线程、内存、GC情况，大幅提升排查效率。三、Spring核心原理（必考）1.SpringBean完整生命周期整体流程：资源加载解析→实例化→属性填充→初始化→销毁。首先Spring扫描配置类和注解，加载Bean定义信息；通过反射无参构造器实例化Bean对象；完成依赖注入，填充属性（@Autowired、@Resource注入）；之后执行初始化前置处理（BeanPostProcessor前置方法）；执行InitializingBean的afterPropertiesSet方法、自定义init-method；再执行BeanPostProcessor后置方法，此时Bean完全初始化完成，放入单例池供业务使用。服务关闭或容器销毁时，执行@PreDestroy标注方法、DisposableBean的destroy方法、自定义destroy-method，完成Bean销毁。2.Spring如何解决循环依赖？三级缓存原理Spring仅能解决单例Bean、setter注入的循环依赖，无法解决构造器注入的循环依赖，构造器注入依赖提前触发，无缓存可用。三级缓存核心是三个Map：一级缓存存放完全初始化完成的单例Bean；二级缓存存放实例化完成、未完成属性填充的半成品Bean；三级缓存存放Bean工厂对象，用于提前暴露Bean引用。循环依赖场景下，A创建时先实例化，将自身工厂放入三级缓存，再注入B；B创建时需要A，从三级缓存获取A的工厂，创建A引用完成注入，B初始化完成后放入一级缓存；A继续完成后续初始化，最终放入一级缓存，彻底解决循环依赖问题。三级缓存的核心意义是提前暴露Bean引用，保证依赖注入闭环。3.SpringAOP动态代理选择规则SpringAOP默认优先使用JDK动态代理，当目标类没有实现接口时，自动切换为CGLIB代理。JDK动态代理基于接口实现，只能代理接口方法，无需引入额外依赖，效率高；缺点是无法代理普通类和非接口方法。CGLIB基于字节码增强，继承目标类生成子类代理对象，可代理普通类和所有公共方法；缺点是无法代理final类和final方法，启动速度稍慢。SpringBoot2.0之后默认统一使用CGLIB代理，简化配置，适配更多业务场景。四、Redis中间件核心（面试重灾区）1.缓存击穿、穿透、雪崩的区别及解决方案缓存穿透：查询数据库和缓存都不存在的数据，比如恶意请求空ID、负数ID，大量请求直接打穿到数据库，压垮数据库。解决方案：接口层参数校验、布隆过滤器拦截无效请求、空结果缓存（设置短期过期时间）。缓存击穿：热点Key过期瞬间，大量并发请求同时落到数据库，瞬时流量冲击大。解决方案：热点Key永不过期、加分布式锁（Redis+Lua）、互斥锁兜底、热点数据定时主动刷新。缓存雪崩：大量缓存Key同时过期，或Redis集群宕机，导致所有请求直达数据库，引发数据库雪崩。解决方案：过期时间加随机偏移量，避免批量过期；搭建Redis主从+哨兵/集群高可用；添加多级缓存、服务熔断降级、限流兜底。2.Redis分布式锁实现原理、存在的问题及优化基础实现：通过SETkeyvalueNXEX过期时间命令，NX保证原子加锁，EX设置锁超时，防止死锁。释放锁通过Lua脚本，判断当前线程持有锁再删除，避免误删他人锁。原生Redis锁存在的问题：锁超时释放导致业务未执行完、锁失效；主从延迟导致锁丢失（主节点加锁成功，未同步到从节点就宕机，新主节点无锁数据）。生产优化方案：使用Redisson实现可重入分布式锁，通过看门狗机制自动续期锁超时时间，解决业务超时问题；Redisson基于主从架构实现锁可靠性，同时支持公平锁、读写锁，适配复杂业务。3.Redis为什么快？单线程模型优势Redis核心是单线程处理IO读写和命令执行，多路复用模型监听多个Socket连接，单线程避免了线程切换、锁竞争的开销，执行效率极高。除此之外，Redis数据全部基于内存操作，内存读写速度远大于磁盘；底层数据结构高度优化（跳表、压缩列表、哈希表）；命令执行简单高效，无复杂计算逻辑；同时采用IO多路复用，单线程可处理万级并发连接。注意：Redis并非完全单线程，持久化、集群同步等后台任务由独立子线程执行，不影响主线程命令处理。五、消息队列MQ核心实战1.MQ的核心作用，业务中什么场景必须用MQ三大核心作用：异步解耦、削峰填谷、流量消峰。异步解耦：将同步长链路拆分为异步链路，减少接口响应时间，解除上下游系统强依赖，下游业务迭代不影响上游核心逻辑。削峰填谷：应对瞬时高并发流量，将突发流量缓存到MQ，平稳消费，避免瞬间流量压垮后端服务和数据库。必备场景：秒杀、活动大促等流量突发场景；系统解耦（订单、支付、物流通知）；异步日志收集、数据同步；分布式事务最终一致性场景；延时任务场景。2.Kafka、RabbitMQ、RocketMQ选型对比Kafka：优势是超高吞吐、低延迟、架构简单，基于磁盘顺序读写，适合大数据量、日志收集、海量数据流场景；缺点是不支持事务、延时消息弱，可靠性中等。RabbitMQ：优势是可靠性高、路由策略丰富、部署简单，支持多种协议，适合业务消息、可靠性要求高的场景；缺点是吞吐能力较弱，不适合超大流量场景。RocketMQ：兼顾高吞吐和高可靠，支持事务消息、延时消息、死信队列，适配电商、金融核心业务，是国内大厂主流选型；综合性能均衡，无明显短板。3.如何保证MQ消息不丢失、不重复消费消息不丢失：分三个阶段保障。生产端：开启消息确认机制，失败重试、本地消息表兜底；服务端：开启持久化、副本同步机制，保证消息落盘；消费端：消费成功后再提交位移，禁止消费前提交，避免消息丢失。不重复消费：MQ天生不保证消息唯一，只保证至少一次投递。业务层通过唯一消息ID做幂等处理，使用Redis、数据库唯一键、状态机判断，重复消息直接过滤，无需业务重试。六、分布式与高并发场景设计（社招重点）1.分布式事务解决方案及选型XA事务：强一致性，两阶段提交，缺点是阻塞时间长、性能差，不适合高并发业务，几乎不用在互联网项目。TCC事务：补偿型事务，分为Try、Confirm、Cancel三个阶段，手动编码实现，一致性高、性能好，适合核心金融、支付业务；缺点是编码成本极高，业务侵入性强。本地消息表：基于本地事务+MQ实现最终一致性，简单易落地、无中间件依赖，适配绝大多数普通业务场景，是中小业务首选方案。SeataAT模式：无侵入、低代码成本，自动生成回滚日志，适配微服务通用场景，大厂微服务主流选型，满足大部分分布式事务需求。2.秒杀系统核心设计方案（高频场景题）秒杀核心痛点：瞬时超高并发、超卖、接口被刷、数据库压力过大。整体采用分层限流、异步削峰、库存预扣架构。前端层：按钮置灰、验证码限流、请求防抖，拦截无效重复请求；网关层：全局限流、IP黑名单、防刷拦截。缓存层：秒杀商品库存预热到Redis，通过Redis+Lua脚本原子扣库存，拦截大部分流量，避免直达数据库。业务层：异步化处理，秒杀成功后发送MQ消息，异步创建订单、扣减数据库库存；设置订单超时自动取消，释放库存，解决库存预留问题。数据库层：数据库乐观锁兜底，防止超卖；分库分表、读写分离，提升数据库抗压能力。3.分布