格力后端笔试全解析：Java、MySQL与场景设计题备考指南

1. 格力的后端笔试题，到底在选什么样的人

先交代一下背景。2020年秋季招聘，格力作为制造业头部企业，开启了规模不小的数字化人才招募，后端开发岗是其中核心方向之一。当年这波笔试在牛客和各类校招群里流传度很高，原因倒不是题目有多难，而是这份卷子非常“制造业+数字化转型”的混合气质——既没有互联网大厂那种动辄hard级算法的下马威，也不是传统软件公司那种纯背八股文的套路卷，它在基础能力、工程习惯和业务理解之间找平衡，筛的是“能直接干活的人”。

如果你正在准备制造业或泛工业领域的后端校招，这份笔试题非常有参考价值。

先说结论：格力这类制造业巨头的后端笔试，重点不在“谁更聪明”，而在“谁的底子更扎实、谁更靠谱”。原因很简单，制造业的信息化系统有大量真实业务约束——生产计划、库存台账、设备数据接入、经销商订单流转，这些场景对稳定性和数据一致性的要求远高于对花哨架构的需求。笔试出题时不会像互联网大厂那样疯狂堆算法和系统设计深度，而是用更务实的方式考察一个应届生能不能理解业务、能不能把基础知识落到实际场景里。

2020年这波秋招的岗位方向也能佐证这一点。当时格力正在大力推进智能家居、工业互联网和电商渠道的数字化，后端岗位既要支撑传统的ERP、MES类业务，也要兼顾IoT设备接入、电商订单、售后服务平台等新方向。这种复合背景决定了笔试题的覆盖面会比较广，但每块难度都控制在“本科阶段认真学就能答出来”的范围内。

1.1 制造业后端和互联网后端，考察偏好有明显差异

互联网后端笔试偏爱考高并发、分布式、缓存一致性这类架构题，因为业务体量摆在那里，每秒几万请求是常态。但制造业后端很多系统的并发量其实没那么夸张——工厂车间的工单系统、经销商管理系统、售后工单平台，日活在几千到几万不等。真正让人头疼的是业务逻辑复杂、数据链条长、异常场景多，比如一台空调从生产入库到经销商提货再到用户安装，中间涉及库存锁定、物流单、结算单多个环节，任何一个环节数据不一致都会引发连锁问题。

所以你会发现，格力的笔试题里不太会出现“设计一个支撑双十一秒杀的系统”或“单机百万连接的IM架构”这类问题，反而更可能出现“订单状态流转时如何保证数据一致性”“并发下单时如何防止超卖”这类贴近真实业务的问题。备考时如果还按照互联网大厂的高并发八股文路子去准备，方向就偏了。

1.2 从笔试题能反推技术栈：Java系为主，Spring生态是主力

结合当年各渠道流传的题目复盘，格力的后端笔试明显偏向Java技术栈，Spring Boot/Spring Cloud相关的题目占了不小比例，数据库方面MySQL是绝对主流，Redis和消息队列也有涉及。这符合国内制造业信息化的普遍现状：Java生态成熟稳定、人才供给充足、适合复杂业务系统的长期维护。

具体到题目类型，大致可以分成四块：基础选择题、简答题、编程题、场景设计题。下面我按实际笔试的答题逻辑，逐块拆解，每块都会结合当年的高频题目和踩坑经验来讲。

2. 题型全览与答题顺序：笔试第一步是战术，不是知识

很多人拿到卷子就开始埋头做题，这个习惯在校招笔试里很吃亏。特别是格力的题量不算小，选择题约20道、简答题4到6道、编程题2到3道、场景设计题1到2道，总时长一般120到150分钟。如果你按试卷顺序从前做到后，很可能会在前面纠结太久，把后面分值更高的设计题挤得没时间写。

2.1 先花3分钟分配时间，再开始答题

我当年做这类笔试题的习惯是：先快速扫一遍全部题目，把每道题的分值和预估用时写在草稿纸上，然后按“先易后难、先高分后低分”的顺序作答。具体建议如下：

注意最后一条的优先级有点反直觉：场景设计题虽然排最后，但你必须在扫题环节就判断它是否好写。如果看到一道“设计一个设备数据上报系统”的题目，而你恰好对这类场景有积累，那就直接跳到这道题先做，因为这类题主观性强，写得好不好有比较大的发挥空间，性价比很高。相反，编程题如果一看就是要用复杂动态规划或高级数据结构，先放一放，不要死磕。

2.2 选择题的高频失分点：不是不会，是“想太多”

