一個「為什麼要分池」先被問回去了：快手 Java 一面，是一場被排好深度的對話

2025 年 9 月中旬，牛客網上流傳出一則快手 Java 開發一面的面經。發文者自述是秋招第一場正式面試，項目與實習還在復健，部門是可靈平臺的開發，偏傳統後端，面試官「很和善」。整份面經以問句的形式被記錄下來，三十多個問號一字排開，像一份被排好版的對話腳本。

先從一個細節看起。這份面經的開場提問相當標準：「實習裡有沒有印象比較深、比較自豪的需求或點？」接下來的走向卻值得注意。面試官順著回答裡的一個詞「分池並發聚合」，連續追問了至少七層：分池解決什麼問題、為什麼要分池、三個執行緒池的參數怎麼定、參考依據是什麼、分池的核心是不是提高並發度、如果只是提高並發度那合併成一個池加大核心執行緒數有什麼區別、放一個池裡問題怎麼排查。一個名詞被翻來覆去地拆，直到拆到最底層的取捨邏輯。

這種追問的密度，和先前我們看過的得物後端一面的十二道題清單是兩種排版。得物那份像一份編號工整的題單，題與題之間相對獨立；快手這份更像一棵不斷向下生長的樹，每一個子節點都從候選人自己的回答裡長出來。面經的記錄格式掩蓋了這一點，但讀者若把問句按縮排重排，會看見一場結構相當嚴謹的深度測試。

題目的排序：從經歷到假設的坡道

整場面試的題目排序有一條清晰的坡道。前半段黏著候選人的實習經歷，N+1 查詢、串行調用、批量接口下移、JVM 記憶體治理、MDC 執行緒追蹤，每一個都是從履歷裡挖出來的磚。中段開始出現假設題：「三個下遊耗時分別是 100ms、200ms、800ms，串行和並行聚合大概各要多久？」「如果 800ms 的服務超時了，接口會怎麼返回？」到了後段，假設被推到極端：「流量漲 100 倍甚至 1000 倍，當前方案還可靠嗎？」

這條坡道的設計意圖很清楚：先確認經歷的真實顆粒度，再用假設情境測出思維的邊界。100 倍流量這個數字選得也講究，它大到讓「加機器」這種直覺答案站不住，卻又沒有誇張到脫離現實。相比那種直接拋系統設計大題的面試，這種從個人經歷出發逐級加壓的方式，對候選人更公平，也更容易暴露真實水位。

一道評價題的措辭設計

面經裡有一道題的措辭特別值得停下來看：「意圖識別關鍵詞攔截：如果攔截 60%，其中 15% 分類錯誤，這種優化值得上線嗎？如何評價 60% 攔截率能證明是好效果？」

這不是知識題，是評價題。60% 和 15% 這兩個數字被並排放在一起，本身就是一個設計過的陷阱：攔截率看似漂亮，錯誤率藏在分母裡。面試官真正想聽的不是算術，是候選人會不會追問「被錯誤攔截的 15% 帶來什麼代價」「好效果的基準線是什麼」。把兩個數字寫進同一個句子，等於把評價框架的入口先藏在句法裡，等候選人自己找出來。這與我們在招銀網路科技一面被排成的題單裡看到的排序邏輯相通：題目的價值有一半寫在措辭裡。

場景題的收尾：一百萬張券與十秒

面試的壓軸是一道完整的場景設計題：「一百萬張券，十秒內一千萬請求，每人限領一張，不允許超發，允許少量失敗但不能重複發券，怎麼設計鏈路？」接著往下追：Redis 加 Lua 做原子扣減之後，如果服務大量宕機會發生什麼、訂單怎麼恢復、兜底方式是什麼。

約束條件的排列順序本身就是一份需求文件的縮影。不允許超發是硬約束，允許少量失敗是軟約束，不能重複發券是冪等約束。三種約束被壓縮在一個句子裡，候選人若能分辨出哪些可以妥協、哪些不能，答案的骨架就出來了。後續的 ShardingSphere 分庫分表擴容題（8 張表改 16 張會發生什麼）、RocketMQ 重複投遞在哪一層做冪等，都是同一個母題的變奏：分散式系統裡，正確性從來不是單點問題，是鏈路問題。

最後的手撕題是 LRU。在一場被場景題撐滿的面試尾端放一道經典算法題，像長跑的最後一圈，不測高度，測底盤穩不穩。

面經作為一種被排版的敘事

回到這份面經本身。發文者在文末補了一句「更新，流程已結束」，評論區有人留言「大佬好強，感覺是沒有 hc」。這些零碎的後記，和三十多個問號一起，構成了秋招季節裡一種特有的文件格式：題目是骨架，追問是肌肉，後記是情緒的註腳。它被寫出來的目的是記錄與分享，但客觀效果是讓一場私人對話變成可複用的公共素材。下一個面試者讀到「為什麼要分池」這一串追問時，學到的不會是答案，是一種把知識問到底的姿勢。

這大概是面經這種文體最有價值的地方。規格表會過期，追問的結構不會。快手這場一面給出的範本，是一場好的技術面試如何從候選人的句子裡找出縫隙，然後溫和地、一層一層地，把縫隙問成一道門。