Java NIO Learning

I. Understanding of UNIX Network Programming 5 I/O models 1.1, blocking I/O models

Blocking I/O (blocking I/O) model, the process calls Recvfrom, whose system calls are not returned until the datagram arrives and is copied into the buffer of the application process or an error occurs. The process is blocked from the start of the call to Recvfrom to the entire period of time it returns.

1.2. Non-blocking I/O model

When an application process calls Recvfrom on a non-blocking descriptor loop like this, we call polling (polling). The application process continuously polls the kernel to see if an operation is ready.

1.3. I/O multiplexing (event-driven) model

1.4. Signal-driven I/O (SIGIO)

1.5. Asynchronous I/O model

1.6. Comparison of I/O models:

Based on the 5 IO models above, the first 4 models-blocking IO, nonblocking io, io multiplexing, and signal-driven IO-are all synchronous I/O models because the true I/O operation (recvfrom) blocks the process and is blocked when the kernel data is copied to the user space.

1.7. Synchronous IO, asynchronous io, blocking IO, non-blocking IO

An IO operation can be divided into two steps: initiating an IO request and the actual IO operation
For example:
1. One write operation of the operating system is divided into two steps: copying data from user space to system space, and writing to Nic from System space.
2, one read operation is divided into two steps: copying data from the network card to the system space, copying the data from the system space to the user space.

The difference between blocking IO and non-blocking IO is that the first step is whether the initiating IO request will be blocked, and if blocking until done is the traditional blocking IO, and if it does not block, then it is non-blocking IO.

The difference between synchronous IO and asynchronous IO is whether the second step is blocked, if the actual IO read-write blocking request process, then is synchronous io, so blocking IO, non-blocking IO, IO multiplexing, signal-driven IO is synchronous io, if not blocked, but the operating system completes the IO two stages of operation and return the results , then it is asynchronous IO.

1.8. IO multiplexing

IO multiplexing is a mechanism by which a process can monitor multiple descriptors and, once a descriptor is ready (usually read-ready or ready to write), notifies the program to read and write accordingly.

From a process point of view, there is not much difference between IO requests and synchronous blocking models using the Select function, and even more than adding a monitor socket and calling the Select function for extra operations. However, the biggest advantage after using select is that the user can process multiple socket IO requests simultaneously in a single line range. The user can register multiple sockets, and then constantly call Select to read the activated socket, to achieve the same line range simultaneous processing of multiple IO requests. In the synchronous blocking model, it is necessary to achieve this goal through multithreading.

IO multiplexing allows multiple IO requests to be processed in a single thread, but the process of each IO request is still blocked (blocking on the Select function), and the average time is even longer than the synchronous blocking IO model. If the user thread registers only the socket or IO request that it is interested in, and then does its own thing and waits until the data arrives, it can increase the CPU utilization.
Because the Select function is blocked, the multiplexed IO model is also known as the asynchronous blocking IO model. Note that the blocking mentioned here refers to the thread being blocked when the Select function executes, not the socket. In general, when using the IO multiplexing model, the socket is set to Nonblock, but this does not have an impact, because when a user initiates an IO request, the data has arrived and the user thread must not be blocked.
IO multiplexing is the most commonly used IO model, but it is not asynchronous enough to be "thorough" because it uses a select system call that blocks threads. So IO multiplexing can only be called asynchronous blocking Io, not true asynchronous IO.

Shows how non-blocking IO allows you to handle multiple connections using a selector zone.

1.9. Select, poll, Epoll

Linux supports IO multiplexing system calls with Select, poll, Epoll, which are kernel-level. But select, poll, and Epoll are essentially synchronous I/O, first block a waiting socket, and block to copy data from the kernel to the user's memory.

The differences between select, poll, and Epoll, such as the following table:

1.10. Two I/O multiplexing modes: Reactor and Proactor

In both modes the event multiplexer feedback to the program information is not the same:
The 1.Reactor mode shows that you can read and write (send and receive) operations.
The 2.Proactor mode indicates that the read-write (send and receive) operation has been completed, and the content can be manipulated in a given buffer.
Reactor is concerned with ready events for I/O operations, while Proactor is concerned with completion events for I/O operations

Generally, the I/O multiplexing mechanism relies on an event demultiplexer. The Separator object separates the I/O events from the event source and distributes them to the corresponding Read/write event handler (the event Handler).

The reactor mode uses synchronous IO, while the proactor uses asynchronous IO.

In reactor, the event splitter is responsible for waiting for the file descriptor or socket to be ready for read and write operations, then passing the ready event to the corresponding processor, and finally the processor is responsible for completing the actual read and write work.

In Proactor mode, the processor or event splitter, which is the processor, is only responsible for initiating asynchronous read and write operations. The IO operation itself is done by the operating system. The parameters passed to the operating system need to include the user-defined data buffer address and data size, from which the operating system can get the data it needs to write the operation, or write the data read from the socket. The event splitter captures the IO operation completion event and then passes the event to the corresponding processor. For example, on Windows, the processor initiates an asynchronous IO operation, and the event splitter waits for the IoCompletion event. Typical asynchronous Pattern implementations are built on the operating system's support for asynchronous APIs, which we call "system-level" asynchronous or "true" asynchrony because the application relies entirely on the operating system to perform real IO work.

The main difference between the reactor and Proactor modes is that the real read and write operations are done by someone, and the reactor requires the application to read or write the data itself, whereas in Proactor mode, the application does not need to perform the actual read/write process. It only needs to read or write from the buffer, and the operating system reads the buffer or writes the buffer to the real IO device.

