13518219792
這篇文章主要介紹了Java中Servlet3.0異步處理的示例分析，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。
肥西ssl適用于網(wǎng)站、小程序/APP、API接口等需要進(jìn)行數(shù)據(jù)傳輸應(yīng)用場景，ssl證書未來市場廣闊！成為創(chuàng)新互聯(lián)的ssl證書銷售渠道，可以享受市場價格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：18982081108（備注：SSL證書合作）期待與您的合作！
通過本篇文章主要給大家講解了在JAVA開發(fā)中Servlet3.0異步處理遇到的問題以及處理辦法，以下是具體內(nèi)容：
Servlet 3.0 開始提供了AsyncContext用來支持異步處理請求，那么異步處理請求到底能夠帶來哪些好處？
Web容器一般來說處理請求的方式是：為每個request分配一個thread。我們都知道thread的創(chuàng)建不是沒有代價的，Web容器的thread pool都是有上限的。
那么一個很容易預(yù)見的問題就是，在高負(fù)載情況下，thread pool都被占著了，那么后續(xù)的request就只能等待，如果運氣不好客戶端會報等待超時的錯誤。
在AsyncContext出現(xiàn)之前，解決這個問題的唯一辦法就是擴(kuò)充Web容器的thread pool。
但是這樣依然有一個問題，考慮以下場景：
有一個web容器，線程池大小200。有一個web app，它有兩個servlet，Servlet-A處理單個請求的時間是10s，Servlet-B處理單個請求的時間是1s。
現(xiàn)在遇到了高負(fù)載，有超過200個request到Servlet-A，如果這個時候請求Servlet-B就會等待，因為所有HTTP thread都已經(jīng)被Servlet-A占用了。
這個時候工程師發(fā)現(xiàn)了問題，擴(kuò)展了線程池大小到400，但是負(fù)載依然持續(xù)走高，現(xiàn)在有400個request到Servlet-A，Servlet-B依然無法響應(yīng)。
看到問題了沒有，因為HTTP thread和Worker thread耦合在了一起，所以導(dǎo)致了當(dāng)大量request到一個耗時操作時，就會將HTTP thread占滿，導(dǎo)致整個Web容器就會無法響應(yīng)。
但是如果使用AsyncContext，我們就可以將耗時的操作交給另一個thread去做，這樣HTTP thread就被釋放出來了，可以去處理其他請求了。
注意，只有使用AsyncContext才能夠達(dá)到上面所講的效果，如果直接new Thread()或者類似的方式的，HTTP thread并不會歸還到容器。
下面是一個官方的例子：
@WebServlet(urlPatterns={"/asyncservlet"}, asyncSupported=true)
public class AsyncServlet extends HttpServlet {
/* ... Same variables and init method as in SyncServlet ... */
@Override
public void doGet(HttpServletRequest request,
HttpServletResponse response) {
response.setContentType("text/html;charset=UTF-8");
final AsyncContext acontext = request.startAsync();
acontext.start(new Runnable() {
public void run() {
String param = acontext.getRequest().getParameter("param");
String result = resource.process(param);
HttpServletResponse response = acontext.getResponse();
/* ... print to the response ... */
acontext.complete();
}
});
}
}陷阱
在這個官方例子里，每個HTTP thread都會開啟另一個Worker thread來處理請求，然后把HTTP thread就歸還給Web容器。但是看AsyncContext.start()方法的javadoc：
Causes the container to dispatch a thread, possibly from a managed thread pool, to run the specified Runnable.
實際上這里并沒有規(guī)定Worker thread到底從哪里來，也許是HTTP thread pool之外的另一個thread pool？還是說就是HTTP thread pool？
The Limited Usefulness of AsyncContext.start()文章里寫道：不同的Web容器對此有不同的實現(xiàn)，不過Tomcat實際上是利用HTTP thread pool來處理AsyncContext.start()的。
這也就是說，我們原本是想釋放HTTP thread的，但實際上并沒有，因為有HTTP thread依然被用作Worker thread，只不過這個thread和接收請求的HTTP thread不是同一個而已。
這個結(jié)論我們也可以通過AsyncServlet1和SyncServlet的Jmeter benchmark看出來，兩者的throughput結(jié)果差不多。啟動方法：啟動Main，然后利用Jmeter啟動benchmark.jmx（Tomcat默認(rèn)配置下HTTP thread pool=200）。
使用ExecutorService
前面看到了Tomcat并沒有單獨維護(hù)Worker thread pool，那么我們就得自己想辦法搞一個，見AsyncServlet2，它使用了一個帶Thread pool的ExecutorService來處理AsyncContext。
其他方式
所以對于AsyncContext的使用并沒有固定的方式，你可以根據(jù)實際需要去采用不同的方式來處理，為此你需要一點Java concurrent programming的知識。
對于性能的誤解
AsyncContext的目的并不是為了提高性能，也并不直接提供性能提升，它提供了把HTTP thread和Worker thread解藕的機制，從而提高Web容器的響應(yīng)能力。
不過AsyncContext在某些時候的確能夠提高性能，但這個取決于你的代碼是怎么寫的。
比如：Web容器的HTTP thread pool數(shù)量200，某個Servlet使用一個300的Worker thread pool來處理AsyncContext。
相比Sync方式Worker thread pool=HTTP thread pool=200，在這種情況下我們有了300的Worker thread pool，所以肯定能夠帶來一些性能上的提升（畢竟干活的人多了）。
相反，如果當(dāng)Worker thread的數(shù)量<=HTTP thread數(shù)量的時候，那么就不會得到性能提升，因為此時處理請求的瓶頸在Worker thread。
你可以修改AsyncServlet2的線程池大小，把它和SyncServlet比較benchmark結(jié)果來驗證這一結(jié)論。
一定不要認(rèn)為Worker thread pool必須比HTTP thread pool大，理由如下：
兩者職責(zé)不同，一個是Web容器用來接收外來請求，一個是處理業(yè)務(wù)邏輯
thread的創(chuàng)建是有代價的，如果HTTP thread pool已經(jīng)很大了再搞一個更大的Worker thread pool反而會造成過多的Context switch和內(nèi)存開銷
AsyncContext的目的是將HTTP thread釋放出來，避免被操作長期占用進(jìn)而導(dǎo)致Web容器無法響應(yīng)
所以在更多時候，Worker thread pool不會很大，而且會根據(jù)不同業(yè)務(wù)構(gòu)建不同的Worker thread pool。
比如：Web容器thread pool大小200，一個慢速Servlet的Worker thread pool大小10，這樣一來，無論有多少請求到慢速操作，它都不會將HTTP thread占滿導(dǎo)致其他請求無法處理。
感謝你能夠認(rèn)真閱讀完這篇文章，希望小編分享的“Java中Servlet3.0異步處理的示例分析”這篇文章對大家有幫助，同時也希望大家多多支持創(chuàng)新互聯(lián)，關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，更多相關(guān)知識等著你來學(xué)習(xí)!
