上個月面完那家大廠回程地鐵上我腦子里還嗡嗡的。面試官最后一句是“你說你去看過源碼那我再問你一句Kafka冪等性到底在冪等什么”那一刻我就知道前面聊完Spring Boot線程池那些“基礎(chǔ)”只是開胃菜真正的硬骨頭才開始。介紹一下自己網(wǎng)名謝飛機Java后端開發(fā)干了五年多每天都在跟Spring Boot、Kafka、中間件這些東西打交道。這次去面的是一個大廠核心業(yè)務(wù)團隊的高級Java開發(fā)崗。三輪面試面試官風(fēng)格完全不同第一輪是個喜歡摳底層原理的架構(gòu)師第二輪是做高并發(fā)平臺的大佬第三輪直接拋出一個“AI Agent 企業(yè)內(nèi)部RAG知識庫”的真實落地場景讓我現(xiàn)場給方案。說實話這三輪我全都踩過坑也全都在現(xiàn)場補了回來。這篇就當(dāng)一次完整復(fù)盤。把三個方向的核心答案、實際踩坑過程以及我回來之后重新整理的生產(chǎn)配置方案一次性寫清楚。不管你是準(zhǔn)備面試還是正好在負(fù)責(zé)線程池調(diào)優(yōu)、Kafka可靠性改造、甚至是把AI Agent塞進(jìn)業(yè)務(wù)系統(tǒng)里的人應(yīng)該都能從這里撈到點東西。1. 第一輪施壓Spring Boot線程池從Tomcat到業(yè)務(wù)線程的“連環(huán)炮”1.1 現(xiàn)場還原面試官為什么從類加載器一路問到這里第一輪面試官很老練上來沒讓我背八股先丟了一個生產(chǎn)問題“我們有個網(wǎng)關(guān)服務(wù)Tomcat默認(rèn)工作線程數(shù)是200壓測時發(fā)現(xiàn)接口RT升高CPU卻跑不滿線程池隊列一直在堆積。你說說你會往哪幾個方向排查”我當(dāng)時第一反應(yīng)是這是一個典型的“線程池配置和流量模型不匹配”的問題。我回答的時候先按自己的排查習(xí)慣說了一遍先看線程池狀態(tài)是拒絕、是排隊還是空閑再看消息鏈路里有沒有阻塞點比如數(shù)據(jù)庫連接池、外部HTTP調(diào)用超時時間最后對比壓測QPS和單次請求耗時反推并發(fā)線程數(shù)需求。面試官點了點頭緊接著就問了第二句“那你專門講講Spring Boot里的線程池Async用的是什么線程池不配置默認(rèn)是什么”這個問題看似基礎(chǔ)實際是整套連環(huán)炮的入口。真正的考點不是“知不知道默認(rèn)配置”而是“知不知道默認(rèn)配置在真實流量下意味著什么”。我把面試現(xiàn)場的關(guān)鍵幾個問答還原一下你感受一下節(jié)奏面試官Async不指定線程池Spring Boot默認(rèn)給你的是什么我TaskExecutionAutoConfiguration自動配置的ThreadPoolTaskExecutor核心線程數(shù)默認(rèn)8最大線程數(shù)其實是Integer.MAX_VALUE隊列用的是無界LinkedBlockingQueue空閑線程存活60秒。面試官那你說這個配置下核心線程滿了以后新任務(wù)去哪我去無界隊列排隊。無界隊列意味著隊列永遠(yuǎn)不會滿所以最大線程數(shù)這個參數(shù)在默認(rèn)配置下形同虛設(shè)真正干活的只有核心線程那8個剩下全部排隊。這就是“CPU不滿、RT卻一直漲”的典型癥狀。面試官如果要改你會怎么定核心線程數(shù)、最大線程數(shù)、隊列長度我按流量模型算不能拍腦袋。比如單請求平均耗時50ms要支撐200 QPS穩(wěn)態(tài)并發(fā)就是200*0.0510核心線程數(shù)至少10以上再考慮峰值和限流留出彈性余量最大線程數(shù)可以到20左右隊列給一個有界值比如200不要讓任務(wù)無限堆積堆滿了就觸發(fā)拒絕策略把壓力傳到上游或者直接快速失敗。這一段對話結(jié)束以后我很明顯感覺到面試官的反饋是正向的。他要的不是“我會用ThreadPoolExecutor”而是“我知道它底層怎么流轉(zhuǎn)也清楚什么配置在什么場景下會出問題”。1.2 復(fù)盤線程池面試題背后的核心考點現(xiàn)在把知識拆開細(xì)講。ThreadPoolExecutor的任務(wù)流轉(zhuǎn)順序是固定的核心線程池滿了之后新任務(wù)先進(jìn)隊列隊列滿了才創(chuàng)建非核心線程直到最大線程數(shù)最大線程數(shù)也滿了才觸發(fā)拒絕策略。很多人背過這個順序但項目里一遇到問題就忘因為大家習(xí)慣性把“核心線程數(shù)”和“最大線程數(shù)”之間的關(guān)系搞混。Spring Boot默認(rèn)的TaskExecutor問題就出在無界隊列上。無界隊列下隊列永遠(yuǎn)不會滿所以“最大線程數(shù)”這個參數(shù)徹底失效。你看到的效果就是不管壓測QPS多高始終只有8個線程在工作其他任務(wù)全在隊列里排隊CPU自然跑不滿RT自然直線上升。更麻煩的是如果任務(wù)長時間積壓隊列里的對象還會占用大量堆內(nèi)存最終引發(fā)Full GC甚至OOM。還有一層是面試官經(jīng)常挖的坑Tomcat工作線程和業(yè)務(wù)線程池是兩個不同的池。Tomcat的工作線程處理的是HTTP請求的接入默認(rèn)maxThreads200負(fù)責(zé)從Socket里讀請求、寫響應(yīng)而你在業(yè)務(wù)代碼里用Async或者自定義線程池是請求進(jìn)入Controller之后再把任務(wù)丟給另一個池子執(zhí)行。兩個池的配置相互獨立壓測時如果發(fā)現(xiàn)Tomcat線程堆積和業(yè)務(wù)線程池堆積排查方向完全是兩回事。至于線程數(shù)怎么定我習(xí)慣用“阻塞系數(shù)”來算而不是記網(wǎng)上的公式。IO密集型場景下線程數(shù)大約是CPU核數(shù)2再除以(1-阻塞系數(shù))比如8核機器、阻塞系數(shù)0.8大約需要82/(1-0.8)80個線程。這里的阻塞系數(shù)指的是線程在等待IO數(shù)據(jù)庫查詢、遠(yuǎn)程調(diào)用、磁盤讀寫上的時間占比越接近1說明等待越嚴(yán)重需要更多線程來掩蓋延遲。CPU密集型場景則簡單得多通常就是CPU核數(shù)加1因為多一點上下文切換反而更劃算。這套算法不是為了精確而是讓你有一個可推導(dǎo)的起點而不是隨手填一個數(shù)字。1.3 實操配置線程池參數(shù)不靠猜靠算面完回來之后我把自己負(fù)責(zé)的那幾個服務(wù)全部排查了一遍統(tǒng)一改成了下面這套有界隊列配置實測下來比默認(rèn)配置穩(wěn)很多。Configuration public class BizThreadPoolConfig { Bean(bizTaskExecutor) public ThreadPoolTaskExecutor bizTaskExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); // 核心線程數(shù)按“穩(wěn)態(tài)QPS * 單任務(wù)耗時”算出來而不是拍腦袋 // 假設(shè)穩(wěn)態(tài) QPS 150單任務(wù)平均耗時 80ms并發(fā)需求 150 * 0.08 12 executor.setCorePoolSize(12); // 最大線程數(shù)核心線程 彈性容量容量給多少要看峰值流量和限流閾值 executor.setMaxPoolSize(24); // 有界隊列寧可觸發(fā)拒絕策略也別讓任務(wù)無限堆積占內(nèi)存 // 隊列長度一般設(shè)為“最大線程數(shù)穩(wěn)態(tài)吞吐的1秒到2秒量” executor.setQueueCapacity(300); executor.setThreadNamePrefix(biz-worker-); executor.setKeepAliveSeconds(60); // 拒絕策略選 CallerRunsPolicy調(diào)用方線程自己跑相當(dāng)于天然限流 // 比 DiscardPolicy 好任務(wù)不會丟比 AbortPolicy 好不會無腦拋異常 executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); // 優(yōu)雅停機應(yīng)用關(guān)閉時先等已有任務(wù)跑完最多等30秒 executor.setWaitForTasksToCompleteOnShutdown(true); executor.setAwaitTerminationSeconds(30); executor.initialize(); return executor; } }這里面有三個細(xì)節(jié)值得多說一句。第一拒絕策略我首選CallerRunsPolicy它的副作用是調(diào)用方線程會被占用等于把壓力反向傳導(dǎo)給上游會在不丟任務(wù)的前提下天然限流對支付、對賬這類不能丟消息的場景很友好。第二有界隊列的長度必須跟最大線程數(shù)配合隊列太小會導(dǎo)致頻繁觸發(fā)拒絕策略太大又會失去“最大線程數(shù)”的意義我一般按“最大線程數(shù)在1秒到2秒內(nèi)的處理能力”來估也就是最大線程數(shù)乘以單個任務(wù)耗時再乘個系數(shù)。第三Async一定要指定自定義的bean名稱否則Spring Boot還是會走默認(rèn)的無界隊列配置。2. 第二輪追問Kafka冪等性你說你用過那你給我講清楚2.1 現(xiàn)場還原冪等性一問到底第二輪面試官是做高并發(fā)中間件平臺的說話節(jié)奏快問題密度高。他上來直接問“你們項目里用了Kafka吧生產(chǎn)端開沒開冪等”我說開了他緊接著就是三連。第一個問題開了冪等它底層是靠哪幾個關(guān)鍵字段保證不重復(fù)的第二個問題冪等生產(chǎn)者能不能跨分區(qū)保證嚴(yán)格不重復(fù)第三個問題業(yè)務(wù)要求一條消息只能被消費一次冪等生產(chǎn)者能不能覆蓋覆蓋不了的話你怎么辦這三個問題我現(xiàn)場答得并不順暢尤其是第三個我當(dāng)時只想到了“在消費端做去重”但沒有及時說出“冪等生產(chǎn)者只保生產(chǎn)端不重復(fù)消費端在at-least-once語義下照樣可能重復(fù)消費”這句話。好在面試官愿意引導(dǎo)我才把整個鏈路串起來了。2.2 原理拆解冪等生產(chǎn)者到底在冪等什么Kafka冪等生產(chǎn)者的核心機制是生產(chǎn)端和broker端共同維護(hù)一對狀態(tài)字段PIDProduceId生產(chǎn)者ID和Sequence Number序列號。生產(chǎn)者啟動后會被分配一個PID在發(fā)送消息時每個分區(qū)都會維護(hù)一個從0開始單調(diào)遞增的Sequence Number每發(fā)一條消息就加1broker端收到消息后會校驗這個序號只接受“當(dāng)前已接收序號1”的批次如果收到的序號比已記錄的小或者出現(xiàn)跳號就判定為重復(fù)或亂序直接拒絕并拋出異常。所以Kafka冪等性真正保證的是同一個PID、同一個分區(qū)、短暫重試場景下的不重復(fù)和有序。它的場景是解決“生產(chǎn)者發(fā)送消息后沒收到ack于是重試導(dǎo)致broker收到兩條相同的消息”這類問題。注意幾個邊界。第一PID不是永久不變的。生產(chǎn)者進(jìn)程重啟之后PID會變之前記錄的Sequence Number狀態(tài)全部失效重啟前可能已經(jīng)提交但未回調(diào)成功的那批消息是有極小概率重復(fù)的。第二跨分區(qū)沒有統(tǒng)一的序列號一個事務(wù)里寫多個分區(qū)每個分區(qū)各自維護(hù)各自的Sequence Number所以冪等生產(chǎn)者不能保證跨分區(qū)的原子性和全局不重復(fù)。第三分區(qū)Leader切換或者broker故障恢復(fù)的過程中如果狀態(tài)日志沒有完全同步也可能出現(xiàn)少量重復(fù)。那如果非要做到跨分區(qū)的不重不丟怎么辦答案是Kafka事務(wù)。事務(wù)型生產(chǎn)者會額外指定一個transactional.id它和PID綁定通過事務(wù)協(xié)調(diào)器維護(hù)跨分區(qū)的事務(wù)狀態(tài)消息先緩存在事務(wù)里最后統(tǒng)一commit后對消費者可見。消費者端還需要配合配置isolation.levelread_committed才能只讀取已提交的事務(wù)消息。這個方案能解決跨分區(qū)原子寫的問題但有性能損耗而且在項目里真正會用到的場景其實不多通常只有“從Kafka讀數(shù)據(jù)處理后寫回另一個Kafka再寫數(shù)據(jù)庫要保證we所有環(huán)節(jié)要么全部成功要么全部失敗”這種跨系統(tǒng)一致性訴求。2.3 高并發(fā)場景的冪等實操生產(chǎn)端配置與消費端去重回來之后我把項目的Kafka生產(chǎn)配置整理成了下面這份可以作為標(biāo)準(zhǔn)模板。spring: kafka: bootstrap-servers: kafka1:9092,kafka2:9092,kafka3:9092 producer: acks: all retries: 3 enable-idempotence: true max-in-flight-requests-per-connection: 5 key-serializer: org.apache.kafka.common.serialization.StringSerializer value-serializer: org.apache.kafka.common.serialization.StringSerializer consumer: group-id: biz-order-group enable-auto-commit: false auto-offset-reset: earliest key-deserializer: org.apache.kafka.common.serialization.StringDeserializer value-deserializer: org.apache.kafka.common.serialization.StringDeserializerenable-idempotencetrue之后acks會被強制提升為allretries也建議開大于0否則冪等沒有意義。max-in-flight-requests-per-connection在新版本里可以設(shè)置為5但如果你在舊版本上還是保守一點設(shè)成1避免亂序觸發(fā)OutOfOrderSequenceException。這個屬性的作用是控制單個連接上最多有多少個未確認(rèn)的請求在飛行設(shè)置越大吞吐越高但亂序風(fēng)險也越大。然后是消費端。很多人以為生產(chǎn)端開了冪等消費端就不會重復(fù)了這是最典型的認(rèn)知誤區(qū)。Kafka默認(rèn)的消費語義是at-least-once也就是說“消息不丟”但“可能重復(fù)”。正常流程是消費者拉取一批消息處理完業(yè)務(wù)邏輯提交offset。如果業(yè)務(wù)邏輯執(zhí)行完、offset還沒來得及提交消費者就掛了重啟后會從舊offset重新拉取這些消息就會被再次消費。生產(chǎn)端冪等完全管不到這個過程。消費端去重我一般用三個方案按場景選。第一Redis冪等標(biāo)記用業(yè)務(wù)唯一鍵比如訂單號作為keysetIfAbsent成功才繼續(xù)處理處理完成寫入結(jié)果適合高吞吐場景但要注意Redis和業(yè)務(wù)數(shù)據(jù)庫的一致性。第二數(shù)據(jù)庫唯一約束直接給業(yè)務(wù)表加唯一索引重復(fù)插入會報錯然后捕獲異常跳過這是最硬的兜底但僅適合有唯一性特征的數(shù)據(jù)。第三狀態(tài)機冪等把每一條消息按業(yè)務(wù)主鍵查狀態(tài)只有在“當(dāng)前狀態(tài)允許流轉(zhuǎn)到目標(biāo)狀態(tài)”時才執(zhí)行更新否則跳過。我實際做項目時最喜歡“數(shù)據(jù)庫唯一約束 Redis標(biāo)記”組合一個保底一個擋流量。消費端去重代碼的骨架大概是這個樣子// 偽代碼消費前做冪等檢查 String key biz:processed: record.key(); Boolean first redisTemplate.opsForValue() .setIfAbsent(key, 1, Duration.ofHours(24)); if (Boolean.TRUE.equals(first)) { // 第一次消費執(zhí)行業(yè)務(wù)邏輯 handle(record.value()); } else { // 已處理過跳過業(yè)務(wù)邏輯直接提交offset }注意Redis里的標(biāo)記盡量設(shè)置過期時間否則存量消息會越積越多同時消費邏輯和Redis寫入之間要做好失敗補償比如先執(zhí)行消費邏輯再寫Redis則可能出現(xiàn)重復(fù)執(zhí)行先寫Redis再執(zhí)行消費邏輯則可能出現(xiàn)Redis已經(jīng)寫了但業(yè)務(wù)失敗導(dǎo)致后續(xù)消息被跳過。經(jīng)驗做法是記錄狀態(tài)時要區(qū)分“處理中”和“已完成”兩種狀態(tài)處理中狀態(tài)帶超時時間完成后改成永久標(biāo)記。這樣即使業(yè)務(wù)失敗超時后還能重試不會漏消息。3. 第三輪開放題AI Agent RAG落地技術(shù)細(xì)節(jié)與工程取舍3.1 情景還原面試官拿著一個質(zhì)檢場景讓我現(xiàn)場設(shè)計第三輪面試官明顯不是做純Java的他更像業(yè)務(wù)架構(gòu)師。他點開屏幕上的一個需求文檔說“我們想做一個面向一線質(zhì)檢人員的智能體。用戶上傳產(chǎn)品缺陷照片智能體要能結(jié)合企業(yè)內(nèi)部知識庫回答這是什么缺陷、應(yīng)該怎么處理。這個場景就是AI Agent加RAG你從工程角度給我一個完整方案包括圖片怎么處理知識庫怎么存儲并發(fā)能不能扛住?！蔽耶?dāng)時心里一緊。因為這類場景我在公司內(nèi)部確實調(diào)研過但沒有真正上線過大規(guī)模生產(chǎn)系統(tǒng)所以回答時很謹(jǐn)慎。我先確認(rèn)了幾個關(guān)鍵信息知識庫有哪些格式圖片數(shù)量級有多大智能體是同步返回還是異步通知要不要考慮權(quán)限。然后給了下面這版方案面試官沒有打斷我說明大方向是對的。3.2 RAG知識庫的圖片存儲能存圖片但重點在“怎么被檢索”先說結(jié)論RAG知識庫當(dāng)然能存儲圖片。OSS、S3、本地文件系統(tǒng)甚至數(shù)據(jù)庫里的BLOB字段都能存圖片。真正的難點是圖片怎么被檢索、怎么和文本知識統(tǒng)一召回。RAG的核心不是“存”而是“找”。檢索階段系統(tǒng)需要把文本問題和知識庫內(nèi)容都映射到一個向量空間用向量相似度找出最相關(guān)的片段。純文本場景好辦用Embedding模型生成文本向量就行。圖片場景就需要多模態(tài)能力。實際落地有三種做法。第一種是圖片生成獨立向量用CLIP這類多模態(tài)模型把整張圖片編碼成一個向量查詢時用戶的圖片也編碼成向量做相似度檢索。這種方案能感知圖片的視覺內(nèi)容但工程復(fù)雜度高向量模型對顯卡算力有要求。第二種是圖片轉(zhuǎn)文本再入庫先對圖片做OCR再配合人工標(biāo)注或視覺大模型生成一段描述文本把這段文本和圖片路徑一起入庫檢索時只走文本召回命中后返回圖片。這種方式成本低、效果好目前很多企業(yè)實測下來最實用。第三種是混合方案圖片向量和文本描述都存檢索時多路召回再融合效果最好但也最復(fù)雜。我當(dāng)時給面試官的方案是第二種為主、第三種做演進(jìn)。原因是一線質(zhì)檢場景里缺陷類型往往集中在有限的幾十種人工標(biāo)注的成本是可控的OCR加描述生成的文本能讓知識庫的檢索質(zhì)量快速達(dá)到可用水平。等數(shù)據(jù)量大了、算力資源充足了再引入多模態(tài)向量。面試官追問了一句“向量庫里到底存什么”我補充說向量庫只存向量和metadata圖片ID、文本、產(chǎn)品型號、缺陷編碼圖片本體放OSS查詢結(jié)果里帶著OSS的URL給前端展示。這個回答他應(yīng)該是認(rèn)可的因為這就是今天大多數(shù)企業(yè)知識庫的常規(guī)架構(gòu)。3.3 RAG落地瓶頸切分、召回、上下文一個都不能偷懶RAG項目最大的特點就是“細(xì)節(jié)多每一個環(huán)節(jié)都可能讓效果斷崖式下降”。我給它排了個序切分、召回、重排、上下文管理。這四個環(huán)節(jié)任何一個做不好回答質(zhì)量都會拉胯。切分是第一個容易翻車的點。固定按512字符切分、重疊128字符是最常見的做法但你要知道這不是銀彈。如果你的文檔里大量是表格、代碼塊、層級標(biāo)題固定長度切分會把語義拆得七零八落檢索的時候經(jīng)常匹配到一半內(nèi)容。更好的做法是按語義邊界切分比如檢測到新的二級標(biāo)題就自動換一個Chunk表格轉(zhuǎn)成文本后再切代碼塊單獨處理。切分時還要保留塊與塊之間的上下文關(guān)系比如每個Chunk里附帶文檔標(biāo)題、父級章節(jié)檢索時可以按父級信息做“二次聚類”。召回是整個RAG效果的關(guān)鍵瓶頸。只用向量召回偶爾會發(fā)現(xiàn)語義相近但關(guān)鍵詞完全不搭的內(nèi)容召不回來。業(yè)界目前比較成熟的做法是多路召回加Rerank向量召回取Top20關(guān)鍵詞召回BM25取Top20合并去重后交給一個Rerank模型重新打分再取Top5送給大模型。Rerank模型不便宜但是這一步帶來的效果提升非常明顯很多從“勉強能用”到“生產(chǎn)可用”的跨越就是靠加了一層Rerank實現(xiàn)的。上下文管理是另一個隱性瓶頸。你有Top5的Chunk每個Chunk可能1000多字加系統(tǒng)提示詞、歷史對話一次性塞給大模型很容易沖爆Token上限。處理方式有幾種按MaxToken限制動態(tài)裁剪Chunk只保留每個Chunk里和問題高相關(guān)的句子引入長會話緩存把歷史對話壓縮成摘要再重新作為上下文或采用Agentic RAG的思路讓智能體自己決定需要檢索幾次、每次檢索什么而不是把所有內(nèi)容一次性塞進(jìn)去。Agentic RAG的好處是讓“檢索”從一次性的動作變成了可決策的動作能回答更復(fù)雜的問題但也意味著單次請求的LLM調(diào)用次數(shù)變多、延遲變高這兩個方向本身就是互斥的要在工程上做平衡。3.4 AI Agent怎么扛并發(fā)大模型調(diào)用是瓶頸架構(gòu)要對癥下藥面試官問“AI Agent怎么扛并發(fā)”的邏輯其實是所有Java后端人員在做AI應(yīng)用時都要面對的一道坎。傳統(tǒng)接口的瓶頸在IO、數(shù)據(jù)庫、緩存而AI Agent的瓶頸在大模型推理。一個Agent請求內(nèi)部可能要調(diào)用四五次LLM理解用戶意圖一次、規(guī)劃任務(wù)一次、檢索后生成答案一次、可能還要做自我糾錯再調(diào)一次。單次LLM調(diào)用就要2秒到10秒一次請求幾十秒非常正常。這時候如果網(wǎng)關(guān)線程池傻傻地同步等待用不了多少Q(mào)PS就能把整個服務(wù)拖死。我的方案分四層。第一層接口層異步化收到請求后立刻返回任務(wù)ID后端消費者把任務(wù)丟進(jìn)隊列處理完成后通過WebSocket、SSE或者輪詢接口通知前端。這樣Tomcat線程不會被長時間占用。第二層智能體任務(wù)編排層做并行化多個獨立的檢索、多個獨立的數(shù)據(jù)查詢并行執(zhí)行把串行鏈路變成DAG能大幅縮短響應(yīng)時間。第三層緩存層最直接的是結(jié)果緩存相同問題直接返回歷史答案進(jìn)階一點是語義緩存把用戶問題向量化和緩存里的歷史問題做相似度判斷相似度超過閾值的直接復(fù)用答案。這塊是真的能省錢的很多知識庫問答場景命中率能做到40%以上。第四層限流降級再兜底為AI調(diào)用設(shè)置專有線程池并和普通業(yè)務(wù)線程池做隔離按客戶等級做限流LLM調(diào)用失敗時走預(yù)設(shè)的兜底話術(shù)或規(guī)則引擎保證用戶體驗不至于斷崖。有一點特別值得展開說線程池隔離背后的并發(fā)計算邏輯。假設(shè)每個Agent請求平均需要60秒才能拿結(jié)果一個8線程的worker池同一時刻只能處理8個請求每個線程一秒鐘最多完成1/60個請求整個池子的總吞吐就是8/60約等于0.13 QPS。如果你能通過并行化把單請求耗時壓縮到10秒同樣的線程池吞吐直接變成8/100.8 QPS提升了6倍。這個計算說明AI Agent扛并發(fā)的核心不是無限加機器而是想方設(shè)法降低單請求持有線程的時間。這也是為什么“異步化”和“盡快釋放線程”在AI場景里比在傳統(tǒng)Web場景里重要得多。4. 三輪面試之后我整理的一份“面試避坑快查表”4.1 高頻問題速查表面完第三天我把面試中涉及的關(guān)鍵知識點做了一張速查表發(fā)在團隊內(nèi)部群里幾個同事說挺有用?，F(xiàn)在貼在下面。場景高頻現(xiàn)象根因分析解決/應(yīng)對方案Spring Boot AsyncCPU不滿、RT升高、線程堆積默認(rèn)無界隊列core8最大線程參數(shù)失效自定義有界隊列線程池按QPS*耗時算核心數(shù)ThreadPoolExecutor隊列滿了直接拋RejectedExecutionException默認(rèn)AbortPolicy按業(yè)務(wù)選CallerRunsPolicy或定制降級策略Kafka生產(chǎn)端開啟冪等后仍擔(dān)心跨分區(qū)重復(fù)冪等只?！癙ID分區(qū)序號”不保證全局需要全局一致性時用事務(wù)型ProducerKafka消費端數(shù)據(jù)重復(fù)入庫at-least-once語義offset未提交導(dǎo)致重復(fù)拉取Redis標(biāo)記/數(shù)據(jù)庫唯一約束/狀態(tài)機RAG知識庫圖片檢索不到圖片沒有轉(zhuǎn)成可檢索的文本或向量OCR描述文本入庫或CLIP多模態(tài)向量RAG檢索效果差召回結(jié)果與問題不相關(guān)單一向量召回不準(zhǔn)多路召回BM25向量 RerankAI Agent并發(fā)請求一多服務(wù)直接不可用LLM調(diào)用慢、同步阻塞持線程異步化任務(wù)并行化語義緩存線程池隔離4.2 排查現(xiàn)場問題的幾個實操路徑除了背知識點面試官更看重“遇到線上問題怎么排”。我的習(xí)慣是先看線程池的運行狀態(tài)再看鏈路耗時最后看消息隊列的堆積和消費速率。線程池可以通過Spring Boot Actuator暴露的metrics看active線程數(shù)和隊列剩余量也可以通過jstack抓線程dump看線程池里到底都在執(zhí)行什么。如果線程全部WAITING在某個鎖上那就不是線程數(shù)的問題而是鎖競爭的問題。Kafka排查延遲高時先分清楚是生產(chǎn)端延遲還是消費端延遲。生產(chǎn)端要看broker端CPU、網(wǎng)絡(luò)帶寬、acksall時的副本同步情況以及有沒有頻繁重試消費端要看消費組是否發(fā)生Rebalance、單條消息處理耗時、消費線程數(shù)是否小于分區(qū)數(shù)。之前遇到過一次消費端延遲高最后發(fā)現(xiàn)是消費組里一個實例的GC時間過長導(dǎo)致心跳超時頻繁觸發(fā)Rebalance消費根本沒進(jìn)度。這個排查順序很通用先隔離再分層看指標(biāo)。RAG應(yīng)用出問題優(yōu)先查的是“檢索環(huán)節(jié)”而不是“生成環(huán)節(jié)”。如果大模型回答得不好先看Top5的召回片段里到底有沒有正確答案。如果正確答案沒有被召回問題在切分和檢索如果正確答案被召回了但大模型沒用上才是提示詞或上下文組裝的問題。這個排查順序能讓定位問題的效率高非常多別一上來就調(diào)prompt。5. 一些真實心里話這類面試到底在考什么三輪面完之后我最大的感受是大廠面試早就不是考“你用過什么框架”而是考“你在一線踩坑之后有沒有真正形成方法論”。Spring Boot線程池那輪真正區(qū)分人的不是知不知道默認(rèn)線程數(shù)是8而是能不能說清楚無界隊列為什么危險、核心線程數(shù)怎么根據(jù)流量算出來。Kafka冪等性那輪區(qū)分人的也不是背不背得出PID和Sequence Number而是能不能意識到“生產(chǎn)端冪等≠消費端冪等”以及遇到跨分區(qū)一致性問題時有什么工具可用。AI Agent和RAG那輪面試官根本不在意你是不是AI專家他在意的是你有沒有系統(tǒng)工程思維知不知道圖片知識庫的存儲與檢索是兩件不同的事知不知道大模型調(diào)用的延遲會對整個后端線程模型造成什么沖擊?；貋碇笪易隽艘患掳熏F(xiàn)在負(fù)責(zé)的系統(tǒng)里所有沒指定線程池的Async全部抓出來改成了有界隊列版本給Kafka消費者補了Redis冪等標(biāo)記還把多模態(tài)RAG的圖片入庫方案整理成了一篇設(shè)計文檔準(zhǔn)備在下次迭代里試點。這不是為了“把面試上答不上的補回來”而是這些內(nèi)容本來就是生產(chǎn)系統(tǒng)里值得做的事。面試只是把平時欠的賬翻出來給你看而已。最后分享一個小心得面試遇到不會的問題別急著編也別直接說不會。先說自己的第一反應(yīng)再把問題拆成兩三個子問題一個一個往下推。大多數(shù)面試官愿意聽思考過程因為真實工作里也沒有人一口氣給出標(biāo)準(zhǔn)答案。把過程講清楚哪怕結(jié)論不完美也遠(yuǎn)好過給出一個背得滾瓜爛熟但經(jīng)不起追問的標(biāo)準(zhǔn)答案。