Java IO Programming Full Solution (iii)-pseudo-asynchronous IO programming

Reprint Please specify source: http://www.cnblogs.com/Joanna-Yan/p/7723174.html

Previous: Java IO programming Full Solution (ii)--traditional bio programming

In order to solve the problem that the synchronous blocking I/O faces a link that requires a threading process, someone later optimizes its threading model, and the backend uses a thread pool to handle requests from multiple clients, forming the number of clients m: the proportional relationship of the maximum thread number n of the thread pool, where m can be much greater than N, The thread pool provides the flexibility to provision threading resources, set the maximum value of threads, and prevent thread exhaustion due to massive concurrent access.

Below, we combine the connection model diagram and the source code, the pseudo-asynchronous I/O analysis, see whether it can solve the problem of synchronous blocking I/O.

1. Pseudo-Asynchronous I/O model diagram

A framework of I/O communication called pseudo-Async can be implemented using the thread pool and task queue, and its model diagram is shown below.

When there is a new client access, the client's socket is encapsulated into a task (the task Implementation java.lang.Runnable interface) is posted to the back-end thread pool for processing, and the JDK thread pool maintains a message queue and n active threads to process the tasks in the message queue. Because the thread pool can set the size of the message queue and the maximum number of threads. Therefore, its resource consumption is controllable, regardless of the number of client concurrent access, will not lead to resource exhaustion and downtime.

Figure 1 Pseudo-asynchronous I/O server-side communication model (M:N)

Below we still use the time server program, transform it into a pseudo-asynchronous I/O time server, and then through the code analysis, to find its drawbacks.

