I/O Reuse

No diagram, no API analysis

 

Development of Io APIs in Java:
Socket-> socketchannel-> asynchronoussocketchannel
Serversocket-> serversocketchannel-> asynchronousserversocketchannel

Synchronous/blocking-> synchronous/non-blocking (multiplexing)-> asynchronous

 

For a brief chatMultiplexing. Multiplexing must be used togetherReactor ModeThe former solves technical problems, and the latter solves software engineering problems.

The technical problem is to separate the waiting and non-waiting parts in Io operations. I/O operations are divided into two parts:
1. Wait for the data to be ready
2. Process Data

 

As we all know, several Io models (blocking, non-blocking, multiplexing, signal-driven, and asynchronous) are different from these two stages. When many connections need to be processed (high concurrency ), it is easy to think of the use of multithreading technology, such as the simplest one-connection-per-thread mode, because waiting for data is inevitable, the result is that the thread sleep continuously-the wake-up switch causes the CPU to be overwhelmed.

The purpose of Io reuse: separate the two stages to allow a thread (and kernel-level thread) to process all the waits, once a corresponding Io event occurs, the notification continues to complete the IO operation. Although there are still blocking and waiting, the waiting always happens in one thread, in this case, multithreading can ensure that other threads process data once awakened. Of course, this requires the support of non-blocking Io APIs (such as non-blocking sockets ). The Select, poll, and epoll before linux2.6 are all implementations of Io multiplexing technology.SelectAndPollBasically consistent,EpollIs their improved version. But in general, they are not really asynchronous Io, because they are still blocked and synchronized during Io read/write (only after one event can be done ). Asynchronous Io refers to the "processing data" phase which is also non-blocking. Iocp on Windows is the real AIO, and theoretically it is more advanced than epoll in Linux.

For the differences between select, poll, and epoll, we recommend this article: http://www.cnblogs.com/anker/p/3265058.html. To put it simply: select and poll have no brains to perform round-robin. With high concurrency ignored, round-robin itself becomes a bottleneck, while epoll uses callback to implement the connections that really need to be processed during round-robin.

 

The reactor mode is used to make it easier to use Io multiplexing technology. It is a concurrent I/O mode, and other modes include multi-process and multi-thread. Reactor itself also has many variants, such as thread per request, worker thread, thread pool, multiple reactors... there are a lot of information on the Internet. Although there is still debate on the advantages and disadvantages of reactor and multi-thread model optimization on the Internet (one of the most obvious disadvantages of reactor is that it cannot take full advantage of multi-core), most highly concurrent frameworks or components are based on reactor, for example, Mina, netty, redis, and nginx (there are multiple working processes to take full advantage of multi-core advantages ). About Java Io reuse can see Doug Lea great god scalable IO in Java (http://gee.cs.oswego.edu/dl/cpjslides/nio.pdf ).

As for asynchronous I/O in jdk1.7, as long as it is running Linux, it is definitely nothing more than epoll. Can it be said that it is still not actually asynchronous io? I personally think that the concept of Asynchronization is granular and cannot be completely asynchronous. In jdk1.7, AIO is asynchronous for programmers from the programming perspective. We don't have to select the program as we did in Multiplexing. What we need to do is to process the business logic in completion handlers.

Another point: the underlying Io operations in the operating system are asynchronous-io interruptions, But synchronization is more in line with normal thinking and easier to understand.

 

At last, I would like to add that although the second phase of asynchronous Io is non-blocking, there is still room for optimization. In the process of data from kernel copy to user space, netty uses the zero-Copy Technology to optimize this step (http://my.oschina.net/plucury/blog/192577), and MMAP.

 

Thank you!

I/O Reuse