序言
對于異步方法調用,從Spring3開始提供了@Async注解,該注解可以被標在方法上,以便異步地調用該方法。調用者將在調用時立即返回,方法的實際執行將提交給Spring TaskExecutor的任務中,由指定的線程池中的線程執行。
在項目應用中,@Async調用線程池,推薦使用自定義線程池的模式。自定義線程池常用方案:重新實現接口AsyncConfigurer。
應用場景
同步:同步就是整個處理過程順序執行,當各個過程都執行完畢,并返回結果。
異步:異步調用則是只是發送了調用的指令,調用者無需等待被調用的方法完全執行完畢;而是繼續執行下面的流程。例如, 在某個調用中,需要順序調用 A, B, C三個過程方法;如他們都是同步調用,則需要將他們都順序執行完畢之后,方算作過程執行完畢;如B為一個異步的調用方法,則在執行完A之后,調用B,并不等待B完成,而是執行開始調用C,待C執行完畢之后,就意味著這個過程執行完畢了。在Java中,一般在處理類似的場景之時,都是基于創建獨立的線程去完成相應的異步調用邏輯,通過主線程和不同的業務子線程之間的執行流程,從而在啟動獨立的線程之后,主線程繼續執行而不會產生停滯等待的情況。
Spring已經實現的線程池
SimpleAsyncTaskExecutor:不是真的線程池,這個類不重用線程,默認每次調用都會創建一個新的線程。
SyncTaskExecutor:這個類沒有實現異步調用,只是一個同步操作。只適用于不需要多線程的地方。
ConcurrentTaskExecutor:Executor的適配類,不推薦使用。如果ThreadPoolTaskExecutor不滿足要求時,才用考慮使用這個類。
SimpleThreadPoolTaskExecutor:是Quartz的SimpleThreadPool的類。線程池同時被quartz和非quartz使用,才需要使用此類。
ThreadPoolTaskExecutor :最常使用,推薦。其實質是對java.util.concurrent.ThreadPoolExecutor的包裝。
異步的方法有:
最簡單的異步調用,返回值為void
帶參數的異步調用,異步方法可以傳入參數
存在返回值,常調用返回Future
Spring中啟用@Async
?
@Async應用默認線程池
Spring應用默認的線程池,指在@Async注解在使用時,不指定線程池的名稱。查看源碼,@Async的默認線程池為SimpleAsyncTaskExecutor。
無返回值調用
基于@Async無返回值調用,直接在使用類,使用方法(建議在使用方法)上,加上注解。若需要拋出異常,需手動new一個異常拋出。
有返回值Future調用
有返回值CompletableFuture調用
CompletableFuture 并不使用@Async注解,可達到調用系統線程池處理業務的功能。 JDK5新增了Future接口,用于描述一個異步計算的結果。雖然 Future 以及相關使用方法提供了異步執行任務的能力,但是對于結果的獲取卻是很不方便,只能通過阻塞或者輪詢的方式得到任務的結果。阻塞的方式顯然和我們的異步編程的初衷相違背,輪詢的方式又會耗費無謂的 CPU 資源,而且也不能及時地得到計算結果。
CompletionStage代表異步計算過程中的某一個階段,一個階段完成以后可能會觸發另外一個階段
一個階段的計算執行可以是一個Function,Consumer或者Runnable。比如:
stage.thenApply(x -> square(x)).thenAccept(x -> System.out.print(x)).thenRun(() -> System.out.println())
一個階段的執行可能是被單個階段的完成觸發,也可能是由多個階段一起觸發
在Java8中,CompletableFuture 提供了非常強大的Future的擴展功能,可以幫助我們簡化異步編程的復雜性,并且提供了函數式編程的能力,可以通過回調的方式處理計算結果,也提供了轉換和組合 CompletableFuture 的方法。
它可能代表一個明確完成的Future,也有可能代表一個完成階段( CompletionStage ),它支持在計算完成以后觸發一些函數或執行某些動作。
它實現了Future和CompletionStage接口
默認線程池的弊端
在線程池應用中,參考阿里巴巴java開發規范:線程池不允許使用Executors去創建,不允許使用系統默認的線程池,推薦通過ThreadPoolExecutor的方式,這樣的處理方式讓開發的工程師更加明確線程池的運行規則,規避資源耗盡的風險。
Executors各個方法的弊端:
newFixedThreadPool和newSingleThreadExecutor:主要問題是堆積的請求處理隊列可能會耗費非常大的內存,甚至OOM。
newCachedThreadPool和newScheduledThreadPool:要問題是線程數最大數是Integer.MAX_VALUE,可能會創建數量非常多的線程,甚至OOM。
@Async默認異步配置使用的是SimpleAsyncTaskExecutor,該線程池默認來一個任務創建一個線程,若系統中不斷的創建線程,最終會導致系統占用內存過高,引發OutOfMemoryError錯誤。針對線程創建問題,SimpleAsyncTaskExecutor提供了限流機制,通過concurrencyLimit屬性來控制開關,當concurrencyLimit>=0時開啟限流機制,默認關閉限流機制即concurrencyLimit=-1,當關閉情況下,會不斷創建新的線程來處理任務。基于默認配置,SimpleAsyncTaskExecutor并不是嚴格意義的線程池,達不到線程復用的功能。歡迎關注公眾號"Java學習之道",查看更多干貨!
@Async應用自定義線程池
自定義線程池,可對系統中線程池更加細粒度的控制,方便調整線程池大小配置,線程執行異常控制和處理。在設置系統自定義線程池代替默認線程池時,雖可通過多種模式設置,但替換默認線程池最終產生的線程池有且只能設置一個(不能設置多個類繼承AsyncConfigurer)自定義線程池有如下模式:
重新實現接口AsyncConfigurer
繼承AsyncConfigurerSupport
配置由自定義的TaskExecutor替代內置的任務執行器
通過查看Spring源碼關于@Async的默認調用規則,會優先查詢源碼中實現AsyncConfigurer這個接口的類,實現這個接口的類為AsyncConfigurerSupport。但默認配置的線程池和異步處理方法均為空,所以,無論是繼承或者重新實現接口,都需指定一個線程池。且重新實現 public Executor getAsyncExecutor()方法。
實現接口AsyncConfigurer
繼承AsyncConfigurerSupport
配置自定義的TaskExecutor
由于AsyncConfigurer的默認線程池在源碼中為空,Spring通過beanFactory.getBean(TaskExecutor.class)先查看是否有線程池,未配置時,通過beanFactory.getBean(DEFAULT_TASK_EXECUTOR_BEAN_NAME, Executor.class),又查詢是否存在默認名稱為TaskExecutor的線程池。所以可在項目中,定義名稱為TaskExecutor的bean生成一個默認線程池。也可不指定線程池的名稱,申明一個線程池,本身底層是基于TaskExecutor.class便可。 比如:
Executor.class:ThreadPoolExecutorAdapter->ThreadPoolExecutor->AbstractExecutorService->ExecutorService->Executor這樣的模式,最終底層為Executor.class,在替換默認的線程池時,需設置默認的線程池名稱為TaskExecutor
TaskExecutor.class:ThreadPoolTaskExecutor->SchedulingTaskExecutor->AsyncTaskExecutor->TaskExecutor這樣的模式,最終底層為TaskExecutor.class,在替換默認的線程池時,可不指定線程池名稱。 ?
-
spring
+關注
關注
0文章
338瀏覽量
14311 -
線程池
+關注
關注
0文章
57瀏覽量
6834 -
注解
+關注
關注
0文章
18瀏覽量
2669
原文標題:阿里巴巴為什么不建議直接使用@Async注解?
文章出處:【微信號:AndroidPush,微信公眾號:Android編程精選】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論