當(dāng)前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

servlet异步_关于Servlet和异步Servlet

發(fā)布時(shí)間：2023/12/3 编程问答 54 豆豆

生活随笔收集整理的這篇文章主要介紹了 servlet异步_关于Servlet和异步Servlet 小編覺得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.

servlet異步

Servlet API是Java EE標(biāo)準(zhǔn)的一部分，自1998年正式發(fā)布2.1規(guī)范以來，一直是基于Java的企業(yè)體系結(jié)構(gòu)的重要組成部分。

它是一種自以為是的API，用于服務(wù)圍繞一些基本概念構(gòu)建的請求/響應(yīng)協(xié)議：

兼容的容器，這是專用的運(yùn)行時(shí)，它可以是獨(dú)立服務(wù)器（過去更常見）或基于庫的嵌入式運(yùn)行時(shí)（如今更常見）。它可以支持一次托管多個(gè)Web應(yīng)用程序，并在它們之間隔離類加載。它還可以提供管理功能，例如應(yīng)用程序部署，啟動(dòng)，停止，資源分配，JNDI命名上下文，帶有連接池的JDBC數(shù)據(jù)源，HTTP適配器，線程池等。基本上，它是Java EE功能的集中管理包，可以刪除兼容的應(yīng)用程序。
一個(gè)或多個(gè)servlet ，即實(shí)現(xiàn)Servlet接口的類，它不是特定于HTTP的，因?yàn)镾ervlet規(guī)范通常是為請求/響應(yīng)協(xié)議設(shè)計(jì)的。實(shí)現(xiàn)接口意味著處理大多數(shù)容器已經(jīng)處理過的servlet配置信息，因此擴(kuò)展作為規(guī)范一部分的抽象類（如GenericServlet甚至HttpServlet ）更為普遍（方便）。除了生命周期管理外，其余要實(shí)現(xiàn)的方法是請求處理程序，當(dāng)請求進(jìn)入時(shí)，容器將調(diào)用該請求處理程序，并應(yīng)為它們提供服務(wù)。他們將通過處理從容器本身作為參數(shù)接收的可變請求和響應(yīng)對象（也包括標(biāo)準(zhǔn)接口），或者通過在發(fā)生某些意外情況時(shí)引發(fā)異常來進(jìn)行此操作，容器將根據(jù)配置方式對其進(jìn)行適當(dāng)?shù)墓芾?#xff0c;例如，通過重定向到JSP頁面。它們還可以包括處理并將處理（的一部分）委托給一個(gè)全新的處理鏈，該處理鏈通過RequestDispatcher映射到一些不同的URL。這是一種鏈接servlet的機(jī)制，主要在2.3引入過濾器之前使用。
一個(gè)或多個(gè)過濾器，擴(kuò)展了Filter接口，并且與servlet相似，不同之處在于它們支持鏈接，即它們按順序排列，可以將請求處理（的一部分）委托給鏈中的下一個(gè)過濾器，并執(zhí)行發(fā)布-處理完成時(shí)。 Servlet始終位于過濾器鏈的末尾。
設(shè)置信息，例如請求和過濾器到HTTP請求的映射，可以通過多種方式提供，從XML描述符到類注釋再到實(shí)際的初始化代碼。
請求服務(wù)線程：每個(gè)請求由一個(gè)專用線程服務(wù)，該線程將運(yùn)行該請求本身已映射到的整個(gè)篩選器鏈，并阻塞與HTTP請求和響應(yīng)相關(guān)的網(wǎng)絡(luò)I / O操作以及任何其他線程完成請求處理所需的-blocking調(diào)用。

剖析Servlet API

如果我們試圖表征長期存在的Servlet API，則可以將其限定為：

