ApacheTomcat8有一个新的基于NIO2的连接器，该连接器已接近生产状态，现在标记为测试版。NIO2不仅符合Servlet3.1的异步IO，它的好处还不止于此。SpeedFirst，是一个快速的速度测试。本机速度是使用Servlet写入1KB数据来测量的，使用ab-k-c100（启用超过100个并发连接并保持它们处于活动状态）使其仅测量在两个请求连接之前进行快速写入和保持。显然这是一个很糟糕的环境标准，但是这个想法只是看看NIO2是否足够快，因为当你关注它的高级API时，它似乎有点慢。这可能会将NIO2作为一个有用的解决方案从您的脑海中抹去，因为Tomcat中已经有一个稳定的NIO连接器，但在频谱的另一端，APR接近本机速度。我很高兴地报告，在这个纯块/轮询压力测试中，NIO2比NIO快得多，大约快50%，并且与APR在这个任务上持平。有了这个关键问题的结果，我们有了一个比当前连接器更优雅的替代方案，因为NIO和APR的轮询管理，NIO的阻塞IO和APR的本地代码已经证明存在看似无穷无尽的复杂性、思考、崩溃、平台特异性等等其他事宜。然而，虽然已经确定了一些可以使用JSSE和静态文件服务（见下文）解决的初步弱点，但现实世界的好处和资源消耗目前尚不清楚。随着线程和轮询管理的完全抽象化，JVM最终将处理所有事情并提供优化的行为。一个简单的API那么它是一个简单的API吗？实际上，使用NIO2仅完成阻塞IO非常简单。和使用NIO一样，一次读或写都会立即返回结果，但与NIO不同的是，这个操作不必完成，它可以在进程中继续异步存在。为了展示，最基本的读/写API使用Future对象，可以在场边轮询（这是一个坏主意）或阻止。如此简单的阻塞与操作时间表看起来不错。“非阻塞”自从在Servlet3.1中引入后就需要一个更复杂的API，它使用任务完成处理程序来通知操作现已完成。这听起来也很简单，但是有一些特殊的问题需要处理，因为NIO2API并没有提供使处理此类问题更容易的所有内容。调用可以（明显或不）完全内联，同步是不直观的（当操作挂起时没有代码块被同步，但似乎没有定义一些重要的对象，如缓冲区状态；死锁的风险仍然存在），不完整的操作是可能的，等等。API确实优化了一些更重要的IO，使用分散和收集。我尝试在Tomcat中利用后者，将来可以在它上面做更多的工作。为什么NIO2更好NIO2看起来简单、快速和直观，但它内部的一些东西仍然可以改进。NIO2异步通道不支持用于发送文件的支持NIO的transferToAPI，我认为这样做并不明智。因此，尽管NIO2连接器的速度并不慢，而且在大多数情况下速度足够快，但它仍然不是最高效的文件服务器。虽然微不足道，但不幸的是，它的实施成本也相对较低。JSSE集成类似于使用SSL引擎的API，通过NIO提供良好的控制和非阻塞能力。但是都得写类似的异步通道包装器代码。NIO2已经包含了JSSE通道代码。JSSE(none)Speed与OpenSSL相比，JSSE仍然和以前一样慢。虽然现在您已经摆脱了这种痛苦，但JSSE看起来仍然是在浪费服务器资源。然而，这个JVM组件是可插入的，所以我们会看看将来是否会有所改进。更好的状态控制除非使用Future，否则您无法在使用完成处理程序时执行诸如查询操作状态之类的基本操作。pendingflag可以在别处获取，实际上这个flag是一个与future共享的int类型的信号量（可以等待pending操作完成）。***，虽然这看起来很直观且不难，但它会导致不必要的复杂性。所以NIO2还有改进的空间。接下来，期待它的发生！英文原文：NIO2inApacheTomcat8翻译链接：http://www.oschina。净/翻译/nio-2-in-apache-tomcat-8
