java并发【转】

来自：http://blog.csdn.net/jiyiqinlovexx/article/details/51204726

引言

BIO和NIO是两种不同的网络通信模型，现如今NIO已经大量应用在Jetty、ZooKeeper、Netty等开源框架中。

一个面向流、一个面向缓冲区

一个是阻塞式的、一个非阻塞

一个没有io多路复用器、一个有

下面通过一个例子解释两者区别：

假设当前服务端程序需要同时从与多个客户端建立的连接读取数据。

 

使用BIO

如果采用阻塞式IO，单线程情况下，处理者线程可能阻塞在其中一个套接字的read上，导致另一个套接字即使准备好了数据也无法处理，这个时候解决的方法就是针对每一个套接字，都新建一个线程处理其数据读取。

所以说，在BIO工作模式下，服务端程序要想同时处理多个套接字的数据读取，在等待接收连接请求的主线程之外，还要为每一个建立好的连接分配一个新的线程进行处理。

 

使用NIO

轮询方式

如果将套接字读操作换成非阻塞的，那么只需要一个线程就可以同时处理套接字，每次检查一个套接字，有数据则读取，没有则检查下一个，因为是非阻塞的，所以执行read操作时若没有数据准备好则立即返回，不会发生阻塞。

 

I/O多路复用

这种轮询的方式缺点是浪费CPU资源，大部分时间可能都是无数据可读的，不必仍不间断的反复执行read操作，I/O多路复用（IOmultiplexing）是一种更好的方法，调用select函数时，其内部会维护一张监听的套接字的列表，其会一直阻塞直到其中某一个套接字有数据准备好才返回，并告诉是哪个套接字可读，这时再调用该套接字的read函数效率更高。

所以基本可以认为 “NIO = I/O多路复用 + 非阻塞式I/O”，大部分情况下是单线程，但也有超过一个线程实现NIO的情况

 

NIO三种模型

上面所讲到的只需要一个线程就可以同时处理多个套接字，这只是其中的一种单线程模型，是一种较为极端的情况，NIO主要包含三种线程模型：

1) Reactor单线程模型

2) Reactor多线程模型

3)主从Reactor多线程模型

 

Reactor单线程模型：

单个线程完成所有事情包括接收客户端的TCP连接请求，读取和写入套接字数据等。

对于一些小容量应用场景，可以使用单线程模型。但是对于高负载、大并发的应用却不合适，主要原因如下：

1) 一个NIO线程同时处理成百上千的链路，性能上无法支撑，即便NIO线程的CPU负荷达到100%，也无法满足海量消息的编码、解码、读取和发送；

2) 当NIO线程负载过重之后，处理速度将变慢，这会导致大量客户端连接超时，超时之后往往会进行重发，这更加重了NIO线程的负载，最终会导致大量消息积压和处理超时，NIO线程会成为系统的性能瓶颈；

3) 可靠性问题：一旦NIO线程意外跑飞，或者进入死循环，会导致整个系统通信模块不可用，不能接收和处理外部消息，造成节点故障。

为了解决这些问题，演进出了Reactor多线程模型。

 

Reactor多线程模型：

Rector多线程模型与单线程模型最大的区别就是有一组NIO线程处理真实的IO操作。

Reactor多线程模型的特点：

1) 有专门一个NIO线程-Acceptor线程用于监听服务端，接收客户端的TCP连接请求；

2) 网络IO操作-读、写等由一个NIO线程池负责，线程池可以采用标准的JDK线程池实现，它包含一个任务队列和N个可用的线程，由这些NIO线程负责消息的读取、解码、编码和发送；

3) 1个NIO线程可以同时处理N条链路，但是1个链路只对应1个NIO线程，防止发生并发操作问题。

在绝大多数场景下，Reactor多线程模型都可以满足性能需求；但是，在极特殊应用场景中，一个NIO线程负责监听和处理所有的客户端连接可能会存在性能问题。例如百万客户端并发连接，或者服务端需要对客户端的握手消息进行安全认证，认证本身非常损耗性能。在这类场景下，单独一个Acceptor线程可能会存在性能不足问题，为了解决性能问题，产生了第三种Reactor线程模型-主从Reactor多线程模型。

即从单线程中由一个线程即监听连接事件、读写事件、由完成数据读写，拆分为由一个线程专门监听各种事件，再由专门的线程池负责处理真正的IO数据读写。

 

主从Reactor多线程模型

主从Reactor线程模型与Reactor多线程模型的最大区别就是有一组NIO线程处理连接、读写事件。

主从Reactor线程模型的特点是：服务端用于接收客户端连接的不再是个1个单独的NIO线程，而是一个独立的NIO线程池。Acceptor接收到客户端TCP连接请求处理完成后（可能包含接入认证等），将新创建的SocketChannel注册到IO线程池（sub reactor线程池）的某个IO线程上，由它负责SocketChannel的读写和编解码工作。Acceptor线程池仅仅只用于客户端的登陆、握手和安全认证，一旦链路建立成功，就将链路注册到后端subReactor线程池的IO线程上，由IO线程负责后续的IO操作。

