Shulou(Shulou.com)06/02 Report--

This article introduces you how to understand NIO2 in Apache Tomcat 8, the content is very detailed, interested friends can refer to, hope to be helpful to you.

Apache Tomcat 8 has a new NIO 2-based connector that is close to normal use and is now marked as a beta. NIO 2 not only to Servlet 3. 1's asynchronous IO is the same, and it has more than that benefit.

Speed

First of all, it is a fast speed test. The native speed is measured by a Servlet writing 1KB data, using ab-k-c 100 (enabling more than 100 concurrent connections and keeping them alive) to measure only one fast write and stay connected before two requests. Obviously this is a scary environmental standard, but the idea is just to see if NIO 2 is fast enough, because it looks a little slow when you notice its advanced API. This may eliminate the presence of NIO 2 as a useful solution in your mind, because there is already a stable NIO connector in Tomcat, but at the other end of the optional range, APR is close to native speed. I am pleased to report that NIO 2 is significantly faster than NIO in this pure block / polling stress test, about 50% faster, and equivalent to the speed at which APR does this task.

With the results of this critical issue, we have a more elegant choice than the current connectors, because the polling management of NIO and APR, the blocking IO of NIO and the native code of APR have been proved to have seemingly endless complexity, thinking, collapse, platform-specific, and so on.

However, although some initial weaknesses have been identified to be addressed using JSSE and static file services (see below), its real-world benefits and resource consumption are unknown. As threading and polling management are completely abstracted, JVM will eventually take control of everything and provide optimized behavior.

A simple API

So is it a simple API? In fact, it is very easy to block IO using NIO 2 to do so. As with NIO, a read or write returns the result immediately, but unlike NIO, which does not need to be complete, it can continue to exist asynchronously with the process. In order to display, the most basic read / write API uses a Future object that can be polled on the side (which is a bad idea) or blocked. Therefore, a simple blocking with an operational time limit looks good.

"non-blocking" due to Servlet 3. 1 was introduced, requiring the use of a more complex task completion handler to notify the API that the operation is now complete. That also sounds simple, but there are special problems to deal with, because NIO 2 API doesn't provide everything that makes it easier to deal with that kind of problem. A call can be completely (obviously or not) completely inline, synchronization is not intuitive (when an operation is suspended, no code block will be synchronized, but it seems that the state of some important objects such as buffer is not defined; the risk of deadlock still exists), incomplete operations are possible, and so on.

API does optimize some of the more important IO, using decentralization and centralization. I try to take advantage of the latter in Tomcat so that I can do more work on it in the future.

Why is NIO 2 better?

NIO 2 looks simple, fast, and intuitive, but something inside it still needs to be improved.

Support for sending files

NIO's transferTo API is not supported by the NIO 2 asynchronous channel, and I don't think that's wise. Therefore, although the original speed of the NIO 2 connector is not slow, and in most cases it is fast enough, it is still not an efficient file server. Although it doesn't matter, it's a misfortune because it doesn't take much trouble to achieve.

JSSE integration

Similar to API using the SSL engine, NIO provides good control and non-blocking capabilities. But everyone has to write similar asynchronous channel encapsulation code. The JSSE channel code has been included in NIO 2.

JSSE (none) speed

Compared with OpenSSL, JSSE is still as slow as before. Although so far you are immune to this grief, JSSE still seems to be wasting server resources. However, this JVM component is pluggable, so we'll see if it can be improved in the future.

Better state control

You can't do basic things like querying the status of an operation when using completion handler, unless you use Future. The pending identity can be obtained elsewhere, and it is actually an int type semaphore shared with future (which can wait for the pending operation to complete). While this may seem intuitive and not difficult, it can lead to more complexity than needed.

On how to understand the NIO2 in Apache Tomcat 8 to share here, I hope that the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.