Servlet 3.1规范（最终版）：Java EE 7标准解析

需积分: 13 172 浏览量更新于2024-07-19 收藏 1.74MB PDF 举报

Java Servlet规范3.1（JSR340）作为Java EE 7平台的一部分，标志着一个重要的里程碑。相较于之前的Servlet 3.0（JSR315）嵌入在Java EE 6中，这个新版本提供了更为全面和清晰的API标准。以下是关于Servlet3.1的关键知识点： 1. 核心内容：Servlet3.1规范详细定义了Java Servlet API的行为和功能，旨在为Web服务器和应用服务器供应商提供开发符合标准的servlet引擎的蓝图，同时对于工具供应商来说，它也是一个开发支持工具的基础。对于经验丰富的Servlet开发者，它揭示了底层机制，帮助他们理解技术原理，但请注意，这不是用户指南，而是为技术专家设计的。 2. 参考实现：规范中提到的参考实现（Reference Implementation, RI）是一个已完成的、行为基准的实现，供其他开发者参考，作为实现规范的具体模型。这有助于确保所有实现的一致性和互操作性。 3. 兼容性测试套件：Java Servlet API的兼容性测试套件（Compatibility Test Suite, CTS）用于评估实现是否符合标准要求。它是验证实现是否与官方规范一致的重要工具，为评估是否为标准实现提供了标准化的依据。 4. 咨询资源：遇到问题时，开发者可以向Java Community Process（JCP）下的Servlet API工作组寻求帮助，他们是解答技术难题的权威机构。同时，鼓励用户提供反馈和建议，以促进未来规范的改进。 5. 目标读者：该规范的主要受众包括Web服务器和应用服务器开发者、工具开发者以及深入理解Servlet技术的高级开发者。对于初学者或寻求用户指南的开发者，建议查阅官方提供的相关资源链接，如<http://java.sun.com/products/servlet>。 6. API规范概览：Servlet3.1规范的重点在于增强安全性、简化编程模型、支持异步处理和WebSocket连接等，这些都是相对于Servlet 3.0的重要改进。了解这些变化有助于开发人员更好地利用最新技术构建高效、安全的Web应用程序。 Servlet3.1规范不仅提升了Java Servlet技术的性能和功能，也为整个Java EE生态系统带来了更好的标准化和一致性。遵循这一规范，开发人员可以编写出更高效、可维护的代码，并确保其在不同环境中的互操作性。

2.1.3 有条件 GET 支持

HttpServlet 定义了用于支持有条件 GET 操作的 getLastModified 方法。所谓的有条件 GET 操作是指客户端

通过 GET 请求获取资源时，当资源自第一次获取那个时间点发生更改后才再次发生数据，否则将使用客户

端缓存的数据。在一些适当的场合，实现此方法可以更有效的利用网络资源，减少不必要的数据发送。

2.2 实例数量

通过注解描述的（第 8 章注解和可插拔性）或者在 Web 应用程序的部署描述符（第 14 章部署描述符）

中描述的 servlet 声明，控制着 servlet 容器如何提供 servlet 实例。

对于未托管在分布式环境中（默认）的 servlet 而言，servlet 容器对于每一个 Servlet 声明必须且只能产生一

个实例。不过，如果 Servlet 实现了 SingleThreadModel 接口，servlet 容器可以选择实例化多个实例以便处

理高负荷请求或者串行化请求到一个特定实例。

如果 servlet 以分布式方式进行部署，容器可以为每个虚拟机（JVM）的每个 Servlet 声明产生一个实例。但

是，如果在分布式环境中 servlet 实现了 SingleThreadModel 接口，此时容器可以为每个容器的 JVM 实例化

多个 Servlet 实例。

2.2.1 关于 Single Thread Model

SingleThreadModel 接口的作用是保证一个特定 servlet 实例的 service 方法在一个时刻仅能被一个线程执行，

一定要注意，此保证仅适用于每一个 servlet 实例，因此容器可以选择池化这些对象。有些对象可以在同一

