声明：本文是《Netty 权威指南》的样章，感谢博文视点授权并发编程网站发布样章，禁止以任何形式转载此文。
为了解决同步阻塞IO面临的一个链路需要一个线程处理的问题，后来有人对它的线程模型进行了优化，后端通过一个线程池来处理多个客户端的请求接入，形成客户端个数M：线程池最大线程数N的比例关系，其中M可以远远大于N，通过线程池可以灵活的调配线程资源，设置线程的最大值，防止由于海量并发接入导致线程耗尽。 下面，我们结合连接模型图和源码，对伪异步IO进行分析，看它是否能够解决同步阻塞IO面临的问题。
2.1.1.伪异步IO模型图
采用线程池和任务队列可以实现一种叫做伪异步的IO通信框架，它的模型图如下：
伪异步IO服务端通信模型（M：N）
当有新的客户端接入的时候，将客户端的Socket封装成一个Task（该任务实现java.lang.Runnable接口）投递到后端的线程池中进行处理,JDK的线程池维护一个消息队列和N个活跃线程对消息队列中的任务进行处理。由于线程池可以设置消息队列的大小和最大线程数，因此，它的资源占用是可控的，无论多少个客户端并发访问，都不会导致资源的耗尽和宕机。 下面的小节，我们依然采用时间服务器程序，将其改造成伪异步IO时间服务器，然后通过对代码进行分析，找出其弊端。
2.1.1.伪异步式IO创建的TimeServer源码分析
我们对服务端代码进行一些改造，源码如下：
01 |
public class TimeServer {
|
07 |
public static void main(String[] args) throws IOException {
|
09 |
if (args != null && args.length > 0) {
|
11 |
port = Integer.valueOf(args[0]);
|
12 |
} catch (NumberFormatException e) {
|
16 |
ServerSocket server = null;
|
18 |
server = new ServerSocket(port);
|
19 |
System.out.println("The time server is start in port : " + port);
|
21 |
TimeServerHandlerExecutePool singleExecutor = new TimeServerHandlerExecutePool(
|
22 |
50, 10000);// 创建IO任务线程池
|
24 |
socket = server.accept();
|
25 |
singleExecutor.execute(new TimeServerHandler(socket));
|
29 |
System.out.println("The time server close");
|
伪异步IO的主函数代码发生了变化，我们首先创建一个时间服务器处理类的线程池，当接收到新的客户端连接的时候，将请求Socket封装成一个Task，然后调用线程池的execute方法执行，从而避免了每个请求接入都创建一个新的线程。 伪异步IO的TimeServerHandlerExecutePool：
01 |
public class TimeServerHandlerExecutePool {
|
03 |
private ExecutorService executor;
|
05 |
public TimeServerHandlerExecutePool(int maxPoolSize, int queueSize) {
|
06 |
executor = new ThreadPoolExecutor(Runtime.getRuntime()
|
07 |
.availableProcessors(), maxPoolSize, 120L, TimeUnit.SECONDS,
|
08 |
new ArrayBlockingQueue(queueSize));
|
10 |
public void execute(java.lang.Runnable task) {
|
11 |
executor.execute(task);
|
由于线程池和消息队列都是有界的，因此，无论客户端并发连接数多大，它都不会导致线程个数过于膨胀或者内存溢出，相比于传统的一连接一线程模型，是一种改良。 由于客户端代码并没有改变，因此，我们直接运行服务端和客户端，看执行结果： 服务端运行结果：
伪异步IO时间服务器服务端运行结果
客户端运行结果：
伪异步IO时间服务器客户端运行结果
伪异步IO通信框架采用了线程池实现，因此避免了为每个请求都创建一个独立线程造成的线程资源耗尽问题。但是由于它底层的通信依然采用同步阻塞模型，因此无法从根本上解决问题。下个小节我们对伪异步IO进行深入分析，找到它的弊端，然后看看NIO是如何从根本上解决这个问题的。
2.1.1.伪异步IO弊端分析
要对伪异步IO的弊端进行深入分析，首先我们看两个JAVA同步IO的API说明，随后我们结合代码进行详细分析。
02 |
* Reads some number of bytes from the input stream and stores them into
|
03 |
* the buffer array <code>b</code>. The number of bytes actually read is
|
04 |
* returned as an integer. This method blocks until input data is
|
05 |
* available, end of file is detected, or an exception is thrown.
|
08 |
If the length of <code>b</code> is zero, then no bytes are read and
|
09 |
* <code>0</code> is returned; otherwise, there is an attempt to read at
|
10 |
* least one byte. If no byte is available because the stream is at the
|
11 |
* end of the file, the value <code>-1</code> is returned; otherwise, at
|
12 |
* least one byte is read and stored into <code>b</code>.
|
15 |
The first byte read is stored into element <code>b[0]</code>, the
|
16 |
* next one into <code>b[1]</code>, and so on. The number of bytes read is,
|
17 |
* at most, equal to the length of <code>b</code>. Let <i>k</i> be the
|
18 |
* number of bytes actually read; these bytes will be stored in elements
|
19 |
* <code>b[0]</code> through <code>b[</code><i>k</i><code>-1]</code>,
|
20 |
* leaving elements <code>b[</code><i>k</i><code>]</code> through
|
21 |
* <code>b[b.length-1]</code> unaffected.
|
23 |
* @param b the buffer into which the data is read.
|
24 |
* @return the total number of bytes read into the buffer, or
|
25 |
* <code>-1</code> if there is no more data because the end of
|
26 |
* the stream has been reached.
|
27 |
* @exception IOException If the first byte cannot be read for any reason
|
28 |
* other than the end of the file, if the input stream has been closed, or
|
29 |
* if some other I/O error occurs.
|
30 |
* @exception NullPointerException if <code>b</code> is <code>null</code>.
|
32 |
public int read(byte b[]) throws IOException {
|
33 |
return read(b, 0, b.length);
|
请注意加粗斜体字部分的API说明，当对Socket的输入流进行读取操作的时候，它会一直阻塞下去，直到发生如下三种事件： 1) 有数据可读 2) 可用数据已经读取完毕 3) 发生空指针或者IO异常 这意味着当对方发送请求或者应答消息比较缓慢、或者网络传输较慢时，读取输入流一方的通信线程将被长时间阻塞，如果对方60S才能够将数据发送完成，读取一方的IO线程也将会被同步阻塞60S，在此期间，其它接入消息只能在消息队列中排队。 下面我们接着对输出流进行分析，还是看JDK IO类库输出流的API文档，然后结合文档说明进行故障分析。 Java 输入流OutputStream：
1 |
public void write(byte b[]) throws IOException
|
2 |
*Writes an array of bytes. This method will block until the bytes are *actually written. |
4 |
b - the data to be written |
6 |
If an I/O error has occurred. |
当调用OutputStream的write方法写输出流的时候，它将会被阻塞直到所有要发送的字节全部写入完毕，或者发生异常。学习过TCP/IP相关知识的都知道，当消息的接收方处理缓慢的时候，将不能及时的从TCP缓冲区读取数据，这将会导致发送方的TCP window size不断减小，直到为0，双方处于Keep-Alive状态，消息发送方将不能再向TCP缓冲区写入消息，这时如果采用的是同步阻塞IO，write操作将会被无限期阻塞，直到TCP window size大于0或者发生IO异常。
通过对输入和输出流的API文档进行分析，我们了解到读和写操作都是同步阻塞的，阻塞的时间取决于对方IO线程的处理速度和网络IO的传输速度。本质上来讲，我们无法保证生产环境的网络状况和对端的应用程序能够足够快，如果我们的应用程序依赖对方的处理速度，它的可靠性就非常差。也许在实验室进行的性能测试结果令大家满意，但是一旦上线运行，面对恶劣的网络环境和良莠不齐的第三方系统，问题就会如火山一样喷发。
伪异步IO实际上仅仅只是对之前IO线程模型的一个简单优化，它无法从根本上解决同步IO导致的通信线程阻塞问题。下面我们就简单分析下如果通信对方返回应答时间过长引起的级联故障：
- 服务端处理缓慢，返回应答消息耗费60S，平时只需要10MS；
- 采用伪异步IO的线程正在读取故障服务节点的响应，由于读取输入流是阻塞的，因此，它将会被同步阻塞60S；
- 假如所有的可用线程都被故障服务器阻塞，那后续所有的IO消息都将在队列中排队；
- 由于线程池采用阻塞队列实现，当队列积满之后，后续入队列的操作将被阻塞；
- 由于前端只有一个Accptor线程接收客户端接入，它被阻塞在线程池的同步阻塞队列之后，新的客户端请求消息将被拒绝，客户端会发生大量的连接超时；
- 由于几乎所有的连接都超时，调用者会认为系统已经崩溃，无法接收新的请求消息。
如何破解这个难题？下个章节的NIO将给出答案。
时间： 2024-11-08 23:22:18
