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

This article mainly introduces "what are the misunderstandings of Java AIO learning". In the daily operation, I believe that many people have doubts about the misunderstandings of Java AIO learning. The editor consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful to answer the questions of "what are the misunderstandings of Java AIO learning?" Next, please follow the editor to study!

Misunderstanding one

Through the comparison of the above table, we can see that the performance-to-price ratio of AIO should be better than that of NIO, but the actual situation is that most people prefer NIO. To be exact, they should prefer the NIO communication framework: Netty. There is nothing wrong with this book, Netty is indeed a very good project, but many people misinterpret the reasons why Netty does not support AIO on Github, which further curbs the development of AIO.

Not faster than NIO (epoll) on unix systems (which is true)

The original meaning of this sentence should be: both NIO and AIO use the epoll pattern on unix systems, and they are essentially the same. But to some extent, Not faster than NIO will mislead people to think that AIO is not as fast as NIO. Here we can use a hypothetical way to prove that this view is not valid.

Suppose:

The performance of epoll is Xero100.

In order to solve the problem of concurrent scheduling and resource allocation, the communication framework will have some performance loss after encapsulating epoll, which is expressed by y.

The final performance result should be r=x-y.

Argument:

A certain NIO framework is based on the performance loss value of epoll encapsulation: yard5, then its final performance is: x-y=95.

If there is an AIO framework that can control the performance loss value to: y = (0pencil 5), then the final performance will be higher than that of the NIO framework. If y > 5, the performance is lower than the NIO framework.

Conclusion:

It is not rigorous to compare the performance of NIO and AIO in terms of whether the underlying model is kqueue, epoll, select or IOCP, and the decision lies in how many basic capabilities can be mined by the framework implementation. Otherwise, the same NIO technology is used, why different frameworks still have high and low levels.

Misunderstanding two

The AIO of Linux system is not mature yet. If this is the reason, you might as well take a look at http://lse.sourceforge.net/io/aio.html, one of the core sentences: Support for kernel AIO has been included in the 2.6 Linux kernel. Note that the Linux kernel has supported AIO mode since version 2.6.

This is a very strange phenomenon, it seems that if you do not support AIO, you will never support it, and the bug that has appeared will exist forever. Just like JAVA NIO's empty rotation training bug, now it has developed to Java 13, and some people still believe that this bug has been there all the time. Frankly speaking, I have not verified whether Java AIO is a real AIO in the Linux environment, nor have I reproduced NIO's empty rotation training bug. But if you give up continuous learning for some reason, your knowledge and knowledge of things can only stay in the past.

So "the AIO of Linux system is not mature" will not be my reason to abandon AIO.

Misunderstanding three

The read cache needs to be pre-allocated for each connection. This is indeed an objective situation. AIO is used by calling the read / write API to register the ByteBuffer object, and when the event is completed, the CompletionHandler is triggered in the form of a callback, so the cache space must be allocated in advance.

But there is one detail that may be overlooked. Even with NIO, when you encounter a half-package / sticky package, you still need a cache object to temporarily store this incomplete data. Especially in high concurrency scenarios, the phenomenon of half-packet / sticky packet is easily aggravated, and the cache allocated by NIO is not much less than that of AIO.

Even assuming that there is no half-packet / sticky packet problem ideally, how much extra memory can be consumed by the pre-allocated form of AIO communication. Allocating 1024 bytes of read cache for each connection can consume less 10MB memory under the condition of 10, 000 concurrent connections. How many concurrency does a Java application server need to support at the same time, 10-50, 000-100000?

At present, known communication frameworks are usually equipped with memory pools, under the premise that AIO only uses the resources in memory pools in advance. With the same memory pool configuration and the same concurrency pressure, if AIO exposes memory problems, we will choose between AIO and NIO.

At this point, the study of "what are the misunderstandings of Java AIO learning" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

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.