Jetty项目中的Servlet API异常处理优化分析

在Jetty 12.0.16版本的EE9 Servlet API实现中，发现了一个关于异常处理机制的性能问题。这个问题主要出现在请求输入流获取过程中对100 Continue临时响应的处理上。

问题背景

当应用程序调用Request.getInputStream()方法时，Jetty内部会尝试发送一个100 Continue临时响应。然而，如果客户端请求中并未包含Expect: 100-continue头部，系统会生成一个IllegalArgumentException异常。虽然这个异常在代码路径中被捕获并忽略，但在生产环境中使用-XX:-OmitStackTraceInFastThrowJVM参数时，会导致明显的性能下降。

技术细节分析

在HTTP协议中，100 Continue机制允许客户端在发送请求体之前，先确认服务器是否愿意接收请求。客户端通过发送Expect: 100-continue头部来启用这一机制。如果服务器准备好接收请求体，它会先发送100 Continue临时响应。

Jetty 11.x版本中，这一机制的实现方式不会产生异常，但在升级到12.0版本后，新的实现方式导致了性能回归。具体表现为：

1. 对于每个不包含Expect: 100-continue的请求，都会触发异常生成
2. 当禁用JVM的快速异常优化时，每次异常都会生成完整的堆栈跟踪
3. 这种异常生成和捕获的开销在大量请求场景下会显著影响吞吐量

解决方案

Jetty团队通过两个提交解决了这个问题：

1. 首先优化了HttpChannelState.ChannelResponse.writeInterim()方法的实现，避免在不必要时抛出异常
2. 然后进一步改进了100 Continue处理逻辑，使其更加符合HTTP协议规范

这些改进使得Jetty 12.x版本在处理普通请求时恢复了与11.x版本相当的性能水平，同时保持了协议实现的正确性。

最佳实践建议

对于使用Jetty的开发者和运维人员，建议：

1. 评估应用程序中100 Continue机制的实际需求，如果不需要可以明确禁用
2. 在生产环境中谨慎使用-XX:-OmitStackTraceInFastThrow参数，了解其对性能的影响
3. 定期更新Jetty版本以获取性能改进和错误修复

这个案例也提醒我们，在Web服务器实现中，即使是看似无害的异常处理路径，也可能在高并发场景下产生显著的性能影响，需要在设计和实现时给予足够重视。