阻塞和非阻塞
阻塞的时候线程会被挂起
阻塞：
当数据还没筹备好时，调用了阻塞的办法，则线程会被挂起，会让出CPU工夫片，此时是无奈解决过去的申请，须要期待其余线程来进行唤醒，该线程能力进行后续操作或者解决其余申请。
非阻塞：
意味着，当数据还没筹备好的时候，即使我调用了阻塞办法，该线程也不会被挂起，后续的申请也可能被解决。
同步
同步和异步跟串行和并行十分形似。
假如在一个场景下：实现一个大工作须要4个小工作。
同步的做法：须要顺次4个步骤，留神这里是顺次，也就是说实现这个步骤，须要先实现前置步骤，也就是说下一个步骤是要看上一个步骤的执行后果。
异步的做法：能够同时进行4个步骤，无需期待其余步骤的执行后果。
阻塞和同步的最实质差异在于：
即使是同步，在期待的过程中，线程是不会被挂起，也不须要让出CPU工夫片的，
在IO中的体现
网络编程的根本模型是：Client/Server模型
两个过程之间要互相通信，其中服务端须要提供地位信息，让客户端找到本人。服务端提供IP地址和监听的端口。
客户端拿着这些信息去向服务端发动建设连贯申请，通过三次握手胜利建设连贯后，客户端就能够通过socket向服务器发送和承受音讯。
BIO
BIO通信模型采纳的是典型的：一申请一应答通信模型
采纳BIO通信模型的服务端，通常会由一个独立的Acceptor线程负责监听客户端的连贯。
他不负责解决申请，他只是起到一个委派工作的作用，当他接管到申请之后，会为每个客户端创立一个新的线程进行链路解决。
解决完之后，通过输入流，返回应答给客户端，而后线程被销毁，资源被回收。
该模型的最大问题就是不足弹性伸缩能力，服务端的线程个数和客户端的并发拜访数是1：1的关系。
因为线程是Java虚拟机十分贵重的资源，当线程书收缩之后，零碎的性能会随着并发量减少呈反比的趋势降落。
而且会有OOM的危险，当没有内存空间创立线程时，就无奈解决客户端申请，最终导致过程宕机或卡死，无奈对外提供服务。
最大的问题就是：每当有一个客户端申请接入时，就会创立一个线程来解决申请。
为了改良这个一线程一连贯模型，前面又演进出通过：
线程池
音讯队列
来实现1个或者多个线程解决N个客户端的模型。
在这里，无论是线程池和音讯队列，都是解决内存空间，线程的问题，并没有实质性地扭转同步阻塞通信实质问题
所以这种优化版本的BIO也被称为是伪异步。
伪异步IO
采纳线程池和工作队列能够实现一种：伪异步的IO通信
将客户端的申请封装成一个Task（该工作实现java.lang.Runnable接口），投递到音讯队列中。
如果通过线程池保护一堆解决线程，去生产队列中的音讯。
处理完毕之后，再去通过客户端就能够了，他的资源是可控的，无论客户端的申请量是多少，也不会发生变化，同样这也是他的毛病之一。
建设连贯的accpet办法、读取数据的read办法都是阻塞。
这就意味着，如果有一方解决申请或者发出请求的比较慢，或者是网络传输比较慢，那么都会影响对方。
当调用OutputStream的write办法写输入流的时候，它将会被阻塞，直到所有要发送的字节全副写入结束，或者产生异样。
在TCP/IP中，当音讯的接管方解决迟缓的时候，因为音讯滑动窗口的存在，那么它的接管窗口就会变小，就是那个TCP window size。
如果这里采纳同步阻塞IO，并且write操作被阻塞很久，直到TCP window size 大于0或者产生IO异样了。
那么通信对方返回应答工夫过长会引起的级联故障：
线程问题：如果所有的可用线程都被故障服务器阻塞，那么后续所有的IO音讯都将被队列中排队。
队列问题：如果队列采纳的是有界队列，队列满了之后那么就会无奈后续解决申请；如果采纳的是无界队列，那么会有OOM危险。
NIO
NIO，官网叫法是new IO，因为它绝对于之前出的java.io包是新增的
然而之前老的IO库都是阻塞的，New IO类库指标就是为了让Java反对非阻塞IO，所有更多的人称为Non-Block IO
缓冲区Buffer
Buffer是一个对象，通常是ByteBuffer类型
任何时候操作NIO中的数据，都须要通过缓冲区。
在NIO库里，所有数据操作是用缓冲区解决的。
读取数据时，是间接读到缓冲区中（这里并没有间接读到某个中央，而是都放到缓冲区中）
写入数据时，写入到缓冲区
缓冲区本质上是一个数组，通常是一个字节数组ByteBuffer，本身还须要保护读写地位，能够用指针或者偏移量来实现。
除了ByteBuffer还有其余根本类型缓冲区：
CharBuffer：字符缓冲区
ShortBuffer：短整型缓冲区
IntBuffer：整形缓冲区
LongBuffer：长整型缓冲区
DoubleBuffer：双精度缓冲区
通常是用ByteBuffer
通道Channel
网络数据通过Channel读取和写入
Channel通道和Stream流最大的区别在于：
Channel的数据流向是双向的
Stream的数据流向是单向的
这就意味着：应用Channel，能够同时进行读和写，他是全双工模型。（能够联想到HTTP1.1 HTTP2.0 HTTP3.0 ``websocket）
多路复用器Selector
Selector是NIO编程的根底
Selector会一直轮询注册在其上的Channel。
如果某个Channel产生读写事件，就代表这个Channel是就绪状态，会被Selector轮询进去。
而后依据SelectionKey能够获取就绪Channel的汇合，进行后续IO操作。
一个Selector能够轮询多个Channel，JDK是基于epoll代替传统的select，所以不受句柄fd的限度。
意味着，一个线程负责Selector的轮询千万个客户端，
AIO
NIO2.0引入了新的异步通道的概念，并提供了异步文件通道和异步套接字通道的实现
通过java.util.concurrent.Future类来示意异步操作的后果。
在执行异步操作的时候传入一个java.nio.channels
CompletionHandler接口的实现类作为操作实现的回调
NIO2.0的异步socket通道是真正的异步非阻塞IO。
同步socket channel：SocketServerChannel
异步socket channel：AsynchronousServerSocketChannel
它不须要通过多路复用器（selector）对注册到外面的通过进行轮询操作，就能够实现异步读写。
AIO和NIO最大的区别在于：异步Socket Channel是被动执行对象
NIO须要咱们把channel注册到selector上进行程序扫描、轮询
AIO则是通过Future类，实现回调办法：completed、failed
4种IO比照
IO模型次要是探讨2个维度：
同步/异步
阻塞/非阻塞
同步/异步的判断规范次要是：Channel的问题
阻塞/非阻塞的判断规范次要是：selector的问题
阻塞的关键点在于：建设连贯和数据传输
BIO（阻塞）意味着在实现建设连贯（accpet）动作之后，能力进行后续操作
NIO（非阻塞）在解决客户端的连贯时，能够将对应的channel注册到Selector上，此时我不论他好了没有，我有Selecotr来帮我去扫就绪态的channel，所以他是非阻塞的
异步非阻塞IO
异步非阻塞IO：AIO
有的人也叫JDK1.4推出的NIO为异步非阻塞IO
然而严格来说，它只能被称为是非阻塞IO，并不是真正意义上的异步
后期selector的底层是通过select/poll来实现的，尽管是用epoll代替了select/poll，下层的API没有变动，只是一次NIO的性能优化，仍旧没有扭转IO的模型
在JDK1.7提供的NIO2.0新增了：异步套接字通道，他才是真正的异步IO。
多路复用器Selector
Selector的外围性能：就是用来轮询注册在它下面的Channel
当发现某个就绪态的Channel，就会找出他的SelectionKey，而后进行后续的IO操作。
后期的时候JDK1.4，selector底层是基于select/poll技术实现
前面优化，应用epoll来代替
伪异步IO
只是在线程层面上进行了一次优化，IO模型并没有扭转
通过解决工作Task队列+线程池解决申请的形式来优化资源