絕對涉及對象，因?yàn)樯婕暗拿總€(gè)概念（無論多么抽象）都已被對象化并轉(zhuǎn)換為接口或類。 “ Servlet”，“ Filter”，“ RequestDispatcher”都是這種建模風(fēng)格的示例。唯一的例外是容器本身，它是幕后的無處不在的參與者，但沒有唯一的表示形式，可以通過顯式參與者或諸如上下文之類的次要對象進(jìn)行間接處理。
它是基于（面向?qū)ο?#xff09;模式的，我們可以識(shí)別其中的許多模式。
它具有狀態(tài)機(jī)語義，它是有狀態(tài)的，并且是可變的，因?yàn)榧僭O(shè)請求處理過程處于某種狀態(tài)（這是所有API的對象化參與者的狀態(tài)的總和，包括容器），那么會(huì)有一些操作將其轉(zhuǎn)換為一個(gè)新的，可部分檢查的不同狀態(tài)，同時(shí)禁止其他過渡（例如，在提交響應(yīng)后轉(zhuǎn)發(fā)請求）。
它是基于處理程序的，因?yàn)槟?#xff08;開發(fā)人員）在感覺舒適時(shí)不會(huì)請求傳入的請求，而是將它們推送到您的servlet中，您不得不將它們編碼為目標(biāo)化的請求處理程序。
它是低級的，因?yàn)樗惶峁┞酚蓹C(jī)制，也沒有建立特定的范例，例如MVC。
它最初是同步的，因?yàn)樘幚沓绦驊?yīng)該在調(diào)用計(jì)算上下文（堆棧）內(nèi)完成請求處理，而根本不打算推遲請求處理。
它明確地基于線程，因?yàn)橐?guī)范指出處理程序的計(jì)算上下文是servlet容器線程。同步和基于線程的結(jié)合在一起基本上意味著Servlet API最初被設(shè)計(jì)為線程阻塞的。

總而言之，它是一個(gè)非常復(fù)雜且自以為是的API，盡管它基于非常普遍的觀點(diǎn)并且具有很長的向后兼容歷史。

順便說一句：Clojure的戒指，HTTP服務(wù)器的全新明晰和簡約視圖

盡管Clojure社區(qū)非常多元化，并且在每個(gè)領(lǐng)域都有很多非常有趣的選擇，但Web的“事實(shí)上”的Clojure低級基本標(biāo)準(zhǔn)框架是Ring 。

鑒于HTTP幾乎是一個(gè)無狀態(tài)的請求-響應(yīng)協(xié)議，HTTP請求服務(wù)自然是一個(gè)非常適合于功能性，輸入-輸出建模風(fēng)格的領(lǐng)域。實(shí)際上，Ring認(rèn)為HTTP請求總共具有3個(gè)具有直接關(guān)系的功能實(shí)體：

處理程序是一個(gè)函數(shù)，其功能是接收一個(gè)具有眾所周知的鍵名和值類型的Clojure映射作為唯一輸入，表示HTTP請求，并生成另一個(gè)必須具有特定結(jié)構(gòu)的Clojure映射作為其輸出（表示HTTP響應(yīng)（這是但是過度簡化，因?yàn)镽ing允許返回更簡單的數(shù)據(jù)結(jié)構(gòu)以方便使用）。
中間件是一個(gè)接收處理程序功能并生成另一個(gè)處理程序功能的功能。因此，中間件是一種高階函數(shù)，旨在以某種特定方式豐富任何處理程序的邏輯，例如攔截和處理文件系統(tǒng)請求或使用多部分預(yù)處理信息來豐富請求本身，因此類似于Servlet過濾器，盡管通過一流的函數(shù)之類的函數(shù)式編程思想使其變得更加簡單。請注意，可以通過功能組合的直接方式將中間件按特定順序鏈接，因?yàn)閷⒅虚g件應(yīng)用于處理程序所獲得的是另一個(gè)處理程序，然后可以將多個(gè)中間件功能應(yīng)用于該處理程序。
適配器是一個(gè)接收處理程序函數(shù)且不返回任何內(nèi)容的函數(shù)，作為其主要輸入。它的目的純粹是產(chǎn)生一些HTTP服務(wù)器的副作用，該HTTP服務(wù)器將使用提供的處理程序來處理請求，因此實(shí)際上是某些先前存在的（或新的）HTTP服務(wù)器技術(shù)的適配器。它的功能接口不是標(biāo)準(zhǔn)的，因?yàn)樗梢越邮盏妮斎朐诤艽蟪潭壬先Q于技術(shù)，但是一種常見的模式是許多適配器將處理程序作為第一個(gè)參數(shù)來接收，然后將與實(shí)現(xiàn)相關(guān)的選項(xiàng)映射（或其他序列）作為第一個(gè)參數(shù)。第二個(gè)。此外，最常用的選項(xiàng)（例如偵聽接口和端口）在大多數(shù)適配器中往往具有相同的鍵名。

