6月安卓手機性價比榜：Note 12 Turbo斷層式碾壓
6月份有一個618，雖然這是京東周年慶的日子，但別的電商也都不約而同的跟進了，反正促銷沒壞處，廠商和用戶都能滿意。618期間一些產品也出現了歷史低價，那么各個價位段的產品性價比
Servlet 3.0之前：每一次Http請求都由一個線程從頭到尾處理。
Servlet 3.0之后，提供了異步處理請求：可以先釋放容器分配給請求的線程與相關資源，減輕系統(tǒng)負擔，從而增加服務的吞吐量。
在springboot應用中，可以有4種方式實現異步接口（至于ResponseBodyEmitter、SseEmitter、StreamingResponseBody，不在本文介紹內，之后新寫文章介紹）：
第一中AsyncContext是Servlet層級的，比較原生的方式，本文不對此介紹（一般都不使用它，太麻煩了）。本文著重介紹后面三種方式。
特別說明：服務端的異步或同步對于客戶端而言是不可見的。不會因為服務端使用了異步，接口的結果就和同步不一樣了。另外，對于單個請求而言，使用異步接口會導致響應時間比同步大，但不特別明顯。具體后文分析。
Controller中，返回一個java.util.concurrent.Callable包裝的任何值，都表示該接口是一個異步接口：
@GetMapping("/testCallAble")public Callable<String> testCallAble() { return () -> { Thread.sleep(40000); return "hello"; };}服務器端的異步處理對客戶端來說是不可見的。例如，上述接口，最終返回的客戶端的是一個String，和同步接口中，直接返回String的效果是一樣的。
Callable 處理過程如下：
控制器返回一個 Callable 。
Callable默認使用SimpleAsyncTaskExecutor類來執(zhí)行，這個類非常簡單而且沒有重用線程。在實踐中，需要使用AsyncTaskExecutor類來對線程進行配置。
Spring提供的WebAsyncTask是對Callable的包裝，提供了更強大的功能，比如：處理超時回調、錯誤回調、完成回調等。本質上，和Callable區(qū)別不大，但是由于它額外封裝了一些事件的回調，所有，通常都使用WebAsyncTask而不是Callable：
@GetMapping("/webAsyncTask")public WebAsyncTask<String> webAsyncTask() { WebAsyncTask<String> result = new WebAsyncTask<>(30003, () -> { return "success"; }); result.onTimeout(() -> { log.info("timeout callback"); return "timeout callback"; }); result.onCompletion(() -> log.info("finish callback")); return result;}這里額外提一下，WebAsyncTask可以配置一個超時時間，這里配置的超時時間比全局配置的超時時間優(yōu)先級都高（會覆蓋全局配置的超時時間）。
DeferredResult使用方式與Callable類似，但在返回結果時不一樣，它返回的時實際結果可能沒有生成，實際的結果可能會在另外的線程里面設置到DeferredResult中去。
//定義一個全局的變量，用來存儲DeferredResult對象private Map<String, DeferredResult<String>> deferredResultMap = new ConcurrentHashMap<>();@GetMapping("/testDeferredResult")public DeferredResult<String> testDeferredResult(){ DeferredResult<String> deferredResult = new DeferredResult<>(); deferredResultMap.put("test", deferredResult); return deferredResult;}如果調用以上接口，會發(fā)現客戶端的請求一直是在pending狀態(tài)——等待后端響應。這里，我簡單的將該接口返回的DeferredResult對象存放在了一個Map集合中，實際應用中可以設計一個對象管理器來統(tǒng)一管理這些個對象。
注意：要考慮定時輪詢（或其他方式）這些對象，將已經處理過或無效的DeferredResult對象清理掉（DeferredResult.isSetOrExpired方法可以判斷是否還有效），避免內存泄露。
這里我又寫了一個接口，模擬:
@GetMapping("/testSetDeferredResult")public String testSetDeferredResult() throws InterruptedException { DeferredResult<String> deferredResult = deferredResultMap.get("test"); boolean flag = deferredResult.setResult("testSetDeferredResult"); if(!flag){ log.info("結果已經被處理，此次操作無效"); } return "ok";}其他線程修改DeferredResult的值：首先是從之前存放DeferredResult的map中拿到DeferredResult的值，然后設置它的返回值。當執(zhí)行deferredResult.setResult之后，可以看到之前pending狀態(tài)的接口完成了響應，得到的結果，就是這里設置的值。
這里也額外說下：在返回DeferredResult時也可以設置超時時間，這個時間的優(yōu)先級也是大于全局設置的。另外，判斷DeferredResult是否有效，只是一個簡單的判斷，實際中判斷有效的并不一定是有效的（比如：客戶端取消了請求，服務端是不知道的），但是一般判斷為無效的，那肯定是無效了。
DeferredResult 處理過程如下：
異步請求，不會一直占用請求的主線程（tomcat容器中處理請求的線程），而是通過一個其他的線程來處理異步任務。也正是如此，在相同的最大請求數配置下，異步請求由于迅速的釋放了主線程，所以才能提高吞吐量。
這里提到一個其他線程，那么這個其他線程我們一般都不適用默認的，都是根據自身情況提供一個線程池供異步請求使用：（我給的參數都是測試用的，實際中不可照搬）。
@Bean("mvcAsyncTaskExecutor")public AsyncTaskExecutor asyncTaskExecutor() { ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor(); // 線程池維護線程的最少數量 // asyncServiceExecutor.setCorePoolSize(Runtime.getRuntime().availableProcessors() + 1); executor.setCorePoolSize(5); // 線程池維護線程的最大數量 executor.setMaxPoolSize(10); // 線程池所使用的緩沖隊列 executor.setQueueCapacity(10); // asyncServiceExecutor.prefersShortLivedTasks(); executor.setThreadNamePrefix("fyk-mvcAsyncTask-Thread-"); asyncServiceExecutor.setBeanName("TaskId" + taskId); // asyncServiceExecutor.setKeepAliveSeconds(20); //調用者執(zhí)行 // asyncServiceExecutor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.DiscardPolicy()); // 線程全部結束才關閉線程池 executor.setWaitForTasksToCompleteOnShutdown(true); // 如果超過60s還沒有銷毀就強制銷毀，以確保應用最后能夠被關閉，而不是阻塞住 executor.setAwaitTerminationSeconds(30); executor.initialize(); return executor;}把這個線程池配置設置到異步請求配置中：
@Configurationpublic class FykWebMvcConfigurer implements WebMvcConfigurer { @Autowired @Qualifier("mvcAsyncTaskExecutor") private AsyncTaskExecutor asyncTaskExecutor; @Override public void configureAsyncSupport(AsyncSupportConfigurer configurer) { //異步操作的超時時間，值為0或者更小，表示永不超時 configurer.setDefaultTimeout(60001); configurer.setTaskExecutor(asyncTaskExecutor); }}異步請求能提高吞吐量，這個是建立在相同配置（這里的配置指的是：最大連接數、最大工作線程數）的情況下。因此并不是說任何接口都可以使用異步請求。比如：一個請求是進行大量的計算（總之就是在處理這個請求的業(yè)務方法時CPU是沒有休息的），這種情況使用異步請求就沒有多大意義了，因為這時的異步請求只是把一個任務從tomcat的工作線程搬到了另一個線程罷了。
直接調大最大工作線程數配置也能到達要求。所以，真正使用異步請求的場景應該是該請求的業(yè)務代碼中，大量的時間CPU是休息的（比如：在業(yè)務代碼中請求其他系統(tǒng)的接口，在其他系統(tǒng)響應之前，CPU是阻塞等待的），這個時候使用異步請求，就可以釋放tomcat的工作線程，讓釋放的工作線程可以處理其他的請求，從而提高吞吐量。
由于異步請求增加了更多的線程切換（同步請求是同一個工作線程一直處理），所以理論上會增加接口的耗時。但，這個耗時很短很短。
本文鏈接：http://www.tebozhan.com/showinfo-26-112714-0.htmlSpringBoot異步接口實現：提高系統(tǒng)的吞吐量
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號