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