Java IO Model Diagram (BIO NIO AIO)

1. The von Neumann model

As shown in the picture:
insert image description here
Image source: Baidu Encyclopedia

Input devices input data to the computer, and output devices receive data output from the computer.
All computer programs can also be abstracted as reading input information from the input device, executing the program stored in the memory through the arithmetic unit and the controller , and finally outputting the result to the output device.

2. Interpretation of I/O model

I/O describes the process of communication between a computer system and external devices. input and output.
In the operating system: In order to ensure the stability and security of the operating system, the address space of a process is divided into user space (User space) and kernel space (Kernel space).
Applications are all running in user space, and only kernel space can perform resource-related operations at the system level. If we want to perform IO operations, we must rely on the capabilities of the kernel space. Programs in user space cannot directly access kernel space.

From the perspective of the application program, our application program initiates an IO call (system call) to the kernel of the operating system, and the kernel responsible for the operating system performs specific IO operations. In other words, our application actually just initiates the call of the IO operation, and the execution of the specific IO is completed by the kernel of the operating system.

insert image description here

3. BIOs

In the synchronous blocking IO model, after the application initiates a read call, it will be blocked until the kernel copies the data to the user space.
insert image description here
There is a problem here, once the number of concurrency is too high, the queuing time will be enough. So there is NIO.

4. NIO

1. Synchronous non-blocking IO

insert image description here

In the synchronous non-blocking IO model, the application will always initiate a read call, waiting for the data to be copied from the kernel space to the user space, and the thread is still blocked until the data is copied to the user space in the kernel.
But there is a problem: the process of the application continuously performing I/O system calls to poll whether the data is ready consumes a lot of CPU resources, such as polling 1000 reads, there will be a huge cost problem. There is multiplexing IO.

2. Multiplexing IO

insert image description here

The thread first initiates a select call (1000 file descriptors are sent to the kernel at one time, and the user polling is done in the kernel to reduce invalid calls), and asks whether the kernel data is ready. After the kernel prepares the data, the user thread initiates a read call. The process called by read (data from kernel space -> user space) is still blocked.
The multiplexing model reduces the consumption of CPU resources by reducing invalid system calls.

select call: a system call provided by the kernel, which supports querying the available status of multiple system calls at once. Almost all operating systems are supported.
epoll call: Linux 2.6 kernel, which belongs to the enhanced version of select call, which optimizes the execution efficiency of IO.

3. NIO with shared space

insert image description here

epoll starts the shared space (mmap), puts 1000 connections (requests) into the red-black tree, and puts the ready data into the linked list, which can be read between threads. IO is reduced, and copy blocking is also reduced. Greatly improved efficiency. This is how the bottom layer of Redis is used.
It can also be extended to zero copy and kafka, so I won't go into too much depth here.

五、AIO

insert image description here
Asynchronous IO is implemented based on the event and callback mechanism, that is, the application will return directly after the operation, and will not be blocked there. When the background processing is completed, the operating system will notify the corresponding thread to perform subsequent operations.

Guess you like

Origin blog.csdn.net/liwangcuihua/article/details/131108616