时刻被多个 servlet 实例访问，如 HttpSession 实例，可以在一个特定的时间对多个 Servlet 可用，包括那些

实现了 SingleThreadModel 接口的 Servlet。

2.3 Servlet 生命周期

Servlet 是按照一个严格定义的生命周期被管理，该生命周期规定了 Servlet 如何被加载、实例化、初始化、

处理客户端请求，以及何时结束服务。该声明周期可以通过 javax.servlet.Servlet 接口中的 init、service 和

destroy 这些 API 来表示，所有 Servlet 必须直接或间接的实现 GenericServlet 或 HttpServlet 抽象类。

2.3.1 加载和实例化

Servlet 容器负责加载和实例化 Servlet。加载和实例化可以发生在容器启动时，或者延迟初始化直到容器决

定有请求需要处理时。当 Servlet 引擎启动后，servlet 容器必须定位所需要的 Servlet 类。Servlet 容器使用

普通的 Java 类加载设施加载 Servlet 类。可以从本地文件系统或远程文件系统或者其他网络服务加载。加载

完 Servlet 类后，容器就可以实例化它并使用了。

2.3.2 初始化

一旦一个 Servlet 对象实例化完毕，容器接下来必须在处理客户端请求之前初始化该 Servlet 实例。初始化

的目的是以便 Servlet 能读取持久化配置数据，初始化一些代价高的资源（比如 JDBC API 连接），或者执

行一些一次性的动作。容器通过调用 Servlet 实例的 init 方法完成初始化，init 方法定义在 Servlet 接口中，

并且提供一个唯一的 ServletConfig 接口实现的对象作为参数，该对象每个 Servlet 实例一个。

配置对象允许 Servlet 访问由 Web 应用配置信息提供的键-值对的初始化参数。该配置对象也提供给 Servlet

去访问一个 ServletContext 对象，ServletContext 描述了 Servlet 的运行时环境。请参考第 4 章，“Servlet Context”

获取 ServletContext 接口的更多信息。

2.3.2.1 初始化时的错误条件

在初始化阶段，servlet 实现可能抛出 UnavailableException 或 ServletException 异常。在这种情况下，Servlet

不能放置到活动服务中，而且 Servlet 容器必须释放它。如果初始化没有成功，destroy 方法不应该被调用。

在实例初始化失败后容器可能再实例化和初始化一个新的实例。此规则的例外是，当抛出的

UnavailableException 表示一个不可用的最小时间，容器在创建和初始化一个新的 servlet 实例之前必须等待

一段时间。

2.3.2.2 使用工具时的注意事项

当一个工具加载并内省某个 Web 应用程序时触发的静态初始化，这种用法与调用 init 初始化方法是有区别

的。在 Servlet 的 init 方法没被调用，开发人员不应该假定其处于活动的容器环境内。比如，当某个 Servlet

仅有静态方法被调用时，不应该与数据库或企业级 JavaBean（EJB）容器建立连接。

2.3.3 请求处理

Servlet 完成初始化后，Servlet 容器就可以使用它处理客户端请求了。客户端请求由 ServletRequest 类型的

request 对象表示。Servlet 封装响应并返回给请求的客户端，该响应由 ServletResponse 类型的 response 对象

表示。这两个对象（request 和 response）是由容器通过参数传递到 Servlet 接口的 service 方法的。

在 HTTP 请求的场景下，容器提供的请求和响应对象具体类型分别是 HttpServletRequest 和

HttpServletResponse。

需要注意的是，由 Servlet 容器初始化的某个 Servlet 实例在服务期间，可以在其生命周期中不处理任何请

求。

2.3.3.1 多线程问题

Servlet 容器可以并发的发送多个请求到 Servlet 的 service 方法。为了处理这些请求，Servlet 开发者必须为

service 方法的多线程并发处理做好充足的准备。一个替代的方案是开发人员实现 SingleThreadModel 接口，

