每年秋招季一過后臺(tái)就會(huì)收到一堆備考私信。問得最多的其實(shí)是同一句話“制造業(yè)大廠的后端崗筆試到底難不難、考什么”我手頭一直留著一套格力2020秋招后端崗筆試題的回憶版當(dāng)時(shí)考完就順手把題目和答案整理成了筆記后來復(fù)盤時(shí)發(fā)現(xiàn)很多同學(xué)掛掉的原因根本不是不會(huì)做而是不知道閱卷人到底想考察什么。這篇文章就把整套題的考察邏輯、典型題目、參考答案以及我踩過的坑一次性說清楚。如果你是準(zhǔn)備后端崗筆試、尤其是想投制造業(yè)頭部企業(yè)的同學(xué)這篇對(duì)你應(yīng)該很有參考價(jià)值。先說結(jié)論這套筆試整體偏基礎(chǔ)難度不算“地獄級(jí)”但覆蓋面非常廣。它不像互聯(lián)網(wǎng)大廠那樣會(huì)把算法題拉到 LeetCode Hard而是更看重 Java 基礎(chǔ)是否扎實(shí)、數(shù)據(jù)庫功底是否過硬、并發(fā)場(chǎng)景下能不能寫出靠譜的方案。題型分為選擇題、簡(jiǎn)答題、編程題、SQL 題和系統(tǒng)設(shè)計(jì)題五類兩個(gè)小時(shí)題量不小時(shí)間分配不合理的人很容易在前面選擇題上磨太久后面編程題反而沒時(shí)間寫。1. 整體題型結(jié)構(gòu)與考察邏輯1.1 筆試整體結(jié)構(gòu)與時(shí)間分配格力 2020 秋招后端崗筆試一共是 20 道選擇題 5 道簡(jiǎn)答題 2 道編程題 2 道 SQL 題 1 道系統(tǒng)設(shè)計(jì)題限時(shí) 120 分鐘。從題量上就能看出平均單題時(shí)間不到 4 分鐘這對(duì)審題速度和答題節(jié)奏要求很高。我記得當(dāng)時(shí)考場(chǎng)里不少人前 40 分鐘就耗在選擇題上后面的大題只能潦草寫幾句這基本等于放棄了一半分?jǐn)?shù)。選擇題里又分單選和多選多選是重災(zāi)區(qū)因?yàn)槁┻x、錯(cuò)選都不得分。這類題覆蓋了 Java 集合、并發(fā)、JVM、Spring、MySQL、Redis、網(wǎng)絡(luò)協(xié)議這些后端高頻考點(diǎn)出題風(fēng)格偏“概念辨析”比如給一段代碼問輸出結(jié)果或者給一個(gè)場(chǎng)景判斷哪個(gè)方案更合適。簡(jiǎn)答題的考察方向比較固定主要集中在并發(fā)編程、JVM 內(nèi)存模型、Spring 核心原理、MySQL 索引和事務(wù)隔離級(jí)別這五個(gè)方向。編程題比較友好一道鏈表操作、一道多線程協(xié)作難度約等于力扣中等偏下更看重你能不能寫出邏輯正確、邊界完整的代碼。SQL 題是訂單表多表聯(lián)查和索引優(yōu)化系統(tǒng)設(shè)計(jì)題則是“家電促銷秒殺活動(dòng)”的高并發(fā)方案設(shè)計(jì)這道題最貼合格力的業(yè)務(wù)場(chǎng)景也是拉開分?jǐn)?shù)差距的關(guān)鍵。1.2 各題型占比與得分策略我用一張表把這套題的題型分布、分值占比和推薦用時(shí)整理了出來備考階段可以直接按這個(gè)比例來訓(xùn)練。題型題量分值占比推薦用時(shí)失分風(fēng)險(xiǎn)點(diǎn)選擇題20題約30%25分鐘多選題漏選、錯(cuò)選簡(jiǎn)答題5題約20%25分鐘只寫結(jié)論不寫原理編程題2題約25%30分鐘邊界條件不完整SQL題2題約15%20分鐘關(guān)聯(lián)條件寫錯(cuò)、索引不加系統(tǒng)設(shè)計(jì)題1題約10%20分鐘沒有分層思路、只說一個(gè)方案這個(gè)時(shí)間分配是我后來復(fù)盤時(shí)算出來的。選擇題雖然分值不高但它是基礎(chǔ)分的“基本盤”優(yōu)先用排除法快速鎖定答案遇到糾結(jié)的多選先標(biāo)記、不戀戰(zhàn)。簡(jiǎn)答題要按“結(jié)論 原理 舉例”的結(jié)構(gòu)寫比如問“volatile 的作用”不能只答“保證可見性”要把 happens-before、內(nèi)存屏障、禁重排這幾個(gè)點(diǎn)都帶上。編程題先寫核心邏輯再補(bǔ)邊界時(shí)間不夠也要把思路注釋寫清楚閱卷人通常會(huì)給步驟分。系統(tǒng)設(shè)計(jì)題要體現(xiàn)分層架構(gòu)從流量入口到數(shù)據(jù)庫逐層拆解哪怕方案不夠完美也要讓閱卷人看到你有全局視野。2. Java基礎(chǔ)與并發(fā)編程核心題目解析2.1 集合框架高頻題HashMap 底層原理這套選擇題里關(guān)于 HashMap 的考察就沒少過而且問得很細(xì)。比如“JDK 1.8 中 HashMap 在什么條件下鏈表會(huì)轉(zhuǎn)紅黑樹”答案是鏈表長(zhǎng)度達(dá)到 8 且數(shù)組長(zhǎng)度達(dá)到 64如果數(shù)組長(zhǎng)度不足 64會(huì)優(yōu)先擴(kuò)容而不是轉(zhuǎn)樹。這里很多人只記得“長(zhǎng)度達(dá)到 8”這一半把“數(shù)組長(zhǎng)度達(dá)到 64”漏掉多選題剛好就錯(cuò)在這里。HashMap 的 put 流程也是簡(jiǎn)答題的熱門候選先對(duì) key 做 hash 擾動(dòng)也就是將高 16 位與低 16 位做異或降低哈希碰撞概率然后通過(n - 1) hash定位到數(shù)組下標(biāo)如果該位置為空直接插入否則遍歷鏈表或紅黑樹存在相同 key 就覆蓋舊值當(dāng)鏈表長(zhǎng)度超過閾值且數(shù)組長(zhǎng)度滿足條件時(shí)轉(zhuǎn)紅黑樹。擴(kuò)容時(shí)默認(rèn)容量是 16負(fù)載因子 0.75每次擴(kuò)容為原來的兩倍。我當(dāng)時(shí)把擴(kuò)容后節(jié)點(diǎn)“高位移動(dòng)”的規(guī)律寫成了一段注釋因?yàn)檫@一步特別容易疏漏JDK 1.8 擴(kuò)容后節(jié)點(diǎn)要么留在原位置要么移動(dòng)到“原位置 舊容量”的位置判斷依據(jù)是新增的那一位 hash 值是 0 還是 1。如果面試/筆試中你能寫出這個(gè)細(xì)節(jié)閱卷人一般會(huì)認(rèn)為你是真的讀過源碼。還要提一下 ConcurrentHashMap因?yàn)椴l(fā)場(chǎng)景下它是 HashMap 的替代方案。JDK 1.7 時(shí)代用的是分段鎖把數(shù)據(jù)分成多個(gè) Segment每個(gè) Segment 一把鎖JDK 1.8 改成 CAS synchronized 鎖鏈表頭節(jié)點(diǎn)粒度更細(xì)。筆試?yán)锝?jīng)常拿它和 Hashtable 對(duì)比Hashtable 是全局鎖并發(fā)度低ConcurrentHashMap 的并發(fā)度遠(yuǎn)高于它。這個(gè)對(duì)比題不難但很多人把“分段鎖”和“CASsynchronized”混在同一個(gè)版本里說這是不準(zhǔn)確的。2.2 并發(fā)與JVM經(jīng)典題volatile、synchronized 與線程池參數(shù)簡(jiǎn)答題里有一道經(jīng)典題volatile 和 synchronized 的區(qū)別。標(biāo)準(zhǔn)答法是從三個(gè)維度展開一是作用volatile 保證可見性和有序性synchronized 保證原子性、可見性和有序性二是使用方式volatile 修飾變量synchronized 修飾方法或代碼塊三是底層實(shí)現(xiàn)volatile 通過內(nèi)存屏障和禁止指令重排實(shí)現(xiàn)synchronized 通過 Monitor 鎖實(shí)現(xiàn)。如果只寫“volatile 是輕量級(jí)的 synchronized”這種答案基本拿不到一半分。線程池參數(shù)的考察方式是給一個(gè) ThreadPoolExecutor 構(gòu)造方法讓你寫出 corePoolSize、maximumPoolSize、keepAliveTime、workQueue、threadFactory、RejectedExecutionHandler 分別代表什么然后描述任務(wù)提交后的完整執(zhí)行流程。這個(gè)流程是核心線程數(shù)未滿時(shí)直接創(chuàng)建核心線程執(zhí)行任務(wù)核心線程數(shù)滿了任務(wù)進(jìn)入阻塞隊(duì)列隊(duì)列滿了創(chuàng)建非核心線程執(zhí)行任務(wù)非核心線程也滿了觸發(fā)拒絕策略。拒絕策略有四種AbortPolicy 直接拋異常、CallerRunsPolicy 調(diào)用者線程執(zhí)行、DiscardPolicy 靜默丟棄、DiscardOldestPolicy 丟棄隊(duì)列頭部的老任務(wù)。筆試?yán)锶菀卓嫉氖恰瓣?duì)列用的是無界隊(duì)列時(shí)maximumPoolSize 參數(shù)是否會(huì)生效”——不會(huì)因?yàn)闊o界隊(duì)列永遠(yuǎn)不會(huì)滿非核心線程永遠(yuǎn)不會(huì)被創(chuàng)建。這個(gè)坑我當(dāng)年就踩過。JVM 方面考了一道內(nèi)存區(qū)域劃分程序計(jì)數(shù)器、虛擬機(jī)棧、本地方法棧、堆、方法區(qū)。其中堆是對(duì)象分配的主要區(qū)域方法區(qū)存類元信息、常量、靜態(tài)變量虛擬機(jī)棧存局部變量表、操作數(shù)棧、動(dòng)態(tài)鏈接和方法出口。還順帶考了“哪些區(qū)域會(huì)發(fā)生 OutOfMemoryError”堆、方法區(qū)、虛擬機(jī)棧都會(huì)程序計(jì)數(shù)器是唯一不會(huì) OOM 的區(qū)域。G1 收集器的特點(diǎn)也是選擇題?？退欠謪^(qū)的、可預(yù)測(cè)停頓時(shí)間的垃圾收集器把堆劃分為多個(gè) Region通過維護(hù)優(yōu)先列表來跟蹤回收價(jià)值高的 Region。2.3 簡(jiǎn)答題實(shí)戰(zhàn)模擬與答題模板我把這套筆試?yán)锍霈F(xiàn)過的簡(jiǎn)答題整理成了一個(gè)小清單建議備考時(shí)直接拿來自測(cè)每題控制在 5 分鐘內(nèi)寫完描述 volatile 的底層實(shí)現(xiàn)原理。解釋 JVM 中類加載的雙親委派機(jī)制。說說 Spring IOC 和 AOP 的理解。MySQL 的 InnoDB 為什么用 B 樹而不是 B 樹或紅黑樹如何理解 Redis 的持久化機(jī)制RDB 和 AOF 各自優(yōu)缺點(diǎn)答題時(shí)我有一個(gè)經(jīng)驗(yàn)不要把簡(jiǎn)答題當(dāng)成“名詞解釋”來寫而要當(dāng)成“給同事講方案”來寫。比如雙親委派機(jī)制先一句話說清定義再說三個(gè)類加載器分別是啟動(dòng)類加載器、擴(kuò)展類加載器和應(yīng)用類加載器然后說加載流程是自底向上檢查、自頂向下加載最后強(qiáng)調(diào)這樣做的好處是避免核心類被重復(fù)加載和篡改。這樣層次分明閱卷人掃一眼就能抓到踩分點(diǎn)。3. 數(shù)據(jù)庫與Spring生態(tài)題目拆解3.1 SQL題多表聯(lián)查與索引優(yōu)化SQL 題給了一個(gè)家電銷售系統(tǒng)的簡(jiǎn)化場(chǎng)景三張表用戶表 users、訂單表 orders、商品表 products。第一問是“統(tǒng)計(jì) 2020 年 9 月下單次數(shù)最多的前 3 位用戶輸出用戶名和下單次數(shù)”。比較穩(wěn)的寫法是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;第二問在此基礎(chǔ)上加了難度在訂單表里查“同時(shí)購買過商品 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;這道題的考點(diǎn)不在 SQL 本身而在你會(huì)不會(huì)建索引。正確的做法是在 orders 表的(user_id, create_time)上建聯(lián)合索引因?yàn)?WHERE 條件里 user_id 用于等值匹配、create_time 用于范圍篩選聯(lián)合索引能同時(shí)命中這兩個(gè)條件。product_id 單獨(dú)建索引即可。如果直接在 create_time 上建單列索引過濾效果會(huì)差很多。很多人不寫索引直接交卷這一小問分?jǐn)?shù)就丟了。3.2 Spring與MyBatis高頻考點(diǎn)Spring 相關(guān)考了 IOC 和 AOP 的概念還深入問到了 Bean 的作用域。單選題里讓你選出“默認(rèn)作用域”正確答案是 singleton。但題目如果換個(gè)問法“哪些作用域下每次獲取都會(huì)創(chuàng)建新對(duì)象”那就要選 prototype。剩下 request、session、application 都是 Web 容器相關(guān)筆試?yán)锍霈F(xiàn)的頻率相對(duì)低一些。另一個(gè)高頻點(diǎn)是 Spring 事務(wù)的傳播行為尤其 REQUIRED 和 REQUIRES_NEW 的區(qū)別。REQUIRED 是默認(rèn)值如果當(dāng)前存在事務(wù)則加入當(dāng)前事務(wù)不存在則新建事務(wù)。REQUIRES_NEW 是無論如何都新建一個(gè)事務(wù)外層事務(wù)掛起內(nèi)層事務(wù)獨(dú)立提交或回滾。經(jīng)典的場(chǎng)景是“記錄日志”功能即使主業(yè)務(wù)失敗日志也不能丟這時(shí)就要用 REQUIRES_NEW。這道題格力筆試的簡(jiǎn)答題里出現(xiàn)過我當(dāng)時(shí)答了定義還順手畫了個(gè)嵌套調(diào)用的示意圖雖然畫得不標(biāo)準(zhǔn)但把“內(nèi)層事務(wù)獨(dú)立提交”這個(gè)點(diǎn)寫清楚了。MyBatis 考察了#{}和${}的區(qū)別。#{}是預(yù)編譯占位符最終通過PreparedStatement的setString等方法傳參能有效防止 SQL 注入${}是字符串拼接直接把值拼接到 SQL 中有注入風(fēng)險(xiǎn)。但${}也不是完全不能用動(dòng)態(tài)表名、排序字段這類無法用占位符的地方只能用${}關(guān)鍵是必須自己控制輸入值。這個(gè)考點(diǎn)如果寫成“盡量用 #{}、避免 ${}”只能算半對(duì)要說出${}的正確使用場(chǎng)景才能拿全分。3.3 從若依框架看企業(yè)級(jí)項(xiàng)目中的權(quán)限與前端分離這套題雖然沒有直接考若依框架但有一道選擇題涉及了“前后端分離模式下如何進(jìn)行身份認(rèn)證”。當(dāng)時(shí)的四個(gè)選項(xiàng)里有 Session、Cookie、JWT、OAuth2正確答案是“以上都可以但常見做法是 JWT 或 OAuth2”。這道題其實(shí)反映了制造業(yè)技術(shù)棧的一個(gè)趨勢(shì)——很多企業(yè)級(jí)項(xiàng)目已經(jīng)在用若依這類前后端分離框架了。若依后端基于 Spring Boot Spring Security JWT前端用 Vue后端接口通過攔截器校驗(yàn) TokenRedis 里存登錄用戶信息和權(quán)限數(shù)據(jù)。備考后端崗時(shí)容易被忽略的一點(diǎn)是“前后端分離后后端需要面對(duì)跨域問題”。如果你熟悉若依這類框架就會(huì)知道后端要通過 CORS 配置或網(wǎng)關(guān)統(tǒng)一處理跨域而不是在每個(gè) Controller 里重復(fù)加注解。面試官考察的其實(shí)是你的項(xiàng)目經(jīng)驗(yàn)是真實(shí)深入的還是只停留在 Demo 層面。能在筆試?yán)锝Y(jié)合框架談幾個(gè)實(shí)際場(chǎng)景比如接口鑒權(quán)、跨域處理、驗(yàn)證碼生成都會(huì)讓閱卷人覺得你是真正碰過項(xiàng)目的。4. 編程題與實(shí)戰(zhàn)手寫題4.1 鏈表反轉(zhuǎn)的兩種解法編程題第一題是“單鏈表反轉(zhuǎn)”函數(shù)簽名給的是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; }這段代碼的關(guān)鍵是把curr.next先存下來再翻轉(zhuǎn)否則鏈表會(huì)斷。很多人第一反應(yīng)是遞歸寫法遞歸到最后一個(gè)節(jié)點(diǎn)然后從后往前翻轉(zhuǎn)指針但遞歸的空間復(fù)雜度是 O(n)迭代是 O(1)。筆試閱卷時(shí)這兩種都能拿分但如果你能在注釋里寫出“迭代法空間復(fù)雜度 O(1)”這個(gè)點(diǎn)會(huì)顯得更有代碼意識(shí)。4.2 Top K 高頻元素優(yōu)先隊(duì)列的正確使用編程題第二題是“給定一個(gè)非空整數(shù)數(shù)組返回前 K 個(gè)高頻元素”。比如數(shù)組是[1,1,1,2,2,3]K2輸出[1,2]。這道題考察的是 Map 堆的組合用法時(shí)間復(fù)雜度可以做到 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; }這里有一個(gè)細(xì)節(jié)優(yōu)先隊(duì)列默認(rèn)是小頂堆所以用“當(dāng)堆大小超過 k 時(shí)移除堆頂”的策略最后留在堆里的就是頻率最高的 k 個(gè)元素。如果誤用大頂堆或者沒控制堆的容量上限復(fù)雜度就會(huì)退化。筆試環(huán)境里不一定能跑代碼驗(yàn)證邏輯所以我通常會(huì)把 HashMap 的統(tǒng)計(jì)流程、堆的容量控制都寫成注釋這樣即使代碼有小問題閱卷人也能看出思路是對(duì)的。4.3 多線程協(xié)作三個(gè)線程交替打印有一道附加的并發(fā)編程題不是必做但我做了三個(gè)線程分別打印 A、B、C循環(huán) 10 次要求輸出順序是 A、B、C、A、B、C……我用的是ReentrantLock配合Condition實(shí)現(xiàn)因?yàn)镃ondition可以精準(zhǔn)喚醒指定線程比wait/notifyAll可控性高很多。ReentrantLock lock new ReentrantLock(); Condition conditionA lock.newCondition(); Condition conditionB lock.newCondition(); Condition conditionC lock.newCondition(); // 每個(gè)線程循環(huán)10次輪到自己的時(shí)候打印然后喚醒下一個(gè)線程寫這道題時(shí)有三個(gè)容易扣分的點(diǎn)一是打印完成后必須finally里釋放鎖二是要用while而不是if來判斷是否輪到自己防止虛假喚醒三是三個(gè) Condition 的順序不能搞錯(cuò)最好用變量維護(hù)當(dāng)前輪次。這類題考察的不只是 API 熟練度更是并發(fā)編程的嚴(yán)謹(jǐn)性。5. 系統(tǒng)設(shè)計(jì)與實(shí)際業(yè)務(wù)場(chǎng)景題5.1 家電促銷秒殺活動(dòng)的高并發(fā)方案這套筆試題的最后一道系統(tǒng)設(shè)計(jì)題場(chǎng)景是一個(gè)空調(diào)品牌的限時(shí)秒殺活動(dòng)預(yù)計(jì)瞬間流量是平時(shí)流量的幾十倍要求設(shè)計(jì)一個(gè)可落地的后端方案。這道題非常典型基本就是把電商高并發(fā)場(chǎng)景的核心考點(diǎn)都覆蓋了我當(dāng)時(shí)用了“分層削峰”的思路來答。第一層是前端限制秒殺按鈕點(diǎn)擊一次后立即置灰防止用戶瘋狂點(diǎn)擊配合驗(yàn)證碼或滑塊拉長(zhǎng)請(qǐng)求間隔。第二層是網(wǎng)關(guān)與接口限流用 Redis Lua 實(shí)現(xiàn)令牌桶或滑動(dòng)窗口限流把超過閾值的請(qǐng)求直接返回“排隊(duì)中”。第三層是庫存預(yù)扣先把商品庫存加載到 Redis下單時(shí)用DECR原子扣減庫存扣減成功才允許創(chuàng)建訂單。第四層是異步處理訂單創(chuàng)建的請(qǐng)求丟進(jìn)消息隊(duì)列后端服務(wù)異步消費(fèi)削峰填谷數(shù)據(jù)庫只承受削峰后的寫流量。最后一層才是數(shù)據(jù)庫兜底用樂觀鎖UPDATE ... WHERE stock 0防止超賣同時(shí)在訂單表加唯一約束防止重復(fù)下單。這道題里最容易踩的坑是“直接把庫存扣減放在數(shù)據(jù)庫里”。如果每秒上萬個(gè)請(qǐng)求同時(shí)打在主庫上行鎖競(jìng)爭(zhēng)會(huì)讓數(shù)據(jù)庫 CPU 直接打滿。我當(dāng)時(shí)的答題策略是先寫清楚 Redis 預(yù)扣庫存的流程再說明 MQ 異步落庫的必要性最后補(bǔ)充了一句“秒殺接口要做接口冪等同一個(gè)用戶同一場(chǎng)活動(dòng)最多只能下單一次”這樣整套方案的閉環(huán)就出來了。5.2 接口冪等與分布式鎖的實(shí)現(xiàn)思路系統(tǒng)設(shè)計(jì)題里有一道交叉考察的小問秒殺場(chǎng)景下用戶瘋狂點(diǎn)擊導(dǎo)致重復(fù)下單怎么從后端保證接口冪等這個(gè)問題的標(biāo)準(zhǔn)解法是 token 機(jī)制用戶進(jìn)入秒殺頁面時(shí)后端先生成一個(gè)唯一 token 存到 Redis用戶提交訂單時(shí)必須攜帶這個(gè) token后端先檢查 token 是否存在存在則刪除并繼續(xù)下單不存在則直接返回“請(qǐng)勿重復(fù)提交”。因?yàn)?Redis 的單線程特性GET DEL可以保證原子性老版本 Redis 需要用 Lua 腳本保證兩步操作原子完成。另一種方案是用數(shù)據(jù)庫唯一鍵兜底比如訂單號(hào)直接使用“用戶 ID 活動(dòng) ID 時(shí)間戳”的拼接結(jié)果在訂單表上建唯一索引重復(fù)插入會(huì)直接報(bào)錯(cuò)。這個(gè)方案實(shí)現(xiàn)簡(jiǎn)單但依賴數(shù)據(jù)庫不適合作為唯一防線。如果題目繼續(xù)深挖分布式場(chǎng)景還可以用 Redisson 的分布式鎖把“查詢庫存、扣減庫存、創(chuàng)建訂單”這三個(gè)操作包在一個(gè)鎖里但我那次答題時(shí)優(yōu)先寫了 Redis 預(yù)扣庫存 唯一鍵約束沒有上分布式鎖因?yàn)檫@套組合對(duì)秒殺場(chǎng)景已經(jīng)足夠。5.3 結(jié)合實(shí)際業(yè)務(wù)智能設(shè)備數(shù)據(jù)上報(bào)接口設(shè)計(jì)有一道選擇題給了一個(gè)場(chǎng)景“空調(diào)設(shè)備每隔 30 秒上報(bào)一次運(yùn)行狀態(tài)后端需要存儲(chǔ)并支持最近 7 天的按小時(shí)聚合查詢?cè)趺丛O(shè)計(jì)存儲(chǔ)方案”備選方案里有 MySQL 單表、MySQL 按月分表、HBase、Redis。直覺上很多人會(huì)選 HBase因?yàn)樗m合海量時(shí)序數(shù)據(jù)但結(jié)合格力這類企業(yè)的實(shí)際場(chǎng)景如果上報(bào)量可控、查詢模式固定MySQL 按月分表 定時(shí)匯總表也完全夠用而且運(yùn)維成本低很多。這道題想考察的不是“哪個(gè)數(shù)據(jù)庫最強(qiáng)”而是“在給定業(yè)務(wù)體量下會(huì)不會(huì)做技術(shù)選型”。我當(dāng)時(shí)答的時(shí)候多寫了一句設(shè)備上報(bào)接口本質(zhì)上是一個(gè)寫入多、讀取少、實(shí)時(shí)性要求高的場(chǎng)景可以在應(yīng)用層加一個(gè)內(nèi)存隊(duì)列批量寫入數(shù)據(jù)庫減少頻繁的數(shù)據(jù)庫連接開銷同時(shí)利用定時(shí)任務(wù)把明細(xì)數(shù)據(jù)聚合成小時(shí)維度的匯總表查詢層只查匯總表。這個(gè)思路其實(shí)和 CEP、時(shí)序數(shù)據(jù)庫的思想很接近雖然當(dāng)時(shí)我還不了解這些概念但“聚合 預(yù)計(jì)算”的套路在后端設(shè)計(jì)里是通用的。6. 復(fù)盤心得與備考建議6.1 做題時(shí)踩過的坑和復(fù)盤復(fù)盤這套題時(shí)我發(fā)現(xiàn)幾個(gè)典型的失分點(diǎn)值得單獨(dú)提醒。第一個(gè)是選擇題里“多選漏選”的問題比如關(guān)于 ConcurrentHashMap 的正確描述里“JDK 1.8 使用分段鎖”和“JDK 1.8 使用 CAS synchronized”這兩項(xiàng)放在一起很多人兩個(gè)都選了但前者是 JDK 1.7 的實(shí)現(xiàn)正確選項(xiàng)只有一個(gè)。這類坑在基礎(chǔ)題里特別常見因?yàn)樗疾斓牟皇恰澳阒肋@個(gè)知識(shí)點(diǎn)”而是“你知道知識(shí)點(diǎn)的版本演進(jìn)”。第二個(gè)坑是 SQL 題沒有寫索引或者寫了但建錯(cuò)字段。我見過一個(gè)同學(xué)把索引建在了orders.create_time上但查詢條件是user_id ? AND create_time BETWEEN ? AND ?這種寫法只會(huì)在 create_time 上走索引user_id 的過濾是在回表后做的效率遠(yuǎn)不如聯(lián)合索引(user_id, create_time)。筆試沒法通過執(zhí)行計(jì)劃驗(yàn)證所以全靠平時(shí)的索引優(yōu)化經(jīng)驗(yàn)。說到底SQL 題不只考語法更考執(zhí)行計(jì)劃思維。第三個(gè)坑是編程題的邊界條件。鏈表反轉(zhuǎn)那題如果輸入是空鏈表或只有一個(gè)節(jié)點(diǎn)代碼要能直接返回空或原鏈表Top K 那題如果 K 大于數(shù)組長(zhǎng)度堆的容量邏輯也要兼容。這些邊界條件不用在筆試環(huán)境里跑測(cè)試用例但注釋里寫清楚會(huì)顯得你經(jīng)驗(yàn)老到。6.2 針對(duì)后端崗筆試的復(fù)習(xí)路線如果你準(zhǔn)備的時(shí)間比較緊我建議按“Java 集合與并發(fā) → JVM → MySQL → Spring → 項(xiàng)目場(chǎng)景題”這條線來走和這套筆試的側(cè)重點(diǎn)基本一致。Java 集合重點(diǎn)盯 HashMap、ConcurrentHashMap、ArrayList/LinkedList并發(fā)重點(diǎn)盯 volatile、synchronized、ReentrantLock、線程池、ThreadLocalJVM 重點(diǎn)盯內(nèi)存區(qū)域、類加載、GCMySQL 重點(diǎn)盯索引、事務(wù)隔離級(jí)別、MVCC、explainSpring 重點(diǎn)盯 IOC、AOP、事務(wù)傳播行為、Bean 生命周期。Redis 和消息隊(duì)列是加分項(xiàng)但優(yōu)先級(jí)沒前面高。如果時(shí)間充裕再補(bǔ)一補(bǔ)分布式鎖、緩存一致性、接口冪等這些場(chǎng)景題。最后想說各大論壇上流傳的所謂“標(biāo)準(zhǔn)答案”只能幫你應(yīng)付選擇題真正拉開差距的其實(shí)是簡(jiǎn)答題和系統(tǒng)設(shè)計(jì)題里體現(xiàn)出的工程思維。拿到題目先別急著寫花 30 秒在草稿紙上列一下答題框架比悶頭寫一堆零散要點(diǎn)要強(qiáng)得多。我當(dāng)年在系統(tǒng)設(shè)計(jì)題里就是把流程圖草稿畫在卷子空白處再把每一個(gè)環(huán)節(jié)從前到后串起來寫最后這道題拿到了不錯(cuò)的分?jǐn)?shù)。