To start with, let’s say you want to eat a dish of covered rice:

Synchronous blocking: You go to a restaurant and order your food and then wait while Shouting, “Are you ready?”

Synchronous non-blocking: After ordering at a restaurant, you walk the dog. But slip away for a while, go back to the restaurant to shout: good have no ah!

Asynchronous blocking: While walking the dog, you get a call from a restaurant saying dinner is ready for you to pick up in person.

Asynchronous non-blocking: The restaurant calls and says, “We know where you are, we’ll bring you back in a minute, just walk the dog.”

A, BIO

Synchronization and blocking, the server implementation mode is one connection one thread, that is, when the client has a connection request, the server needs to start a thread for processing, if the connection does not do anything will cause unnecessary thread overhead, of course, can be improved through the thread pool mechanism.

Second, the NIO

Synchronous non-blocking, the server implementation mode is one request one thread, that is, the connection request sent by the client is registered with the multiplexer, the multiplexer polls the connection to have I/O requests only start a thread for processing.

NIO itself is event-driven and addresses the large concurrency problem in BIO: In web applications that use synchronous I/O, multiple client requests must be processed simultaneously, or clients must communicate with multiple servers simultaneously. That is, each client request is assigned to a thread to process separately. This will do what we want, but at the same time, it will cause another problem. Each time a thread is created, a certain amount of memory (also known as working memory) is allocated for that thread, and the operating system itself has a limit on the total number of threads. If the client requests too much, the server may become overwhelmed and reject the client’s requests, or even crash the server.

NIO is based on Reactor. When a socket has a stream that can be read or written to the socket, the operating system notifies the reference program accordingly. The application then reads the stream into the buffer or writes the stream to the operating system. In other words, there is no longer a connection for each processing thread, but a valid request for each thread, and when the connection has no data, there is no worker thread to process it.

One important difference between BIO and NIO is that when we use BIO, we tend to introduce multiple threads, each connected to a separate thread. NIO uses a single thread or a small number of threads, one thread per connection. IO is the most important place when a connection is created, don’t need to correspond to a single thread, the connection will be registered to the multiplexer, so all connections only need one thread, you could just when the thread of the multiplexer poll, found the connection with the request, to open a thread for processing, This is the one-request-per-thread pattern.

In NIO, when a request comes in, the open thread may wait for resources from the back-end application (JDBC connection, etc.), but the thread will be blocked, and when the concurrency comes in, it will have the same problem as in BIO.

Third, AIO

Unlike NIO, when reading or writing, you simply call the API’s read or write methods directly. Both methods are asynchronous. In the case of reads, when there is a stream to read, the operating system passes the readable stream into the buffer of the read method and notifies the application. For write operations, the operating system actively notifies the application when the stream passed by the write method has been written. Read /write methods are asynchronous and call callback functions when they are finished. In JDK1.7, this is called nio.2, which adds the following four asynchronous channels under the java.nio.channels package:

  • AsynchronousSocketChannel
  • AsynchronousServerSocketChannel
  • AsynchronousFileChannel
  • AsynchronousDatagramChannel

The read/write method returns an object that calls the callback function directly after the read/write operation.

BIO, NIO, AIO Application scenario analysis:

•BIO mode is suitable for small and fixed number of connections. This mode requires high server resources, concurrency is limited to the application, and the only choice before JDK1.4, but the program is intuitive and simple to understand. •NIO is suitable for architectures with a large number of connections and relatively short (light operation) connections, such as chat servers, where concurrency is limited to applications and programming is complex. JDK1.4 supports this approach. •AIO mode is used for architecture with large number of connections and long connections (heavy operation), such as photo album server. It fully calls OS to participate in concurrent operation, and programming is complicated, which is supported by JDK7.