由容器保证一个 service 方法在同一个时间点仅被一个请求线程调用，但是此方案是不推荐的。Servlet 容器

可以通过串行化访问 Servlet 的请求，或者维护一个 Servlet 实例池完成该需求。如果 Web 应用中的 Servlet

被标注为分布式的，容器应该为每一个分布式应用程序的 JVM 维护一个 Servlet 实例池。

对于那些没有实现 SingleThreadModel 接口的 Servlet，但是它的 service 方法（或者是那些 HttpServlet 中通

过 service 方法分派的 doGet、doPost 等分派方法）是通过 synchronized 关键词定义的，Servlet 容器不能使

用实例池方案，并且只能使用序列化请求进行处理。强烈推荐开发人员不要去通过 service 方法（或者那些

由 Service 分派的方法），因为这将严重影响性能。

2.3

.3.2 请求处理时的异常

Servlet 在处理一个请求时可能抛出 ServletException 或 UnavailableException 异常。ServletException 表示在

处理请求时出现了一些错误，容器应该采取适当的措施清理掉这个请求。

UnavailableException 表示 servlet 目前无法处理请求，或者临时性的或者永久性的。

如果 UnavailableException 表示的是一个永久性的不可用，Servlet 容器必须从服务中移除这个 Servlet，调用

它的 destroy 方法，并释放 Servlet 实例。所有被容器拒绝的请求，都会返回一个 SC_NOT_FOUND (404) 响

应。

如果 UnavailableException 表示的是一个临时性的不可用，容器可以选择在临时不可用的这段时间内路由任

何请求到 Servlet。所以在这段时间内被容器拒绝的请求，都会返回一个 SC_SERVICE_UNAVAILABLE (503)

响应状态码，且同时会返回一个 Retry-After 头指示此 Servlet 什么时候可用。容器可以选择忽略永久性和临

时性不可用的区别，并把 UnavailableExceptions 视为永久性的，从而 Servlet 抛出 UnavailableException 后需

要把它从服务中移除。

2.3.3.3 异步处理

有时候，Filter 及/或 Servlet 在生成响应之前必须等待一些资源或事件以便完成请求处理。比如，Servlet 在

进行生成一个响应之前可能等待一个可用的 JDBC 连接，或者一个远程 web 服务的响应，或者一个 JMS 消

息，或者一个应用程序事件。在 Servlet 中等待是一个低效的操作，因为这是阻塞操作，从而白白占用一个

线程或其他一些受限资源。许多线程为了等待一个缓慢的资源比如数据库经常发生阻塞，可能引起线程饥

饿，且降低整个 Web 容器的服务质量。当

Servlet 3.0 引入了异步处理请求的能力，使线程可以返回到容器，从而执行更多的任务。当开始异步处理请

求时，另一个线程或回调可以或者产生响应，或者调用完成（complete）或请求分派（dispatch），这样，它

可以在容器上下文使用 AsyncContext.dispatch 方法运行。一个典型的异步处理事件顺序是：

1. 请求被接收到，通过一系列如用于验证的等标准的 filter 之后被传递到 Servlet。

2. servlet 处理请求参数及（或）内容体从而确定请求的类型。

3. 该 servlet 发出请求去获取一些资源或数据，例如，发送一个远程 web 服务请求或加入一个等待 JDBC 连

接的队列。

4. servlet 不产生响应并返回。

5. 过了一段时间后，所请求的资源变为可用，此时处理线程继续处理事件，要么在同一个线程，要么通过

AsyncContext 分派到容器中的一个资源上。

Java 企业版的功能，如第 15.2.2 节，在第 15-1

78 页的“Web 应用环境”和第 15.3.1 节，在第 15-180

页的“EJB 调用的安全标识传播”，仅提初始化请求的线程执行，或者请求经过 AsyncContext.dispatch

方法被分派到容器。Java 企业版的功能可能支持由 AsyncContext.start(Runnable)方法使用其他线程直

接操作响应对象。

