系列 · 第 9 篇（收官）：跨域、防盜鏈、配置寫法、并發(fā)容量與事件機制)
Spring 面經(jīng)系列 · 第 9 篇收官跨域與防盜鏈、配置寫法、容量并發(fā)、批量插入、事件機制與源碼設(shè)計模式前面八篇走完了 Spring 主干Bean 生命周期、循環(huán)依賴、容器擴展點、AOP、事務(wù)、MVC、Spring Boot、微服務(wù)。這一篇收剩下的八道題它們有個共同特征——不是純八股面試官問它們時手里拿的是你的項目簡歷?！盖岸苏{(diào)接口跨域怎么辦」「防盜鏈做過嗎」「100 萬條數(shù)據(jù)怎么導(dǎo)」「你這服務(wù)能同時扛多少請求」「Controller是單例并發(fā)怎么處理」「讀配置有幾種寫法」「事件監(jiān)聽用過嗎」「源碼里有哪些設(shè)計模式」——這八問的殺傷力不在知識點而在它逼你給出具體數(shù)字、具體類名、具體取舍。說「用 CORS 就行」和「我用 Nginx 反代因為要兼容老瀏覽器」是兩個層次報「8192」和「8192 是連接上限真正并行的是 200 個線程瓶頸在數(shù)據(jù)庫連接池」也是兩個層次。素材是 P07、P08、P10、P11、P13、P16、P41、P42 八個分 P。凡視頻給的具體數(shù)字我一律標注「視頻口述未復(fù)現(xiàn)」。1. 跨域與防盜鏈一個管瀏覽器放行一個管資源訪問這兩件事常被并成一句回答其實不在同一層?？缬駽ORS -- 瀏覽器同源策略 -- 決定「誰家前端能讀到我給的響應(yīng)」 -- 服務(wù)端只負責(zé)把響應(yīng)頭寫對 防盜鏈 -- 服務(wù)端資源訪問控制 -- 決定「誰在拿我的資源」 -- 需要真的攔下來1.1 先釘死「跨域只發(fā)生在瀏覽器」同源比協(xié)議、域名、端口作者補了二級域名不同、IP 不同也算跨域。值得記的是那個反問跨域一定有異常嗎不一定。異常只在前端發(fā)生因為瀏覽器有同源策略后端RestTemplate請求別的域也是跨域但不報錯——沒有瀏覽器就沒人執(zhí)行這條規(guī)矩。推出來的結(jié)論就是兩者的分界線服務(wù)端配 CORS 只是「給瀏覽器一個放行憑據(jù)」對 curl、爬蟲、服務(wù)器間調(diào)用完全無效。想白嫖資源的人根本不看你的響應(yīng)頭。所以「配了 CORS 就等于安全」是錯的作者也因此把防盜鏈單獨做成了一題。1.2 五種方式與各自的邊界方式寫法要點視頻口徑生效層限制與坑什么時候真用JSONP前端dataType指定 jsonp自動帶一個隨機值的callback后端聲明同名參數(shù)接住返回callback(數(shù)據(jù))拼成的格式前后端都寫只支持 GET參數(shù)名兩端耦合改一處改兩邊只剩維護上古系統(tǒng)作者明確它已被 CORS 替代CrossOrigin打在某個 Controller 或方法上后端注解一接口一注解量大了鋪不開只開放一兩個接口WebMvcConfigurer重寫「添加跨域映射」那個方法用注冊器按路徑前綴批量放行后端配置類全局配置類容易膨脹一批接口統(tǒng)一放行CorsFilter注冊一個CorsFilterBean過濾器層與其他 Filter 的先后順序會影響結(jié)果想在入口層全量解決Nginx 反向代理前端站由 Nginx 起舉例 8081帶約定前綴如/cors的請求轉(zhuǎn)到后端 8080接入層換部署拓撲要重配本地開發(fā)得靠 devServer 代理作者最推薦前后端代碼零改動瀏覽器側(cè)還有個細節(jié)復(fù)雜請求會被請求兩次。瀏覽器一旦發(fā)現(xiàn)跨域就自動附加請求頭復(fù)雜請求先發(fā)的第一次是OPTIONS探后端支不支持第二次才真正帶參。視頻強調(diào)這套「由瀏覽器決定」因此依賴瀏覽器版本支持作者口徑是 IE 不低于 10兼容矩陣未核實。再補一個真會被追問的坑這條我核過源碼帶 Cookie 時要設(shè)allowCredentialstrue此時allowedOrigins不能寫*——CorsConfiguration直接拋IllegalArgumentException得顯式列 origins 或改用allowedOriginPatterns。「來源全開 允許憑證」這個看著最省事的配法在框架層根本不成立。Q1跨域和防盜鏈是同一件事的兩種說法嗎不是判定方向還是反的。CORS 是默認禁止、顯式放行不在白名單響應(yīng)照樣發(fā)回去只是瀏覽器拒絕交給 JS 讀防盜鏈是默認允許、主動攔截服務(wù)端自己判來源、身份或時間判不過就 403。兩者甚至?xí)ハ嗖鹋_——我見過服務(wù)端校驗Referer白名單卻沒寫自家前端域名跨域通了、資源全 403。工程上比較穩(wěn)的分工是跨域放接入層訪問控制靠鑒權(quán)、簽名與時效。1.3 三種防盜鏈本質(zhì)都是「提高破解成本」作者的場景很直白數(shù)據(jù)是網(wǎng)站的核心競爭力爬蟲偷資源既壓服務(wù)器又損利益。他也給了這篇最清醒的一句「哪怕你再怎么防也只能增加破解的難度」——只要數(shù)據(jù)能被正常訪問攻擊者就能偽裝成正常用戶。手段判定依據(jù)實現(xiàn)位置作者給的繞過方式Referer 校驗請求頭Referer是否在允許來源不在直接拒Nginx 校驗或 Boot 里聲明一個過濾器取頭判斷直接偽造RefererToken 校驗登錄后下發(fā) token轉(zhuǎn)寫作 “GWT”疑為 JWT未核實每次攜帶缺失或校驗失敗即拒后端攔截器攻擊者打登錄接口拿 token 再帶上時間校驗響應(yīng)時給前端埋時間戳請求回來算差值作者口徑是「停留超過允許時長舉例 300ms判為正常否則視為盜鏈」前端埋點 后端算差值每次偽造請求前sleep一秒共性是單點必破所以作者的落點有兩處值得記時間校驗一定有誤判要疊加拖動驗證碼讓人證明是真人大廠再疊一層行為風(fēng)控——用大數(shù)據(jù)分析行為異常沉淀成黑名單每次請求過濾。合起來就是防盜鏈的真實定位分層疊加 持續(xù)對抗沒有銀彈。300ms 那個閾值方向在轉(zhuǎn)寫里含糊我按「間隔過短判為機器」理解屬筆者判斷。2. 讀配置的六種寫法只談寫法與選型加載原理與優(yōu)先級在 第 7 篇 §7 講過這里不重復(fù)。這題問的是另一個層面同一個 key 落到代碼里有六種寫法。#寫法粒度前提與坑典型場景1Value(${xxx.name})單個 key所在類必須是 Bean配置里必須有這個 key否則啟動報錯故要給默認值${a:b}static/final不生效視頻口徑一兩個開關(guān)、閾值2ConfigurationProperties(prefixxxx)前綴下整棵子樹需可綁定的屬性結(jié)構(gòu)批量綁定作者原話一二十個字段不用寫一二十個注解3注入Environment調(diào)getProperty運行時任意 key它本身就是 Bean直接裝配運行時決定作者舉例配一個目標 class 加isEnable動態(tài)控制某個 Bean 是否生效4實現(xiàn)EnvironmentAware#setEnvironment同上容器回調(diào)賦值不靠注入寫組件的人自定義 starter、自動配置類里取底層 Bean作者說「耦合更低」5PropertySourceValue自定義外部文件作者明確這注解只吃.properties要讀 YAML 得配PropertySourcesPlaceholderConfigurerBean往里放YamlPropertiesFactoryBean指定外部 YAML全局配置之外還有獨立文件6JDKPropertiesInputStream任意文件與 Spring 無關(guān)無占位符無 profile工具類、單測、容器還沒起來的早期作者的選型一句可用前三種最實用后三種都是「讀外部自定義文件」才動。我再加一條新業(yè)務(wù)配置一律走ConfigurationProperties成組、可校驗、IDE 能提示Value只留零散項。最容易出事故的是寫法 1 的兩個靜默失效——類不是 Bean自己new的、字段是static配置就是注不進去且不提示。3. 容量題Spring Boot 可以同時處理多少請求作者開場就承認這題有歧義這個判斷對。歧義在「同時處理」指哪個數(shù)能被接受的連接數(shù) -- maxConnections店里能坐多少桌 真正并行執(zhí)行的 -- maxThreads幾個廚師同時在炒 一秒吃下的請求 -- QPS 并發(fā)數(shù) / 平均耗時出菜速度3.1 四個參數(shù)與帶版本的默認值視頻的比喻很好背Web 服務(wù)器是飯店線程是廚師正式 兼職連接數(shù)是店里能坐的桌數(shù)等待數(shù)是門口能排的隊伍。參數(shù)Boot 屬性名Tomcat 屬性官方默認值飯店比喻最大線程數(shù)server.tomcat.threads.maxmaxThreads200正式兼職總數(shù)真正「同時處理」的量最小空閑線程server.tomcat.threads.min-spareminSpareThreads10常駐正式員工最大連接數(shù)server.tomcat.max-connectionsmaxConnections8192店里能坐的桌數(shù)最大等待數(shù)server.tomcat.accept-countacceptCount100門口能排多少隊連接超時server.tomcat.connection-timeoutconnectionTimeout文檔 60000ms發(fā)行版server.xml寫 20000ms排隊者的耐心默認值不是我的印象是查的Tomcat 9.0 與 Tomcat 10.1 的 Connector 文檔四條一致Spring Boot 2.7 屬性附錄 同值。報數(shù)帶版本是這題的基本禮貌。一條請求的判定順序請求到達 -- ① 連接數(shù) maxConnections 否 -- OS 隊列(acceptCount)再不滿直接拒 ↓ 是 ② 有空閑線程minSpare 都忙則擴到 maxThreads -- ③ 不夠則進線程池隊列 -- ④ 耐心用完 -- connect timeout3.2 視頻的答案和我的不同意見視頻的答法是從 Spring 的配置元數(shù)據(jù) JSON 里查默認值得maxConnections8192、acceptCount100于是「8192 100 8292就是這題的答案」。查元數(shù)據(jù)這個動作值得學(xué)但算法口徑我不認同8292 是「被接受 排隊」的連接總量不是「同時處理」同一刻真正在跑業(yè)務(wù)的線程最多只有 200。只報 8292被追一句「那你的 200 個線程在干什么」就露餡。作者隨后壓了一輪視頻口述未復(fù)現(xiàn)演示配maxConnections30、acceptCount10、maxThreads20、minThreads10接口sleep2 秒壓測線程 100另配連接超時 300ms結(jié)果 140 請求里 40 成功、60 失敗異常率 60%。這組數(shù)字正好把四參數(shù)演完100 請求 -- 30 桌 10 隊 40 被接住 -- 其余 60 耐心只有 300ms、業(yè)務(wù)要 2s -- 全超時 40 里真正并行是 20 個線程 -- 另 20 個進線程池隊列等前一個炒完他的收尾意見很實在這幾個參數(shù)在高并發(fā)應(yīng)用里肯定要調(diào)但要「結(jié)合硬件性能、網(wǎng)絡(luò) IO 模型、實際壓測與監(jiān)控」才能定最優(yōu)。Q2那這題面試里到底怎么答三步。先糾口徑三個概念不是一回事再帶版本報默認值Tomcat NIO 連接器maxConnections8192、acceptCount100、maxThreads200、minSpareThreads10所以理論并行度是 200最后給真正的算法并發(fā) ≈ QPS × 平均響應(yīng)時間一個 200 線程、單請求 100ms 的服務(wù)理論吞吐就在 2000 QPS 附近而實際瓶頸通常在下游數(shù)據(jù)庫連接池、遠程調(diào)用、GC。收尾一句「我們項目實測是……」比背 8292 有效。至于參數(shù)怎么調(diào)到最優(yōu)我的態(tài)度和作者一致點到為止比硬講 IO 模型安全。4. 線程并發(fā)Bean 那半在第 1 篇這半講處理鏈路分工先說清第 1 篇 §6 講「單例 Bean 的字段怎么被并發(fā)讀寫」第 6 篇 §2 講「控制器單例的狀態(tài)問題」。P16 是緊接著追問下來的——除了把成員變量挪進方法還有什么辦法視頻給了四種我按代價排方案做法為什么就安全了代價消滅狀態(tài)變量只聲明在方法里每線程一個棧幀無共享幾乎為零首選換多例Scope(prototype)線程一、二各拿一個新實例操作自己那份每次走完整創(chuàng)建鏈、容器不留引用被單例持有則等于白配ThreadLocal字段包成ThreadLocalset賦get取兩條線程雖共用同一個單例但值綁在各自線程上必須清理線程池復(fù)用會串數(shù)據(jù)同步鎖synchronized方法或代碼塊線程二被擋在外面等前者return釋放鎖才進并行變串行影響吞吐量視頻原話要記的是這四種解法暴露的判斷力多例把并發(fā)壓力換成了創(chuàng)建開銷同步鎖把接口吞吐手動砍成 1。4.1 線程和狀態(tài)在哪兒相遇這題的深度在這張圖Tomcat worker 線程 -- Filter -- DispatcherServlet -- Controller單例 -- Service單例 -- JDBC / 遠程調(diào)用 一條請求 一條線程從頭走到尾同步阻塞模型單例 Controller/Service 是全進程共享的協(xié)作者而請求級狀態(tài)本來就該住在每請求一條線程上。所以 Spring 自己就是ThreadLocal的重度用戶請求上下文RequestContextHolder第 6 篇點過、事務(wù)與那條連接的復(fù)用TransactionSynchronizationManager第 5 篇 §5、語言區(qū)域LocaleContextHolder、AOP 暴露的當前代理exposeProxy第 4 篇。一句話理解框架用線程隔離的上下文放請求級狀態(tài)用無狀態(tài) Bean 放協(xié)作者兩者配合才讓單例 Bean 在高并發(fā)下成立。這才是「Spring 怎么處理并發(fā)」的答案。4.2 ThreadLocal 的兩條風(fēng)險線一是泄漏與臟讀。線程池里線程不銷毀跑完一個任務(wù)接著跑下一個上一次的 value 還掛在ThreadLocalMap上既占內(nèi)存連帶其引用的對象圖又能被下個請求讀到。JDK 17 文檔 能核到的表述是「線程消失后它的 thread-local 副本才會被回收除非還有其他引用」——反過來說線程不死清理只能靠你。寫法沒得商量try { ... } finally { HOLDER.remove(); }或者別自己造用框架給好的上下文。二是異步鏈路踩空。Async方法、DeferredResult、自己提交進線程池的任務(wù)都跑在另一條線程上前面那套上下文一律拿不到。這個坑我在SimpleApplicationEventMulticaster的 javadoc 里看到同一邏輯的官方表述設(shè)了異步 executor 后調(diào)用方不再阻塞但異步執(zhí)行不帶調(diào)用線程的事務(wù)、類加載器等上下文除非 executor 支持。解法是把數(shù)據(jù)當參數(shù)傳或用TaskDecorator復(fù)制上下文ThreadPoolTaskExecutor確有這個字段其余未逐行核對。5. 工程性能線程池把 100 萬條插入從 90 秒壓到 17 秒P08 全程在給數(shù)字均為視頻口述筆者未復(fù)現(xiàn)做法關(guān)鍵配置視頻里的耗時單線程循環(huán)批量插 100 萬無并發(fā)90 多秒接近 100切 100 份 × 每份 1 萬逐份異步批量保存線程池核心 32 / 最大 6616 核17 秒左右繼續(xù)加線程核心 100 / 最大 20016 秒幾乎沒變第三步才是重點作者結(jié)論一句可背「線程并不是越多越好改善不大反而浪費資源這些資源該留給別的業(yè)務(wù)」。5.1 抽成可復(fù)用套路造數(shù)/讀源 -- 切片每片 1 萬 -- 線程池逐片提交 -- 每片一次批量寫 countDown -- latch.await() 收口 -- 統(tǒng)計耗時切片大小一片對應(yīng)一次批量寫。太大容易撞報文長度限制和長事務(wù)max_allowed_packet的具體值未核實太小則網(wǎng)絡(luò)往返占大頭。用CountDownLatch收口計數(shù)等于片數(shù)這里是 100每份保存完countDown()主線程await()到全部異步線程跑完再統(tǒng)計耗時。我補一句await()不配超時一個卡死的任務(wù)會讓主線程永遠掛著。線程數(shù)按任務(wù)性質(zhì)定作者先分兩類——IO 密集讀文件、走網(wǎng)絡(luò)會阻塞、CPU 反而閑與 CPU 密集數(shù)據(jù)處理、排序、分析CPU 滿載并判定操作數(shù)據(jù)庫是 IO 密集于是核心線程按核數(shù) ×2他補 1 是「防不可預(yù)料的阻塞時 CPU 能切給多余線程」16 核給 32/33。他講最大線程數(shù)時前后不一先說四倍又說「也就是核心的兩倍66」我按 66 理解成 2 倍加余量這類公式在面試里說「按任務(wù)類型定、壓測收口」更穩(wěn)。Async要配自定義線程池作者口徑是「Async默認不推薦直接用但在 Boot 里太方便只要把自定義線程池 Bean 設(shè)成它用的線程池就沒問題」。他還點了ThreadPoolTaskExecutor與 JDKThreadPoolExecutor的區(qū)別核心數(shù)、最大數(shù)、阻塞隊列、空閑等待、拒絕策略都有額外能給每個線程設(shè)名字前綴——排線上堆棧時這條特別值。5.2 它和事務(wù)一致性是什么關(guān)系這段必須主動交代。任務(wù)丟進線程池后執(zhí)行線程變了事務(wù)上下文就斷了這 100 份是 100 個互不相干的事務(wù)完全可能 99 份成功、1 份失敗。多線程事務(wù)為什么保不了一致、那「兩句代碼」的解法第 5 篇 §7 已成篇P39、P03不重復(fù)。所以套路的定位要說準它適合初始化導(dǎo)數(shù)、離線灌數(shù)據(jù)、報表落庫這類「能重跑」的任務(wù)不適合業(yè)務(wù)寫單。真要在業(yè)務(wù)里并發(fā)寫得配三件事——每片冪等重跑不產(chǎn)生重復(fù)、失敗記錄與重試、斷點續(xù)跑或者讓一片要么全成要么全敗靠重跑收斂。別指望線程池替你保住 ACID。Q3為什么開到 100、200 反而不比 32 快因為收益來源不是線程數(shù)而是把串行等待的 IO 時間重疊掉。100 份數(shù)據(jù)、32 并發(fā)已經(jīng)把網(wǎng)絡(luò)和磁盤等待填滿再加線程只是讓更多線程一起去堵同一個瓶頸——數(shù)據(jù)庫連接池上限、單條 INSERT 還是 multi-values、MySQL 服務(wù)端的日志與索引維護。前 32 個是重疊等待后面的是排隊等待切換開銷和鎖競爭還往上加。筆者補一條常被拿來同類優(yōu)化的項Connector/J 的rewriteBatchedStatements視頻沒提默認值與效果未從官方文檔核實。作者的落點是對的參數(shù)靠壓測加上線后監(jiān)控來定大項目還要上動態(tài)線程池——參數(shù)改了不可能重啟而線上線程池的使用情況對程序員是黑盒得在用量觸閾值時告警下發(fā)那套可看 第 8 篇的配置中心如 Nacos。6. Spring 事件機制進程內(nèi)解耦的那一檔作者開場替讀者說了實話大部分同學(xué)不知道事件監(jiān)聽因為學(xué) Spring 時不講、寫代碼也很少用。但它源碼里出現(xiàn)頻率極高——視頻原話是Spring 集成其他框架大量用事件監(jiān)聽做擴展Boot 和各微服務(wù)組件都靠它看源碼繞不過。6.1 三件套與觀察者角色映射組成你要寫的觀察者模式里的角色事件Event繼承ApplicationEvent或直接用內(nèi)置的被發(fā)布出來的通知監(jiān)聽器Listenerimplements ApplicationListenerXxxEvent或方法標EventListener觀察者發(fā)布者Publisher容器已建好業(yè)務(wù)側(cè)調(diào)publishEvent()被觀察者 分發(fā)器ApplicationEventMulticaster業(yè)務(wù)的例子是「下單后減庫存」想把減庫存和下單解耦就發(fā)一個下單事件監(jiān)聽器做后續(xù)。作者的用途判斷也直白——就是給業(yè)務(wù)之間解耦順帶提高可擴展性與可維護性。發(fā)布路徑可以畫成一條鏈publishEvent(event) -- SimpleApplicationEventMulticaster.multicastEvent -- 按事件類型篩監(jiān)聽器 -- 依次 onApplicationEvent默認在調(diào)用線程同步跑完除了自己發(fā)容器在 IOC 加載的多個位置已替我們發(fā)好了。視頻給的數(shù)字是「內(nèi)置五個事件」點名了上下文刷新完畢、啟動、停止、關(guān)閉以及請求處理那一類想在容器 refresh 完成后擴展監(jiān)聽對應(yīng)事件就行——跟第 3 篇 §5 里ContextRefreshedEvent那個收尾擴展點是同一件事數(shù)量與類名清單我未逐一對照 API 核數(shù)。6.2 同步是默認異步有兩條路最容易答錯的就是這點。視頻表述很準事件默認同步發(fā)布——你在這里發(fā)事件必須等監(jiān)聽器代碼執(zhí)行完發(fā)布點后面的語句才繼續(xù)。這點在SimpleApplicationEventMulticaster的 javadoc 里能對上默認所有監(jiān)聽器在調(diào)用線程里被調(diào)用好處是開銷小風(fēng)險是「一個失控的監(jiān)聽器可能堵住整個應(yīng)用」。同一個 javadoc 還給了常被忽略的一條異常處理器默認是 none監(jiān)聽器拋異常會中斷本次廣播并拋回發(fā)布者——所以監(jiān)聽器里必須自己兜異常。改成異步視頻給兩條路給監(jiān)聽加注解或給分發(fā)器設(shè)一個TaskExecutor——底層判斷到你配了 executor就用它起子線程執(zhí)行監(jiān)聽器這就是「異步事件發(fā)布的核心機制是多線程」。要注意的正是 §4.2 那句一旦異步監(jiān)聽器就不在調(diào)用線程的事務(wù)上下文里了。事務(wù)綁定事件視頻未展開實踐最有用的一塊我核過 javadocTransactionalEventListener默認階段是AFTER_COMMIT等事務(wù)提交后才觸發(fā)fallbackExecution默認false當前沒有事務(wù)在跑就把事件丟掉——線上最常見的一類靜默失效就是它。更要緊的是那段警告AFTER_COMMIT/AFTER_ROLLBACK/AFTER_COMPLETION階段事務(wù)已提交或回滾但事務(wù)資源可能仍活躍此時在監(jiān)聽器里繼續(xù)寫庫改動不會被提交要接著落庫得另起事務(wù)REQUIRES_NEW或走異步。Q4事件監(jiān)聽能替掉 MQ 嗎作者取舍很務(wù)實小型應(yīng)用用事件解耦「大一點的應(yīng)用一般用 MQ 替代事件監(jiān)聽」因為分布式場景下 MQ 性能和能力都更合適。我把「不能替」寫成三條① 事件只在當前進程內(nèi)傳多實例部署時另一個實例根本收不到② 沒有持久化和重試進程一重啟還沒跑的監(jiān)聽邏輯就沒了③ 沒有削峰同步模式下發(fā)布者線程直接承擔(dān)監(jiān)聽器耗時。反過來它的價值也明確零外部依賴不必為「下單成功后干點啥」引入 Kafka/RocketMQ 一整套集群、天然貼著事務(wù)邊界、以及它是 Spring 生態(tài)自己擴展自己的方式。判斷標準一句同進程、允許一起掛 → 事件跨進程、要求不丟 → MQ。7. 源碼里的設(shè)計模式十個但別說十個作者的開場條件是「你簡歷寫了熟讀 Spring 源碼」這題就跑不掉。他說整理了十個并給出體現(xiàn)位置轉(zhuǎn)寫里能確認的落點我列全模式視頻給的落點我的口徑與核實狀態(tài)簡單工廠BeanFactory類名可核按 beanName 定義產(chǎn)出實例「它就是簡單工廠」屬模式歸類是口徑工廠方法FactoryBean類名可核容器給外部的是getObject()的產(chǎn)物而非工廠單例單例 Bean / 單例池第 1 篇 §4 已辨析這是容器管的單例不是 GoF 單例模式別混著答代理AOP 底層JDK 動態(tài)代理 / CGLIB代理在哪一步創(chuàng)建見 第 4 篇 §5觀察者事件監(jiān)聽就是本篇 §6 那三個角色能連起來講最好模板方法「幾乎所有外接擴展」各類后置處理器refresh()里一串doXxx、BeanPostProcessor前后兩段第 1、3 篇畫過標簽是視頻口徑責(zé)任鏈AOP 的方法調(diào)用過程攔截器鏈依次往下調(diào)第 4 篇 §6 那條鏈是否嚴格算責(zé)任鏈是筆者判斷適配器Spring MVC作者還沒看 MVC 源碼可以先不說常指HandlerAdapter——視頻中提到筆者未對照源碼核實裝飾器BeanWrapper視頻中提到筆者未對照源碼核實策略把配置類注冊成BeanDefinition時用的excludeFilters/includeFilters轉(zhuǎn)寫作 exclude field體現(xiàn)不同導(dǎo)入導(dǎo)出策略視頻中提到筆者未對照源碼核實這兩個數(shù)組與FilterType確實存在歸類按視頻口徑作者的答題策略建議照搬記住五六個就夠——工廠、單例、代理、觀察者、責(zé)任鏈這五個基本白撿模板方法屬于「任何框架都用了無腦答」真把十個背滿「面試官已經(jīng)沒耐心聽下去了」。我和他的用法略有不同這題的加分點是模式 具體類名 它解決了什么這三件套。講清兩個FactoryBean解決「實例化過程要我自己控制」SimpleApplicationEventMulticaster解決「發(fā)布方與訂閱方互不知曉」比報十個名字有效。本文覆蓋分 P分 P視頻原始標題本文對應(yīng)小節(jié)P07SpringBoot防盜鏈的3種方式1.3三種手段與「只能增加破解難度」P08springboot線程池百萬數(shù)據(jù)插入5三段耗時、切片 線程池 CountDownLatch套路P10SpringBoot解決跨域的5種方式1.1、1.2五種方式對照表、預(yù)檢與瀏覽器限制P11SpringBoot讀配置的6種方式2六種寫法對照表與選型P13SpringBoot可以同時處理多少請求3四參數(shù)默認值、飯店比喻、8292 的口徑爭議P16Spring如何處理線程并發(fā)問題4四種解法 鏈路上的 ThreadLocal、泄漏與異步P41Spring事件監(jiān)聽的核心機制是什么6三件套、同步默認、異步兩條路、事務(wù)綁定P42Spring源碼用到了哪些設(shè)計模式7十個模式對照表與答題策略最后總結(jié)這八題串起來是同一類問題面試官在驗證你有沒有把框架放進真實流量里跑過。我的判斷分四層。第一跨域與防盜鏈必須一起講跨域是瀏覽器的規(guī)矩、服務(wù)端只是配合防盜鏈是服務(wù)端的判定、得自己攔。五種跨域里真正只剩兩條能用——CorsFilter/WebMvcConfigurer管開發(fā)期Nginx 反代管部署期JSONP 是歷史。第二容量題和并發(fā)題都埋著口徑陷阱。8292 是連接數(shù)不是并發(fā)數(shù)同步鎖是安全但不是方案能立住的表達是并行度看maxThreads容量看 QPS × RT瓶頸看下游以及Spring 靠「無狀態(tài) Bean 線程隔離上下文」支撐并發(fā)你寫的 ThreadLocal 只在同一線程內(nèi)成立異步一律踩空。第三性能類題目必須答成「數(shù)字 歸因 收口方式」。17 秒比 90 秒快靠的是重疊 IO 等待不是線程多歸因講清了作者那句「參數(shù)要靠壓測和監(jiān)控定、大項目上動態(tài)線程池」才不是套話。批量插入還要補一條邊界它是能重跑的任務(wù)不是能保整體一致的業(yè)務(wù)寫單——主動交代事務(wù)邊界比等追問好。第四P41、P42 是源碼收尾。事件機制一句話同進程、允許丟、零依賴 → 事件跨進程、不能丟、要削峰 → MQ。設(shè)計模式別貪多能連著類名講兩三個比背十個名字更像看過源碼的人。事實說明視頻里給的事實只代表轉(zhuǎn)寫表述錯字我已按書面術(shù)語修正跨域異常只在前端發(fā)生后端RestTemplate/HTTP client 請求別的域不報錯五種方案為 JSONP只支持 GET、兩端耦合、CrossOrigin單接口、WebMvcConfigurer按前綴批量、CorsFilter全量、Nginx 反代作者最推薦前后端零改動復(fù)雜請求先OPTIONS預(yù)檢、可能請求兩次且需瀏覽器版本支持舉例 IE 不低于 10。三種防盜鏈為 RefererNginx 或過濾器校驗可偽造、Token登錄下發(fā)可合法獲取后攜帶、時間戳差值舉例 300ms可被「請求前睡一秒」繞過并建議疊加拖動驗證碼、大廠再疊行為分析與黑名單。讀配置六寫法為Value、ConfigurationProperties、注入Environment、EnvironmentAware、PropertySource作者稱只吃 propertiesYAML 需PropertySourcesPlaceholderConfigurerYamlPropertiesFactoryBean、JDKProperties手讀流結(jié)論是前三種最實用Value須是 Bean、key 缺失啟動報錯、static/final 不生效。容量題飯店比喻與四參數(shù)含義演示配置 30/10/20/10、超時 300ms、sleep 2s、壓測 100 得 40 成功 60 失敗查元數(shù)據(jù)得默認值 8192 100 8292。并發(fā)題局部變量、prototype、ThreadLocal、synchronized四種解法作者明確最后一種影響吞吐。批量插入90 多秒 → 切 100 份 × 1 萬 線程池核心 32/最大 66CountDownLatch→ 17 秒 → 核心 100/最大 200 → 16 秒Async默認不推薦直接用、需自定義線程池 BeanThreadPoolTaskExecutor比 JDK 的多線程名前綴IO 密集可核數(shù) ×21 兜底后續(xù)靠壓測、監(jiān)控與動態(tài)線程池。事件監(jiān)聽三部分為事件、監(jiān)聽器、發(fā)布者核心機制是觀察者模式內(nèi)置約五個事件默認同步阻塞異步靠加注解或給分發(fā)器配TaskExecutor小應(yīng)用用事件、大應(yīng)用用 MQ。設(shè)計模式整理十個轉(zhuǎn)寫能確認的落點見 §7 表建議答五六個即可。官方文檔 / 公開事實本次親自核實鏈接見文末① Tomcat 9.0 與 Tomcat 10.1 的 Connector 文檔NIO 連接器默認maxThreads200、minSpareThreads10、acceptCount100、maxConnections8192connectionTimeout文檔默認 60000ms發(fā)行版server.xml寫 20000ms達到maxConnections后「接受但不處理」再一個連接、之后由 OS 按acceptCount排隊② Spring Boot 2.7.18 屬性附錄 中對應(yīng)四項同值③ Spring Framework APIcurrent頁面顯示 7.0.9的SimpleApplicationEventMulticaster默認在調(diào)用線程通知所有監(jiān)聽器原文警告失控監(jiān)聽器可堵住應(yīng)用setTaskExecutor可改異步、但異步執(zhí)行不參與調(diào)用線程的事務(wù)/類加載上下文ErrorHandler默認 none、監(jiān)聽器異常中斷本次廣播并拋給發(fā)布者④ 同版本TransactionalEventListenerphase默認AFTER_COMMITfallbackExecution默認false無事務(wù)時事件被丟棄并警告此階段繼續(xù)寫庫的改動不會被提交⑤ v6.1.14 源碼ThreadPoolTaskExecutorcorePoolSize1、maxPoolSizeInteger.MAX_VALUE、keepAliveSeconds60、queueCapacityInteger.MAX_VALUEqueueCapacity0時用SynchronousQueue有taskDecorator字段⑥ 同 tag 源碼CorsConfigurationallowCredentialstrue且allowedOrigins含*時拋IllegalArgumentException并提示改用allowedOriginPatterns⑦ JDK 17ThreadLocalAPI線程消失后其 thread-local 副本才可被回收除非存在其他引用。源碼原文因raw.githubusercontent.com連接被重置改由 jsDelivr 的 GitHub 鏡像按同一 tag 拉取。筆者判斷 / 未核實① 「8292 是本題答案」是視頻口徑我判定它混淆連接上限與并行度該反駁屬筆者判斷② P13 的 40 成功/60 失敗/異常率 60%以及 P08 的 90 多秒/17 秒/16 秒與 32、66、100、200 這些線程數(shù)全是視頻口述、未復(fù)現(xiàn)的觀察值不構(gòu)成性能結(jié)論③ 壓測工具轉(zhuǎn)寫作 “g matter”我按 JMeter 理解屬推測④ 「CORS 需 IE10 及以上」的兼容矩陣、Nginx 校驗 Referer 的指令名與寫法、max_allowed_packet默認值均未核實⑤ 時間戳防盜鏈 300ms 的閾值方向在轉(zhuǎn)寫里含糊我按「間隔過短判為機器」理解改用服務(wù)端下發(fā)帶時效的一次性簽名屬筆者建議⑥PropertySource只支持 properties、YAML 必須靠YamlPropertiesFactoryBean是視頻口徑Value在 static/final 上失效的確切成因、ConfigurationProperties需要哪些開啟方式如EnableConfigurationProperties未核對⑦Async未指定 executor 時底層退化成什么執(zhí)行器我沒核到源碼v6.1.14 里該類父類文件的路徑與我嘗試的不一致故只轉(zhuǎn)述作者的「默認不推薦直接用」Boot 自動配置那個線程池的默認參數(shù)也未核實⑧ThreadLocalMap「弱鍵強值」這條常見表述我只核到 JDK 文檔「線程消失后才回收」那句Entry 引用強度未看源碼⑨ MySQL 的rewriteBatchedStatements、以及數(shù)據(jù)庫連接池上限如 HikariCPmaximumPoolSize會卡住并發(fā)寫都是筆者補充默認值與效果未從官方文檔核實⑩ 「200 線程 × 100ms ≈ 2000 QPS」是我給的分析框架視頻沒有且假設(shè)了純阻塞、無下游瓶頸? P41「內(nèi)置五個事件」的確切數(shù)量與類名清單、以及 Boot/Spring Cloud 各組件靠事件集成的具體落點未逐一對照源碼? P42 表中標「視頻中提到筆者未對照源碼核實」的三處MVC 適配器HandlerAdapter、BeanWrapper歸裝飾器、excludeFilters/includeFilters歸策略以及把BeanFactory/FactoryBean歸為簡單工廠與工廠方法、把后置處理器歸為模板方法、把 AOP 調(diào)用鏈歸為責(zé)任鏈都屬模式歸類源碼里不會有這種注釋? 文中判定鏈與流程示意是我按轉(zhuǎn)寫描述和文檔行為重繪的不代表視頻畫面原圖。參考資料 致謝[1] Spring面經(jīng)-嗶哩嗶哩77 個分 P 的 Spring 面經(jīng)合集本文取材其中 P07、P08、P10、P11、P13、P16、P41、P42 八段文中一律稱「視頻作者」感謝他每題都配了可跑的例子。[2] Apache Tomcat 9.0 配置文檔 · The HTTP Connector / Tomcat 10.1 同頁線程數(shù)、連接數(shù)、acceptCount、connectionTimeout默認值。[3] Spring Boot 2.7.18 參考文檔 · Application Properties 附錄server.tomcat.*屬性名與默認值。[4] Spring Framework API · SimpleApplicationEventMulticaster / TransactionalEventListener同步默認、異步 executor 的上下文限制、AFTER_COMMIT與fallbackExecution。[5] Spring Framework v6.1.14 源碼 · ThreadPoolTaskExecutor / CorsConfiguration線程池默認值、allowCredentials與*的沖突經(jīng) jsDelivr 鏡像核對原文。[6] Spring Framework 官網(wǎng) / Spring Boot 官網(wǎng) / Nginx 官網(wǎng) / MySQL 官網(wǎng) / Apache JMeter 官網(wǎng) / Apache Kafka 官網(wǎng) / Apache RocketMQ 官網(wǎng) / Nacos 官網(wǎng) / Oracle JDK 17 API。[7] 同系列前八篇Bean 生命周期、循環(huán)依賴、容器擴展點、AOP 與代理、事務(wù)、Spring MVC、Spring Boot、微服務(wù)本篇所有交叉引用只給一句指向不重復(fù)展開。 Spring 面經(jīng)系列 · 第 9 篇（收官）：跨域、防盜鏈、配置寫法、并發(fā)容量與事件機制
Spring 面經(jīng)系列 · 第 9 篇收官跨域與防盜鏈、配置寫法、容量并發(fā)、批量插入、事件機制與源碼設(shè)計模式前面八篇走完了 Spring 主干Bean 生命周期、循環(huán)依賴、容器擴展點、AOP、事務(wù)、MVC、Spring Boot、微服務(wù)。這一篇收剩下的八道題它們有個共同特征——不是純八股面試官問它們時手里拿的是你的項目簡歷?！盖岸苏{(diào)接口跨域怎么辦」「防盜鏈做過嗎」「100 萬條數(shù)據(jù)怎么導(dǎo)」「你這服務(wù)能同時扛多少請求」「Controller是單例并發(fā)怎么處理」「讀配置有幾種寫法」「事件監(jiān)聽用過嗎」「源碼里有哪些設(shè)計模式」——這八問的殺傷力不在知識點而在它逼你給出具體數(shù)字、具體類名、具體取舍。說「用 CORS 就行」和「我用 Nginx 反代因為要兼容老瀏覽器」是兩個層次報「8192」和「8192 是連接上限真正并行的是 200 個線程瓶頸在數(shù)據(jù)庫連接池」也是兩個層次。素材是 P07、P08、P10、P11、P13、P16、P41、P42 八個分 P。凡視頻給的具體數(shù)字我一律標注「視頻口述未復(fù)現(xiàn)」。1. 跨域與防盜鏈一個管瀏覽器放行一個管資源訪問這兩件事常被并成一句回答其實不在同一層?？缬駽ORS -- 瀏覽器同源策略 -- 決定「誰家前端能讀到我給的響應(yīng)」 -- 服務(wù)端只負責(zé)把響應(yīng)頭寫對 防盜鏈 -- 服務(wù)端資源訪問控制 -- 決定「誰在拿我的資源」 -- 需要真的攔下來1.1 先釘死「跨域只發(fā)生在瀏覽器」同源比協(xié)議、域名、端口作者補了二級域名不同、IP 不同也算跨域。值得記的是那個反問跨域一定有異常嗎不一定。異常只在前端發(fā)生因為瀏覽器有同源策略后端RestTemplate請求別的域也是跨域但不報錯——沒有瀏覽器就沒人執(zhí)行這條規(guī)矩。推出來的結(jié)論就是兩者的分界線服務(wù)端配 CORS 只是「給瀏覽器一個放行憑據(jù)」對 curl、爬蟲、服務(wù)器間調(diào)用完全無效。想白嫖資源的人根本不看你的響應(yīng)頭。所以「配了 CORS 就等于安全」是錯的作者也因此把防盜鏈單獨做成了一題。1.2 五種方式與各自的邊界方式寫法要點視頻口徑生效層限制與坑什么時候真用JSONP前端dataType指定 jsonp自動帶一個隨機值的callback后端聲明同名參數(shù)接住返回callback(數(shù)據(jù))拼成的格式前后端都寫只支持 GET參數(shù)名兩端耦合改一處改兩邊只剩維護上古系統(tǒng)作者明確它已被 CORS 替代CrossOrigin打在某個 Controller 或方法上后端注解一接口一注解量大了鋪不開只開放一兩個接口WebMvcConfigurer重寫「添加跨域映射」那個方法用注冊器按路徑前綴批量放行后端配置類全局配置類容易膨脹一批接口統(tǒng)一放行CorsFilter注冊一個CorsFilterBean過濾器層與其他 Filter 的先后順序會影響結(jié)果想在入口層全量解決Nginx 反向代理前端站由 Nginx 起舉例 8081帶約定前綴如/cors的請求轉(zhuǎn)到后端 8080接入層換部署拓撲要重配本地開發(fā)得靠 devServer 代理作者最推薦前后端代碼零改動瀏覽器側(cè)還有個細節(jié)復(fù)雜請求會被請求兩次。瀏覽器一旦發(fā)現(xiàn)跨域就自動附加請求頭復(fù)雜請求先發(fā)的第一次是OPTIONS探后端支不支持第二次才真正帶參。視頻強調(diào)這套「由瀏覽器決定」因此依賴瀏覽器版本支持作者口徑是 IE 不低于 10兼容矩陣未核實。再補一個真會被追問的坑這條我核過源碼帶 Cookie 時要設(shè)allowCredentialstrue此時allowedOrigins不能寫*——CorsConfiguration直接拋IllegalArgumentException得顯式列 origins 或改用allowedOriginPatterns。「來源全開 允許憑證」這個看著最省事的配法在框架層根本不成立。Q1跨域和防盜鏈是同一件事的兩種說法嗎不是判定方向還是反的。CORS 是默認禁止、顯式放行不在白名單響應(yīng)照樣發(fā)回去只是瀏覽器拒絕交給 JS 讀防盜鏈是默認允許、主動攔截服務(wù)端自己判來源、身份或時間判不過就 403。兩者甚至?xí)ハ嗖鹋_——我見過服務(wù)端校驗Referer白名單卻沒寫自家前端域名跨域通了、資源全 403。工程上比較穩(wěn)的分工是跨域放接入層訪問控制靠鑒權(quán)、簽名與時效。1.3 三種防盜鏈本質(zhì)都是「提高破解成本」作者的場景很直白數(shù)據(jù)是網(wǎng)站的核心競爭力爬蟲偷資源既壓服務(wù)器又損利益。他也給了這篇最清醒的一句「哪怕你再怎么防也只能增加破解的難度」——只要數(shù)據(jù)能被正常訪問攻擊者就能偽裝成正常用戶。手段判定依據(jù)實現(xiàn)位置作者給的繞過方式Referer 校驗請求頭Referer是否在允許來源不在直接拒Nginx 校驗或 Boot 里聲明一個過濾器取頭判斷直接偽造RefererToken 校驗登錄后下發(fā) token轉(zhuǎn)寫作 “GWT”疑為 JWT未核實每次攜帶缺失或校驗失敗即拒后端攔截器攻擊者打登錄接口拿 token 再帶上時間校驗響應(yīng)時給前端埋時間戳請求回來算差值作者口徑是「停留超過允許時長舉例 300ms判為正常否則視為盜鏈」前端埋點 后端算差值每次偽造請求前sleep一秒共性是單點必破所以作者的落點有兩處值得記時間校驗一定有誤判要疊加拖動驗證碼讓人證明是真人大廠再疊一層行為風(fēng)控——用大數(shù)據(jù)分析行為異常沉淀成黑名單每次請求過濾。合起來就是防盜鏈的真實定位分層疊加 持續(xù)對抗沒有銀彈。300ms 那個閾值方向在轉(zhuǎn)寫里含糊我按「間隔過短判為機器」理解屬筆者判斷。2. 讀配置的六種寫法只談寫法與選型加載原理與優(yōu)先級在 第 7 篇 §7 講過這里不重復(fù)。這題問的是另一個層面同一個 key 落到代碼里有六種寫法。#寫法粒度前提與坑典型場景1Value(${xxx.name})單個 key所在類必須是 Bean配置里必須有這個 key否則啟動報錯故要給默認值${a:b}static/final不生效視頻口徑一兩個開關(guān)、閾值2ConfigurationProperties(prefixxxx)前綴下整棵子樹需可綁定的屬性結(jié)構(gòu)批量綁定作者原話一二十個字段不用寫一二十個注解3注入Environment調(diào)getProperty運行時任意 key它本身就是 Bean直接裝配運行時決定作者舉例配一個目標 class 加isEnable動態(tài)控制某個 Bean 是否生效4實現(xiàn)EnvironmentAware#setEnvironment同上容器回調(diào)賦值不靠注入寫組件的人自定義 starter、自動配置類里取底層 Bean作者說「耦合更低」5PropertySourceValue自定義外部文件作者明確這注解只吃.properties要讀 YAML 得配PropertySourcesPlaceholderConfigurerBean往里放YamlPropertiesFactoryBean指定外部 YAML全局配置之外還有獨立文件6JDKPropertiesInputStream任意文件與 Spring 無關(guān)無占位符無 profile工具類、單測、容器還沒起來的早期作者的選型一句可用前三種最實用后三種都是「讀外部自定義文件」才動。我再加一條新業(yè)務(wù)配置一律走ConfigurationProperties成組、可校驗、IDE 能提示Value只留零散項。最容易出事故的是寫法 1 的兩個靜默失效——類不是 Bean自己new的、字段是static配置就是注不進去且不提示。3. 容量題Spring Boot 可以同時處理多少請求作者開場就承認這題有歧義這個判斷對。歧義在「同時處理」指哪個數(shù)能被接受的連接數(shù) -- maxConnections店里能坐多少桌 真正并行執(zhí)行的 -- maxThreads幾個廚師同時在炒 一秒吃下的請求 -- QPS 并發(fā)數(shù) / 平均耗時出菜速度3.1 四個參數(shù)與帶版本的默認值視頻的比喻很好背Web 服務(wù)器是飯店線程是廚師正式 兼職連接數(shù)是店里能坐的桌數(shù)等待數(shù)是門口能排的隊伍。參數(shù)Boot 屬性名Tomcat 屬性官方默認值飯店比喻最大線程數(shù)server.tomcat.threads.maxmaxThreads200正式兼職總數(shù)真正「同時處理」的量最小空閑線程server.tomcat.threads.min-spareminSpareThreads10常駐正式員工最大連接數(shù)server.tomcat.max-connectionsmaxConnections8192店里能坐的桌數(shù)最大等待數(shù)server.tomcat.accept-countacceptCount100門口能排多少隊連接超時server.tomcat.connection-timeoutconnectionTimeout文檔 60000ms發(fā)行版server.xml寫 20000ms排隊者的耐心默認值不是我的印象是查的Tomcat 9.0 與 Tomcat 10.1 的 Connector 文檔四條一致Spring Boot 2.7 屬性附錄 同值。報數(shù)帶版本是這題的基本禮貌。一條請求的判定順序請求到達 -- ① 連接數(shù) maxConnections 否 -- OS 隊列(acceptCount)再不滿直接拒 ↓ 是 ② 有空閑線程minSpare 都忙則擴到 maxThreads -- ③ 不夠則進線程池隊列 -- ④ 耐心用完 -- connect timeout3.2 視頻的答案和我的不同意見視頻的答法是從 Spring 的配置元數(shù)據(jù) JSON 里查默認值得maxConnections8192、acceptCount100于是「8192 100 8292就是這題的答案」。查元數(shù)據(jù)這個動作值得學(xué)但算法口徑我不認同8292 是「被接受 排隊」的連接總量不是「同時處理」同一刻真正在跑業(yè)務(wù)的線程最多只有 200。只報 8292被追一句「那你的 200 個線程在干什么」就露餡。作者隨后壓了一輪視頻口述未復(fù)現(xiàn)演示配maxConnections30、acceptCount10、maxThreads20、minThreads10接口sleep2 秒壓測線程 100另配連接超時 300ms結(jié)果 140 請求里 40 成功、60 失敗異常率 60%。這組數(shù)字正好把四參數(shù)演完100 請求 -- 30 桌 10 隊 40 被接住 -- 其余 60 耐心只有 300ms、業(yè)務(wù)要 2s -- 全超時 40 里真正并行是 20 個線程 -- 另 20 個進線程池隊列等前一個炒完他的收尾意見很實在這幾個參數(shù)在高并發(fā)應(yīng)用里肯定要調(diào)但要「結(jié)合硬件性能、網(wǎng)絡(luò) IO 模型、實際壓測與監(jiān)控」才能定最優(yōu)。Q2那這題面試里到底怎么答三步。先糾口徑三個概念不是一回事再帶版本報默認值Tomcat NIO 連接器maxConnections8192、acceptCount100、maxThreads200、minSpareThreads10所以理論并行度是 200最后給真正的算法并發(fā) ≈ QPS × 平均響應(yīng)時間一個 200 線程、單請求 100ms 的服務(wù)理論吞吐就在 2000 QPS 附近而實際瓶頸通常在下游數(shù)據(jù)庫連接池、遠程調(diào)用、GC。收尾一句「我們項目實測是……」比背 8292 有效。至于參數(shù)怎么調(diào)到最優(yōu)我的態(tài)度和作者一致點到為止比硬講 IO 模型安全。4. 線程并發(fā)Bean 那半在第 1 篇這半講處理鏈路分工先說清第 1 篇 §6 講「單例 Bean 的字段怎么被并發(fā)讀寫」第 6 篇 §2 講「控制器單例的狀態(tài)問題」。P16 是緊接著追問下來的——除了把成員變量挪進方法還有什么辦法視頻給了四種我按代價排方案做法為什么就安全了代價消滅狀態(tài)變量只聲明在方法里每線程一個棧幀無共享幾乎為零首選換多例Scope(prototype)線程一、二各拿一個新實例操作自己那份每次走完整創(chuàng)建鏈、容器不留引用被單例持有則等于白配ThreadLocal字段包成ThreadLocalset賦get取兩條線程雖共用同一個單例但值綁在各自線程上必須清理線程池復(fù)用會串數(shù)據(jù)同步鎖synchronized方法或代碼塊線程二被擋在外面等前者return釋放鎖才進并行變串行影響吞吐量視頻原話要記的是這四種解法暴露的判斷力多例把并發(fā)壓力換成了創(chuàng)建開銷同步鎖把接口吞吐手動砍成 1。4.1 線程和狀態(tài)在哪兒相遇這題的深度在這張圖Tomcat worker 線程 -- Filter -- DispatcherServlet -- Controller單例 -- Service單例 -- JDBC / 遠程調(diào)用 一條請求 一條線程從頭走到尾同步阻塞模型單例 Controller/Service 是全進程共享的協(xié)作者而請求級狀態(tài)本來就該住在每請求一條線程上。所以 Spring 自己就是ThreadLocal的重度用戶請求上下文RequestContextHolder第 6 篇點過、事務(wù)與那條連接的復(fù)用TransactionSynchronizationManager第 5 篇 §5、語言區(qū)域LocaleContextHolder、AOP 暴露的當前代理exposeProxy第 4 篇。一句話理解框架用線程隔離的上下文放請求級狀態(tài)用無狀態(tài) Bean 放協(xié)作者兩者配合才讓單例 Bean 在高并發(fā)下成立。這才是「Spring 怎么處理并發(fā)」的答案。4.2 ThreadLocal 的兩條風(fēng)險線一是泄漏與臟讀。線程池里線程不銷毀跑完一個任務(wù)接著跑下一個上一次的 value 還掛在ThreadLocalMap上既占內(nèi)存連帶其引用的對象圖又能被下個請求讀到。JDK 17 文檔 能核到的表述是「線程消失后它的 thread-local 副本才會被回收除非還有其他引用」——反過來說線程不死清理只能靠你。寫法沒得商量try { ... } finally { HOLDER.remove(); }或者別自己造用框架給好的上下文。二是異步鏈路踩空。Async方法、DeferredResult、自己提交進線程池的任務(wù)都跑在另一條線程上前面那套上下文一律拿不到。這個坑我在SimpleApplicationEventMulticaster的 javadoc 里看到同一邏輯的官方表述設(shè)了異步 executor 后調(diào)用方不再阻塞但異步執(zhí)行不帶調(diào)用線程的事務(wù)、類加載器等上下文除非 executor 支持。解法是把數(shù)據(jù)當參數(shù)傳或用TaskDecorator復(fù)制上下文ThreadPoolTaskExecutor確有這個字段其余未逐行核對。5. 工程性能線程池把 100 萬條插入從 90 秒壓到 17 秒P08 全程在給數(shù)字均為視頻口述筆者未復(fù)現(xiàn)做法關(guān)鍵配置視頻里的耗時單線程循環(huán)批量插 100 萬無并發(fā)90 多秒接近 100切 100 份 × 每份 1 萬逐份異步批量保存線程池核心 32 / 最大 6616 核17 秒左右繼續(xù)加線程核心 100 / 最大 20016 秒幾乎沒變第三步才是重點作者結(jié)論一句可背「線程并不是越多越好改善不大反而浪費資源這些資源該留給別的業(yè)務(wù)」。5.1 抽成可復(fù)用套路造數(shù)/讀源 -- 切片每片 1 萬 -- 線程池逐片提交 -- 每片一次批量寫 countDown -- latch.await() 收口 -- 統(tǒng)計耗時切片大小一片對應(yīng)一次批量寫。太大容易撞報文長度限制和長事務(wù)max_allowed_packet的具體值未核實太小則網(wǎng)絡(luò)往返占大頭。用CountDownLatch收口計數(shù)等于片數(shù)這里是 100每份保存完countDown()主線程await()到全部異步線程跑完再統(tǒng)計耗時。我補一句await()不配超時一個卡死的任務(wù)會讓主線程永遠掛著。線程數(shù)按任務(wù)性質(zhì)定作者先分兩類——IO 密集讀文件、走網(wǎng)絡(luò)會阻塞、CPU 反而閑與 CPU 密集數(shù)據(jù)處理、排序、分析CPU 滿載并判定操作數(shù)據(jù)庫是 IO 密集于是核心線程按核數(shù) ×2他補 1 是「防不可預(yù)料的阻塞時 CPU 能切給多余線程」16 核給 32/33。他講最大線程數(shù)時前后不一先說四倍又說「也就是核心的兩倍66」我按 66 理解成 2 倍加余量這類公式在面試里說「按任務(wù)類型定、壓測收口」更穩(wěn)。Async要配自定義線程池作者口徑是「Async默認不推薦直接用但在 Boot 里太方便只要把自定義線程池 Bean 設(shè)成它用的線程池就沒問題」。他還點了ThreadPoolTaskExecutor與 JDKThreadPoolExecutor的區(qū)別核心數(shù)、最大數(shù)、阻塞隊列、空閑等待、拒絕策略都有額外能給每個線程設(shè)名字前綴——排線上堆棧時這條特別值。5.2 它和事務(wù)一致性是什么關(guān)系這段必須主動交代。任務(wù)丟進線程池后執(zhí)行線程變了事務(wù)上下文就斷了這 100 份是 100 個互不相干的事務(wù)完全可能 99 份成功、1 份失敗。多線程事務(wù)為什么保不了一致、那「兩句代碼」的解法第 5 篇 §7 已成篇P39、P03不重復(fù)。所以套路的定位要說準它適合初始化導(dǎo)數(shù)、離線灌數(shù)據(jù)、報表落庫這類「能重跑」的任務(wù)不適合業(yè)務(wù)寫單。真要在業(yè)務(wù)里并發(fā)寫得配三件事——每片冪等重跑不產(chǎn)生重復(fù)、失敗記錄與重試、斷點續(xù)跑或者讓一片要么全成要么全敗靠重跑收斂。別指望線程池替你保住 ACID。Q3為什么開到 100、200 反而不比 32 快因為收益來源不是線程數(shù)而是把串行等待的 IO 時間重疊掉。100 份數(shù)據(jù)、32 并發(fā)已經(jīng)把網(wǎng)絡(luò)和磁盤等待填滿再加線程只是讓更多線程一起去堵同一個瓶頸——數(shù)據(jù)庫連接池上限、單條 INSERT 還是 multi-values、MySQL 服務(wù)端的日志與索引維護。前 32 個是重疊等待后面的是排隊等待切換開銷和鎖競爭還往上加。筆者補一條常被拿來同類優(yōu)化的項Connector/J 的rewriteBatchedStatements視頻沒提默認值與效果未從官方文檔核實。作者的落點是對的參數(shù)靠壓測加上線后監(jiān)控來定大項目還要上動態(tài)線程池——參數(shù)改了不可能重啟而線上線程池的使用情況對程序員是黑盒得在用量觸閾值時告警下發(fā)那套可看 第 8 篇的配置中心如 Nacos。6. Spring 事件機制進程內(nèi)解耦的那一檔作者開場替讀者說了實話大部分同學(xué)不知道事件監(jiān)聽因為學(xué) Spring 時不講、寫代碼也很少用。但它源碼里出現(xiàn)頻率極高——視頻原話是Spring 集成其他框架大量用事件監(jiān)聽做擴展Boot 和各微服務(wù)組件都靠它看源碼繞不過。6.1 三件套與觀察者角色映射組成你要寫的觀察者模式里的角色事件Event繼承ApplicationEvent或直接用內(nèi)置的被發(fā)布出來的通知監(jiān)聽器Listenerimplements ApplicationListenerXxxEvent或方法標EventListener觀察者發(fā)布者Publisher容器已建好業(yè)務(wù)側(cè)調(diào)publishEvent()被觀察者 分發(fā)器ApplicationEventMulticaster業(yè)務(wù)的例子是「下單后減庫存」想把減庫存和下單解耦就發(fā)一個下單事件監(jiān)聽器做后續(xù)。作者的用途判斷也直白——就是給業(yè)務(wù)之間解耦順帶提高可擴展性與可維護性。發(fā)布路徑可以畫成一條鏈publishEvent(event) -- SimpleApplicationEventMulticaster.multicastEvent -- 按事件類型篩監(jiān)聽器 -- 依次 onApplicationEvent默認在調(diào)用線程同步跑完除了自己發(fā)容器在 IOC 加載的多個位置已替我們發(fā)好了。視頻給的數(shù)字是「內(nèi)置五個事件」點名了上下文刷新完畢、啟動、停止、關(guān)閉以及請求處理那一類想在容器 refresh 完成后擴展監(jiān)聽對應(yīng)事件就行——跟第 3 篇 §5 里ContextRefreshedEvent那個收尾擴展點是同一件事數(shù)量與類名清單我未逐一對照 API 核數(shù)。6.2 同步是默認異步有兩條路最容易答錯的就是這點。視頻表述很準事件默認同步發(fā)布——你在這里發(fā)事件必須等監(jiān)聽器代碼執(zhí)行完發(fā)布點后面的語句才繼續(xù)。這點在SimpleApplicationEventMulticaster的 javadoc 里能對上默認所有監(jiān)聽器在調(diào)用線程里被調(diào)用好處是開銷小風(fēng)險是「一個失控的監(jiān)聽器可能堵住整個應(yīng)用」。同一個 javadoc 還給了常被忽略的一條異常處理器默認是 none監(jiān)聽器拋異常會中斷本次廣播并拋回發(fā)布者——所以監(jiān)聽器里必須自己兜異常。改成異步視頻給兩條路給監(jiān)聽加注解或給分發(fā)器設(shè)一個TaskExecutor——底層判斷到你配了 executor就用它起子線程執(zhí)行監(jiān)聽器這就是「異步事件發(fā)布的核心機制是多線程」。要注意的正是 §4.2 那句一旦異步監(jiān)聽器就不在調(diào)用線程的事務(wù)上下文里了。事務(wù)綁定事件視頻未展開實踐最有用的一塊我核過 javadocTransactionalEventListener默認階段是AFTER_COMMIT等事務(wù)提交后才觸發(fā)fallbackExecution默認false當前沒有事務(wù)在跑就把事件丟掉——線上最常見的一類靜默失效就是它。更要緊的是那段警告AFTER_COMMIT/AFTER_ROLLBACK/AFTER_COMPLETION階段事務(wù)已提交或回滾但事務(wù)資源可能仍活躍此時在監(jiān)聽器里繼續(xù)寫庫改動不會被提交要接著落庫得另起事務(wù)REQUIRES_NEW或走異步。Q4事件監(jiān)聽能替掉 MQ 嗎作者取舍很務(wù)實小型應(yīng)用用事件解耦「大一點的應(yīng)用一般用 MQ 替代事件監(jiān)聽」因為分布式場景下 MQ 性能和能力都更合適。我把「不能替」寫成三條① 事件只在當前進程內(nèi)傳多實例部署時另一個實例根本收不到② 沒有持久化和重試進程一重啟還沒跑的監(jiān)聽邏輯就沒了③ 沒有削峰同步模式下發(fā)布者線程直接承擔(dān)監(jiān)聽器耗時。反過來它的價值也明確零外部依賴不必為「下單成功后干點啥」引入 Kafka/RocketMQ 一整套集群、天然貼著事務(wù)邊界、以及它是 Spring 生態(tài)自己擴展自己的方式。判斷標準一句同進程、允許一起掛 → 事件跨進程、要求不丟 → MQ。7. 源碼里的設(shè)計模式十個但別說十個作者的開場條件是「你簡歷寫了熟讀 Spring 源碼」這題就跑不掉。他說整理了十個并給出體現(xiàn)位置轉(zhuǎn)寫里能確認的落點我列全模式視頻給的落點我的口徑與核實狀態(tài)簡單工廠BeanFactory類名可核按 beanName 定義產(chǎn)出實例「它就是簡單工廠」屬模式歸類是口徑工廠方法FactoryBean類名可核容器給外部的是getObject()的產(chǎn)物而非工廠單例單例 Bean / 單例池第 1 篇 §4 已辨析這是容器管的單例不是 GoF 單例模式別混著答代理AOP 底層JDK 動態(tài)代理 / CGLIB代理在哪一步創(chuàng)建見 第 4 篇 §5觀察者事件監(jiān)聽就是本篇 §6 那三個角色能連起來講最好模板方法「幾乎所有外接擴展」各類后置處理器refresh()里一串doXxx、BeanPostProcessor前后兩段第 1、3 篇畫過標簽是視頻口徑責(zé)任鏈AOP 的方法調(diào)用過程攔截器鏈依次往下調(diào)第 4 篇 §6 那條鏈是否嚴格算責(zé)任鏈是筆者判斷適配器Spring MVC作者還沒看 MVC 源碼可以先不說常指HandlerAdapter——視頻中提到筆者未對照源碼核實裝飾器BeanWrapper視頻中提到筆者未對照源碼核實策略把配置類注冊成BeanDefinition時用的excludeFilters/includeFilters轉(zhuǎn)寫作 exclude field體現(xiàn)不同導(dǎo)入導(dǎo)出策略視頻中提到筆者未對照源碼核實這兩個數(shù)組與FilterType確實存在歸類按視頻口徑作者的答題策略建議照搬記住五六個就夠——工廠、單例、代理、觀察者、責(zé)任鏈這五個基本白撿模板方法屬于「任何框架都用了無腦答」真把十個背滿「面試官已經(jīng)沒耐心聽下去了」。我和他的用法略有不同這題的加分點是模式 具體類名 它解決了什么這三件套。講清兩個FactoryBean解決「實例化過程要我自己控制」SimpleApplicationEventMulticaster解決「發(fā)布方與訂閱方互不知曉」比報十個名字有效。本文覆蓋分 P分 P視頻原始標題本文對應(yīng)小節(jié)P07SpringBoot防盜鏈的3種方式1.3三種手段與「只能增加破解難度」P08springboot線程池百萬數(shù)據(jù)插入5三段耗時、切片 線程池 CountDownLatch套路P10SpringBoot解決跨域的5種方式1.1、1.2五種方式對照表、預(yù)檢與瀏覽器限制P11SpringBoot讀配置的6種方式2六種寫法對照表與選型P13SpringBoot可以同時處理多少請求3四參數(shù)默認值、飯店比喻、8292 的口徑爭議P16Spring如何處理線程并發(fā)問題4四種解法 鏈路上的 ThreadLocal、泄漏與異步P41Spring事件監(jiān)聽的核心機制是什么6三件套、同步默認、異步兩條路、事務(wù)綁定P42Spring源碼用到了哪些設(shè)計模式7十個模式對照表與答題策略最后總結(jié)這八題串起來是同一類問題面試官在驗證你有沒有把框架放進真實流量里跑過。我的判斷分四層。第一跨域與防盜鏈必須一起講跨域是瀏覽器的規(guī)矩、服務(wù)端只是配合防盜鏈是服務(wù)端的判定、得自己攔。五種跨域里真正只剩兩條能用——CorsFilter/WebMvcConfigurer管開發(fā)期Nginx 反代管部署期JSONP 是歷史。第二容量題和并發(fā)題都埋著口徑陷阱。8292 是連接數(shù)不是并發(fā)數(shù)同步鎖是安全但不是方案能立住的表達是并行度看maxThreads容量看 QPS × RT瓶頸看下游以及Spring 靠「無狀態(tài) Bean 線程隔離上下文」支撐并發(fā)你寫的 ThreadLocal 只在同一線程內(nèi)成立異步一律踩空。第三性能類題目必須答成「數(shù)字 歸因 收口方式」。17 秒比 90 秒快靠的是重疊 IO 等待不是線程多歸因講清了作者那句「參數(shù)要靠壓測和監(jiān)控定、大項目上動態(tài)線程池」才不是套話。批量插入還要補一條邊界它是能重跑的任務(wù)不是能保整體一致的業(yè)務(wù)寫單——主動交代事務(wù)邊界比等追問好。第四P41、P42 是源碼收尾。事件機制一句話同進程、允許丟、零依賴 → 事件跨進程、不能丟、要削峰 → MQ。設(shè)計模式別貪多能連著類名講兩三個比背十個名字更像看過源碼的人。事實說明視頻里給的事實只代表轉(zhuǎn)寫表述錯字我已按書面術(shù)語修正跨域異常只在前端發(fā)生后端RestTemplate/HTTP client 請求別的域不報錯五種方案為 JSONP只支持 GET、兩端耦合、CrossOrigin單接口、WebMvcConfigurer按前綴批量、CorsFilter全量、Nginx 反代作者最推薦前后端零改動復(fù)雜請求先OPTIONS預(yù)檢、可能請求兩次且需瀏覽器版本支持舉例 IE 不低于 10。三種防盜鏈為 RefererNginx 或過濾器校驗可偽造、Token登錄下發(fā)可合法獲取后攜帶、時間戳差值舉例 300ms可被「請求前睡一秒」繞過并建議疊加拖動驗證碼、大廠再疊行為分析與黑名單。讀配置六寫法為Value、ConfigurationProperties、注入Environment、EnvironmentAware、PropertySource作者稱只吃 propertiesYAML 需PropertySourcesPlaceholderConfigurerYamlPropertiesFactoryBean、JDKProperties手讀流結(jié)論是前三種最實用Value須是 Bean、key 缺失啟動報錯、static/final 不生效。容量題飯店比喻與四參數(shù)含義演示配置 30/10/20/10、超時 300ms、sleep 2s、壓測 100 得 40 成功 60 失敗查元數(shù)據(jù)得默認值 8192 100 8292。并發(fā)題局部變量、prototype、ThreadLocal、synchronized四種解法作者明確最后一種影響吞吐。批量插入90 多秒 → 切 100 份 × 1 萬 線程池核心 32/最大 66CountDownLatch→ 17 秒 → 核心 100/最大 200 → 16 秒Async默認不推薦直接用、需自定義線程池 BeanThreadPoolTaskExecutor比 JDK 的多線程名前綴IO 密集可核數(shù) ×21 兜底后續(xù)靠壓測、監(jiān)控與動態(tài)線程池。事件監(jiān)聽三部分為事件、監(jiān)聽器、發(fā)布者核心機制是觀察者模式內(nèi)置約五個事件默認同步阻塞異步靠加注解或給分發(fā)器配TaskExecutor小應(yīng)用用事件、大應(yīng)用用 MQ。設(shè)計模式整理十個轉(zhuǎn)寫能確認的落點見 §7 表建議答五六個即可。官方文檔 / 公開事實本次親自核實鏈接見文末① Tomcat 9.0 與 Tomcat 10.1 的 Connector 文檔NIO 連接器默認maxThreads200、minSpareThreads10、acceptCount100、maxConnections8192connectionTimeout文檔默認 60000ms發(fā)行版server.xml寫 20000ms達到maxConnections后「接受但不處理」再一個連接、之后由 OS 按acceptCount排隊② Spring Boot 2.7.18 屬性附錄 中對應(yīng)四項同值③ Spring Framework APIcurrent頁面顯示 7.0.9的SimpleApplicationEventMulticaster默認在調(diào)用線程通知所有監(jiān)聽器原文警告失控監(jiān)聽器可堵住應(yīng)用setTaskExecutor可改異步、但異步執(zhí)行不參與調(diào)用線程的事務(wù)/類加載上下文ErrorHandler默認 none、監(jiān)聽器異常中斷本次廣播并拋給發(fā)布者④ 同版本TransactionalEventListenerphase默認AFTER_COMMITfallbackExecution默認false無事務(wù)時事件被丟棄并警告此階段繼續(xù)寫庫的改動不會被提交⑤ v6.1.14 源碼ThreadPoolTaskExecutorcorePoolSize1、maxPoolSizeInteger.MAX_VALUE、keepAliveSeconds60、queueCapacityInteger.MAX_VALUEqueueCapacity0時用SynchronousQueue有taskDecorator字段⑥ 同 tag 源碼CorsConfigurationallowCredentialstrue且allowedOrigins含*時拋IllegalArgumentException并提示改用allowedOriginPatterns⑦ JDK 17ThreadLocalAPI線程消失后其 thread-local 副本才可被回收除非存在其他引用。源碼原文因raw.githubusercontent.com連接被重置改由 jsDelivr 的 GitHub 鏡像按同一 tag 拉取。筆者判斷 / 未核實① 「8292 是本題答案」是視頻口徑我判定它混淆連接上限與并行度該反駁屬筆者判斷② P13 的 40 成功/60 失敗/異常率 60%以及 P08 的 90 多秒/17 秒/16 秒與 32、66、100、200 這些線程數(shù)全是視頻口述、未復(fù)現(xiàn)的觀察值不構(gòu)成性能結(jié)論③ 壓測工具轉(zhuǎn)寫作 “g matter”我按 JMeter 理解屬推測④ 「CORS 需 IE10 及以上」的兼容矩陣、Nginx 校驗 Referer 的指令名與寫法、max_allowed_packet默認值均未核實⑤ 時間戳防盜鏈 300ms 的閾值方向在轉(zhuǎn)寫里含糊我按「間隔過短判為機器」理解改用服務(wù)端下發(fā)帶時效的一次性簽名屬筆者建議⑥PropertySource只支持 properties、YAML 必須靠YamlPropertiesFactoryBean是視頻口徑Value在 static/final 上失效的確切成因、ConfigurationProperties需要哪些開啟方式如EnableConfigurationProperties未核對⑦Async未指定 executor 時底層退化成什么執(zhí)行器我沒核到源碼v6.1.14 里該類父類文件的路徑與我嘗試的不一致故只轉(zhuǎn)述作者的「默認不推薦直接用」Boot 自動配置那個線程池的默認參數(shù)也未核實⑧ThreadLocalMap「弱鍵強值」這條常見表述我只核到 JDK 文檔「線程消失后才回收」那句Entry 引用強度未看源碼⑨ MySQL 的rewriteBatchedStatements、以及數(shù)據(jù)庫連接池上限如 HikariCPmaximumPoolSize會卡住并發(fā)寫都是筆者補充默認值與效果未從官方文檔核實⑩ 「200 線程 × 100ms ≈ 2000 QPS」是我給的分析框架視頻沒有且假設(shè)了純阻塞、無下游瓶頸? P41「內(nèi)置五個事件」的確切數(shù)量與類名清單、以及 Boot/Spring Cloud 各組件靠事件集成的具體落點未逐一對照源碼? P42 表中標「視頻中提到筆者未對照源碼核實」的三處MVC 適配器HandlerAdapter、BeanWrapper歸裝飾器、excludeFilters/includeFilters歸策略以及把BeanFactory/FactoryBean歸為簡單工廠與工廠方法、把后置處理器歸為模板方法、把 AOP 調(diào)用鏈歸為責(zé)任鏈都屬模式歸類源碼里不會有這種注釋? 文中判定鏈與流程示意是我按轉(zhuǎn)寫描述和文檔行為重繪的不代表視頻畫面原圖。參考資料 致謝[1] Spring面經(jīng)-嗶哩嗶哩77 個分 P 的 Spring 面經(jīng)合集本文取材其中 P07、P08、P10、P11、P13、P16、P41、P42 八段文中一律稱「視頻作者」感謝他每題都配了可跑的例子。[2] Apache Tomcat 9.0 配置文檔 · The HTTP Connector / Tomcat 10.1 同頁線程數(shù)、連接數(shù)、acceptCount、connectionTimeout默認值。[3] Spring Boot 2.7.18 參考文檔 · Application Properties 附錄server.tomcat.*屬性名與默認值。[4] Spring Framework API · SimpleApplicationEventMulticaster / TransactionalEventListener同步默認、異步 executor 的上下文限制、AFTER_COMMIT與fallbackExecution。[5] Spring Framework v6.1.14 源碼 · ThreadPoolTaskExecutor / CorsConfiguration線程池默認值、allowCredentials與*的沖突經(jīng) jsDelivr 鏡像核對原文。[6] Spring Framework 官網(wǎng) / Spring Boot 官網(wǎng) / Nginx 官網(wǎng) / MySQL 官網(wǎng) / Apache JMeter 官網(wǎng) / Apache Kafka 官網(wǎng) / Apache RocketMQ 官網(wǎng) / Nacos 官網(wǎng) / Oracle JDK 17 API。[7] 同系列前八篇Bean 生命周期、循環(huán)依賴、容器擴展點、AOP 與代理、事務(wù)、Spring MVC、Spring Boot、微服務(wù)本篇所有交叉引用只給一句指向不重復(fù)展開。