不畏浮云遮望眼，只缘身在此山中

最近再看dubbo源码，然后看到通信模块的netty，卡住了，感觉netty源码似懂非懂，有些原理根本不知道为什么是这样，特别是netty中使用到的通信模型，更是云里雾里，所以还是决定从Java中IO开始重新入手，逐渐深入，今天就来记录下BIO与NIO模型，主要是看了视频后的观后感，视频地址文末会分享出来，讲的比较好，文章写的比较简单入门，所以要深入，需要自己去研究源码，当然后面自己有更深的心得，也会分享出来。如有文中有书写或其他问题，请留言指导修正，互相交流，共同进步，本人QQ：417213902。

主要从以下几个方面入手：

• 1、提出一个疑问：您能描述下一个http请求吗？
• 2、通过在tomcat中的使用，对BIO与NIO模型比较
• 3、BIO与NIO应用场景

一、提出疑问

这个一般大中型公司面试最喜欢的一到题目：
您能描述下一个http请求吗？
解答如下，主要从下面两个方面阐述

• 网络层，数据传输层面
  　网络传输：TCP、UDP
  　通信模型：BIO、NIO、AIO

• 应用层，数据处理层面
  　应用协议：http、rmi 、webservice、redis、jms
  　序列化协议：json、
  　业务处理：servlet
  从上面可知道，BIO、NIO或者是AIO 是作用于网络层的通信模型

  
  image.png

二、BIO与NIO的比较

1、实践测试
由于时间问题，比较流程大概描述下，后面直接给出结论，有兴趣的小伙伴可以自己去尝试下。
在tomcat7下分别配置指定AIO和NIO模型， 模拟做http请求，查看在设定相同的最大请求数下，随着请求数增多，BIO和NIO不同模型下线程数变化情况。tomcat7 默认情况下就是使用BIO模型，配置是在 server.xml里

image.png

表示采用BIO

image.png
表示采用NIO
测试结果 ：

BIO ：随着请求数增多，线程数也会增多
NIO :  随着请求数增多，线程数不会增多

2、理论说明

• (1) BIO : 同步阻塞式模型，在tomcat中它的原理是从客户端到服务端在建立连接、写入、读取等都是一个线程处理，所以它是稳定的、安全的。它也是实现中java中的serverSocket，调用accept方法，这个accept在有请求时返回一个socket，没有请求时，就阻塞着，但是这里的阻塞并不是导致它就是阻塞模型的原来，其真正原因是网络传输、业务处理等阻塞，阻塞的时间取决于对方I/O线程的处理速度和网络I/O的传输速度。

  
  image.png

在以BIO模型实现的tomcat中，线程有，

• Acceptor线程 ： 不断调用 Accept()方法
• Exec线程 ： 执行调用业务

当然以上问题，在tomcat中针对使用BIO问题，也做了相应的优化，比如使用线程池，实现异步阻塞式模型，

image.png

• (2) NIO：同步非阻塞式模型，在tomcat7后开始支持NIO模型，tomcat8已经开始支持AIO模型了。NIO中之所以能够支持数万级别的高并发，其主要原因是它有通道的多路复用的实现，叫Selector，在nio.channels包下，它负责轮询请求状态，并封装在SelectionKey中，通知其他线程去执行。

在以NIO模型实现的tomcat中，线程有，

• ClientPoller 线程：多路复用器(Selector)，轮询监听四类事件（Connect、Accept、Read、Write），会通知exec线程 。 tomcat 中默认是两个线程，可配置
• Acceptor线程 ： 不断调用 Accept()方法

• Exec线程 ： 执行调用业务

  
  image.png

NIO，默认也是支持阻塞式 ，configureBlocking(false) 设置成非阻塞的

三、应用场景

• BIO ： 适用于连接数目比较小且固定的架构，这种方式对服务器资源要求比较高，并发局限于应用中，JDK1.4以前的唯一选择，但程序直观简单易理解，tomcat7之前支持的通信模型
• NIO：适用于连接数目多且连接比较短（轻操作）的架构，比如聊天服务器，并发局限于应用中，编程比较复杂，JDK1.4开始支持，tomcat7开始支持的通信模型

2017-12-03 23:18:00