第八章描述的@WebServlet 和@WebFilter 注解有一个属性——asyncSupported，boolean 类型默认值

为 false。当 asyncSupported 设置为 true，应用通过执行 startAsync（见下文）可以启动一个单独的线

程中进行异步处理，并把请求和响应的引用传递给这个线程，然后退出原始线程所在的容器。这意

味着响应将遍历（相反的顺序）与进入时相同的过滤器（或过滤器链）。直到 AsyncContext 调用

complete（见下文）时响应才会被提交。如果异步任务在容器启动的分派之前执行，且调用了 startAsync

并返回给容器，此时应用需负责处理请求和响应对象的并发访问。

从一个 Servlet 分派时，把 asyncSupported=true 设置为 false 是允许的。这种情况下，当 servlet 的 service

方法不支持异步退出时，响应将被提交，且容器负责调用 AsyncContext 的 complete，以便所有感兴

趣的 AsyncListener 得到触发知。过滤器作为清理要完成的异步任务持有的资源的一种机制，也应该

使用 AsyncListener. onComplete 触发的结果。

从一个同步 Servlet 分派到另一个异步 Servlet 是非法的。不过与该点不同的是当应用调用 startAsync

时将抛出 IllegalStateException。这将允许 servlet 只能作为同步的或异步的 Servlet。

应用在一个与初始请求所用的不同的线程中等待异步任务直到可以直接写响应，这个线程不知道任

何过滤器。如果过滤器想处理新线程中的响应，那就必须在处理进入时的初始请求时包装 response，

并且把包装的 response 传递给链中的下一个过滤器，并最终交给 Servlet。因此，如果响应是包装的

（可能被包装多次，每一个过滤器一次），并且应用处理请求并直接写响应，这将只写响应的包装对

象，即任何输出的响应都会由响应的包装对象处理。当应用在一个单独的线程中读请求时，写内容

到响应的包装对象，这其实是从请求的包装对象读取，并写到响应的包装对象，因此对包装对象操

作的所有输入及（或）输出将继续存在。

如果应用选择这样做的话，它将可以使用 AsyncContext 从一个新线程发起到容器资源的分派请求。这将允

许在容器范围内使用像 JSP 这种内容生成技术。

除了注解属性外，我们还添加了如下方法/类：

■ ServletRequest

■ public AsyncContext startAsync(ServletRequest req, ServletResponse res)。这个方法的作用是将请求转换

为异步模式，并使用给定的请求及响应对象和 getAsyncTimeout 返回的超时时间初始化它的

AsyncContext。ServletRequest 和 ServletResponse 参数必须是与传递给 servlet 的 service 或 filter 的 doFilter

方法相同的对象，或者是 ServletRequestWrapper 和 ServletResponseWrapper 子类的包装对象。当应用退

出 service 方法时，调用该方法必须确保 response 没有被提交。当调用返回的 AsyncContext 的

AsyncContext.complete 或 AsyncContext 超时并且没有监听器处理超时时，它将被提交。异步超时定时

器直到请求和它关联的响应从容器返回时才启动。AsyncContext 可以被异步线程用来写响应，它也能

用来通知没有关闭和提交的响应。

如果请求在不支持异步操作的 servlet 或 filter 范围中调用 startAsync，或者响应已经被提交或关闭，或

者在同一个分派期间重复调用，这些是非法的。从调用 startAsync 返回的 AsyncContext 可以接着被用

来进行进一步的异步处理。调用返回的 AsyncContext 的 hasOriginalRequestResponse()方法将返回 false，

除非传过去的 ServletRequest 和 ServletResponse 参数是最原始的那个或不是应用提供的包装器。

在请求设置为异步模式后，在入站调用期间添加的一些请求及（或）响应的包装器可能需要在异步操

作期间一直保持，并且它们关联的资源可能也不会释放，出站方向调用的所有过滤器可以以此作为一

个标志。

一个在入站调用期间的过滤器应用的 ServletRequestWrapper 可以被出站调用的过滤器释放，只有当给