2. Timeserver source code Analysis for pseudo-asynchronous I/O creation

 PackageJoanna.yan.poio;Importjava.io.IOException;ImportJava.net.ServerSocket;ImportJava.net.Socket;/*** Pseudo-asynchronous I/O *@authorJoanna.yan * @date October 24, 2017 morning 10:16:10*/ Public classTimeserver { Public Static voidMain (string[] args) {intport=9090; if(args!=NULL&&args.length>0){            Try{Port=integer.valueof (args[0]); } Catch(Exception e) {//with default values}} ServerSocket server=NULL; Try{Server=NewServerSocket (port); System.out.println ("The time server is a start in port:" +port); Socket Socket=NULL; //Create a thread pool for a time server classTimeserverhandlerexecutepool singleexecutor=NewTimeserverhandlerexecutepool (50, 10000);//Create I/O tasks                         while(true) {Socket=server.accept (); //When a new client connection is received, the request socket is encapsulated into a task and then invoked by the Execute method. This avoids the creation of a new thread for each request access. Singleexecutor.execute (NewTimeserverhandler (socket)); }        } Catch(IOException e) {e.printstacktrace (); }finally{            if(server!=NULL){                Try{System.out.println ("The time server close"); Server=NULL;                Server.close (); } Catch(IOException e) {e.printstacktrace (); }            }        }    }}

 PackageJoanna.yan.poio;ImportJava.util.concurrent.ArrayBlockingQueue;ImportJava.util.concurrent.ExecutorService;ImportJava.util.concurrent.ThreadPoolExecutor;ImportJava.util.concurrent.TimeUnit;/*** Because the thread pool and message queue are bounded, no matter how large the number of concurrent connections to the client, it does not cause the number of threads to swell or memory overflow, * compared to the traditional one-thread model, is an improvement. * @authorJoanna.yan * @date October 24, 2017 PM 2:39:49*/ Public classTimeserverhandlerexecutepool {PrivateExecutorservice executor;  PublicTimeserverhandlerexecutepool (intMaxpoolsize,intqueuesize) {Executor=NewThreadpoolexecutor (Runtime.getruntime (). Availableprocessors (), Maxpoolsize,120L, Timeunit.seconds,NewArrayblockingqueue<java.lang.runnable>(queuesize)); }         Public voidExecute (java.lang.Runnable Task) {Executor.execute (Task);; }}

 PackageJoanna.yan.poio;ImportJava.io.BufferedReader;Importjava.io.IOException;ImportJava.io.InputStreamReader;ImportJava.io.PrintWriter;ImportJava.net.Socket;Importjava.util.Date; Public classTimeserverhandlerImplementsrunnable{Privatesocket socket;  PublicTimeserverhandler (socket socket) { This. Socket =socket; } @Override Public voidrun () {BufferedReader in=NULL; PrintWriter out=NULL; Try{ in=NewBufferedReader (NewInputStreamReader ( This. Socket.getinputstream ())); out=NewPrintWriter ( This. Socket.getoutputstream (),true); String currenttime=NULL; String Body=NULL;  while(true) {Body=In.readline (); if(body==NULL){                     Break; } System.out.println ("The time server receive order:" +body); //If the request message is the instruction "Query time order" for the queried times, the current system time is obtained. Currenttime= "QUERY time ORDER". Equalsignorecase (body)?NewDate (System.currenttimemillis ()). ToString (): "Bad ORDER";            Out.println (currenttime); }        } Catch(IOException e) {e.printstacktrace (); }finally{            if(in!=NULL){                Try{in.close (); } Catch(IOException e) {e.printstacktrace (); }            }            if(out!=NULL) {out.close (); out=NULL; }            if( This. socket!=NULL){                Try {                     This. Socket.close ();  This. socket=NULL; } Catch(IOException e) {e.printstacktrace (); }            }        }    }}

The pseudo-asynchronous I/O communication framework employs thread pooling implementations, thus avoiding the thread resource exhaustion problem caused by creating a separate thread for each request. However, because its underlying communication still uses the synchronous blocking model, it cannot solve the problem fundamentally.

3. Pseudo-Asynchronous I/O malpractice analysis

To make an in-depth analysis of the drawbacks of pseudo-asynchronous I/O, let's look at two Java synchronous I/O API descriptions first. We then combined the code for a detailed analysis.

Note that the Bold Italic section of the API illustrates that when the input stream of the socket is read, it will block until the following three events occur.

• have data to read;
• The available data has been read;
• A null pointer or I/O exception occurred.

This means that when the other party sends a request or response message is slow, or the network transmission is slow, read the input stream one side of the communication thread will be blocked for a long time, if the other side to 60s to be able to send the data to complete, read one side of the I/O thread will also be synchronized blocking 60s, during this period, Other access messages can only be queued in the message queue.

Next we will analyze the output stream, or look at the API documentation for the JDK I/O class library output stream, and then combine the documentation instructions for failure analysis.

When the write method of the OutputStream is called and the output stream is written, it will be blocked until the bytes to be sent are all written, or an exception occurs. People who have learned about TCP/IP know that when the receiver processing of the message is slow, it will not be able to read the data from the TCP buffer in time, which will cause the sender's TCP window size to decrease until it is 0 and the two sides are in keep-alive state. The message sender will no longer be able to write a message to the TCP buffer, which is if the synchronous blocking I/o,write operation will be blocked indefinitely until the TCP window size is greater than 0 or an I/O exception occurs.

By analyzing the API documentation for the input and output streams, we learned that both read and write operations are synchronously blocked, and the time to block depends on the processing speed of the other I/O threads and the network I/O transfer speed. In essence, we cannot guarantee that the network condition of the production environment and the application to the end are fast enough, and that if our application relies on the other party's processing speed, it is very unreliable.

Pseudo-Asynchronous I/O is really just a simple optimization of the previous I/O threading model, and it does not fundamentally address the communication thread blocking problems caused by synchronous I/O. The following is a simple analysis of the communication if the return response time is too long, will cause cascading failures.

1. The service side processing is slow, the return reply message consumes 60s, usually only needs 10ms.
2. A thread with pseudo-asynchronous I/O is reading the response from the failed service node, and because the read input stream is blocked, it will be blocked by synchronization by 60s.
3. If all available threads are blocked by the failed server, all subsequent I/O messages will be queued in the queue.
4. Since the thread pool is implemented in a blocking queue, subsequent queued operations will be blocked when the queues are full.
5. Since the front end has only one Accptor thread receiving client access, it is blocked by the synchronization blocking queue of the online pool, and the new client request message is rejected, and the client will have a large number of connection timeouts.
6. Because almost all connections are timed out, the caller will assume that the system has crashed and cannot receive the new request message.

So how is this problem solved? The following NIO will give an answer.

Java IO Programming Full solution (d)--nio programming

If this article is helpful to you, please give me a reward!

Java IO Programming Full Solution (iii)-pseudo-asynchronous IO programming