选择题是基础分的保证，正常情况应该拿到80%以上正确率。但很多同学偏偏在选择题上翻车，原因不是没复习到，而是被干扰项带着走。举几个当年出现过的典型陷阱类型：

第一类是“看似正确但表述绝对化”的选项。比如考察Java异常处理的题目，选项里出现“finally块中一定不能有return语句”这种绝对化表述，基本可以直接排除。虽然finally块中写return确实会吞掉异常，但语言本身没有禁止，只是不推荐，所以不能选“不能”。

第二类是“概念混淆型”选项。比如考察线程池参数，会把核心线程数和最大线程数的默认值调换，或者把饱和策略的触发条件搞混。这类题要求你不仅记住参数值，而且要理解它们在什么时机生效。说实话，这类题做错不是因为你记性差，而是因为你只背了结论，没推演过过程。后面第3章我会用一个典型例子详细拆解。

第三类是“版本差异陷阱”。比如HashMap在JDK 7和JDK 8中的数据结构变化，问“链表在什么条件下转红黑树”，如果对版本差异不够敏感，很容易选错。格力2020年笔试就出现过类似题目，考察的是HashMap在JDK 8中链表长度到8且数组长度到64时才转红黑树，两个条件缺一不可。

建议的答题策略是：一眼能确定答案的直接选，不确定的先跳过，全部做完后再回来推敲。不要在单题上超过1分钟，选择题总时长必须控制在30分钟以内，否则后面大题会被严重压缩。

3. Java与并发基础：这部分不能靠“背答案”过关

Java是格力后端岗的核心语言，笔试中占比最大的基础题几乎都围绕Java展开。但值得注意的是，2020年这波题目对Java基础的考察并不是简单的知识点复述，而是更偏向“理解原理并能说明为什么”的层次。比如考集合类会问“HashMap为什么线程不安全”、考并发会问“线程池参数应该怎么设”，这些题没有标准死答案，但答得好不好一眼就能看出你是背的还是懂的。

3.1 线程池参数这道题，怎么答出“用过的人”的感觉

线程池相关题目在制造业后端笔试里出现频率极高，格力也不例外。常见问法有两种：一种是直接问“ThreadPoolExecutor的核心参数有哪些，分别是什么作用”，另一种是给场景问“线程池参数怎么设置”。

简单说下参数：核心线程数（corePoolSize）、最大线程数（maximumPoolSize）、空闲线程存活时间（keepAliveTime）、阻塞队列（workQueue）、线程工厂（threadFactory）、拒绝策略（handler）。背出来不难，但大多数人栽在“参数怎么设”上。

我当时答题的思路是这样：先说清楚两个关键参数的关系——**当提交的任务数大于核心线程数且队列未满时，新任务会进入队列等待，而不是直接创建新线程；只有当队列也满了，才会继续创建线程直到最大线程数；如果达到最大线程数还有任务进来，才触发拒绝策略。**这个过程必须表述准确，因为它直接决定线程池的实际行为。

然后针对场景设计参数时，我会分情况讨论：

• CPU密集型任务：核心线程数设为CPU核数+1，队列用有界队列，避免无限堆积。
• IO密集型任务：核心线程数可以设到CPU核数的2倍甚至更高，因为线程大部分时间在等待IO，可以多开线程提高吞吐。
• 混合型任务：看哪个占比高，或拆成两个线程池分别处理。

最后一定要带上一句：**“参数没有绝对标准，必须结合业务的并发量、任务耗时和可接受的排队时间来确定，而且要压测验证。”**这句话能让阅卷人看到你是有工程思维的，而不是只会背书。实际上，这个题在面试环节被追问的概率也很高，我认识有同学笔试题写了“根据场景灵活设置”，面试时就被考了“如果任务平均耗时500ms，QPS峰值为200，核心线程数怎么估算”——这类问题你现场推一下得出结果，远比背参考答案更让人信服。

3.2 集合类源码题：HashMap的线程不安全点在哪里

格力笔试中集合类考得最多的是HashMap，尤其是它线程不安全的表现和原因。这题常见但不简单，因为需要你理解HashMap的内部结构才能讲明白。

HashMap线程不安全主要体现在三个地方：

1. **JDK 7及以前，扩容时多线程并发put可能导致环形链表，get时出现死循环。**原因是扩容采用头插法，并发转移元素时链表顺序会反转，形成闭环。
2. **JDK 8以后头插改为尾插，死循环问题解决了，但并发put仍可能导致数据覆盖。**比如两个线程同时算得同一个数组下标，都执行到插入位置，后写的会把先写的覆盖掉。
3. **size字段不是原子性的，并发操作时Map的元素个数统计不准确。**这个很多人容易忽略，但它确实是线程不安全的体现之一。

