Netty番外话

这一篇不涉及具体的Netty工作原理的内容，只是作为一个导读的内容来引导大家思考为什么要产生像Netty的框架。后面会写一些文章来探讨Netty的工作原理和源码实现。

多线程处理请求的模型

1. Thread per request
这种模型的结构如下：
//一个主控程序产生新的线程去处理逻辑
while(true){
    acceptConnect; //没有连接来就阻塞在这里
    if(hasConnect){
   newThread().start(); //开户一个新的线程去处理请求
}
}

优点：
编程简单，易用于并发量不是很大的情境中。
缺点：
随着线程数目不断增长，服务器的性能也随之下降，因为开启一个线程系统要消耗8KB的内存大小。

2. Thread per request (thread pool)
针对第一种情况，提出了线程池的解决方案，这样线程数目不会随着连接数的增大而线性增加。但是它也存在问题，如果线程数目大，
线程创建和线程上下文切换是一个非常大的问题，如果线程数目少，那么对于大量的请求而言，很可能是存在连接超时的现象。

其实在我们平时常见的通信中，通信会阻塞在两个地方：
一是：接受连接时，socket.accept()，没有连接来就等待；
二是：IO操作地，read(),write()，没有数据就绪就会等待
下面通过Event Driven模型来解决这个问题。

3. Event Driven
这种模型的结构如下：

while(true){
    //所有事件的触发是由操作系统来支持的
    if(hasConnectEvent){ //有连接就执行相应的操作，不会阻塞在这里
    doConnect();
}
if(hasReadData){ //有数据读就绪就执行相应的操作，不会阻塞在这里
    doRead();    //会有一个线程来处理
}
if(hadWriteData){ //有数据写就绪就执行相应的操作，不会阻塞在这里
    doWrite();   //会有一个线程来处理
}
}

这种模型就是所谓的NIO原型。这种模型在一定程序上很大的提高了并发量，但是它也存在自己的极限，那就是在读写线程中处理
速度要什么快，一般而言，线程数量达到100就很不错，如果10w并发量，那么每一个线程就要处理1000个连接，也即是每个连接
处理要什么快，如果是1s，那么不就完了，最后1000个线程要等1000s，10几分钟的时间是受不了的!