如何讓Java Web 的性能翻倍？？？答曰——

響應式編程

響應式編程說來話長，概念也比較晦澀難懂，畫風也與我們常用的命令式編程不一樣。說清它的來龍去脈并不是小編今天的重點，我們只需要知道它是關于構建異步、事件驅動的非阻塞I/O應用即可。

要說明的是，此響應式(Reactive)非彼響應式(Responsive)。

雖然小編認為應該翻譯為“反應式”。不過國內已翻譯為“響應式”了，為避免混淆，本文也采用相同的術語。你知道本文說的不是H5那個響應式，就可以了。

Spring WebFlux

Spring框架從5.0開始擁抱ReactiveStreams規范，這個規范亦被Java9吸納為java.util.concurrent.Flow。而Spring WebFlux則是Spring團隊推出的基于響應式編程模型的Web框架。

性能測試

接下來我們通過測試，看看spring-webflux框架相對于自家的spring-webmvc，在性能上有什么差異。

我們測試以下3個框架：

1.spring-webmvc

2.spring-webflux

3.node.js?+ koa2(用以性能著稱的Node.js做參考)

三個框架均提供一個HTTP接口，直接返回“Hello World”字符串。

另外，JVM與Node均不作性能調優。

硬件方面，使用兩臺網絡直通的DigitalOcean云主機兩臺：

主機

配置

角色

benchmark-01

2U /?2GB

受壓服務器

benchmark-02

1U / 1GB

壓力源服務器

壓測使用wrk，并發數從100開始，每次遞增100，直至1000。每個框架采樣6次，取平均值。

由于我們著重考慮高并發下的性能，限于篇幅，我們對比在1000并發下，3個框架的性能指標：

框架

CPU占用率

內存使用

線程數

平均QPS

備注

spring-webmvc

198%

380M

2115

6621

spring-webflux

198%

390M

19

13112

koa2

198%

200M

12

13832

使用PM2啟動2個實例，以充分利用多核

可以看出，在同等用例下，spring-webflux有相對于spring-webmvc兩倍的QPS，能夠達到與Node差不多的性能。

我們都知道，越多的線程意味著越多的CPU上下文切換消耗。在1000并發下，spring-webflux僅需19個線程，而spring-webmvc則需要使用2000多個線程。從結果來看，3個case的CPU均跑滿，因此服務器的瓶頸為CPU，可以推測，在多核多CPU的服務器下，性能差距會進一步加大。

另外，這只是純框架層面的測試，響應式的優勢在I/O密集、復雜業務場景，在這類場景下優勢會更為明顯。

總結

spring-webflux還處于Milestone階段，在性能上的提升已經足夠誘人。況且響應式編程模型還納入了Java 9的API，有構建高并發應用，而又希望繼續使用統一的Java技術棧的團隊，可以持續關注。

總結

以上是生活随笔為你收集整理的java线程数翻倍性能翻倍_术业专攻 | 如何让Java Web性能翻倍？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。