每年秋招季一过后台就会收到一堆备考私信。问得最多的其实是同一句话“制造业大厂的后端岗笔试到底难不难、考什么”我手头一直留着一套格力2020秋招后端岗笔试题的回忆版当时考完就顺手把题目和答案整理成了笔记后来复盘时发现很多同学挂掉的原因根本不是不会做而是不知道阅卷人到底想考察什么。这篇文章就把整套题的考察逻辑、典型题目、参考答案以及我踩过的坑一次性说清楚。如果你是准备后端岗笔试、尤其是想投制造业头部企业的同学这篇对你应该很有参考价值。先说结论这套笔试整体偏基础难度不算“地狱级”但覆盖面非常广。它不像互联网大厂那样会把算法题拉到 LeetCode Hard而是更看重 Java 基础是否扎实、数据库功底是否过硬、并发场景下能不能写出靠谱的方案。题型分为选择题、简答题、编程题、SQL 题和系统设计题五类两个小时题量不小时间分配不合理的人很容易在前面选择题上磨太久后面编程题反而没时间写。1. 整体题型结构与考察逻辑1.1 笔试整体结构与时间分配格力 2020 秋招后端岗笔试一共是 20 道选择题 5 道简答题 2 道编程题 2 道 SQL 题 1 道系统设计题限时 120 分钟。从题量上就能看出平均单题时间不到 4 分钟这对审题速度和答题节奏要求很高。我记得当时考场里不少人前 40 分钟就耗在选择题上后面的大题只能潦草写几句这基本等于放弃了一半分数。选择题里又分单选和多选多选是重灾区因为漏选、错选都不得分。这类题覆盖了 Java 集合、并发、JVM、Spring、MySQL、Redis、网络协议这些后端高频考点出题风格偏“概念辨析”比如给一段代码问输出结果或者给一个场景判断哪个方案更合适。简答题的考察方向比较固定主要集中在并发编程、JVM 内存模型、Spring 核心原理、MySQL 索引和事务隔离级别这五个方向。编程题比较友好一道链表操作、一道多线程协作难度约等于力扣中等偏下更看重你能不能写出逻辑正确、边界完整的代码。SQL 题是订单表多表联查和索引优化系统设计题则是“家电促销秒杀活动”的高并发方案设计这道题最贴合格力的业务场景也是拉开分数差距的关键。1.2 各题型占比与得分策略我用一张表把这套题的题型分布、分值占比和推荐用时整理了出来备考阶段可以直接按这个比例来训练。题型题量分值占比推荐用时失分风险点选择题20题约30%25分钟多选题漏选、错选简答题5题约20%25分钟只写结论不写原理编程题2题约25%30分钟边界条件不完整SQL题2题约15%20分钟关联条件写错、索引不加系统设计题1题约10%20分钟没有分层思路、只说一个方案这个时间分配是我后来复盘时算出来的。选择题虽然分值不高但它是基础分的“基本盘”优先用排除法快速锁定答案遇到纠结的多选先标记、不恋战。简答题要按“结论 原理 举例”的结构写比如问“volatile 的作用”不能只答“保证可见性”要把 happens-before、内存屏障、禁重排这几个点都带上。编程题先写核心逻辑再补边界时间不够也要把思路注释写清楚阅卷人通常会给步骤分。系统设计题要体现分层架构从流量入口到数据库逐层拆解哪怕方案不够完美也要让阅卷人看到你有全局视野。2. Java基础与并发编程核心题目解析2.1 集合框架高频题HashMap 底层原理这套选择题里关于 HashMap 的考察就没少过而且问得很细。比如“JDK 1.8 中 HashMap 在什么条件下链表会转红黑树”答案是链表长度达到 8 且数组长度达到 64如果数组长度不足 64会优先扩容而不是转树。这里很多人只记得“长度达到 8”这一半把“数组长度达到 64”漏掉多选题刚好就错在这里。HashMap 的 put 流程也是简答题的热门候选先对 key 做 hash 扰动也就是将高 16 位与低 16 位做异或降低哈希碰撞概率然后通过(n - 1) hash定位到数组下标如果该位置为空直接插入否则遍历链表或红黑树存在相同 key 就覆盖旧值当链表长度超过阈值且数组长度满足条件时转红黑树。扩容时默认容量是 16负载因子 0.75每次扩容为原来的两倍。我当时把扩容后节点“高位移动”的规律写成了一段注释因为这一步特别容易疏漏JDK 1.8 扩容后节点要么留在原位置要么移动到“原位置 旧容量”的位置判断依据是新增的那一位 hash 值是 0 还是 1。如果面试/笔试中你能写出这个细节阅卷人一般会认为你是真的读过源码。还要提一下 ConcurrentHashMap因为并发场景下它是 HashMap 的替代方案。JDK 1.7 时代用的是分段锁把数据分成多个 Segment每个 Segment 一把锁JDK 1.8 改成 CAS synchronized 锁链表头节点粒度更细。笔试里经常拿它和 Hashtable 对比Hashtable 是全局锁并发度低ConcurrentHashMap 的并发度远高于它。这个对比题不难但很多人把“分段锁”和“CASsynchronized”混在同一个版本里说这是不准确的。2.2 并发与JVM经典题volatile、synchronized 与线程池参数简答题里有一道经典题volatile 和 synchronized 的区别。标准答法是从三个维度展开一是作用volatile 保证可见性和有序性synchronized 保证原子性、可见性和有序性二是使用方式volatile 修饰变量synchronized 修饰方法或代码块三是底层实现volatile 通过内存屏障和禁止指令重排实现synchronized 通过 Monitor 锁实现。如果只写“volatile 是轻量级的 synchronized”这种答案基本拿不到一半分。线程池参数的考察方式是给一个 ThreadPoolExecutor 构造方法让你写出 corePoolSize、maximumPoolSize、keepAliveTime、workQueue、threadFactory、RejectedExecutionHandler 分别代表什么然后描述任务提交后的完整执行流程。这个流程是核心线程数未满时直接创建核心线程执行任务核心线程数满了任务进入阻塞队列队列满了创建非核心线程执行任务非核心线程也满了触发拒绝策略。拒绝策略有四种AbortPolicy 直接抛异常、CallerRunsPolicy 调用者线程执行、DiscardPolicy 静默丢弃、DiscardOldestPolicy 丢弃队列头部的老任务。笔试里容易考的是“队列用的是无界队列时maximumPoolSize 参数是否会生效”——不会因为无界队列永远不会满非核心线程永远不会被创建。这个坑我当年就踩过。JVM 方面考了一道内存区域划分程序计数器、虚拟机栈、本地方法栈、堆、方法区。其中堆是对象分配的主要区域方法区存类元信息、常量、静态变量虚拟机栈存局部变量表、操作数栈、动态链接和方法出口。还顺带考了“哪些区域会发生 OutOfMemoryError”堆、方法区、虚拟机栈都会程序计数器是唯一不会 OOM 的区域。G1 收集器的特点也是选择题常客它是分区的、可预测停顿时间的垃圾收集器把堆划分为多个 Region通过维护优先列表来跟踪回收价值高的 Region。2.3 简答题实战模拟与答题模板我把这套笔试里出现过的简答题整理成了一个小清单建议备考时直接拿来自测每题控制在 5 分钟内写完描述 volatile 的底层实现原理。解释 JVM 中类加载的双亲委派机制。说说 Spring IOC 和 AOP 的理解。MySQL 的 InnoDB 为什么用 B 树而不是 B 树或红黑树如何理解 Redis 的持久化机制RDB 和 AOF 各自优缺点答题时我有一个经验不要把简答题当成“名词解释”来写而要当成“给同事讲方案”来写。比如双亲委派机制先一句话说清定义再说三个类加载器分别是启动类加载器、扩展类加载器和应用类加载器然后说加载流程是自底向上检查、自顶向下加载最后强调这样做的好处是避免核心类被重复加载和篡改。这样层次分明阅卷人扫一眼就能抓到踩分点。3. 数据库与Spring生态题目拆解3.1 SQL题多表联查与索引优化SQL 题给了一个家电销售系统的简化场景三张表用户表 users、订单表 orders、商品表 products。第一问是“统计 2020 年 9 月下单次数最多的前 3 位用户输出用户名和下单次数”。比较稳的写法是SELECT u.user_name, COUNT(o.id) AS order_cnt FROM users u JOIN orders o ON u.id o.user_id WHERE o.create_time 2020-09-01 00:00:00 AND o.create_time 2020-10-01 00:00:00 GROUP BY u.id, u.user_name ORDER BY order_cnt DESC LIMIT 3;第二问在此基础上加了难度在订单表里查“同时购买过商品 A 和商品 B 的用户 ID”。我的做法是先分别筛出购买过 A 和 B 的用户集合再取交集SELECT a.user_id FROM ( SELECT DISTINCT user_id FROM orders WHERE product_id A ) a JOIN ( SELECT DISTINCT user_id FROM orders WHERE product_id B ) b ON a.user_id b.user_id;这道题的考点不在 SQL 本身而在你会不会建索引。正确的做法是在 orders 表的(user_id, create_time)上建联合索引因为 WHERE 条件里 user_id 用于等值匹配、create_time 用于范围筛选联合索引能同时命中这两个条件。product_id 单独建索引即可。如果直接在 create_time 上建单列索引过滤效果会差很多。很多人不写索引直接交卷这一小问分数就丢了。3.2 Spring与MyBatis高频考点Spring 相关考了 IOC 和 AOP 的概念还深入问到了 Bean 的作用域。单选题里让你选出“默认作用域”正确答案是 singleton。但题目如果换个问法“哪些作用域下每次获取都会创建新对象”那就要选 prototype。剩下 request、session、application 都是 Web 容器相关笔试里出现的频率相对低一些。另一个高频点是 Spring 事务的传播行为尤其 REQUIRED 和 REQUIRES_NEW 的区别。REQUIRED 是默认值如果当前存在事务则加入当前事务不存在则新建事务。REQUIRES_NEW 是无论如何都新建一个事务外层事务挂起内层事务独立提交或回滚。经典的场景是“记录日志”功能即使主业务失败日志也不能丢这时就要用 REQUIRES_NEW。这道题格力笔试的简答题里出现过我当时答了定义还顺手画了个嵌套调用的示意图虽然画得不标准但把“内层事务独立提交”这个点写清楚了。MyBatis 考察了#{}和${}的区别。#{}是预编译占位符最终通过PreparedStatement的setString等方法传参能有效防止 SQL 注入${}是字符串拼接直接把值拼接到 SQL 中有注入风险。但${}也不是完全不能用动态表名、排序字段这类无法用占位符的地方只能用${}关键是必须自己控制输入值。这个考点如果写成“尽量用 #{}、避免 ${}”只能算半对要说出${}的正确使用场景才能拿全分。3.3 从若依框架看企业级项目中的权限与前端分离这套题虽然没有直接考若依框架但有一道选择题涉及了“前后端分离模式下如何进行身份认证”。当时的四个选项里有 Session、Cookie、JWT、OAuth2正确答案是“以上都可以但常见做法是 JWT 或 OAuth2”。这道题其实反映了制造业技术栈的一个趋势——很多企业级项目已经在用若依这类前后端分离框架了。若依后端基于 Spring Boot Spring Security JWT前端用 Vue后端接口通过拦截器校验 TokenRedis 里存登录用户信息和权限数据。备考后端岗时容易被忽略的一点是“前后端分离后后端需要面对跨域问题”。如果你熟悉若依这类框架就会知道后端要通过 CORS 配置或网关统一处理跨域而不是在每个 Controller 里重复加注解。面试官考察的其实是你的项目经验是真实深入的还是只停留在 Demo 层面。能在笔试里结合框架谈几个实际场景比如接口鉴权、跨域处理、验证码生成都会让阅卷人觉得你是真正碰过项目的。4. 编程题与实战手写题4.1 链表反转的两种解法编程题第一题是“单链表反转”函数签名给的是public ListNode reverseList(ListNode head)。这道题算是后端笔试题里的“老朋友”了但每次都能筛掉不少人。我给出的第一种解法是迭代法public ListNode reverseList(ListNode head) { ListNode prev null; ListNode curr head; while (curr ! null) { ListNode next curr.next; curr.next prev; prev curr; curr next; } return prev; }这段代码的关键是把curr.next先存下来再翻转否则链表会断。很多人第一反应是递归写法递归到最后一个节点然后从后往前翻转指针但递归的空间复杂度是 O(n)迭代是 O(1)。笔试阅卷时这两种都能拿分但如果你能在注释里写出“迭代法空间复杂度 O(1)”这个点会显得更有代码意识。4.2 Top K 高频元素优先队列的正确使用编程题第二题是“给定一个非空整数数组返回前 K 个高频元素”。比如数组是[1,1,1,2,2,3]K2输出[1,2]。这道题考察的是 Map 堆的组合用法时间复杂度可以做到 O(n log k)。核心代码如下public int[] topKFrequent(int[] nums, int k) { MapInteger, Integer countMap new HashMap(); for (int num : nums) { countMap.put(num, countMap.getOrDefault(num, 0) 1); } PriorityQueueInteger heap new PriorityQueue( (a, b) - countMap.get(a) - countMap.get(b) ); for (int key : countMap.keySet()) { heap.offer(key); if (heap.size() k) { heap.poll(); } } int[] result new int[k]; for (int i 0; i k; i) { result[i] heap.poll(); } return result; }这里有一个细节优先队列默认是小顶堆所以用“当堆大小超过 k 时移除堆顶”的策略最后留在堆里的就是频率最高的 k 个元素。如果误用大顶堆或者没控制堆的容量上限复杂度就会退化。笔试环境里不一定能跑代码验证逻辑所以我通常会把 HashMap 的统计流程、堆的容量控制都写成注释这样即使代码有小问题阅卷人也能看出思路是对的。4.3 多线程协作三个线程交替打印有一道附加的并发编程题不是必做但我做了三个线程分别打印 A、B、C循环 10 次要求输出顺序是 A、B、C、A、B、C……我用的是ReentrantLock配合Condition实现因为Condition可以精准唤醒指定线程比wait/notifyAll可控性高很多。ReentrantLock lock new ReentrantLock(); Condition conditionA lock.newCondition(); Condition conditionB lock.newCondition(); Condition conditionC lock.newCondition(); // 每个线程循环10次轮到自己的时候打印然后唤醒下一个线程写这道题时有三个容易扣分的点一是打印完成后必须finally里释放锁二是要用while而不是if来判断是否轮到自己防止虚假唤醒三是三个 Condition 的顺序不能搞错最好用变量维护当前轮次。这类题考察的不只是 API 熟练度更是并发编程的严谨性。5. 系统设计与实际业务场景题5.1 家电促销秒杀活动的高并发方案这套笔试题的最后一道系统设计题场景是一个空调品牌的限时秒杀活动预计瞬间流量是平时流量的几十倍要求设计一个可落地的后端方案。这道题非常典型基本就是把电商高并发场景的核心考点都覆盖了我当时用了“分层削峰”的思路来答。第一层是前端限制秒杀按钮点击一次后立即置灰防止用户疯狂点击配合验证码或滑块拉长请求间隔。第二层是网关与接口限流用 Redis Lua 实现令牌桶或滑动窗口限流把超过阈值的请求直接返回“排队中”。第三层是库存预扣先把商品库存加载到 Redis下单时用DECR原子扣减库存扣减成功才允许创建订单。第四层是异步处理订单创建的请求丢进消息队列后端服务异步消费削峰填谷数据库只承受削峰后的写流量。最后一层才是数据库兜底用乐观锁UPDATE ... WHERE stock 0防止超卖同时在订单表加唯一约束防止重复下单。这道题里最容易踩的坑是“直接把库存扣减放在数据库里”。如果每秒上万个请求同时打在主库上行锁竞争会让数据库 CPU 直接打满。我当时的答题策略是先写清楚 Redis 预扣库存的流程再说明 MQ 异步落库的必要性最后补充了一句“秒杀接口要做接口幂等同一个用户同一场活动最多只能下单一次”这样整套方案的闭环就出来了。5.2 接口幂等与分布式锁的实现思路系统设计题里有一道交叉考察的小问秒杀场景下用户疯狂点击导致重复下单怎么从后端保证接口幂等这个问题的标准解法是 token 机制用户进入秒杀页面时后端先生成一个唯一 token 存到 Redis用户提交订单时必须携带这个 token后端先检查 token 是否存在存在则删除并继续下单不存在则直接返回“请勿重复提交”。因为 Redis 的单线程特性GET DEL可以保证原子性老版本 Redis 需要用 Lua 脚本保证两步操作原子完成。另一种方案是用数据库唯一键兜底比如订单号直接使用“用户 ID 活动 ID 时间戳”的拼接结果在订单表上建唯一索引重复插入会直接报错。这个方案实现简单但依赖数据库不适合作为唯一防线。如果题目继续深挖分布式场景还可以用 Redisson 的分布式锁把“查询库存、扣减库存、创建订单”这三个操作包在一个锁里但我那次答题时优先写了 Redis 预扣库存 唯一键约束没有上分布式锁因为这套组合对秒杀场景已经足够。5.3 结合实际业务智能设备数据上报接口设计有一道选择题给了一个场景“空调设备每隔 30 秒上报一次运行状态后端需要存储并支持最近 7 天的按小时聚合查询怎么设计存储方案”备选方案里有 MySQL 单表、MySQL 按月分表、HBase、Redis。直觉上很多人会选 HBase因为它适合海量时序数据但结合格力这类企业的实际场景如果上报量可控、查询模式固定MySQL 按月分表 定时汇总表也完全够用而且运维成本低很多。这道题想考察的不是“哪个数据库最强”而是“在给定业务体量下会不会做技术选型”。我当时答的时候多写了一句设备上报接口本质上是一个写入多、读取少、实时性要求高的场景可以在应用层加一个内存队列批量写入数据库减少频繁的数据库连接开销同时利用定时任务把明细数据聚合成小时维度的汇总表查询层只查汇总表。这个思路其实和 CEP、时序数据库的思想很接近虽然当时我还不了解这些概念但“聚合 预计算”的套路在后端设计里是通用的。6. 复盘心得与备考建议6.1 做题时踩过的坑和复盘复盘这套题时我发现几个典型的失分点值得单独提醒。第一个是选择题里“多选漏选”的问题比如关于 ConcurrentHashMap 的正确描述里“JDK 1.8 使用分段锁”和“JDK 1.8 使用 CAS synchronized”这两项放在一起很多人两个都选了但前者是 JDK 1.7 的实现正确选项只有一个。这类坑在基础题里特别常见因为它考察的不是“你知道这个知识点”而是“你知道知识点的版本演进”。第二个坑是 SQL 题没有写索引或者写了但建错字段。我见过一个同学把索引建在了orders.create_time上但查询条件是user_id ? AND create_time BETWEEN ? AND ?这种写法只会在 create_time 上走索引user_id 的过滤是在回表后做的效率远不如联合索引(user_id, create_time)。笔试没法通过执行计划验证所以全靠平时的索引优化经验。说到底SQL 题不只考语法更考执行计划思维。第三个坑是编程题的边界条件。链表反转那题如果输入是空链表或只有一个节点代码要能直接返回空或原链表Top K 那题如果 K 大于数组长度堆的容量逻辑也要兼容。这些边界条件不用在笔试环境里跑测试用例但注释里写清楚会显得你经验老到。6.2 针对后端岗笔试的复习路线如果你准备的时间比较紧我建议按“Java 集合与并发 → JVM → MySQL → Spring → 项目场景题”这条线来走和这套笔试的侧重点基本一致。Java 集合重点盯 HashMap、ConcurrentHashMap、ArrayList/LinkedList并发重点盯 volatile、synchronized、ReentrantLock、线程池、ThreadLocalJVM 重点盯内存区域、类加载、GCMySQL 重点盯索引、事务隔离级别、MVCC、explainSpring 重点盯 IOC、AOP、事务传播行为、Bean 生命周期。Redis 和消息队列是加分项但优先级没前面高。如果时间充裕再补一补分布式锁、缓存一致性、接口幂等这些场景题。最后想说各大论坛上流传的所谓“标准答案”只能帮你应付选择题真正拉开差距的其实是简答题和系统设计题里体现出的工程思维。拿到题目先别急着写花 30 秒在草稿纸上列一下答题框架比闷头写一堆零散要点要强得多。我当年在系统设计题里就是把流程图草稿画在卷子空白处再把每一个环节从前到后串起来写最后这道题拿到了不错的分数。