Ring也是一種自以為是的API，并且在某些方面它并不偏離流行的概念，例如，它仍然是基于處理程序的，盡管適配器只是功能的想法使得將其用作嵌入式HTTP非常簡單。其他完全傳統(tǒng)的應(yīng)用程序的邊界”；加上它是同步的，這非常好，因?yàn)樗勾a簡單易維護(hù)。仍然需要對主題保持新鮮，清晰和簡約的觀點(diǎn)，嘗試完全消除偶發(fā)的復(fù)雜性，并提供最少數(shù)量的正交概念，以利用功能編程思想和動(dòng)態(tài)語言靈活性來簡潔有效地處理領(lǐng)域的內(nèi)在復(fù)雜性為了這個(gè) 這種方法非常符合Clojure語言本身的精神。

請注意，Ring并沒有提及執(zhí)行上下文：對于某些人來說，基于輕量級光纖而不是重量級線程來為其阻塞API實(shí)現(xiàn)適配器是完全可以的：這正是Comsat提供的，Ring的清晰性和簡約性極大地簡化了此類編寫整合。

Servlet 3.0異步

Servlet規(guī)范的Async附加示例說明了以下事實(shí)：OOP不一定簡化有狀態(tài)API的復(fù)雜性。有時(shí)相反，它只能通過在表中散布狀態(tài)，將其拆分并放入對象中來提供這樣做的危險(xiǎn)幻覺。

這種錯(cuò)覺實(shí)際上會(huì)使情況惡化，因?yàn)樗刮覀冋J(rèn)為，開發(fā)有狀態(tài)API的看似非常簡單的想法確實(shí)可以正常工作而不會(huì)產(chǎn)生意想不到的后果。

Servlet 3.0中 Async功能背后的“簡單”思想是一種新的請求模式，即異步請求模式。當(dāng)通過startAsync方法調(diào)用將請求切換為異步時(shí)，我們“簡單地”告訴容器，只要請求處理鏈（過濾器和servlet）返回并且其關(guān)聯(lián)的容器線程完成，我們就根本不意味著請求處理已經(jīng)完成，因此不應(yīng)將響應(yīng)發(fā)送回HTTP客戶端。相反，應(yīng)將其保留，直到其他執(zhí)行上下文發(fā)出確實(shí)已完成請求處理的信號為止，并且它將通過對startAsync調(diào)用返回的AsyncContext對象的complete或dispatch方法調(diào)用來complete 。

不用說，異步模式與先前存在的Servlet API的有狀態(tài)移動(dòng)部分可能存在幾種交互作用：接下來，我們將對其中的一些進(jìn)行交互。

異步模式下的錯(cuò)誤處理

AsyncContext提供了注冊有關(guān)請求處理進(jìn)度和異常情況的偵聽器的功能，但是我們將在容器線程之外運(yùn)行自管理執(zhí)行上下文，因此容器無法為我們捕獲和處理異常。

相反， AsyncContext確實(shí)提供了一種新的處理委托形式，它將控制權(quán)轉(zhuǎn)移回容器管理的線程，這就是dispatch方法的目的。通過在請求屬性中設(shè)置錯(cuò)誤條件（和任何其他相關(guān)信息）之后使用它，并檢查請求的調(diào)度程序類型，我們可以驗(yàn)證我們確實(shí)在處理源自異步處理流的異常條件，然后選擇重新引發(fā)異常，這一次可以依靠容器的管理能力。

這種方法有點(diǎn)復(fù)雜，并且基本上需要使用經(jīng)過改進(jìn)的前向/調(diào)度功能，實(shí)際上，事實(shí)上，這些功能以前已被過濾器棄用。但是它可以工作，并且能夠模仿在同步設(shè)置中發(fā)生的錯(cuò)誤處理流程。衡量它的效率當(dāng)然很有趣。

