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