Java Network Programming from entry to mastery (31): non-blocking I/O Introduction

In network applications, synchronous I/O (blocking I/O) and non-blocking I/O can be used for data communication. These two methods are not mutually exclusive and replace each other. We can use either of the two communication methods separately or in combination in our daily applications. In this article, we will introduce what is non-blocking I/O and why this communication method is used, the next article provides a simple example to demonstrate how to use non-blocking I/O for communication in network applications.

I. What is non-blocking I/O?

We can call synchronous I/O as blocking I/O, and non-blocking I/O as asynchronous I/O. This book uses the commonly used name: Synchronous I/O and non-blocking I/O. Although they are called differently, they have the same meaning. Readers should pay attention to this when reading other books.

Before explaining what is non-blocking I/O, you should first understand what is synchronous I/O, and what synchronization here refers. The concept of synchronization mainly refers to the process of code execution in sequence in programming. For example, if the main method in a Java program does not use multiple threads, the code in this method must be executed sequentially from the beginning to the end. This is called synchronization. If multithreading is used, different code segments are executed simultaneously from a macro perspective. This is called asynchronous. The concept of synchronization in synchronous I/O is similar. That is to say, in the process of I/O communication, as long as the communication at a certain step is not completed, other communication cannot be performed. So what is synchronization here? Before answering this question, let's first recall where network communication may be blocked. If you read the previous chapter, you will know the answer. The client may be congested in two ways: connecting to the server (when the connect method is called) and reading and writing data. The server may also be blocked in two ways: Waiting for client requests (when the accept method is called) and reading/writing data (in general, writing data will not be blocked, however, if the network environment is poor, write operations on the client and server may also be blocked ). That is to say, the time-out period that can be set may be blocked. Synchronization in I/O means that the program remains in the waiting state except for the following two situations:

1. Connect to the server, read and write data, or wait for the client request to be executed normally.

2. a timeout exception is thrown after waiting for the timeout time.

We learned what synchronous I/O is. The most obvious difference between non-blocking I/O and synchronous I/O is that all possible blocked addresses of synchronous I/O will not be blocked in non-blocking I/O. For example, if the data cannot be read at the moment. So that the program can execute other code and the system will continuously detect this unfinished read operation, this operation will be completed until you can continue reading data.

Java provides a set of APIs in JDK1.4 and later versions to specifically operate non-blocking I/O. We can find related classes and interfaces in the java. nio package and its sub-packages. Because this API is a New I/o api provided by JDK, it is also called New I/O. This is the origin of the package name nio. This API is composed of three main parts: buffer (Buffers), channel (Channels) and non-blocking I/O core classes. The details of these three parts will be described later in this chapter.

Ii. Why use non-blocking I/O

In a network application that uses synchronous I/O, multithreading is required to process requests from multiple clients at the same time or to communicate with multiple servers at the same time. That is to say, each client request is allocated to a thread for separate processing. Although this can meet our requirements, it will also bring about another problem. Each time a thread is created, a certain amount of memory space (also called the working memory) is allocated to the thread, and the operating system itself limits the total number of threads. If the client has too many requests, the server program may reject the client's requests because it is overwhelmed, or even the server may be paralyzed.

Of course, you can use the thread pool (which will be explained in the third part) to relieve the pressure on the server, but this does not solve the problem of Server Denial of response caused by too intensive access on the client. Although there is a request buffer on the server side as a guarantee, the buffer size is limited (generally 50). If the number of client requests far exceeds this number, the client will still receive the denial of service information.

In this case, non-blocking I/O can be used to solve this problem. Because non-blocking I/O programs are generally single-threaded (sometimes the program segments that use non-blocking I/O may be placed in a separate thread, the main thread is responsible for processing user input. Therefore, the number of client requests received by the server does not increase as the number of worker threads increases. Therefore, the use of non-blocking I/O mode will not be limited by the operating system's total number of threads, nor will it occupy a large number of server resources.

Although non-blocking I/O can achieve the goal of processing a large number of client requests without occupying a large number of server resources. However, this communication method cannot completely replace synchronous I/O. For example, non-blocking I/O is not suitable for applications that need to maintain the connection status as the FTP server (the reason will be described in later sections ). Non-blocking I/O applications are generally more on the server, because the client generally does not need to process a large number of connections (except for some applications, such as Baidu and Google Web Spider, to download multiple web pages at the same time, you need to establish a large number of connections on the client to meet the requirements), and the server program generally needs to receive and process a large number of client requests. Therefore, you need to use multithreading (synchronous I/O) or non-blocking I/O to achieve this goal. If a server application does not process so many client requests, multithreading and I/O synchronization may be better, because this method is more flexible than non-blocking I/O.

We have been talking about non-blocking I/O and network applications. In fact, non-blocking I/O is not equal to the network. We can also apply non-blocking I/O to non-network applications, such as file replication. Because synchronous I/O is based on byte streams, rather than blocking I/O is based on the buffer zone and channel. Therefore, theoretically, the larger the file to be operated, the more advantageous non-blocking I/O is. For small file operations, the efficiency of these two methods is almost the same. According to the experiment, copying a 4G file is generally about 15% faster than synchronizing I/O files in non-blocking I/O mode.