答题时我建议先讲清楚这个演进过程，再点出核心结论：**HashMap设计上就不是给并发场景用的，并发场景应该用ConcurrentHashMap。**然后可以补充ConcurrentHashMap的实现差异：JDK 7用分段锁（Segment继承自ReentrantLock），JDK 8改为CAS+synchronized锁Node节点，锁粒度更细，并发性能更好。

这种答法的好处是把“背结论”和“理解过程”区分开了。阅卷人看到的不是一个只会说“HashMap线程不安全”的候选人，而是一个能讲清楚“为什么不安全、怎么演进、替代方案是什么”的候选人。注意，笔试答题不是面试，不用展开太多，但关键脉络必须完整。

3.3 synchronized和ReentrantLock的区别，不要只背表格

这道题几乎每次笔试都会出现，但大部分答案都停留在“synchronized是关键字、ReentrantLock是类”“synchronized自动释放锁、ReentrantLock要手动释放”这种表格对比上。这样答没毛病，但太平了，拉不开差距。

更有价值的答法是把视角放在“JDK 6之后synchronized经历了什么”上。JDK 6对synchronized做了大量优化，引入了偏向锁、轻量级锁、重量级锁的升级过程，锁的粒度从无锁到偏向锁、再到轻量级锁、最后到重量级锁。在低竞争场景下，synchronized的性能已经不输ReentrantLock，而且它使用更简单、不容易出错。

那ReentrantLock还有什么存在的意义？答案是它的功能更丰富：

• 支持公平锁和非公平锁，synchronized只能是非公平的；
• 支持尝试获取锁（tryLock）和超时获取锁，这在实际业务中非常有用；
• 支持多个条件变量（Condition），可以用更细的粒度控制线程的等待和唤醒。

回答时把这些点串成一个逻辑链：**为什么有了synchronized还需要ReentrantLock？因为需求多样性，有了多样化的工具才能应对复杂的并发控制场景。**如果再结合一个实际案例，比如“使用tryLock避免多线程竞争时长时间阻塞”，这题的答案就很完整了。

4. 数据库与场景设计题：真正拉开差距的地方

数据库是后端笔试的另一座大山，尤其是MySQL。格力这份题里，数据库相关的分值占比肉眼可见地高，而且简答题和场景设计题往往围绕数据库展开。原因不复杂——制造业业务系统里，数据是核心资产，而MySQL是绝大多数中小型系统的存储底座。哪怕你Java写得再漂亮，数据库设计不合理、SQL写得烂，系统一样跑不起来。

4.1 索引失效类题目：别死记“最左前缀”，要理解B+树的行为

索引题几乎是MySQL笔试的必考项，格力2020年的卷子里出了不少。常见问法是“以下SQL哪些能用到索引，哪些会失效，为什么”，选项设计得很刁钻，专门挑那些“看似能用但实际用不上”的写法当干扰项。

失效场景我就不一一列举了，大家应该都背过：对索引列使用函数、隐式类型转换、前导模糊查询、OR连接非索引列、在索引列上做计算等。但有一个问题——**如果你只背场景，换个问法就懵了。**比如“为什么对索引列使用函数会导致索引失效？”这时候你需要理解B+树的索引结构。

B+树的索引是有序排列的，存储的是列的实际值。当你对列使用函数时，比如WHERE DATE(create_time) = '2024-01-01'，数据库需要在每个索引值上先执行函数再比较，函数的返回值是无序的，B+树有序索引的优势就没了，优化器只能放弃索引扫描改走全表。同理，隐式类型转换本质上也是让列参与了一个函数操作。

理解到这一层，哪怕题目怎么变，你都能判断出来。我建议在备考时不要只背“口诀”，而是每次遇到索引题都问自己一句：**这个条件下B+树还能不能保持有序地定位到目标数据？**这样做的效果远好于背二十条失效规则。

4.2 场景设计题：像“设备数据上报”这种题，怎么答出层次感

格力2020年秋招笔试里有一道很有代表性的场景设计题：**“工厂有大量设备，设备会定时上报运行状态数据，高峰时每秒上报数千条数据。请设计一个数据接收和存储方案。”**这种题没有标准答案，考察的是综合分析能力和业务理解。

我当时答题时把方案拆成了四层：

第一层是接入层。设备数据上报需要一个统一的HTTP接口或MQTT网关，接口要做到幂等，因为网络不稳定时设备会重试，同一份数据可能被发送多次。幂等的实现可以用唯一请求ID+数据库唯一索引来处理。

