如何美化网站,怎么做网站优化,甘肃网站建设的过程,企业网站如何做优化servlet异步Servlet API是Java EE标准的一部分#xff0c;自1998年正式发布2.1规范以来#xff0c;一直是基于Java的企业体系结构的重要组成部分。 它是一种自以为是的API#xff0c;用于服务围绕一些基本概念构建的请求/响应协议#xff1a; 兼容的容器 #xff0c;这是… servlet异步 Servlet API是Java EE标准的一部分自1998年正式发布2.1规范以来一直是基于Java的企业体系结构的重要组成部分。 它是一种自以为是的API用于服务围绕一些基本概念构建的请求/响应协议 兼容的容器 这是专用的运行时它可以是独立服务器过去更常见或基于库的嵌入式运行时如今更常见。 它可以支持一次托管多个Web应用程序并在它们之间隔离类加载。 它还可以提供管理功能例如应用程序部署启动停止资源分配JNDI命名上下文带有连接池的JDBC数据源HTTP适配器线程池等。 基本上它是Java EE功能的集中管理包可以删除兼容的应用程序。 一个或多个servlet 即实现Servlet接口的类它不是特定于HTTP的因为Servlet规范通常是为请求/响应协议设计的。 实现接口意味着处理大多数容器已经处理过的servlet配置信息因此扩展作为规范一部分的抽象类如GenericServlet甚至HttpServlet 更为普遍方便。 除了生命周期管理外其余要实现的方法是请求处理程序 当请求进入时容器将调用该请求处理程序 并应为它们提供服务。 他们将通过处理从容器本身作为参数接收的可变请求和响应对象也包括标准接口或者通过在发生某些意外情况时引发异常来进行此操作容器将根据配置方式对其进行适当的管理例如通过重定向到JSP页面。 它们还可以包括处理并将处理的一部分委托给一个全新的处理链该处理链通过RequestDispatcher映射到一些不同的URL。 这是一种链接servlet的机制主要在2.3引入过滤器之前使用。 一个或多个过滤器 扩展了Filter接口并且与servlet相似不同之处在于它们支持链接 即它们按顺序排列可以将请求处理的一部分委托给链中的下一个过滤器并执行发布-处理完成时。 Servlet始终位于过滤器链的末尾。 设置信息 例如请求和过滤器到HTTP请求的映射可以通过多种方式提供从XML描述符到类注释再到实际的初始化代码。 请求服务线程 每个请求由一个专用线程服务该线程将运行该请求本身已映射到的整个筛选器链并阻塞与HTTP请求和响应相关的网络I / O操作以及任何其他线程完成请求处理所需的-blocking调用。 剖析Servlet API 如果我们试图表征长期存在的Servlet API则可以将其限定为 绝对涉及对象因为涉及的每个概念无论多么抽象都已被对象化并转换为接口或类。 “ Servlet”“ Filter”“ RequestDispatcher”都是这种建模风格的示例。 唯一的例外是容器本身它是幕后的无处不在的参与者但没有唯一的表示形式可以通过显式参与者或诸如上下文之类的次要对象进行间接处理。 它是基于面向对象模式的 我们可以识别其中的许多 模式 。 它具有状态机语义 它是有状态的 并且是可变的因为假设请求处理过程处于某种状态这是所有API的对象化参与者的状态的总和包括容器那么会有一些操作将其转换为一个新的可部分检查的不同状态同时禁止其他过渡例如在提交响应后转发请求。 它是基于处理程序的因为您开发人员在感觉舒适时不会请求传入的请求而是将它们推送到您的servlet中您不得不将它们编码为目标化的请求处理程序。 它是低级的因为它不提供路由机制也没有建立特定的范例例如MVC。 它最初是同步的因为处理程序应该在调用计算上下文堆栈内完成请求处理而根本不打算推迟请求处理。 它明确地基于线程因为规范指出处理程序的计算上下文是servlet容器线程。 同步和基于线程的结合在一起基本上意味着Servlet API最初被设计为线程阻塞的 。 总而言之它是一个非常复杂且自以为是的API尽管它基于非常普遍的观点并且具有很长的向后兼容历史。 顺便说一句Clojure的戒指HTTP服务器的全新明晰和简约视图 尽管Clojure社区非常多元化并且在每个领域都有很多非常有趣的选择但Web的“事实上”的Clojure低级基本标准框架是Ring 。 鉴于HTTP几乎是一个无状态的请求-响应协议HTTP请求服务自然是一个非常适合于功能性输入-输出建模风格的领域。 实际上Ring认为HTTP请求总共具有3个具有直接关系的功能实体 处理程序是一个函数其功能是接收一个具有众所周知的键名和值类型的Clojure映射作为唯一输入表示HTTP请求并生成另一个必须具有特定结构的Clojure映射作为其输出表示HTTP响应这是但是过度简化因为Ring允许返回更简单的数据结构以方便使用。 中间件是一个接收处理程序功能并生成另一个处理程序功能的功能。 因此中间件是一种高阶函数旨在以某种特定方式丰富任何处理程序的逻辑例如拦截和处理文件系统请求或使用多部分预处理信息来丰富请求本身因此类似于Servlet过滤器尽管通过一流的函数之类的函数式编程思想使其变得更加简单。 请注意可以通过功能组合的直接方式将中间件按特定顺序链接 因为将中间件应用于处理程序所获得的是另一个处理程序然后可以将多个中间件功能应用于该处理程序。 适配器是一个接收处理程序函数且不返回任何内容的函数作为其主要输入。 它的目的纯粹是产生一些HTTP服务器的副作用该HTTP服务器将使用提供的处理程序来处理请求因此实际上是某些先前存在的或新的HTTP服务器技术的适配器。 它的功能接口不是标准的因为它可以接收的输入在很大程度上取决于技术但是一种常见的模式是许多适配器将处理程序作为第一个参数来接收然后将与实现相关的选项映射或其他序列作为第一个参数。第二个。 此外最常用的选项例如侦听接口和端口在大多数适配器中往往具有相同的键名。 Ring也是一种自以为是的API并且在某些方面它并不偏离流行的概念例如它仍然是基于处理程序的尽管适配器只是功能的想法使得将其用作嵌入式HTTP非常简单。其他完全传统的应用程序的边界” 加上它是同步的 这非常好因为它使代码简单易维护。 仍然需要对主题保持新鲜清晰和简约的观点尝试完全消除偶发的复杂性并提供最少数量的正交概念以利用功能编程思想和动态语言灵活性来简洁有效地处理领域的内在复杂性为了这个 这种方法非常符合Clojure语言本身的精神。 请注意Ring并没有提及执行上下文对于某些人来说基于轻量级光纤而不是重量级线程来为其阻塞API实现适配器是完全可以的这正是Comsat提供的Ring的清晰性和简约性极大地简化了此类编写整合。 Servlet 3.0异步 Servlet规范的Async附加示例说明了以下事实OOP不一定简化有状态API的复杂性。 有时相反它只能通过在表中散布状态将其拆分并放入对象中来提供这样做的危险幻觉。 这种错觉实际上会使情况恶化因为它使我们认为开发有状态API的看似非常简单的想法确实可以正常工作而不会产生意想不到的后果。 Servlet 3.0中 Async功能背后的“简单”思想是一种新的请求模式即异步请求模式 。 当通过startAsync方法调用将请求切换为异步时我们“简单地”告诉容器只要请求处理链过滤器和servlet返回并且其关联的容器线程完成我们就根本不意味着请求处理已经完成因此不应将响应发送回HTTP客户端。 相反应将其保留直到其他执行上下文发出确实已完成请求处理的信号为止并且它将通过对startAsync调用返回的AsyncContext对象的complete或dispatch方法调用来complete 。 不用说异步模式与先前存在的Servlet API的有状态移动部分可能存在几种交互作用接下来我们将对其中的一些进行交互。 异步模式下的错误处理 AsyncContext提供了注册有关请求处理进度和异常情况的侦听器的功能但是我们将在容器线程之外运行自管理执行上下文因此容器无法为我们捕获和处理异常。 相反 AsyncContext确实提供了一种新的处理委托形式它将控制权转移回容器管理的线程这就是dispatch方法的目的。 通过在请求属性中设置错误条件和任何其他相关信息之后使用它并检查请求的调度程序类型我们可以验证我们确实在处理源自异步处理流的异常条件然后选择重新引发异常这一次可以依靠容器的管理能力。 这种方法有点复杂并且基本上需要使用经过改进的前向/调度功能实际上事实上这些功能以前已被过滤器弃用。 但是它可以工作并且能够模仿在同步设置中发生的错误处理流程。 衡量它的效率当然很有趣。 Servlet API也一直提供sendError功能但到目前为止 尚不清楚它是否以及如何以异步模式工作即使在大多数流行的servlet容器如Jetty和Tomcat中这种情况也很容易导致开放问题 。 在异步模式下过滤 Servlet 3.0规范明确禁止在与容器线程不同的执行上下文中运行过滤器链接。 此限制意味着在请求处理链末尾的唯一处理程序即Servlet可以将请求置于异步模式而预处理过滤器逻辑只能在容器的线程中执行。 这是非常不幸的因为自从引入过滤器以来许多流行的框架和应用程序开发人员就使用它们来执行大量的请求处理而这些请求处理可以受益于在单独的执行上下文例如光纤中运行而不会阻塞昂贵的容器线程。 实际上在流行的servlet容器中有一些关于此限制的未解决问题 。 Servlet 3.1异步HTTP I / O Servlet 3.0能够从请求处理完成中分离容器的线程和Servlet的处理代码但是用于读取请求和写入响应的I / O仍然是线程阻塞的。 Servlet 3.1通过setReadListener和setWriteListener方法向请求添加了异步I / O功能 如果它们已经处于异步模式。 关于这套新的API有一些缺点 最多可以注册一个读和一个写侦听器。 仅在将请求置于异步模式后 API才会强制注册它们。 侦听器接口是全新的例如与NIO API没有任何共同点。 异步API允许更高效的实现但是这样做的方式是错误的 那就是采用卷积编程模型而不是提供比线程更有效的执行上下文同时保持极其有用的“阻塞”抽象。 另一方面 异步API可以很容易地转换为高效和富于表现力的光纤阻塞 API 。 “现状”和前进的方向 许多具有实质性结构的组织已经在基于servlet的技术上进行了大量投资改变它们的方向是一项相关的成本需要权衡具体的好处。 他们中的一些人对此感到满意并且不受现有缺点的影响。 至于其他的可能性并希望将来会发生将来的servlet规范将解决这些问题但是servlet API是一个庞大而复杂的规范。 它还需要保持一定程度的向后兼容性因此发布规范审查可能要花费一些时间更不用说servlet容器正确有效和可靠地实现它们了。 当然可以使用诸如Ring之类的servlet替代方案并且某些组织可以决定转移到不同的API上来为它们付出代价以提高生产力并允许构建更多可维护的代码资产。 对于新的实现此成本通常可以更低而不是移植现有的实现。 如果您的组织中基于servlet的API最明显的缺点是效率或异步编程模型的缺点那么Comsat中存在一个非常可行且成本低廉的替代方案它将使您仍然可以使用简单的阻塞抽象和熟悉的抽象Servlet API以及Web和DB领域中的许多其他流行的和标准的API但具有光纤提供的效率水平。 翻译自: https://www.javacodegeeks.com/2015/04/on-servlets-and-async-servlets.htmlservlet异步