Servlet API也一直提供sendError功能，但到目前為止，尚不清楚它是否（以及如何）以異步模式工作，即使在大多數(shù)流行的servlet容器（如Jetty和Tomcat）中，這種情況也很容易導(dǎo)致開放問題。

在異步模式下過濾

Servlet 3.0規(guī)范明確禁止在與容器線程不同的執(zhí)行上下文中運(yùn)行過濾器鏈接。此限制意味著，在請求處理鏈末尾的唯一處理程序（即Servlet）可以將請求置于異步模式，而預(yù)處理過濾器邏輯只能在容器的線程中執(zhí)行。

這是非常不幸的，因?yàn)樽詮囊脒^濾器以來，許多流行的框架和應(yīng)用程序開發(fā)人員就使用它們來執(zhí)行大量的請求處理，而這些請求處理可以受益于在單獨(dú)的執(zhí)行上下文（例如光纖）中運(yùn)行而不會(huì)阻塞昂貴的容器線程。

實(shí)際上，在流行的servlet容器中有一些關(guān)于此限制的未解決問題。

Servlet 3.1：異步HTTP I / O

Servlet 3.0能夠從請求處理完成中分離容器的線程和Servlet的處理代碼，但是用于讀取請求和寫入響應(yīng)的I / O仍然是線程阻塞的。

Servlet 3.1通過setReadListener和setWriteListener方法向請求添加了異步I / O功能（如果它們已經(jīng)處于異步模式）。

關(guān)于這套新的API有一些缺點(diǎn)：

最多可以注冊一個(gè)讀和一個(gè)寫偵聽器。
僅在將請求置于異步模式后，API才會(huì)強(qiáng)制注冊它們。
偵聽器接口是全新的，例如，與NIO API沒有任何共同點(diǎn)。
異步API允許更高效的實(shí)現(xiàn)，但是這樣做的方式是錯(cuò)誤的，那就是采用卷積編程模型，而不是提供比線程更有效的執(zhí)行上下文，同時(shí)保持極其有用的“阻塞”抽象。另一方面，異步API可以很容易地轉(zhuǎn)換為高效和富于表現(xiàn)力的光纖阻塞 API 。

“現(xiàn)狀”和前進(jìn)的方向

許多具有實(shí)質(zhì)性結(jié)構(gòu)的組織已經(jīng)在基于servlet的技術(shù)上進(jìn)行了大量投資，改變它們的方向是一項(xiàng)相關(guān)的成本，需要權(quán)衡具體的好處。

他們中的一些人對此感到滿意，并且不受現(xiàn)有缺點(diǎn)的影響。至于其他的可能性，并希望將來會(huì)發(fā)生，將來的servlet規(guī)范將解決這些問題，但是servlet API是一個(gè)龐大而復(fù)雜的規(guī)范。它還需要保持一定程度的向后兼容性，因此發(fā)布規(guī)范審查可能要花費(fèi)一些時(shí)間，更不用說servlet容器正確，有效和可靠地實(shí)現(xiàn)它們了。

當(dāng)然，可以使用諸如Ring之類的servlet替代方案，并且某些組織可以決定轉(zhuǎn)移到不同的API上來為它們付出代價(jià)，以提高生產(chǎn)力并允許構(gòu)建更多可維護(hù)的代碼資產(chǎn)。對于新的實(shí)現(xiàn)，此成本通常可以更低，而不是移植現(xiàn)有的實(shí)現(xiàn)。

如果您的組織中基于servlet的API最明顯的缺點(diǎn)是效率或異步編程模型的缺點(diǎn)，那么Comsat中存在一個(gè)非常可行且成本低廉的替代方案：它將使您仍然可以使用簡單的阻塞抽象和熟悉的抽象Servlet API（以及Web和DB領(lǐng)域中的許多其他流行的和標(biāo)準(zhǔn)的API），但具有光纖提供的效率水平。

翻譯自: https://www.javacodegeeks.com/2015/04/on-servlets-and-async-servlets.html