當我們接收請求的時候，實際上請求在到達我們的程序之前，會有一個請求隊列，所有請求都會先在請求隊列中
BIO：同步阻塞
在BIO中會使用socket.accept()方法來一個一個的接收請求，由於accept方法是阻塞的，所以當我們接收到一個請求後，會給這個請求獨立分配一個線程去處理這個請求，這種請求方式就是BIO
但是這裏會有一個問題，如果我的鏈接是個空連接，並沒有數據交互，他依然需要佔用一個線程，並且隨着連接數量變多，線程數量也會越來越多，服務器壓力越來越大。
NIO：同步非阻塞
NIO中有三個模型，分別是select模型，poll模型，epoll模型
- select模型
在select模型中，所有的請求都是由同一個線程接收，之後再進行不同的處理，這個線程就叫做多路複用器，在select模型中，把每一個請求鏈接都當作一個channel對象，然後將每個channe對象註冊到多路複用器中，然後多路複用器會對註冊進來的channe進行循環遍歷，當有數據到來時，會開啓一個新的線程，來對該channel進行處理。select在監聽channel對象是否有數據到來時，需要從用戶態內存拷貝該文件的文件句柄到內核態內存中，交由底層的系統來監聽，監聽之後再拷貝回用戶態中
這中處理方式就會對比BIO就會減少線程的佔用，因爲如果沒有數據交互，我是沒有必要開啓線程進行處理的
- poll模型
poll模型與select模型的處理方式是一樣的，區別就是poll模型的channel註冊是沒有數量限制的，但是select模型在註冊到多路複用器時，一個多路複用器最多隻能註冊1024個請求
- epoll模型
在select模型中存在兩個問題：
（1）多路複用器可以處理的請求數量過小，只有1024；
（2）select在監聽channel對象是否有數據到來時，需要從用戶態內存拷貝該文件的文件句柄到內核態內存中，交由底層的系統來監聽，監聽之後再拷貝回用戶態中，這樣需要進行兩次拷貝
針對第一個問題，epoll沒有這個限制，它所支持的FD上限是最大可以打開文件的數目，這個數字一般遠大於2048,舉個例子,在1GB內存的機器上大約是10萬左右
對於第二個問題，epoll模型增加了一個用戶態和內核態都可以進行操作的公共內存區域，只需要將channel對象拷貝到這個公共的內存中就可以讓底層系統進行監聽，不需要進行第二次的拷貝，提高運行效率