即从多线程模型中由一个线程来监听连接事件和数据读写事件，拆分为一个线程监听连接事件，线程池的多个线程监听已经建立连接的套接字的数据读写事件，另外和多线程模型一样有专门的线程池处理真正的IO操作。

各自适用场景

NIO适用场景

服务器需要支持超大量的长时间连接。比如10000个连接以上，并且每个客户端并不会频繁地发送太多数据。例如总公司的一个中心服务器需要收集全国便利店各个收银机的交易信息，只需要少量线程按需处理维护的大量长期连接。

Jetty、Mina、Netty、ZooKeeper等都是基于NIO方式实现。

 

BIO适用场景

适用于连接数目比较小，并且一次发送大量数据的场景，这种方式对服务器资源要求比较高，并发局限于应用中。

等待某一个指定的事件发生后，才让多个等待的线程继续执行，以下是我能想到的几个方法，欢迎讨论、指正。

1.闭锁CountDownLatch

闭锁是典型的等待事件发生的同步工具类，将闭锁的初始值设置1，所有线程调用await方法等待，当事件发生时调用countDown将闭锁值减为0，则所有await等待闭锁的线程得以继续执行。

 

2.阻塞队列BlockingQueue

所有等待事件的线程尝试从空的阻塞队列获取元素，将阻塞，当事件发生时，向阻塞队列中同时放入N个元素(N的值与等待的线程数相同)，则所有等待的线程从阻塞队列中取出元素后得以继续执行。

 

3.信号量Semaphore

设置信号量的初始值为等待的线程数N，一开始将信号量申请完，让剩余的信号量为0，待事件发生时，同时释放N个占用的信号量，则等待信号量的所有线程将获取信号量得以继续执行。 

 

4.栅栏CyclicBarrier

设置栅栏的初始值为1，当事件发生时，调用barrier.wait()冲破设置的栅栏，将调用指定的Runable线程执行，在该线程中启动N个新的子线程执行。这个方法并不是让执行中的线程全部等待在某个点，待某一事件发生后继续执行。

 

特别注意：不能用“条件队列”，多个线程阻塞等待在条件队列上，事件发生时调用“条件队列”的notifyAll方法或者signalAll方法虽然能唤醒所有等待线程，但是只有一个线程能够获得该条件队列的锁得以调度执行，其它线程未获得锁仍将继续阻塞等待。

主线程等待多个子线程执行完才继续执行，以下是我能想到的几种方法，欢迎讨论、指正。

1.闭锁CountDownLatch

闭锁是典型的等待事件发生的同步工具类，将闭锁的初始值设置为与子线程数目相同，每个子线程执行完成都调用CountDown()方法，主线程调用await()方法等待计数值变为零之后恢复继续执行。

 

2.线程间同步方法

假设有N个子线程，每个子线程执行完成都将一个全局的原子变量加1，待某个线程将原子变量加到N之后，则利用以下三种方法将主线程唤醒。

1. 互斥信号量Semaphore：主线程申请占用信号量失败阻塞，由子线程释放信号量唤醒。
2. 阻塞队列BlockingQueue：主线程尝试从空队列取东西失败阻塞，由子线程放入东西唤醒。
3. 条件队列：主线程wait/await在内置或显式的条件队列上，由子线程notify/signal唤醒。

 

3.Future的get()方法

提交子线程到线程池执行的时候维护好所有子线程的Future对象，主线程中循环调用所有Future对象的get方法等待子线程执行完成并返回结果。

 

4.CompletionService的take()方法

提交所有子线程到ExecutorCompletionService线程池执行，主线程通过其take方法等待所有子线程执行完成并返回结果。

 

5.Thread的join()方法

创建Thread对象并start启动之后维护好所有子线程的Thread对象，在主线程中循环调用所有子线程这个Thread对象的join方法，等待所有子线程执行完成。

 

6.栅栏CyclicBarrier

栅栏是典型的等待所有线程到达同一栅栏位置的同步工具类。可以在所有子线程的结束位置设置栅栏，待所有子线程达到栅栏位置后执行指定的Runnable线程，此方法并不是严格意义的等待所有子线程执行完成后继续执行主线程，而是执行另一个线程。

 

7.线程池的awaitTermination()方法

ExecutorService的awaitTermination()方法定义如下：

boolean awaitTermination(long timeout,

                         TimeUnit unit)

                         throwsInterruptedException

这个方法作用是等待提交的任务全部执行完成，但是需要设置超时时间，若超时则会返回false，所以并不能准确估计需要等待多长时间。