BIO与反应器模式
BIO（同步阻塞IO）
我们熟知的Socket编程就是一种BIO，一个socket连接一个处理线程（这个线程负责这个Socket连接的一系列数据传输操作）。阻塞的原因在于：操作系统允许的线程数量是有限的，多个socket申请与服务端建立连接时，服务端不能提供相应数量的处理线程，没有分配到处理线程的连接就会阻塞等待或被拒绝。 比如说，当我们最开始使用Java编写网络请求，都是建立一个ServerSocket，它负责绑定IP地址，启动监听端口；然后，Socket负责发起连接操作，连接成功建立后，双方通过输入输出流进行同步阻塞式通信；如果没有成功建立，要么等待，要么被拒绝。即：一个连接，要求Server对应一个处理线程。 简单描述一下BIO的服务端通信模型：采用BIO通信模型的服务端，通常由一个独立的Acceptor线程负责监听客户端的连接，它接收到客户端连接请求之后为每个客户端创建一个新的线程进行链路处理每次处理完成后，通过输出流返回应答给客户端，线程销毁。即典型的一请求一应答通信模型。
该模型最大的问题就是缺乏弹性伸缩能力，当客户端并发访问量增加后，服务端的线程个数和客户端并发访问数呈1:1的正比关系，Java中的线程也是比较宝贵的系统资源，线程数量快速膨胀后，系统的性能将急剧下降，随着访问量的继续增大，系统最终就死掉了
反应器(reactor)模式
使用单线程模拟多线程，提高资源利用率和程序的效率，增加系统吞吐量
一个老板经营一个饭店，传统模式：来一个客人安排一个服务员招呼，客人很满意；(相当于一个连接一个线程)后来客人越来越多，需要的服务员越来越多，资源条件不足以再请更多的服务员了，传统模式已经不能满足需求。老板之所以为老板自然有过人之处，老板发现，服务员在为客人服务时，当客人点菜的时候，服务员基本处于等待状态，(阻塞线程，不做事）。于是乎就让服务员在客人点菜的时候，去为其他客人服务，当客人菜点好后再招呼服务员即可。反应器(reactor)模式诞生了饭店的生意红红火火，几个服务员就足以支撑大量的客流量，老板用有限的资源赚了更多的MONEY