第二层是削峰层。几千条每秒的写入量，如果直接压进MySQL，虽然勉强能扛，但会让业务查询变慢，尤其当数据持续堆积时。所以中间加一个消息队列（如Kafka或RocketMQ）做缓冲，消费端异步写入数据库，削峰填谷，同时利用队列的重试机制保证数据不丢。

第三层是存储层。设备运行数据时序性很强，可以按天分表，以设备ID和时间戳作为联合索引。高频查询场景是用设备ID查某个时间段的数据，加一个时间范围条件能有效利用索引。如果有条件，冷数据可以定期归档到单独的库或转为文件存储，避免单表数据量过大。

第四层是数据一致性保障。消息队列可能重复消费，所以消费端要做幂等处理，方案可以是利用数据库的唯一索引，或者在业务表里加一个“上报记录ID”的字段，消费时先查重再插入。另外，如果设备数据影响生产决策，还需要监控消费积压，积压超过阈值就告警。

这四层写下来，体现的不只是知识储备，更是对真实业务场景的打法理解。笔试题里遇到这类系统设计的问题，框架感很重要，先给一个整体流程，再逐一填充细节，比想到哪写到哪强得多。

4.3 事务隔离级别与并发状态更新：别把“默认”当“正确”

事务隔离级别也是数据库部分的常客。MySQL默认是REPEATABLE READ（可重复读），Oracle默认是READ COMMITTED，这个考点本身不难，但结合业务场景时很多人容易答偏。

格力笔试出现过类似问题：**“一个订单系统，多个用户并发修改同一个订单的状态，如何避免更新丢失？”**这题考察的是事务隔离级别和锁机制的综合应用。

首先要明确，MySQL的REPEATABLE READ虽然解决了不可重复读问题，但不能完全避免更新丢失。两个事务同时读取到同一版本的数据，然后各自修改并提交，后提交的会覆盖先提交的结果。解决办法有几种：

一是使用SELECT ... FOR UPDATE给数据行加锁，这是悲观锁思路，简单可靠但并发性能一般。

二是使用乐观锁，在订单表加version字段，更新时带上WHERE version = 当前版本号，如果影响行数为0，说明版本冲突，需要重试。这个方案并发性能更好，也是实际业务中常见做法。

三是用原子更新语句，比如UPDATE order SET status = 'PAID' WHERE order_id = ? AND status = 'UNPAID'，让数据库在单条语句内完成判断和更新的原子操作。这种方式不需要额外字段，但对状态流转复杂的场景不适用。

答题时最好把这三种方案都列出来，然后指出各有利弊，根据实际业务选择。这种“给出多个方案+分析取舍”的答法，比只推荐一种更能体现工程能力。

5. 算法题：中档题的稳定性比难题的突破更值钱

格力后端笔试的算法题难度，整体定位在LeetCode Easy到Medium之间，偶尔出现一道接近Medium偏上的动态规划或双指针题。相比互联网大厂，这个难度对非竞赛型选手相当友好。但友好不意味着能拿满分，很多人折在不是“不会做”，而是“会做但没做完”或“做出来了但细节错”。

5.1 拿到一道编程题，先做这三件事

第一件事：不要急着写代码，先读三遍题目，确认输入输出格式和边界条件。校招笔试的编程题经常在边界上埋坑，比如数组可能为空、链表可能只有一个节点、字符串可能包含空格。这些情况考虑不全，代码再正确也过不了全部用例。

第二件事：估一下数据范围，判断解法是否可行。如果数组长度是10^5，那O(n^2)的暴力法会超时，必须想O(n)或O(nlogn)的解法。如果长度是100以内，暴力法完全够用，没必要想复杂解法。这个判断要在30秒内完成。

第三件事：写之前先想好测试用例，至少想一个普通场景、一个边界场景、一个极端场景，代码写完立刻用这三个用例自测。很多人在笔试环境里不敢花时间做测试用例，觉得浪费时间，实际情况是——写完后编译通过但逻辑错误，反而要花更多时间调试。

5.2 一道有代表性的动态规划题：从暴力递归到状态定义

2020年格力的算法题里有一道版本流传较广的题目，变体很多，大概是“给定一个整数数组，找出一段连续子数组，使其和最大，返回这个最大值”。这是经典的“最大子序和”问题。

很多人在笔试中第一反应是暴力双重循环，把所有子数组的和都算一遍。这个解法在数据量小的时候没问题，但如果数组长度较大就会超时。更优的解法是动态规划，状态转移方程是：dp[i] = max(dp[i-1] + nums[i], nums[i])，其中dp[i]表示以第i个元素结尾的子数组的最大和。这样一次遍历就能得出结果，时间复杂度O(n)，空间复杂度可以优化到O(1)。

