：@Async線程池、WebFlux與消息隊列全解析)
1. 為什么要做異步調用從一次接口超時說起先講一個真實的場景。之前我給某個后臺管理系統(tǒng)做導出功能用戶在前端點了一個“導出報表”后端同步去數(shù)據(jù)庫里查幾十萬條數(shù)據(jù)再拼裝Excel最后返回文件流。單次執(zhí)行時間普遍在15秒以上前端請求早超時了用戶反復點了幾次后臺直接堆了好幾個線程在處理同一件事。這個問題的根源不在代碼性能而是同步阻塞的調用模型。請求線程從接收到返回全程霸占著不放導出的耗時越長能用線程就越少數(shù)據(jù)庫連接池、Tomcat線程池都被拖累服務整體吞吐跟著掉。SpringBoot下的異步調用就是面向這類場景的標準解法把耗時操作丟給另一個線程去執(zhí)行請求線程立刻返回調用方不需要干等。本文會從三種主流實現(xiàn)方式展開基于Async注解的線程池異步、基于WebFlux的響應式異步、以及消息隊列的最終解耦同時把實際開發(fā)中容易踩的失效、線程耗盡、上下文丟失這幾個坑一并講清楚。2. SpringBoot異步調用整體方案盤點2.1 同步、異步、阻塞、非阻塞幾個概念先理清聊異步之前得先把概念統(tǒng)一一下不然下面代碼容易看混。同步和異步說的是調用方的處理方式。調一個方法必須等它跑完才能繼續(xù)做別的事就是同步調用后立即返回結果通過回調、輪詢、Future或事件來獲取就是異步。阻塞和非阻塞說的是線程的狀態(tài)。線程在等待結果期間被掛起、不能做別的事就是阻塞線程發(fā)起操作后不等待繼續(xù)往下執(zhí)行就是非阻塞?！爱惒健辈坏扔凇翱臁彼皇亲尞斍熬€程不被拖住。真正省時間的是并行的計算資源所以異步方案幾乎必須配套線程池否則異步任務全堆在單線程里反而更慢。2.2 三套方案怎么選方案核心機制適合場景需要注意的點Async 線程池AOP代理 獨立線程池執(zhí)行方法業(yè)務代碼里局部耗時的操作比如發(fā)通知、寫日志、生成報表自調用無效、線程池參數(shù)要配好WebFlux 響應式異步基于Netty事件循環(huán) 響應式流高并發(fā)IO密集型接口網(wǎng)關層、數(shù)據(jù)聚合接口全鏈路要反應式不能混用阻塞調用消息隊列異步生產(chǎn)者發(fā)消息消費者獨立處理跨系統(tǒng)解耦、削峰填谷、可靠投遞場景需要額外中間件要考慮消息冪等這三套方案不是互相替代的關系。一個大型項目里接口內部會用Async處理局部任務核心入口用WebFlux扛流量系統(tǒng)之間再用消息隊列解耦各管一段。3. Async注解最常用的異步實現(xiàn)方式3.1 第一個Demo從配置到生效Async是Spring框架自帶的能力SpringBoot里用起來很方便。先在啟動類或者配置類上加上EnableAsync意思是開啟異步調用的注解掃描SpringBootApplication EnableAsync public class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); } }然后寫一個異步服務把需要異步執(zhí)行的方法用Async標記Service public class NotificationService { Async public void sendSms(String mobile, String content) { // 模擬短信接口耗時 try { Thread.sleep(3000); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } System.out.println(短信發(fā)送完成: mobile); } }調用方正常注入Service調用方法就行RestController RequestMapping(/api/order) public class OrderController { private final NotificationService notificationService; public OrderController(NotificationService notificationService) { this.notificationService notificationService; } PostMapping(/create) public String createOrder() { // 訂單業(yè)務邏輯 notificationService.sendSms(138****1234, 您的訂單已創(chuàng)建); return 下單成功; } }運行起來請求接口后響應立刻返回不會等那3秒。短信任務在獨立的線程里執(zhí)行這就是最基礎的Async用法。3.2 為什么Async能生效代理機制要明白這是理解Async的關鍵點也是后續(xù)排查失效問題的理論基礎。Spring容器在啟動時掃描到Async注解的方法會給Bean生成一個代理對象。當我們從容器里拿到這個Bean并調用方法時實際調用的是代理對象代理對象會先把任務提交給線程池然后返回。也就是說異步邏輯是被“包裝”進去的而不是你寫的那個方法本身變成了異步?；谶@個原理有兩個經(jīng)典結論第一Async方法必須被Spring容器管理也就是放在Service、Component這些Bean里。第二同一個類內部調用帶Async的方法不會走代理等于直接調用原方法異步失效。后面第6部分我會專門講這個坑。3.3 自定義線程池讓異步任務跑在正確的線程上默認情況下Async用的是Spring自帶的SimpleAsyncTaskExecutor這個類每次執(zhí)行都會新建一個線程沒有復用機制。高并發(fā)場景下線程數(shù)無上限增長系統(tǒng)資源很快耗盡。生產(chǎn)環(huán)境必須自定義線程池。推薦用Java配置類創(chuàng)建ThreadPoolTaskExecutorConfiguration public class AsyncConfig { Bean(taskExecutor) public Executor taskExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); // 核心線程數(shù)正常情況下常駐的線程數(shù)量 executor.setCorePoolSize(10); // 最大線程數(shù)高峰期最多能擴展到的線程數(shù)量 executor.setMaxPoolSize(50); // 隊列容量核心線程全忙時新任務先放隊列 executor.setQueueCapacity(200); // 線程名前綴排查問題時好識別 executor.setThreadNamePrefix(async-task-); // 拒絕策略隊列也滿的時候怎么處理新任務 executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.initialize(); return executor; } }參數(shù)大小怎么定這是被問得最多的。核心線程數(shù)參考機器的CPU核數(shù)和任務類型。IO密集型任務調遠程接口、讀寫文件等待時間占比高核心線程數(shù)可以設成CPU核數(shù)的2倍以上CPU密集型任務大量計算設成CPU核數(shù)加1到2個就夠。設核心線程10、最大線程50、隊列200意思是正常情況下10個線程在跑任務多的時候先排隊隊滿之后才會把線程數(shù)往上提最多50個還是處理不過來就觸發(fā)拒絕策略。使用自定義線程池時Async注解里要指定名字Async(taskExecutor) public void sendSms(String mobile, String content) {如果不指定Spring會按類型查找默認執(zhí)行器找到唯一實現(xiàn)類就自動使用。建議還是顯式寫名字多個線程池并存時不容易混。3.4 有返回值的異步調用Future與CompletableFuture現(xiàn)實中很多異步任務需要帶結果回來。Async支持Future類型的返回值最常用的是CompletableFuture。Service public class ReportService { Async(taskExecutor) public CompletableFutureString generateReport(Long userId) { // 耗時邏輯比如統(tǒng)計數(shù)據(jù) String reportContent 用戶 userId 的報表數(shù)據(jù)...; return CompletableFuture.completedFuture(reportContent); } }調用方可以主動組合多個異步任務public String handleReportRequest() throws Exception { CompletableFutureString reportFuture reportService.generateReport(1001L); CompletableFutureString otherFuture otherService.generateOtherData(1002L); // 等待兩個任務都完成并合并結果 String result CompletableFuture.allOf(reportFuture, otherFuture) .thenApply(v - reportFuture.join() otherFuture.join()) .get(30, TimeUnit.SECONDS); return result; }allOf會等所有任務完成后再執(zhí)行合并邏輯get方法設置超時時間避免任務卡死導致調用方無限等待。這里有一個細節(jié)CompletableFuture.join和get的區(qū)別。get拋受檢異常需要try-catch或向上拋出join不拋受檢異常直接在RuntimeException里包裝。業(yè)務代碼里我更習慣用get帶超時至少不會把控制權無限交給異步任務。3.5 異步任務的異常處理Async方法默認的異常處理方式是如果方法沒有返回值異常會被吞掉日志里可能什么都看不到。這是新手最容易忽略的點。處理方案有兩種。第一種方法返回Future異常會封裝在Future里調用get時拋出由調用方處理。這種方式能讓異?；氐綐I(yè)務鏈路但調用方需要等待結果有些場景不算理想。第二種實現(xiàn)AsyncUncaughtExceptionHandler配置成自定義的異步異常處理器Configuration public class AsyncExceptionConfig implements AsyncConfigurer { Override public Executor getAsyncExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(10); executor.setMaxPoolSize(50); executor.setQueueCapacity(200); executor.setThreadNamePrefix(async-); executor.initialize(); return executor; } Override public AsyncUncaughtExceptionHandler getAsyncUncaughtExceptionHandler() { return (ex, method, params) - { // 這里統(tǒng)一記錄異常日志或者接入告警系統(tǒng) System.err.println(異步方法執(zhí)行異常: method.getName()); ex.printStackTrace(); }; } }注意如果實現(xiàn)AsyncConfigurergetAsyncExecutor里返回的Executor就是全局默認的線程池所有沒指定名稱的Async都會用它。如果類里還有其他配置方式要避免兩個配置源互相覆蓋。異常處理選哪種取決于對這個異步任務結果的依賴程度。純通知類任務用自定義Handler記錄異常就夠了核心流程的分支任務建議返回Future讓主流程能感知失敗。3.6 Async與事務的疊加效果Async和Transactional同時使用時很多人以為事務會正常工作實際上需要分情況。Spring的事務也是通過代理實現(xiàn)的Transactional默認只在當前線程內生效。Async方法把邏輯推到了另一個線程事務注解如果只寫在異步方法上事務還是有效的——只要事務管理器能拿到對應的連接。但組合時的經(jīng)典問題是事務傳播。假設主方法開啟事務調用本類里一個被Async標記的方法這個方法又寫了Transactional此時它跑在另一個線程里主線程的事務上下文傳不過去兩個事務互相獨立。如果異步方法內部對同一數(shù)據(jù)做了修改主事務提交失敗時異步事務可能已經(jīng)提交了數(shù)據(jù)一致性就出問題了。實操建議把異步和事務當成兩個獨立的邊界。事務管理交給主流程異步方法里的數(shù)據(jù)一致性靠消息確認、狀態(tài)機或者定時補償來解決不要指望跨線程的兩個代理還能保持完整的ACID語義。4. WebFlux響應式異步換一種執(zhí)行模型4.1 WebFlux不是“異步版的SpringMVC”有些人把WebFlux理解成“用起來更異步的MVC框架”這是不對的。WebFlux改變了底層的執(zhí)行模型。SpringMVC基于Servlet規(guī)范每個請求占用一個Tomcat工作線程線程阻塞時這個線程什么都不能干。WebFlux基于Netty事件循環(huán)用的是少量線程配合事件回調來處理海量并發(fā)請求。線程不阻塞等待而是注冊回調數(shù)據(jù)來了再觸發(fā)后續(xù)邏輯。所以WebFlux的高并發(fā)能力來自它極低的線程占用。同樣一臺機器MVC能扛幾百并發(fā)時WebFlux往往能扛幾千甚至更高前提是代碼里不能有阻塞調用。引入WebFlux在pom里加依賴dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-webflux/artifactId /dependency注意如果項目里同時引入了spring-boot-starter-webMVC要移除其中一個或者明確端口配置否則兩個容器會沖突。4.2 響應式寫法的基本形態(tài)接口返回Mono或Flux類型表示這個結果是“未來某個時刻才會出現(xiàn)的”RestController RequestMapping(/api/user) public class UserReactiveController { private final UserService userService; public UserReactiveController(UserService userService) { this.userService userService; } GetMapping(/{id}) public MonoUser getUser(PathVariable Long id) { return Mono.fromCallable(() - userService.findById(id)) .subscribeOn(Schedulers.boundedElastic()); } }這個接口里findById這個阻塞型操作被丟到boundedElastic線程池里執(zhí)行而Netty事件循環(huán)線程立刻返回不阻塞。等數(shù)據(jù)查到了再通過回調把響應寫回客戶端。4.3 響應式鏈路的寫法規(guī)范響應式異步的關鍵在于整條鏈路都要保持響應式。如果Service層用的是JPA的findById這本身就是阻塞調用。把它包在Mono.fromCallable里的效果是異步線程執(zhí)行了阻塞查詢這確實能提升并發(fā)但底層依賴的還是線程池本質上是“用線程池隔離阻塞”而不是真正的全鏈路響應式。真正做到全鏈路響應式要求數(shù)據(jù)訪問層也返回響應式類型。比如用R2DBC訪問數(shù)據(jù)庫public interface UserRepository extends ReactiveCrudRepositoryUser, Long { FluxUser findByStatus(String status); } RestController public class UserController { private final UserRepository userRepository; public UserController(UserRepository userRepository) { this.userRepository userRepository; } GetMapping(/active) public FluxUser getActiveUsers() { return userRepository.findByStatus(ACTIVE); } }這種寫法下從HTTP入口到數(shù)據(jù)庫驅動全程沒有阻塞等待。每個環(huán)節(jié)都是“準備好了就通知下一個環(huán)節(jié)”線程利用率極高。4.4 實際項目里的語句WebFlux適合網(wǎng)關層、聚合層比如給App提供統(tǒng)一的聚合接口同時調用訂單服務、支付服務、用戶服務的接口把它們的結果合并返回。每個下游調用都返回響應式結果合并時用zippublic MonoOrderDetailVO getOrderDetail(String orderId) { MonoOrder orderMono orderClient.getOrder(orderId); MonoListPayment paymentMono paymentClient.getPayments(orderId); MonoUser userMono userClient.getUserByOrderId(orderId); return Mono.zip(orderMono, paymentMono, userMono) .map(tuple - { Order order tuple.getT1(); ListPayment payments tuple.getT2(); User user tuple.getT3(); return buildVO(order, payments, user); }); }三個下游調用并行執(zhí)行全部返回后組裝成VO發(fā)給客戶端。如果是MVC寫法這種聚合要么串行請求要么手動管理線程池代碼冗長且容易出錯。4.5 WebFlux的代價響應式不是免費的午餐。它最大的問題是調試困難。傳統(tǒng)代碼的堆棧在線程切換后變得支離破碎異常信息經(jīng)常不會指向真正出問題的位置。響應式代碼的學習曲線也陡峭flatMap、concatMap、switchIfEmpty這些操作符的語義不熟悉的人很容易寫出性能極差的代碼。我的個人結論是中小型項目業(yè)務邏輯復雜團隊也沒有響應式經(jīng)驗不要強行上WebFlux。用Async配合線程池改造局部痛點性價比高得多。WebFlux適合高并發(fā)、IO密集、業(yè)務鏈路清晰的下游聚合或網(wǎng)關項目。5. 消息隊列跨系統(tǒng)異步解耦5.1 什么時候需要消息隊列Async解決的是進程內的異步消息隊列解決的是跨進程的異步。訂單創(chuàng)建后要通知積分系統(tǒng)、短信平臺、物流系統(tǒng)如果通過RPC同步調用任何一個下游出問題都會拖累下單主流程而且下游流量波動還會反過來擠壓訂單服務的資源。消息隊列的方案是訂單服務把“訂單創(chuàng)建完成”這個事件以消息的形式寫入隊列下單請求到這里就結束了。積分服務、短信服務分別訂閱這個主題各自來消費。訂單服務不再依賴下游的可用性下游也通過訂閱的方式解耦了與訂單服務的強綁定。流程訂單服務作為Producer發(fā)送消息到Topic消息隊列Broker持久化消息確認收到積分服務、物流服務作為Consumer訂閱Topic各自消費消息更新自己的數(shù)據(jù)5.2 消息隊列和Async怎么配合消息隊列兩側都會用到Async。Producer側發(fā)送消息本身是快速操作但網(wǎng)絡異常重試時可能耗時所以發(fā)送邏輯可以用Async異步化避免阻塞業(yè)務主流程。Consumer側如果一次拉取到多條消息單條消息處理耗時較長可以在消費者內部再用Async把每條消息的業(yè)務處理丟到線程池并發(fā)執(zhí)行提升消費吞吐。要注意的是消費端的并發(fā)度控制。如果消費者線程池開得太大消息處理太快可能壓垮下游數(shù)據(jù)庫。一般建議消費線程池的最大線程數(shù)跟數(shù)據(jù)庫連接池大小掛鉤保證線程數(shù)不超過連接數(shù)的上限。5.3 消息隊列的可靠性問題消息隊列把同步調用變成了異步通知同時也引出了一個新的問題怎么保證消息不丟、不重、不亂序。不丟Producer發(fā)送時開啟確認機制Broker持久化完成后再返回成功Consumer消費后處理完業(yè)務再提交位點。不重消費端要做冪等因為消息隊列的語義是“至少一次”重復消費是正常現(xiàn)象。常見做法是消費端先查本地狀態(tài)已經(jīng)處理過的直接返回成功或者用唯一業(yè)務ID去重。不亂序同一業(yè)務的消息要保證分區(qū)鍵一致讓它們進同一個分區(qū)消費者單線程消費這個分區(qū)。這部分的坑主要集中在冪等上。很多項目剛開始只做了“不丟”沒做“不重”線上跑一段時間就發(fā)現(xiàn)重復數(shù)據(jù)。做消息隊列異步第一件要設計好的事就是冪等方案而不是消息發(fā)送本身。6. 三大高階問題失效、線程耗盡、上下文丟失6.1 Async失效的幾種常見場景熟悉了代理原理之后失效問題基本都能自己排查。最常見的失效場景有四種第一種方法通過this調用。比如一個Service里面methodA調用methodBmethodB標了Async。因為this指的是原始對象而不是Spring代理所以Async不生效。解決辦法注入自身代理或者把異步方法拆到另一個Service里。第二種異步方法不是public。Spring的代理默認只能攔截public方法private和protected方法不會進入代理邏輯。第三種異步方法所在Bean沒有被Spring管理。比如自己new出來的對象Spring根本不知道它的存在。第四種配置類上沒有EnableAsync。這個看起來低級但項目里多模塊化之后經(jīng)常出現(xiàn)主啟動類掃描不到配置類的情況。6.2 線程池被打滿的排查方法異步任務量大時線程池可能被打滿任務進隊列隊列也滿了觸發(fā)拒絕策略。CallerRunsPolicy會把這個任務交給調用方線程執(zhí)行看起來是“降級”但調用量巨大時會把請求線程拖死。排查時主要靠日志。所以自定義線程池時setThreadNamePrefix非常重要executor.setThreadNamePrefix(async-notify-);日志里搜async-notify線程能看到線程數(shù)是否接近maximumPoolSize隊列深度是否持續(xù)增長。如果隊列長期堆積說明核心線程數(shù)偏低或者任務量超過預期要調整參數(shù)而不是無限加線程。另外一個容易忽略的點是如果任務里都有數(shù)據(jù)庫查詢線程池配置不能只看服務本身的指標還要看數(shù)據(jù)庫連接池的可用連接數(shù)。線程數(shù)設50數(shù)據(jù)庫連接池默認只有1050個線程同時查庫10個持有連接剩下40個在等待這比不異步還要糟糕。線程池參數(shù)必須與會話外資源聯(lián)動評估。6.3 異步線程里丟失請求上下文Async方法里需要拿到當前登錄用戶信息、請求頭、traceId時經(jīng)常發(fā)現(xiàn)是null。這是因為請求線程的數(shù)據(jù)存在ThreadLocal里而異步任務跑在不同的線程上ThreadLocal不共享。常用解決辦法是裝飾器模式主線程在提交任務前把關鍵上下文拷貝一份傳給目標線程。Spring提供了TaskDecorator接口可以優(yōu)雅地實現(xiàn)上下文傳遞Bean(taskExecutor) public Executor taskExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(10); executor.setMaxPoolSize(50); executor.setQueueCapacity(200); executor.setThreadNamePrefix(async-); // 任務提交時將主線程的上下文復制到子線程 executor.setTaskDecorator(runnable - { // 實際項目中這里會把請求上下文對象暫存 MapString, String contextMap copyContextFromCurrentThread(); return () - { try { setContextToCurrentThread(contextMap); runnable.run(); } finally { clearContext(); } }; }); executor.initialize(); return executor; }如果是Spring Cloud鏈路追蹤的場景也可以用類似方式把traceId從主線程傳到異步線程保證全鏈路日志能串起來。具體到邏輯執(zhí)行這段decorator是為了展示結構實際會把traceId、用戶信息請求上下文做成一個線程私有對象。6.4 異步事務隔離與資源共享異步任務共享數(shù)據(jù)庫連接池、Redis連接池時要考慮資源競爭問題。之前幫別人排查過一個線上故障異步線程池核心線程從5調到了20數(shù)據(jù)庫連接池沒動結果每個異步任務里都有大約300ms的數(shù)據(jù)庫查詢20個線程同時查詢連接池不夠用主業(yè)務的請求也開始等連接整個服務響應變慢。這類問題的排查步驟是看監(jiān)控里線程池活躍線程數(shù)看數(shù)據(jù)庫連接池活躍連接數(shù)看兩者是否存在明顯的共同增長趨勢計算單個任務的平均IO時間反推需要的并發(fā)度不要盲目調高線程池資源配置是聯(lián)動的關系。7. 常見問題速查與避坑清單下面這個表是根據(jù)我在項目中遇到過的真實情況整理的方便直接對照排查。問題可能原因解決思路Async方法同步執(zhí)行this自調用、方法非public、Bean未被Spring管理拆Service、改public、確認包掃描異步異常無日志輸出方法無返回Future且未配置異常處理器自定義AsyncUncaughtExceptionHandler線程數(shù)暴增使用了默認SimpleAsyncTaskExecutor自定義線程池并指定名稱隊列任務堆積核心線程數(shù)過少或任務量突增壓測后調參結合隊列容量一起評估異步方法內用戶信息為空ThreadLocal無法跨線程傳遞使用TaskDecorator拷貝上下文接口偶爾變得很慢異線程池觸發(fā)了拒絕策略CallerRunsPolicy監(jiān)控線程池指標動態(tài)調參異步事務數(shù)據(jù)不一致跨線程事務隔離導致主流程管事務異步靠補償WebFlux接口里用了Thread.sleep阻塞了事件循環(huán)線程改為非阻塞延時或換到boundedElastic補充幾個容易忽略的實踐細節(jié)每個異步任務都要有業(yè)務標識。日志里把業(yè)務ID、用戶ID、traceId全部打出來排查問題的時候能直接定位到是哪個任務、哪個線程在跑。線程池參數(shù)要支持動態(tài)調整。生產(chǎn)環(huán)境用配置中心管理核心線程數(shù)、最大線程數(shù)壓測發(fā)現(xiàn)問題后可以在不重啟服務的情況下修改效果比改代碼快很多。異步任務要有熔斷或者降級方案。線程池滿時的拒絕策略不要只選一種結合業(yè)務的容忍度來選?？梢詠G棄不重要任務DiscardPolicy也可以讓調用方自己跑CallerRunsPolicy但要做到心里有數(shù)知道每種策略的副作用。8. 異步調用的監(jiān)控指標與可觀測性設計用了異步之后問題排查難度確實會上升。同步模式下一個請求從開始到結束是一條清晰的調用鏈異步線程切來切去傳統(tǒng)日志就斷了。所以異步用得越多可觀測性越要跟上。至少要監(jiān)控四個指標線程池活躍線程數(shù)隊列積壓數(shù)量任務執(zhí)行耗時P99分位被拒絕的任務數(shù)量活躍線程數(shù)能看出線程池是否持續(xù)處于高水位隊列積壓數(shù)量能提前預警任務堆積執(zhí)行耗時能看出單個任務的健康狀況被拒絕的任務數(shù)量直接反映系統(tǒng)是否已經(jīng)超出容量。日志配合MDC來做traceId傳接我在上一部分提過用TaskDecorator傳上下文就是為了讓異步線程的日志也帶上同一個traceId。每個異步任務開始和結束時各打一條日志記錄線程名、任務名、業(yè)務ID、耗時自己畫一條時間軸基本能還原出任務執(zhí)行的完整路徑。監(jiān)控指標都接好之后判斷線程池參數(shù)是否合理的依據(jù)就變得具體了。線程池穩(wěn)定在核心線程數(shù)附近、隊列偶爾積壓但能在幾秒內排空這是比較健康的狀態(tài)。如果線程數(shù)長期貼近最大線程數(shù)、隊列持續(xù)有積壓說明系統(tǒng)已經(jīng)滿負荷了加線程不如削任務。9. 異步改造的實際落地順序不管項目里選擇哪種異步方案都不建議一次性大規(guī)模改造。我見過的所有改造失敗案例幾乎都是因為“把異步當成了萬能的性能開關”一口氣把所有服務都標成Async結果線上問題此起彼伏又不知道從哪里排起。比較穩(wěn)的推進方式是分四步走。第一步盤點場景。把項目里所有耗時超過1秒的操作都列出來標注它們是否依賴主流程的結果。比如發(fā)送短信、生成日志、統(tǒng)計數(shù)據(jù)這些明顯是分支任務適合異步化。第二步先做Async打底。給這些分支任務加上線程池和異步注解同時把異常處理器、日志、監(jiān)控配套做好。這一步投入小見效快也是積累異步經(jīng)驗最快的方式。第三步局部引入WebFlux。當某個入口的并發(fā)瓶頸特別明顯比如聚合接口、網(wǎng)關入口而這個服務的業(yè)務鏈路又相對清晰這部分可以嘗試換成響應式編程。不要一開始就把所有Service都改成Mono和Flux鏈路過深會讓改造成本成倍增長。第四步涉及跨系統(tǒng)的異步再上消息隊列。消息隊列引入的是整個中間件的運維成本如果沒有明確的削峰、解耦需求就不要為了用而用。10. 一點個人經(jīng)驗收尾做異步調用這些年最大的體會是異步方案從來不是技術問題而是取舍問題。它把當前線程的“等待時間”轉移給了別的線程換來的是接口響應速度的提升和系統(tǒng)吞吐量的改善代價是代碼復雜性、排查難度的上升以及分布式場景下一致性問題的新增。實際動手時我的習慣是先畫一張簡單的調用鏈路圖標出每個環(huán)節(jié)的耗時、線程、依賴再考慮在這個鏈路的哪個環(huán)節(jié)插入異步。不看鏈路就動手加注解往往是在給系統(tǒng)埋雷。如果你剛上手SpringBoot異步調用不用急著把三套方案都吃透先在自己項目里找一個實實在在的痛點比如每次下發(fā)通知都阻塞請求、導出數(shù)據(jù)超時、日志寫入拖慢業(yè)務用Async配合線程池改造一遍把代理失效、上下文傳遞、異常監(jiān)控這幾個點親手踩一遍比看再多文檔都有用。工具選型也一樣沒有絕對最好的方案。進程內的異步優(yōu)先Async高并發(fā)聚合優(yōu)先WebFlux跨系統(tǒng)解耦優(yōu)先消息隊列。每個方案的代價不一樣選適合自己項目階段的已經(jīng)足夠。 SpringBoot異步調用實戰(zhàn)：@Async線程池、WebFlux與消息隊列全解析
1. 為什么要做異步調用從一次接口超時說起先講一個真實的場景。之前我給某個后臺管理系統(tǒng)做導出功能用戶在前端點了一個“導出報表”后端同步去數(shù)據(jù)庫里查幾十萬條數(shù)據(jù)再拼裝Excel最后返回文件流。單次執(zhí)行時間普遍在15秒以上前端請求早超時了用戶反復點了幾次后臺直接堆了好幾個線程在處理同一件事。這個問題的根源不在代碼性能而是同步阻塞的調用模型。請求線程從接收到返回全程霸占著不放導出的耗時越長能用線程就越少數(shù)據(jù)庫連接池、Tomcat線程池都被拖累服務整體吞吐跟著掉。SpringBoot下的異步調用就是面向這類場景的標準解法把耗時操作丟給另一個線程去執(zhí)行請求線程立刻返回調用方不需要干等。本文會從三種主流實現(xiàn)方式展開基于Async注解的線程池異步、基于WebFlux的響應式異步、以及消息隊列的最終解耦同時把實際開發(fā)中容易踩的失效、線程耗盡、上下文丟失這幾個坑一并講清楚。2. SpringBoot異步調用整體方案盤點2.1 同步、異步、阻塞、非阻塞幾個概念先理清聊異步之前得先把概念統(tǒng)一一下不然下面代碼容易看混。同步和異步說的是調用方的處理方式。調一個方法必須等它跑完才能繼續(xù)做別的事就是同步調用后立即返回結果通過回調、輪詢、Future或事件來獲取就是異步。阻塞和非阻塞說的是線程的狀態(tài)。線程在等待結果期間被掛起、不能做別的事就是阻塞線程發(fā)起操作后不等待繼續(xù)往下執(zhí)行就是非阻塞?！爱惒健辈坏扔凇翱臁彼皇亲尞斍熬€程不被拖住。真正省時間的是并行的計算資源所以異步方案幾乎必須配套線程池否則異步任務全堆在單線程里反而更慢。2.2 三套方案怎么選方案核心機制適合場景需要注意的點Async 線程池AOP代理 獨立線程池執(zhí)行方法業(yè)務代碼里局部耗時的操作比如發(fā)通知、寫日志、生成報表自調用無效、線程池參數(shù)要配好WebFlux 響應式異步基于Netty事件循環(huán) 響應式流高并發(fā)IO密集型接口網(wǎng)關層、數(shù)據(jù)聚合接口全鏈路要反應式不能混用阻塞調用消息隊列異步生產(chǎn)者發(fā)消息消費者獨立處理跨系統(tǒng)解耦、削峰填谷、可靠投遞場景需要額外中間件要考慮消息冪等這三套方案不是互相替代的關系。一個大型項目里接口內部會用Async處理局部任務核心入口用WebFlux扛流量系統(tǒng)之間再用消息隊列解耦各管一段。3. Async注解最常用的異步實現(xiàn)方式3.1 第一個Demo從配置到生效Async是Spring框架自帶的能力SpringBoot里用起來很方便。先在啟動類或者配置類上加上EnableAsync意思是開啟異步調用的注解掃描SpringBootApplication EnableAsync public class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); } }然后寫一個異步服務把需要異步執(zhí)行的方法用Async標記Service public class NotificationService { Async public void sendSms(String mobile, String content) { // 模擬短信接口耗時 try { Thread.sleep(3000); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } System.out.println(短信發(fā)送完成: mobile); } }調用方正常注入Service調用方法就行RestController RequestMapping(/api/order) public class OrderController { private final NotificationService notificationService; public OrderController(NotificationService notificationService) { this.notificationService notificationService; } PostMapping(/create) public String createOrder() { // 訂單業(yè)務邏輯 notificationService.sendSms(138****1234, 您的訂單已創(chuàng)建); return 下單成功; } }運行起來請求接口后響應立刻返回不會等那3秒。短信任務在獨立的線程里執(zhí)行這就是最基礎的Async用法。3.2 為什么Async能生效代理機制要明白這是理解Async的關鍵點也是后續(xù)排查失效問題的理論基礎。Spring容器在啟動時掃描到Async注解的方法會給Bean生成一個代理對象。當我們從容器里拿到這個Bean并調用方法時實際調用的是代理對象代理對象會先把任務提交給線程池然后返回。也就是說異步邏輯是被“包裝”進去的而不是你寫的那個方法本身變成了異步?；谶@個原理有兩個經(jīng)典結論第一Async方法必須被Spring容器管理也就是放在Service、Component這些Bean里。第二同一個類內部調用帶Async的方法不會走代理等于直接調用原方法異步失效。后面第6部分我會專門講這個坑。3.3 自定義線程池讓異步任務跑在正確的線程上默認情況下Async用的是Spring自帶的SimpleAsyncTaskExecutor這個類每次執(zhí)行都會新建一個線程沒有復用機制。高并發(fā)場景下線程數(shù)無上限增長系統(tǒng)資源很快耗盡。生產(chǎn)環(huán)境必須自定義線程池。推薦用Java配置類創(chuàng)建ThreadPoolTaskExecutorConfiguration public class AsyncConfig { Bean(taskExecutor) public Executor taskExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); // 核心線程數(shù)正常情況下常駐的線程數(shù)量 executor.setCorePoolSize(10); // 最大線程數(shù)高峰期最多能擴展到的線程數(shù)量 executor.setMaxPoolSize(50); // 隊列容量核心線程全忙時新任務先放隊列 executor.setQueueCapacity(200); // 線程名前綴排查問題時好識別 executor.setThreadNamePrefix(async-task-); // 拒絕策略隊列也滿的時候怎么處理新任務 executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.initialize(); return executor; } }參數(shù)大小怎么定這是被問得最多的。核心線程數(shù)參考機器的CPU核數(shù)和任務類型。IO密集型任務調遠程接口、讀寫文件等待時間占比高核心線程數(shù)可以設成CPU核數(shù)的2倍以上CPU密集型任務大量計算設成CPU核數(shù)加1到2個就夠。設核心線程10、最大線程50、隊列200意思是正常情況下10個線程在跑任務多的時候先排隊隊滿之后才會把線程數(shù)往上提最多50個還是處理不過來就觸發(fā)拒絕策略。使用自定義線程池時Async注解里要指定名字Async(taskExecutor) public void sendSms(String mobile, String content) {如果不指定Spring會按類型查找默認執(zhí)行器找到唯一實現(xiàn)類就自動使用。建議還是顯式寫名字多個線程池并存時不容易混。3.4 有返回值的異步調用Future與CompletableFuture現(xiàn)實中很多異步任務需要帶結果回來。Async支持Future類型的返回值最常用的是CompletableFuture。Service public class ReportService { Async(taskExecutor) public CompletableFutureString generateReport(Long userId) { // 耗時邏輯比如統(tǒng)計數(shù)據(jù) String reportContent 用戶 userId 的報表數(shù)據(jù)...; return CompletableFuture.completedFuture(reportContent); } }調用方可以主動組合多個異步任務public String handleReportRequest() throws Exception { CompletableFutureString reportFuture reportService.generateReport(1001L); CompletableFutureString otherFuture otherService.generateOtherData(1002L); // 等待兩個任務都完成并合并結果 String result CompletableFuture.allOf(reportFuture, otherFuture) .thenApply(v - reportFuture.join() otherFuture.join()) .get(30, TimeUnit.SECONDS); return result; }allOf會等所有任務完成后再執(zhí)行合并邏輯get方法設置超時時間避免任務卡死導致調用方無限等待。這里有一個細節(jié)CompletableFuture.join和get的區(qū)別。get拋受檢異常需要try-catch或向上拋出join不拋受檢異常直接在RuntimeException里包裝。業(yè)務代碼里我更習慣用get帶超時至少不會把控制權無限交給異步任務。3.5 異步任務的異常處理Async方法默認的異常處理方式是如果方法沒有返回值異常會被吞掉日志里可能什么都看不到。這是新手最容易忽略的點。處理方案有兩種。第一種方法返回Future異常會封裝在Future里調用get時拋出由調用方處理。這種方式能讓異?；氐綐I(yè)務鏈路但調用方需要等待結果有些場景不算理想。第二種實現(xiàn)AsyncUncaughtExceptionHandler配置成自定義的異步異常處理器Configuration public class AsyncExceptionConfig implements AsyncConfigurer { Override public Executor getAsyncExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(10); executor.setMaxPoolSize(50); executor.setQueueCapacity(200); executor.setThreadNamePrefix(async-); executor.initialize(); return executor; } Override public AsyncUncaughtExceptionHandler getAsyncUncaughtExceptionHandler() { return (ex, method, params) - { // 這里統(tǒng)一記錄異常日志或者接入告警系統(tǒng) System.err.println(異步方法執(zhí)行異常: method.getName()); ex.printStackTrace(); }; } }注意如果實現(xiàn)AsyncConfigurergetAsyncExecutor里返回的Executor就是全局默認的線程池所有沒指定名稱的Async都會用它。如果類里還有其他配置方式要避免兩個配置源互相覆蓋。異常處理選哪種取決于對這個異步任務結果的依賴程度。純通知類任務用自定義Handler記錄異常就夠了核心流程的分支任務建議返回Future讓主流程能感知失敗。3.6 Async與事務的疊加效果Async和Transactional同時使用時很多人以為事務會正常工作實際上需要分情況。Spring的事務也是通過代理實現(xiàn)的Transactional默認只在當前線程內生效。Async方法把邏輯推到了另一個線程事務注解如果只寫在異步方法上事務還是有效的——只要事務管理器能拿到對應的連接。但組合時的經(jīng)典問題是事務傳播。假設主方法開啟事務調用本類里一個被Async標記的方法這個方法又寫了Transactional此時它跑在另一個線程里主線程的事務上下文傳不過去兩個事務互相獨立。如果異步方法內部對同一數(shù)據(jù)做了修改主事務提交失敗時異步事務可能已經(jīng)提交了數(shù)據(jù)一致性就出問題了。實操建議把異步和事務當成兩個獨立的邊界。事務管理交給主流程異步方法里的數(shù)據(jù)一致性靠消息確認、狀態(tài)機或者定時補償來解決不要指望跨線程的兩個代理還能保持完整的ACID語義。4. WebFlux響應式異步換一種執(zhí)行模型4.1 WebFlux不是“異步版的SpringMVC”有些人把WebFlux理解成“用起來更異步的MVC框架”這是不對的。WebFlux改變了底層的執(zhí)行模型。SpringMVC基于Servlet規(guī)范每個請求占用一個Tomcat工作線程線程阻塞時這個線程什么都不能干。WebFlux基于Netty事件循環(huán)用的是少量線程配合事件回調來處理海量并發(fā)請求。線程不阻塞等待而是注冊回調數(shù)據(jù)來了再觸發(fā)后續(xù)邏輯。所以WebFlux的高并發(fā)能力來自它極低的線程占用。同樣一臺機器MVC能扛幾百并發(fā)時WebFlux往往能扛幾千甚至更高前提是代碼里不能有阻塞調用。引入WebFlux在pom里加依賴dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-webflux/artifactId /dependency注意如果項目里同時引入了spring-boot-starter-webMVC要移除其中一個或者明確端口配置否則兩個容器會沖突。4.2 響應式寫法的基本形態(tài)接口返回Mono或Flux類型表示這個結果是“未來某個時刻才會出現(xiàn)的”RestController RequestMapping(/api/user) public class UserReactiveController { private final UserService userService; public UserReactiveController(UserService userService) { this.userService userService; } GetMapping(/{id}) public MonoUser getUser(PathVariable Long id) { return Mono.fromCallable(() - userService.findById(id)) .subscribeOn(Schedulers.boundedElastic()); } }這個接口里findById這個阻塞型操作被丟到boundedElastic線程池里執(zhí)行而Netty事件循環(huán)線程立刻返回不阻塞。等數(shù)據(jù)查到了再通過回調把響應寫回客戶端。4.3 響應式鏈路的寫法規(guī)范響應式異步的關鍵在于整條鏈路都要保持響應式。如果Service層用的是JPA的findById這本身就是阻塞調用。把它包在Mono.fromCallable里的效果是異步線程執(zhí)行了阻塞查詢這確實能提升并發(fā)但底層依賴的還是線程池本質上是“用線程池隔離阻塞”而不是真正的全鏈路響應式。真正做到全鏈路響應式要求數(shù)據(jù)訪問層也返回響應式類型。比如用R2DBC訪問數(shù)據(jù)庫public interface UserRepository extends ReactiveCrudRepositoryUser, Long { FluxUser findByStatus(String status); } RestController public class UserController { private final UserRepository userRepository; public UserController(UserRepository userRepository) { this.userRepository userRepository; } GetMapping(/active) public FluxUser getActiveUsers() { return userRepository.findByStatus(ACTIVE); } }這種寫法下從HTTP入口到數(shù)據(jù)庫驅動全程沒有阻塞等待。每個環(huán)節(jié)都是“準備好了就通知下一個環(huán)節(jié)”線程利用率極高。4.4 實際項目里的語句WebFlux適合網(wǎng)關層、聚合層比如給App提供統(tǒng)一的聚合接口同時調用訂單服務、支付服務、用戶服務的接口把它們的結果合并返回。每個下游調用都返回響應式結果合并時用zippublic MonoOrderDetailVO getOrderDetail(String orderId) { MonoOrder orderMono orderClient.getOrder(orderId); MonoListPayment paymentMono paymentClient.getPayments(orderId); MonoUser userMono userClient.getUserByOrderId(orderId); return Mono.zip(orderMono, paymentMono, userMono) .map(tuple - { Order order tuple.getT1(); ListPayment payments tuple.getT2(); User user tuple.getT3(); return buildVO(order, payments, user); }); }三個下游調用并行執(zhí)行全部返回后組裝成VO發(fā)給客戶端。如果是MVC寫法這種聚合要么串行請求要么手動管理線程池代碼冗長且容易出錯。4.5 WebFlux的代價響應式不是免費的午餐。它最大的問題是調試困難。傳統(tǒng)代碼的堆棧在線程切換后變得支離破碎異常信息經(jīng)常不會指向真正出問題的位置。響應式代碼的學習曲線也陡峭flatMap、concatMap、switchIfEmpty這些操作符的語義不熟悉的人很容易寫出性能極差的代碼。我的個人結論是中小型項目業(yè)務邏輯復雜團隊也沒有響應式經(jīng)驗不要強行上WebFlux。用Async配合線程池改造局部痛點性價比高得多。WebFlux適合高并發(fā)、IO密集、業(yè)務鏈路清晰的下游聚合或網(wǎng)關項目。5. 消息隊列跨系統(tǒng)異步解耦5.1 什么時候需要消息隊列Async解決的是進程內的異步消息隊列解決的是跨進程的異步。訂單創(chuàng)建后要通知積分系統(tǒng)、短信平臺、物流系統(tǒng)如果通過RPC同步調用任何一個下游出問題都會拖累下單主流程而且下游流量波動還會反過來擠壓訂單服務的資源。消息隊列的方案是訂單服務把“訂單創(chuàng)建完成”這個事件以消息的形式寫入隊列下單請求到這里就結束了。積分服務、短信服務分別訂閱這個主題各自來消費。訂單服務不再依賴下游的可用性下游也通過訂閱的方式解耦了與訂單服務的強綁定。流程訂單服務作為Producer發(fā)送消息到Topic消息隊列Broker持久化消息確認收到積分服務、物流服務作為Consumer訂閱Topic各自消費消息更新自己的數(shù)據(jù)5.2 消息隊列和Async怎么配合消息隊列兩側都會用到Async。Producer側發(fā)送消息本身是快速操作但網(wǎng)絡異常重試時可能耗時所以發(fā)送邏輯可以用Async異步化避免阻塞業(yè)務主流程。Consumer側如果一次拉取到多條消息單條消息處理耗時較長可以在消費者內部再用Async把每條消息的業(yè)務處理丟到線程池并發(fā)執(zhí)行提升消費吞吐。要注意的是消費端的并發(fā)度控制。如果消費者線程池開得太大消息處理太快可能壓垮下游數(shù)據(jù)庫。一般建議消費線程池的最大線程數(shù)跟數(shù)據(jù)庫連接池大小掛鉤保證線程數(shù)不超過連接數(shù)的上限。5.3 消息隊列的可靠性問題消息隊列把同步調用變成了異步通知同時也引出了一個新的問題怎么保證消息不丟、不重、不亂序。不丟Producer發(fā)送時開啟確認機制Broker持久化完成后再返回成功Consumer消費后處理完業(yè)務再提交位點。不重消費端要做冪等因為消息隊列的語義是“至少一次”重復消費是正常現(xiàn)象。常見做法是消費端先查本地狀態(tài)已經(jīng)處理過的直接返回成功或者用唯一業(yè)務ID去重。不亂序同一業(yè)務的消息要保證分區(qū)鍵一致讓它們進同一個分區(qū)消費者單線程消費這個分區(qū)。這部分的坑主要集中在冪等上。很多項目剛開始只做了“不丟”沒做“不重”線上跑一段時間就發(fā)現(xiàn)重復數(shù)據(jù)。做消息隊列異步第一件要設計好的事就是冪等方案而不是消息發(fā)送本身。6. 三大高階問題失效、線程耗盡、上下文丟失6.1 Async失效的幾種常見場景熟悉了代理原理之后失效問題基本都能自己排查。最常見的失效場景有四種第一種方法通過this調用。比如一個Service里面methodA調用methodBmethodB標了Async。因為this指的是原始對象而不是Spring代理所以Async不生效。解決辦法注入自身代理或者把異步方法拆到另一個Service里。第二種異步方法不是public。Spring的代理默認只能攔截public方法private和protected方法不會進入代理邏輯。第三種異步方法所在Bean沒有被Spring管理。比如自己new出來的對象Spring根本不知道它的存在。第四種配置類上沒有EnableAsync。這個看起來低級但項目里多模塊化之后經(jīng)常出現(xiàn)主啟動類掃描不到配置類的情況。6.2 線程池被打滿的排查方法異步任務量大時線程池可能被打滿任務進隊列隊列也滿了觸發(fā)拒絕策略。CallerRunsPolicy會把這個任務交給調用方線程執(zhí)行看起來是“降級”但調用量巨大時會把請求線程拖死。排查時主要靠日志。所以自定義線程池時setThreadNamePrefix非常重要executor.setThreadNamePrefix(async-notify-);日志里搜async-notify線程能看到線程數(shù)是否接近maximumPoolSize隊列深度是否持續(xù)增長。如果隊列長期堆積說明核心線程數(shù)偏低或者任務量超過預期要調整參數(shù)而不是無限加線程。另外一個容易忽略的點是如果任務里都有數(shù)據(jù)庫查詢線程池配置不能只看服務本身的指標還要看數(shù)據(jù)庫連接池的可用連接數(shù)。線程數(shù)設50數(shù)據(jù)庫連接池默認只有1050個線程同時查庫10個持有連接剩下40個在等待這比不異步還要糟糕。線程池參數(shù)必須與會話外資源聯(lián)動評估。6.3 異步線程里丟失請求上下文Async方法里需要拿到當前登錄用戶信息、請求頭、traceId時經(jīng)常發(fā)現(xiàn)是null。這是因為請求線程的數(shù)據(jù)存在ThreadLocal里而異步任務跑在不同的線程上ThreadLocal不共享。常用解決辦法是裝飾器模式主線程在提交任務前把關鍵上下文拷貝一份傳給目標線程。Spring提供了TaskDecorator接口可以優(yōu)雅地實現(xiàn)上下文傳遞Bean(taskExecutor) public Executor taskExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(10); executor.setMaxPoolSize(50); executor.setQueueCapacity(200); executor.setThreadNamePrefix(async-); // 任務提交時將主線程的上下文復制到子線程 executor.setTaskDecorator(runnable - { // 實際項目中這里會把請求上下文對象暫存 MapString, String contextMap copyContextFromCurrentThread(); return () - { try { setContextToCurrentThread(contextMap); runnable.run(); } finally { clearContext(); } }; }); executor.initialize(); return executor; }如果是Spring Cloud鏈路追蹤的場景也可以用類似方式把traceId從主線程傳到異步線程保證全鏈路日志能串起來。具體到邏輯執(zhí)行這段decorator是為了展示結構實際會把traceId、用戶信息請求上下文做成一個線程私有對象。6.4 異步事務隔離與資源共享異步任務共享數(shù)據(jù)庫連接池、Redis連接池時要考慮資源競爭問題。之前幫別人排查過一個線上故障異步線程池核心線程從5調到了20數(shù)據(jù)庫連接池沒動結果每個異步任務里都有大約300ms的數(shù)據(jù)庫查詢20個線程同時查詢連接池不夠用主業(yè)務的請求也開始等連接整個服務響應變慢。這類問題的排查步驟是看監(jiān)控里線程池活躍線程數(shù)看數(shù)據(jù)庫連接池活躍連接數(shù)看兩者是否存在明顯的共同增長趨勢計算單個任務的平均IO時間反推需要的并發(fā)度不要盲目調高線程池資源配置是聯(lián)動的關系。7. 常見問題速查與避坑清單下面這個表是根據(jù)我在項目中遇到過的真實情況整理的方便直接對照排查。問題可能原因解決思路Async方法同步執(zhí)行this自調用、方法非public、Bean未被Spring管理拆Service、改public、確認包掃描異步異常無日志輸出方法無返回Future且未配置異常處理器自定義AsyncUncaughtExceptionHandler線程數(shù)暴增使用了默認SimpleAsyncTaskExecutor自定義線程池并指定名稱隊列任務堆積核心線程數(shù)過少或任務量突增壓測后調參結合隊列容量一起評估異步方法內用戶信息為空ThreadLocal無法跨線程傳遞使用TaskDecorator拷貝上下文接口偶爾變得很慢異線程池觸發(fā)了拒絕策略CallerRunsPolicy監(jiān)控線程池指標動態(tài)調參異步事務數(shù)據(jù)不一致跨線程事務隔離導致主流程管事務異步靠補償WebFlux接口里用了Thread.sleep阻塞了事件循環(huán)線程改為非阻塞延時或換到boundedElastic補充幾個容易忽略的實踐細節(jié)每個異步任務都要有業(yè)務標識。日志里把業(yè)務ID、用戶ID、traceId全部打出來排查問題的時候能直接定位到是哪個任務、哪個線程在跑。線程池參數(shù)要支持動態(tài)調整。生產(chǎn)環(huán)境用配置中心管理核心線程數(shù)、最大線程數(shù)壓測發(fā)現(xiàn)問題后可以在不重啟服務的情況下修改效果比改代碼快很多。異步任務要有熔斷或者降級方案。線程池滿時的拒絕策略不要只選一種結合業(yè)務的容忍度來選?？梢詠G棄不重要任務DiscardPolicy也可以讓調用方自己跑CallerRunsPolicy但要做到心里有數(shù)知道每種策略的副作用。8. 異步調用的監(jiān)控指標與可觀測性設計用了異步之后問題排查難度確實會上升。同步模式下一個請求從開始到結束是一條清晰的調用鏈異步線程切來切去傳統(tǒng)日志就斷了。所以異步用得越多可觀測性越要跟上。至少要監(jiān)控四個指標線程池活躍線程數(shù)隊列積壓數(shù)量任務執(zhí)行耗時P99分位被拒絕的任務數(shù)量活躍線程數(shù)能看出線程池是否持續(xù)處于高水位隊列積壓數(shù)量能提前預警任務堆積執(zhí)行耗時能看出單個任務的健康狀況被拒絕的任務數(shù)量直接反映系統(tǒng)是否已經(jīng)超出容量。日志配合MDC來做traceId傳接我在上一部分提過用TaskDecorator傳上下文就是為了讓異步線程的日志也帶上同一個traceId。每個異步任務開始和結束時各打一條日志記錄線程名、任務名、業(yè)務ID、耗時自己畫一條時間軸基本能還原出任務執(zhí)行的完整路徑。監(jiān)控指標都接好之后判斷線程池參數(shù)是否合理的依據(jù)就變得具體了。線程池穩(wěn)定在核心線程數(shù)附近、隊列偶爾積壓但能在幾秒內排空這是比較健康的狀態(tài)。如果線程數(shù)長期貼近最大線程數(shù)、隊列持續(xù)有積壓說明系統(tǒng)已經(jīng)滿負荷了加線程不如削任務。9. 異步改造的實際落地順序不管項目里選擇哪種異步方案都不建議一次性大規(guī)模改造。我見過的所有改造失敗案例幾乎都是因為“把異步當成了萬能的性能開關”一口氣把所有服務都標成Async結果線上問題此起彼伏又不知道從哪里排起。比較穩(wěn)的推進方式是分四步走。第一步盤點場景。把項目里所有耗時超過1秒的操作都列出來標注它們是否依賴主流程的結果。比如發(fā)送短信、生成日志、統(tǒng)計數(shù)據(jù)這些明顯是分支任務適合異步化。第二步先做Async打底。給這些分支任務加上線程池和異步注解同時把異常處理器、日志、監(jiān)控配套做好。這一步投入小見效快也是積累異步經(jīng)驗最快的方式。第三步局部引入WebFlux。當某個入口的并發(fā)瓶頸特別明顯比如聚合接口、網(wǎng)關入口而這個服務的業(yè)務鏈路又相對清晰這部分可以嘗試換成響應式編程。不要一開始就把所有Service都改成Mono和Flux鏈路過深會讓改造成本成倍增長。第四步涉及跨系統(tǒng)的異步再上消息隊列。消息隊列引入的是整個中間件的運維成本如果沒有明確的削峰、解耦需求就不要為了用而用。10. 一點個人經(jīng)驗收尾做異步調用這些年最大的體會是異步方案從來不是技術問題而是取舍問題。它把當前線程的“等待時間”轉移給了別的線程換來的是接口響應速度的提升和系統(tǒng)吞吐量的改善代價是代碼復雜性、排查難度的上升以及分布式場景下一致性問題的新增。實際動手時我的習慣是先畫一張簡單的調用鏈路圖標出每個環(huán)節(jié)的耗時、線程、依賴再考慮在這個鏈路的哪個環(huán)節(jié)插入異步。不看鏈路就動手加注解往往是在給系統(tǒng)埋雷。如果你剛上手SpringBoot異步調用不用急著把三套方案都吃透先在自己項目里找一個實實在在的痛點比如每次下發(fā)通知都阻塞請求、導出數(shù)據(jù)超時、日志寫入拖慢業(yè)務用Async配合線程池改造一遍把代理失效、上下文傳遞、異常監(jiān)控這幾個點親手踩一遍比看再多文檔都有用。工具選型也一樣沒有絕對最好的方案。進程內的異步優(yōu)先Async高并發(fā)聚合優(yōu)先WebFlux跨系統(tǒng)解耦優(yōu)先消息隊列。每個方案的代價不一樣選適合自己項目階段的已經(jīng)足夠。