當(dāng)我們在處理慢接口問題時,經(jīng)常會使用多線程技術(shù),將能夠并行處理的任務(wù)拆分到不同的線程中處理,等任務(wù)處理完成后,再收集各線程的處理結(jié)果,進行后續(xù)的處理。整體思路如下圖所示:
圖片
這樣可以將并行部分的總耗時從 sum 降為 max,從而大幅降低接口的響應(yīng)時間。
訂單詳情頁耗時嚴(yán)重,p99 將近3秒,已經(jīng)驗證影響用戶體驗,本次迭代小艾專門對該接口進行優(yōu)化。迭代剛上線,該接口的響應(yīng)時間大幅降低,p99 降低到 800 毫秒以內(nèi),大家紛紛向小艾發(fā)來祝賀。但好景不長,隨著流量的增加,接口響應(yīng)時間也在逐漸變長,p99 超過 5 秒,最后系統(tǒng)拋出大量的 RejectedExecutionException 異常,這個接口不可用。最終,QA伙伴火速進行回滾操作,系統(tǒng)恢復(fù)正常。
系統(tǒng)恢復(fù)后,小艾仔細查看系統(tǒng)監(jiān)控,CPU使用率并不高,內(nèi)存也處于正常水位,接口性能居然比優(yōu)化前還差,真心不知道哪里出了問題。
優(yōu)化前代碼:
public RestResult<OrderDetailVO> getOrderDetail(@PathVariable Long orderId){ Stopwatch stopwatch = Stopwatch.createStarted(); OrderService.Order order = this.orderService.getById(orderId); if (order == null){ return RestResult.success(null); } OrderDetailVO orderDetail = new OrderDetailVO(); orderDetail.setUser(userService.getById(order.getUserId())); orderDetail.setAddress(addressService.getById(order.getUserAddressId())); orderDetail.setCoupon(couponService.getById(order.getCouponId())); orderDetail.setProduct(productService.getById(order.getProductId())); log.info("串行 Cost {} ms", stopwatch.stop().elapsed(TimeUnit.MILLISECONDS)); return RestResult.success(orderDetail);}
優(yōu)化前耗時:
圖片
優(yōu)化后代碼:
public RestResult<OrderDetailVO> getOrderDetailNew(@PathVariable Long orderId){ Stopwatch stopwatch = Stopwatch.createStarted(); OrderService.Order order = this.orderService.getById(orderId); if (order == null){ return RestResult.success(null); } Future<UserService.User> userFuture = this.executorService.submit(() -> userService.getById(order.getUserId())); Future<AddressService.Address> addressFuture = this.executorService.submit(() -> addressService.getById(order.getUserAddressId())); Future<CouponService.Coupon> couponFuture = this.executorService.submit(() -> couponService.getById(order.getCouponId())); Future<ProductService.Product> productFuture = this.executorService.submit(() -> productService.getById(order.getProductId())); OrderDetailVO orderDetail = new OrderDetailVO(); orderDetail.setUser(getFutureValue(userFuture)); orderDetail.setProduct(getFutureValue(productFuture)); orderDetail.setAddress(getFutureValue(addressFuture)); orderDetail.setCoupon(getFutureValue(couponFuture)); log.info("并行 Cost {} ms", stopwatch.stop().elapsed(TimeUnit.MILLISECONDS)); return RestResult.success(orderDetail); }
優(yōu)化后耗時:
圖片
可見采用并行優(yōu)化后,接口的響應(yīng)時間從 4 秒 將至 1 秒,效果還是非常明顯的。
但,繼續(xù)加大請求量,系統(tǒng)便出現(xiàn)問題,如下圖所示:
圖片
在流量逐漸增加的過程中,從日志中可以得到以下信息:
初期耗時穩(wěn)定,基本在 1 秒左右
接口耗時逐漸增大,甚至遠超串行處理的耗時(大于 4 秒)
有些請求直接拋出 RejectedExecutionException 異常
從代碼中并未發(fā)現(xiàn)任何問題,設(shè)計思路也非常清晰,其核心問題在線程池使用上,項目線程池配置如下:
int coreSize = Runtime.getRuntime().availableProcessors();executorService = new ThreadPoolExecutor(coreSize, coreSize * 5, 5L, TimeUnit.MINUTES, new LinkedBlockingQueue<Runnable>(1024) );
核心配置為:
在這個配置下,我們推演下以上的三個現(xiàn)象。
如下圖所示:
圖片
整體流程如下:
這正是想要的執(zhí)行結(jié)果,任務(wù)被并行執(zhí)行,大幅降低接口耗時。
隨著流量的增加,所有的核心線程都處于忙碌狀態(tài),此時新任務(wù)將進入等待隊列,具體如下:
圖片
整體流入如下:
任務(wù)在隊列中等待線程調(diào)度時間
任務(wù)分配到線程后,任務(wù)實際執(zhí)行時間
主線程等待時間 = 隊列等待時間 + 任務(wù)執(zhí)行時間。當(dāng)任務(wù)隊列非常長時,整體時間將遠超串行執(zhí)行時間。
流量繼續(xù)增加,線程池的任務(wù)隊列已滿并且線程數(shù)量也達到上限,此時會觸發(fā)拒絕策略,具體如下:
圖片
線程池默認拒絕策略為:AbortPolicy,直接拋出 RejectedExecutionException,從而觸發(fā)接口異常。
還有更可怕的情況,就是部分提交,也就是主線程已經(jīng)成功提交幾個任務(wù),如下圖所示:
圖片
核心流程如下:
前面已經(jīng)分析的很清楚,問題的本質(zhì)就是線程池資源分配不合理,核心參數(shù)設(shè)置錯誤:
除線程池參數(shù)問題外,還有個小問題:主線程完成任務(wù)提交后處于等待狀態(tài),未執(zhí)行任何有意義的操作,存在資源浪費。
改進線程池如下所示:
int coreSize = Runtime.getRuntime().availableProcessors();executorService = new ThreadPoolExecutor(coreSize, coreSize * 5, 5L, TimeUnit.MINUTES, new SynchronousQueue<>(), new ThreadPoolExecutor.CallerRunsPolicy() );
線程池配置如下:
在這個配置下,及時線程池中的所有資源全部耗盡,也只會降級到串行執(zhí)行,不會讓系統(tǒng)變的更糟糕。
新配置下,系統(tǒng)表現(xiàn)如下:
圖片
在最差的情況下也僅僅與串行執(zhí)行耗時一致。
總體來說就一句話:線程池有資源可用,那就為主線程分擔(dān)部分壓力;如果沒有資源可用,那就由主線程獨自完成。
上面提到一個小問題,在資源充足情況下,所有任務(wù)均有線程池線程完成,主線程一致處于等待狀態(tài),存在一定的資源浪費。
如下圖所示:
圖片
3 個任務(wù)耗費 4 個線程資源:
為了充分利用線程資源,可以讓主線程負責(zé)執(zhí)行任意一個任務(wù)。如下圖所示:
圖片
主線程不在盲目等待,也負責(zé)一個任務(wù)的執(zhí)行,這樣 3 個任務(wù)只需 3 個線程即可。
代碼上也非常簡單,具體如下:
public RestResult<OrderDetailVO> getOrderDetailNew(@PathVariable Long orderId){ Stopwatch stopwatch = Stopwatch.createStarted(); OrderService.Order order = this.orderService.getById(orderId); if (order == null){ return RestResult.success(null); } Future<UserService.User> userFuture = this.executorService.submit(() -> userService.getById(order.getUserId())); Future<AddressService.Address> addressFuture = this.executorService.submit(() -> addressService.getById(order.getUserAddressId())); Future<CouponService.Coupon> couponFuture = this.executorService.submit(() -> couponService.getById(order.getCouponId()));// Future<ProductService.Product> productFuture = this.executorService.submit(() -> productService.getById(order.getProductId())); OrderDetailVO orderDetail = new OrderDetailVO(); // 由主線程負責(zé)運行 orderDetail.setProduct(productService.getById(order.getProductId())); orderDetail.setUser(getFutureValue(userFuture)); orderDetail.setAddress(getFutureValue(addressFuture)); orderDetail.setCoupon(getFutureValue(couponFuture)); log.info("并行 Cost {} ms", stopwatch.stop().elapsed(TimeUnit.MILLISECONDS)); return RestResult.success(orderDetail);}
主線程執(zhí)行不同的任務(wù),會對接口的響應(yīng)時間產(chǎn)生影響嗎?
不會,并行執(zhí)行整體耗時為 max(任務(wù)耗時),主線程必須獲取全部結(jié)果才能運行,所以必須等待這么長時間。
代碼倉庫:https://gitee.com/litao851025/learnFromBug
代碼地址:https://gitee.com/litao851025/learnFromBug/tree/master/src/main/java/com/geekhalo/demo/thread/paralleltask
本文鏈接:http://www.www897cc.com/showinfo-26-66204-0.html【故障現(xiàn)場】多線程性能優(yōu)化最大的坑,99%人都不自知
聲明:本網(wǎng)頁內(nèi)容旨在傳播知識,若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系,我們將在第一時間刪除處理。郵件:2376512515@qq.com