笔试时如果你能写出这个解法，已经超过了大多数候选人。但如果你想在这道题上更亮眼，可以再补一句：如果数组允许为空，需要特殊处理；如果题目要求返回子数组的起始和结束位置，需要用变量记录状态变化的时刻。这种“拿到题先想清楚变体和边界”的习惯，在阅卷时很加分。

5.3 字符串处理题要小心“实现细节”翻车

另一类高频算法题是字符串处理，常见的有反转字符串、判断回文串、字符串匹配等。这类题思路不复杂，但实现细节非常考验基本功。比如反转字符串时是否允许使用额外空间？不允许的话就要用双指针原地交换；判断回文串时是否忽略空格和标点？大小写是否敏感？这些条件不确认清楚，代码写得再漂亮都是白搭。

一个很实用的建议是：笔试编程题里尽量用最直白的解法，不要炫技。能用常规循环解决的问题就不要玩函数式编程，能用数组就不要硬用Map，代码越简单越不容易出bug。毕竟是限时环境，稳定跑通所有用例永远比写一个优雅但容易翻车的解法更划算。

6. 复盘方法：把每次笔试变成下一轮面试的资产

很多同学笔试完就扔到一边，等结果出来才后悔这个没复习、那个没想到。但真正有效的做法是：**每一次笔试结束，不管结果如何，立刻做一次结构化复盘。**笔试题目是面试官亲自出的或精选的，等于他们亲口告诉你“我们重视什么”，这些信息比任何面经都值钱。

6.1 复盘四步法，把笔试题吃干榨净

我的复盘方法分四步。第一步，重做一遍所有错题和不会的题，不看答案，独立推导到得出正确结果。第二步，整理每道题背后的知识点，建立知识点清单，比如“索引失效”这件事，对应的是B+树结构、查询优化器原理、Explain执行计划，把它们关联起来，形成一个知识簇，而不是散点。第三步，针对没答好的题目，预测面试时可能追问的方向，并提前准备好回答。第四步，把这份复盘笔记保存下来，面试前翻一遍，往往会有奇效。

这四步里，第三步最容易被忽略，但其实最值得做。比如你笔试时线程池参数设置题答得不完整，面试官极大概率会追问“如果任务执行中抛异常会怎样”“队列大小怎么定”“拒绝策略选了AbortPolicy会发生什么”。这些问题如果不提前准备，面试现场很容易卡壳。笔试题的本质是面试官给的“考点提纲”，顺着提纲深入准备，效率远高于漫无目的地刷面经。

6.2 从笔试题到面试的衔接：你能讲出来的才真正是你的

有这么一个规律：你在笔试里写的每一句话，都可能在面试中被拎出来反复盘问。如果你写了“使用了Redis缓存热点数据”，面试官一定会追问“缓存和数据库的一致性怎么保证”“缓存穿透和雪崩怎么解决”“如果Redis挂了怎么办”。所以笔试时尽量写自己真正理解的内容，千万不要为了显得厉害而堆砌名词。

这不是说不能写不了解的东西，而是说写了之后要马上补课。每次笔试结束后，凡是出现在自己答案里的技术点，都要能做到“能画图、能举例、能写Demo”的程度。所谓“能画图”，是能画出系统交互流程；“能举例”是能讲出一个真实场景中的应用案例；“能写Demo”是能在本地快速跑通一个小示例。能达到这个标准，笔试答案里的内容才能真正内化成自己的能力。

我自己当年参加校招时，有一道场景设计题里提到了“使用Kafka做削峰”，但其实那时我对Kafka的认识相当浅，只是在博客里看过这种方案。笔试结束后我花了整整两天时间，把Kafka的架构原理、消费者组机制、消息可靠性保障全啃了一遍，并写了一个生产者消费者的Demo跑通。果不其然，那场面试的面试官真的围绕Kafka问了十几个问题，我因为提前补了课，全部答了上来，面试环节直接扭转了笔试的劣势。

所以我的建议是：**从笔试结束的那一刻开始，就把笔试内容当作面试的预演，而不是已经翻篇的过去式。**你在这份卷子上写的每一个字，都可能在面试时成为你的进阶题或送命题，关键看你后续怎么处理。

回想2020年那次格力秋招，我发现最有价值的收获不是最终拿到了什么Offer，而是通过这份笔试题，我重新校准了自己对“后端工程师”这个岗位的认知——技术栈可以迁移，工程思维和解决问题的框架才是核心竞争力。希望这篇文章能帮你少走一些弯路，在笔试题面前不只是“会答”，而是“知道为什么这么答”。