Second, Java NIO

NIO, some call it new I/O because it is new in relation to the previous I/O class library, so it is called New I/O. However, since the old I/O class Library was the target of blocking the i/o,new I/O class library for Java to support nonblocking I/O, more people prefer to call non-blocking I/O (non-block I/O).

2.1. Non-blocking understanding of NIO

Note that the select is blocked, whether through the operating system notification (Epoll) or nonstop polling (select,poll), the function is blocked. So you can safely call this function in a while (true) without worrying about CPU idling.

NIO uses reactor mode, a reactor thread aggregates a multiplexer selector, which can register, listen, and poll hundreds of channel simultaneously, an IO thread can concurrently handle N client connections simultaneously, and the threading model is optimized to 1:N (N < The maximum number of handles available to the process) or m:n (M is typically the maximum number of handlers available for CPU cores + 1, N < processes).

Java NIO is not synchronous non-blocking I/O, why does Java NiO provide selector-based asynchronous network I/O?
The IO model of Java NIO is synchronous non-blocking, where synchronous asynchrony refers to whether a process is involved in a real IO operation (a copy of the data kernel-state user state).
Instead, Java NIO provides asynchronous processing, which should refer to async on the programming model. Event-driven based on reactor mode, event handler registration and processor execution are asynchronous.

AIO (Async I/O) is a step further: not only is waiting for readiness to be non-blocking, even the process of data from the NIC to the memory is asynchronous.
In other words, the user of bio is most concerned with "I want to read", NIO users are most concerned about "I can read", in the AIO model users need to pay more attention to "read."
An important feature of NIO is that the socket's primary read, write, register, and receive functions are non-blocking during the wait-ready phase, and the real I/O operations are synchronous (CPU consuming but very high performance).

2.2. How to combine the incident model with NIO non-blocking characteristics

Bio model, the reason for the need for multi-threading, is because in the I/O operation, there is no way to know whether to write, can read, can only "silly wait", even through a variety of estimates, the operating system is not able to read and write, can not be in the Socket.read () and the Socket.write () function returns, these two functions cannot be effectively interrupted. So apart from the multi-thread process, there is no good way to use the CPU.

The read and write functions of NIO can be returned immediately, which gives us the best chance to take advantage of the CPU: If a connection cannot read and write (Socket.read () returns 0 or socket.write () returns 0), we can write down this matter. Logging is typically done by registering the tag bit on the selector and then switching to another ready connection (channel) to continue reading and writing.

We can probably summarize how NiO solves the bottleneck of threading and handles massive connections:

NiO is turned into a single-threaded polling event by the original blocking read-write (occupy thread), and the read-write network descriptor is found to be read and written. In addition to polling for events that are blocked (nothing that can be done must be blocked), the remaining I/O operations are pure CPU operations, and there is no need to turn on multithreading.
And because of the thread savings, the number of connections due to the problem caused by thread switching is also solved, which provides the possibility to deal with massive connections.

2.3. Understanding asynchronous non-blocking I/O

Many people like to refer to the NIO framework provided by JDK1.4 as asynchronous non-blocking I/O, but if you strictly differentiate between the UNIX network programming model and the JDK implementation, in fact it can only be called nonblocking I/O and cannot be called asynchronous nonblocking I/O. Prior to the earlier versions of JDK1.4 and 1.5 update10, the JDK selector was based on the Select/poll model, which is non-blocking I/O based on I/O multiplexing technology, not asynchronous I/O. In the JDK1.5 update10 and Linux core2.6 above, Sun optimized the implementation of Selctor, which replaced Epoll with Select/poll at the bottom, with no change in the upper API, which could be considered a one-time optimization of the JDK NiO, But it still hasn't changed the I/O model.
The NIO2.0 provided by JDK1.7, which is a new asynchronous socket channel, is a true asynchronous I/O that can pass a signal variable when an asynchronous I/O operation is completed and the associated method is recalled when the operation is complete, and asynchronous I/O is also called AIO.
The NIO class library supports non-blocking read and write operations, which are asynchronous compared to previous synchronous blocking reads and writes, so many people are accustomed to calling NiO asynchronous non-blocking I/O, including many books that introduce NIO programming. In order to conform to our custom, we also refer to NIO as asynchronous non-blocking I/O or non-blocking I/O.

Third, the core composition of Java NiO 3.1, channels (channel) and buffers (buffer)

Basically, all IO starts with a channel in NiO. The Channel is a bit like a stream. Data can be read from the channel to buffer, or it can be written from buffer to the channel. Here's a diagram:

3.2. Multiplexer (Selector)

Selector allows single-threaded processing of multiple channel. If your app has multiple connections (channels) open, but the traffic is low for each connection, it's convenient to use selector. For example, in a chat server.

This is the illustration of using a selector to process 3 channel in a single thread:

To use selector, you have to register the channel with selector and then call its select () method. This method will always block to a registered channel with event readiness. Once this method returns, the thread can handle these events, with examples of events such as new connections coming in, data receiving, and so on.

Iv. Summary

Finally, let's summarize what NiO has brought us:
Event-driven models
Avoid multithreading
Single-threaded multitasking
Non-blocking i/o,i/o reads and writes are no longer blocked, but returns 0
Block-based transmissions, which are typically more efficient than stream-based transmissions
More advanced IO functions, zero-copy
Io multiplexing greatly improves the scalability and usability of Java network applications

Java NIO Learning