從雙親委派一路問到AI網關：去哪兒這場一面，把新舊考題攪在了同一張卷子上

去哪兒的秋招一面面經最近在牛客網上流傳，職缺名稱是AI應用開發。有趣的地方在於題目的組成：一邊是Java後端面試的經典老題，JVM類載入與雙親委派模型；另一邊是多模型AI網關的路由、降級與故障隔離設計題。老八股與新場景題出現在同一場面試裡，圍觀的求職者留言區自然熱鬧。

先把這份面經的題目攤開來看。

自我介紹之後，先考了JVM

面試的第一個技術題是JVM類載入的完整過程，以及雙親委派模型在實際工程中解決了什麼問題。這是Java後端面試的長青題，去哪兒作為以Java技術棧為主的旅遊平臺，問這題並不意外。

原po給出的答案也相當完整。類載入分為載入、驗證、準備、解析、初始化幾個階段：載入階段把二進位位元組流轉為運行時資料結構並生成Class物件；驗證階段檢查位元組碼合法性；準備階段為類變數分配記憶體並設零值；解析階段把符號引用轉為直接引用；初始化階段才執行類變數賦值與靜態程式碼區塊。

雙親委派的核心邏輯則是：類載入器收到請求後優先交給父載入器，父載入器無法完成時子載入器才自己載入。它解決兩個問題，一是避免核心類被業務程式碼替換，就算你自己寫一個java.lang.String也不會覆蓋JDK的實作；二是避免同一個類被重複載入。

不過原po也補了一句很有面試感的收尾：雙親委派並非所有場景都適用，SPI、JDBC、Tomcat多應用隔離與部分插件系統，會透過執行緒上下文類載入器甚至主動打破委派順序。這一段往往是面試官想聽的加分項，能說出「什麼時候不適用」，比背出流程更能證明理解。

AI網關設計題，才是這場面試的重頭戲

真正讓這份面經有討論度的，是第三題：在一個多模型AI網關中，如何設計模型路由、降級和故障隔離。

原po給出的框架是四層拆分：請求接入層負責鑑權、限流、參數校驗與請求編號；策略層依任務類型、租戶、延遲要求、預算和上下文長度選擇模型；模型適配層屏蔽不同供應商在請求格式、串流回應、工具呼叫與錯誤碼上的差異；治理層負責超時、重試、熔斷、監控與成本統計。

路由策略部分，原po強調不能只靠固定優先級，可以綜合品質、延遲、成本與近期錯誤率算一個動態評分。故障隔離部分則列得相當細：每個模型供應商獨立連線池與並發號誌、每租戶獨立額度、單模型超時不能佔滿整個網關執行緒池、重試要限次並用指數退避，而且只有網路錯誤、限流錯誤這類可恢復錯誤才值得重試，參數錯誤盲目重試只是浪費token。

降級策略也講得很務實：主模型故障時降到能力較弱但穩定的模型，結構化任務最好保留一個規則引擎或本地模型作最後兜底，避免所有請求都依賴外部大模型。

這種題目已經不是背多分能應付的範圍，它考的是分散式系統的通用素養，加上對大模型服務特性的理解。這與我們先前觀察過的美團那場把考題藏進「如果讓你設計」的Agent一面方向一致，場景題正在成為AI相關職缺的標配考法。

Redis持久化收尾，老題回了鍋

最後一題回到傳統後端領域：Redis RDB與AOF持久化原理的區別，以及生產環境如何選擇。

RDB是時間點快照，透過fork子進程把記憶體資料寫入臨時檔案再替換舊檔，優點是檔案緊湊、恢復快，缺點是兩次快照之間的資料可能丟失。AOF記錄的是寫命令，重啟時重新執行命令恢復資料，丟失視窗更小，但檔案更大、重寫時有磁碟與CPU壓力。刷碟策略上，everysec是生產環境的常見折中，always最安全但效能損失明顯。

這題放在最後，多少有種「確認基本功」的意味。

一張卷子，兩個時代

把三題並排放著看，這份面經的訊息其實很清楚。AI應用開發這個職缺名稱聽起來很新，但去哪兒要的人仍然是Java基本功扎實、懂Redis、懂JVM的後端工程師，只是在此之上，還要能設計多模型網關這類AI時代的基礎設施。

這與我們先前分析過的騰訊IEG那份AI協作問在八股之前的面經形成了有趣的對照：有的公司把AI相關題放在最前面，有的公司把它夾在經典八股中間，順序不同，傳遞的訊號卻類似，新舊考題不再是二選一，而是疊加。

對正在秋招的求職者來說，這份面經的參考價值就在這裡。JVM雙親委派不會因為職缺掛了AI兩個字就消失，而只會背雙親委派的人，也應付不了動態路由評分與熔斷降級的追問。兩邊都得會，這大概是今年AI應用開發崗最誠實的門檻描述。