定的 ServletRequest 是由 AsyncContext 初始化的且通过调用 AsyncContext.getRequest()返回的，不包括

之前说的 ServletRequestWrapper。这规则同样适用于 ServletResponseWrapper 实例。

■ public AsyncContext startAsync() 是一个简便方法，使用原始请求和响应对象用于异步处理。请注意，

如果它们在你想调用此方法之前被包装了，这个方法的使用者应该刷出（flush）响应，确保数据写到

被包装的响应中没有丢失。

■ public AsyncContext getAsyncContext() – 返回由 startAsync 调用创建的或初始化的 AsyncContext。如

果请求已经被设置为异步模式，调用 getAsyncContext 是非法的。

■ public boolean isAsyncSupported() – 如果请求支持异常处理则返回 true，否则返回 false。一旦请求传

给了过滤器或 servlet 不支持异步处理（通过指定的注解或声明），异步支持将被禁用。

■ public boolean isAsyncStarted() – 如果请求的异步处理已经开始将返回 true，否则返回 false。如果这

个请求自从被设置为异步模式后已经使用任意一个 AsyncContext.dispatch 方法分派，或者成功调用了

AsynContext.complete 方法，这个方法将返回 false。

■ public DispatcherType getDispatcherType() – 返回请求的分派器（dispatcher）类型。容器使用请求的

分派器类型来选择需要应用到请求的过滤器。只有匹配分派器类型和 url 模式（url pattern）的过滤器

才会被应用。允许一个过滤器配置多个分派器类型，过滤器可以根据请求的不同分派器类型处理请求。

请求的初始分派器类型定义为 DispatcherType.REQUEST 。使用

RequestDispatcher.forward(ServletRequest, ServletResponse) 或 RequestDispatcher.include(ServletRequest,

ServletResponse) 分派时，它们的请求的分派器类型分别是 DispatcherType.FORWARD 或

DispatcherType.INCLUDE ，当一个异步请求使用任意一个 AsyncContext.dispatch 方法分派时该请求的

分派器类型是 DispatcherType.ASYNC。最后，由容器的错误处理机制分派到错误页面的分派器类型是

DispatcherType.ERROR 。

■ AsyncContext – 该类表示在 ServletRequest 启动的异步操作执行上下文，AsyncContext 由之前描述的

ServletRequest.startAsync 创建并初始化。AsyncContext 的方法：

■ public ServletRequest getRequest() – 返回调用 startAsync 用于初始化 AsyncContext 的请求对象。当在

异步周期之前调用了 complete 或任意一个 dispatch 方法，调用 getRequest 将抛出 IllegalStateException。

■ public ServletResponse getResponse() –返回调用 startAsync 用于初始化 AsyncContext 的响应对象。当

在异步周期之前调用了 complete 或任意一个 dispatch 方法，调用 getResponse 将抛出

IllegalStateException。

■ public void setTimeout(long timeoutMilliseconds) – 设置异步处理的超时时间，以毫秒为单位。该方法

调用将覆盖容器设置的超时时间。如果没有调用 setTimeout 设置超时时间，将使用容器默认的超时时

间。一个小于等于 0 的数表示异步操作将永不超时。当调用任意一个 ServletRequest.startAsync 方法时，

一旦容器启动的分派返回到容器，超时时间将应用到 AsyncContext。当在异步周期开始时容器启动的

剩余160页未读，继续阅读

只为追寻

粉丝: 0
资源: 3

Servlet 3.1规范（最终版）：Java EE 7标准解析

servlet3.1

servlet 3.0 jar 包综合下载

Servlet3.1规范（最终版）.中文

servlet3.1api 文档

怎么查看servlet的版本与idea的版本对应

eclipse如何web应用升级到支持Servlet 3.0规范的版本

如何web应用升级到支持Servlet 3.0规范的版本。

idea如何创建servlet

tomcat中的servlet版本是多少

servlet-api 版本

最新资源