不畏浮云遮望眼，只缘身在此山中
最近再看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里
表示采用BIO
表示采用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问题，也做了相应的优化，比如使用线程池，实现异步阻塞式模型，
- (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
