针对客户端，当在发送文件时，如果卡顿，怎么办，同时想聊天，当时程序我是基于多线程实现的，在客户端里，聊天时启动一个线程，传送文件时，启动另一个线程，所以在客户端并不会影响，面试官就说知道了，但是，针对服务器的性能优化，我做的不好，针对每一个客户端开启线程，造成服务器压力过大
问题
网络通信是基于阻塞式API的——即当程序执行输入，输出操作以后，在这些操作返回之前会一直阻塞线程，所以服务器端必须为每个客户端提供一个独立的线程来进行处理。当服务器端需要同时处理大量客户端时，这种做法会导致性能下降，使用NIO API则可以让服务器端使用一个或者有限的几个线程来同时处理连接到服务器端的所有客户端。
上图中有两个关键类：Channel 和 Selector，它们是 NIO 中两个核心概念。我们还用前面的城市交通工具来继续比喻 NIO 的工作方式，这里的 Channel 要比 Socket 更加具体，它可以比作为某种具体的交通工具，如汽车或是高铁等，而 Selector 可以比作为一个车站的车辆运行调度系统，它将负责监控每辆车的当前运行状态：是已经出战还是在路上等等，也就是它可以轮询每个 Channel 的状态。这里还有一个 Buffer 类，它也比 Stream 更加具体化，我们可以将它比作为车上的座位，Channel 是汽车的话就是汽车上的座位，高铁上就是高铁上的座位，它始终是一个具体的概念，与 Stream 不同。Stream 只能代表是一个座位，至于是什么座位由你自己去想象，也就是你在去上车之前并不知道，这个车上是否还有没有座位了，也不知道上的是什么车，因为你并不能选择，这些信息都已经被封装在了运输工具（Socket）里面了，对你是透明的。NIO 引入了 Channel、Buffer 和 Selector 就是想把这些信息具体化，让程序员有机会控制它们，如：当我们调用 write() 往 SendQ 写数据时，当一次写的数据超过 SendQ 长度是需要按照 SendQ 的长度进行分割，这个过程中需要有将用户空间数据和内核地址空间进行切换，而这个切换不是你可以控制的。而在 Buffer 中我们可以控制 Buffer 的 capacity，并且是否扩容以及如何扩容都可以控制。
