Socket IO與NIO(四)

阻塞IO和非阻塞IO

若是要到達百萬級別，那麼消耗的硬件資源時很是高的，咱們分析消耗性能的一個點是IO模塊，也就是阻塞IO的問題，由於阻塞IO的存在，致使 咱們只能使用一個線程去進行等待，而咱們使用線程的時候，會額外的消耗一部分線程資源，這部分線程資源也會引發CPU的調度問題，若是說 咱們的數量爆發，到達必定的數量以後的話，咱們當前的鏈接數量若是已經到達到了上萬級別，那麼這個時候其實消息發送是很是頻繁的，而若是 這個時候咱們有大量的時間處於一個線程的切換上面，那麼這一部分時間實際上是徹底被浪費掉了，咱們要作的是把線程的切換儘量的減小，讓CPU 去作真正的一個數據處理的一個消耗。

咱們每一個客戶端到的，都給他建立了一個線程去作read write close操做，那這部分操做呢，其實大部分狀況下都是出於一個阻塞狀態，也就是 阻塞到了咋們的一個read或者是write，這個時候咱們線程其實什麼事情都沒幹，他僅僅作的一件事情就是去等待CPU調度，而CPU每次調度過來的 時候，他會掃描到咋們的線程上，發現咋們的線程沒有去取消他等待任何的一個觸發機制的存在，也就是說數據並無到達，那麼這個時候並不會 取消他的等待，這個線程還會繼續等待。此時CPU看似沒有消耗，但CPU要消耗一個線程與線程之間的一個切換，一個掃描的時間，這個時候CPU其實 有一些額外的時候花費在了線程掃描和線程切換上面，以及若是有信息達到了，A線程有數據到達，那麼此時會從阻塞的read到執行狀態，可是一旦 咋們的線程從阻塞到執行狀態，而咱們又只有一個CPU調度狀況下，那麼必然存在CPU正在執行的任務和如今待執行的任務的一個切換，那這個時候 兩個任務都執行，但又只有一個CPU存在，那麼此時CPU能幹的事情是切換運行這兩個任務線程，那麼切換運行是屬於內核當中的切換，而此時的切換 消耗是比較高的，由於他要從用戶執行狀態切換到系統級別的一個內核態，而從用戶狀態切換內核態之間的一個狀態切換會消耗大量的時間，而 這些時候都是能夠避免的。減小一個線程的數量也就減小了一個狀態轉換的時間消耗，還能夠減小CPU掃描線程狀態的時間。 從內存狀態來講，每個線程建立的時候，必然存在維護這個線程的一系列狀態的一些參數，好比說維護狀態是否運行，維護這個線程是否處於運行 以及他的一系列IO的調度，還有咋們和用戶態 內核態之間的一些鏈接關係上的一些參數的維持，那麼這些東西其實都是輸入咋們線程的。你建立 線程達到必定數量以後，那麼這部分的內存累計其實很是可怕的，一個線程內存累計很是上，在1.4之前咱們的線程大概會佔用1M左右，那麼甚至 在老版本上回暫用2M左右的內存，雖然咱們如今測試下來到咋們java8甚至java9上面一個線程建立的消耗是很是低的 也就幾百k，可是這個幾百k 到達上萬級別的時候，其實累加起來也是比較大的消耗，那麼這部分消耗徹底能夠用來作數據處理。

非阻塞IO線程優點

全部客戶端到達以後，服務器都會收到一個到底的事件，例如說A客戶端到達了，那這個時候服務端會收到一個客戶端到達事件，此時會和客戶端 進行一個鏈接創建，創建好了以後，我此時僅僅只是說我要註冊一下和A客戶端這個鏈接通道上面的觀察，觀察什麼呢？觀察咋們的事件，也就是 讀事件，就是說當A客戶端有數據到達的時候，你再來回調我，沒有的時候就不要回調我，也不要阻塞我。服務器端線程其實只有一個，也就是 主線程，主線程在運行的狀況下，首先會註冊一個說有哪些客戶端到達，而後每一個客戶端到達以後，僅僅只是給每一個客戶端都註冊說你有數據到達 的時候在通知我，以後主線程繼續幹他的監聽，監聽有沒有事情到達。這個時候假設A計算機給服務器發送消息了，咱們會多建立一個線程嗎？ 不會！咱們在和A計算機創建好鏈接以後，我緊跟着幹了一件當你有數據到達的時候，你再來通知我，註冊好了以後，我此時處於一個等待事件的 過程。你創建鏈接，這是一個事件，你有數據來也是一個事件，我能夠把這些事件都放到主線程當中去等待。主線程說A計算機有數據來了，這個 時候我將A計算機的數據讀取完了，讀取完了以後，我又回到等待事件的流程。這個時候B計算機來了，咱們把B計算機數據處理完了以後，咱們又 無論了，又繼續等待。在這樣的一個狀況下，咱們的主線程實際上是一個串行的工做模式，串行的去處理全部計算機的消息以及他的回送和讀取的操做。 這種狀況下主線程是很是頻繁的，他作的事情很是多，他作了鏈接客戶端，創建客戶端之間的一個關係，而後讀取客戶端的數據，而且在必定的 狀況下咱們可能會把數據回送到對應的客戶端，這是主線程要作的事情，咱們使用一個線程就完成了1000個客戶端的鏈接，這是很是高效的。這個 性能不是說信息處理速度的性能，而是說線程處於一個繁忙狀態，充分利用了計算機的當前線程的資源。可是咱們不能說充分利用了整個計算機的 資源，由於整個計算機不僅一個CPU，只用一個線程確定是弱化了計算機的能力，此時咱們會把事情進行必定的分組，而後使用不一樣的線程池去 作對應的事情，從而知足計算機性能的調度。 服務器能夠用一個線程就完成上千上萬個客戶端的鏈接，固然這樣的狀況下，好比線程在讀取A計算機數據的時候，就算B C計算機到達了數據，那 這個時候僅僅只是你到達了數據，線程這個時候並不能去處理大家到達的數據，這就是他的劣勢。

非阻塞IO

NIO全稱：Non-blocking I/O。

JDK1.4引入全新的輸入輸出標準庫NIO，也叫New I/O。

在標準Java代碼中提供了高速的、可伸縮性的、面向塊的、非阻塞的IO操做。數據是面向塊的不是一個字節一個字節的處理，少了不少校驗。

NIO也並非一個很是好的設計，由於他有必定的缺陷。

阻塞IO的線程消耗：

當一個客戶端鏈接過來時，server.accept()會從阻塞態變成一個執行態，執行的時候會獲得一個Socket，這個時候作的一件事情是把這個Socket 當前的inputStream和outputstream轉換成了2個線程，或者說最少也有一個線程inputstream讀取數據，由於outputstream不是每時每刻都須要 寫入，那麼咱們的寫入能夠放在真正須要寫入的時候，使用一個線程池來作到這樣一個效果，可是讀取操做是必定會消耗的。

NIO family一覽

• Buffer 緩衝區：用於數據處理的基本單元，客戶端發送與接收數據都須要經過Buffer轉發進行。不能一個字節一個字節的處理數據，須要一個 東西來打包咱們的數據，這個就是buffer。
• Channel通道：相似於流；但不一樣於IN/OUT。
• Stream；流具備獨佔性與單向性；通道則偏向於數據的流通多樣性。
• Selectors選擇器：處理客戶端全部事情的分類器。非阻塞IO的事件註冊與產生是由selectors來管理的。

Charset擴展部分

• Charset 字符編碼：加密 解密。
• 原生支持的、數據通道級別的數據處理方式，能夠用於數據傳輸級別的數據加密 解密操做。

NIO-buffer

• Buffer包括：Buffer是一個父類 抽象類 ByteBuffer, CharBuffer, ShortBuffer, IntBuffer, LongBuffer, FloatBuffer, DoubleBuffer
• 與傳統的不一樣，數據寫的時候先寫到Buffer->Channel;讀取反之。
• 爲NIO塊狀操做提供基礎，數據都按「塊」進行傳輸。
• 一個Buffer表明一「塊」數據。

NIO-Channel

• 能夠從通道中獲取數據也能夠輸出數據到通道；按「塊」Buffer進行。
• 能夠併發也能夠異步讀寫數據。能夠併發往裏面寫數據，也能夠併發的從通道讀取數據，這個時候通常會存在一個問題，一個Channel表明一個 鏈接，表明我服務器端的一個channel就表明和客戶端的一個鏈接，他分別有兩個東西一個是讀，一個是寫，當咱們使用多線程去進行寫的 時候，必而後會存在每一個線程在丟數據給他的時候，你確定是先丟一個Buffer給他，你A線程丟了一個buffer給channel，B線程丟了一個 buffer給channel，這個時候發送的順序是不定的，有可能B先被調度到了就先被髮送出去了，而後再發A的buffer，那麼客戶端接受的數據 也會是亂的，當你的數據是依賴於buffer順序的時候，不要併發讀寫操做。
• 讀數據時讀取到Buffer，寫數據則必須經過Buffer寫數據。
• 包括：FileChannel、SocketChannel、DatagramChannel等。

Selector註冊事件

• SelectorKey.OP_CONNECT鏈接就緒。客戶端想要鏈接到服務器的時候，鏈接是要通過3次握手，4次揮手。不管是NIO仍是普通IO，Socket的基本 原理是不變的。3次握手多是一個比較耗時的操做，由於在網絡比較差的狀況下，其實這個鏈接是必定耗時的操做，假如如今有個鏈接操做， 客戶端想要的是我想要鏈接服務器，可是何時鏈接好了再進行後面的數據處理，沒有鏈接好的話，我在界面上給顯示一個loading...， 此時咱們就能夠註冊一個OP_CONNECT事件。我先調用一次鏈接而且我調用鏈接以前，我先把本身設置爲非阻塞IO，而後進行一個鏈接，鏈接 的時候，我再註冊一個說，當我鏈接就緒的時候請你告訴我，我去幹其餘事情。而後鏈接好了，再回調回來講，這個事件鏈接就緒了，鏈接 就緒了以後，我就能夠作後面的數據發送或者是接受。當你要發送數據的時候，這時網卡也不必定在線，也有可能你要給他發送數據的時候， 網卡剛好是一個繁忙的狀態，你就是發不出去，就是要等，你發10個字節也有可能要等幾十毫秒以上，這個時間是不定的取決於網卡的繁忙 狀態，這個時候就須要註冊一個寫的事件。
• SelectorKey.OP_ACCEPT接受就緒。當客戶端發送鏈接到服務器端的時候，服務器端這個時候會收到客戶端的鏈接請求到來，這個時候服務器端 能夠選擇拒絕客戶端鏈接或者是正常的創建好客戶端的鏈接。當客戶端鏈接創建好了以後，服務器端就會收到一個ACCEPT（鏈接就緒）， 服務器端天然也是同樣，服務器端本身先註冊一個當有客戶端鏈接就緒的時候，請告訴個人事情，當有客戶端鏈接上了以後，這個事件就會 觸發，服務器端就能夠獲得客戶端鏈接的Socket，而後進行後面的一些操做讀寫。後面的兩個操做就取決於網卡狀態了。
• SelectorKey.OP_READ 讀就緒 就是說有數據來了。
• SelectorKey.OP_WRITE 寫就緒 就是說當前網卡是能夠輸出數據的。

Selector使用流程

• open()開啓一個選擇器，能夠給選擇器註冊須要關注的事件。爲何不new一個Selector，由於Selector也是一個抽象類，有不少子類，內部是有 一個緩衝機制的，open()多是從緩衝當中取出來一個當前空閒的Selector給你使用。
• register() 將一個Channel註冊到選擇器，當選擇器觸發對應關注事件時回調到Channel中，處理相關數據。你註冊那4個事件的時候關注的是 channel的狀態。Selector不是一個觀察者模式，他是一個半觀察者模式，你僅僅只是能夠註冊這個事件，也能夠取消一個關注事件。可是 事件到達的時候，並不會直接回送給你，你須要本身去遍歷這個池子。你去遍歷的時候也就須要一個最基本的線程，因此說你最少須要一個 線程。
• select()/selectNow()一個通道Channel，處理一個當前的可用、待處理的通道數據。select()是一個阻塞操做，阻塞到真正有事件到達的時候。 有什麼事情到達呢？有一個channel的事件到達。咱們能夠在一個select上註冊不少個channel去關注不一樣的事件，好比第一個客戶端達到的 讀事件和第二個客戶端到達的寫的事件，註冊分別是不同的。調用select拿到的是一個集合。當第一個客戶端讀是可用的，第二個客戶端 的寫是可用的，select拿回來的就是2個元素的數組，而後分別把數組裏面的數據取出來講第一個Channel的讀是就緒的，這個時候我就去處理 第一個Channel的讀操做，第二個Channel的寫也就緒的，這個時候也處理它的寫操做。

Selector使用流程

• SelectorKeys()拿到當前就緒的通道，咱們select()的時候是一個阻塞狀態，阻塞事件到達，若是此時想要退出整個程序怎麼作？你是阻塞狀態 退不了程序。
• wakeUp()喚醒一個處於select狀態的選擇器。喚醒他，就算這個時候沒有一個可用的事件到達，他也能夠直接喚醒select狀態，這個時候select 返回來的數量是0。
• close()關閉一個選擇器，註銷全部關注的事件。

Selector注意事項

• 註冊到選擇器的通道必須爲非阻塞狀態。

• FileChannel不能用於Selector，由於FileChannel不能切換爲非阻塞模式；套接字通道能夠。文件通道，他可使用通道的方式去操做文件，也 就是說可使用快狀的方式去操做文件，能夠把一整塊文件放到Buffer當中，而後一整塊寫入到File，或者說從File當中讀取一整塊數據到 Buffer，而後再把Buffer數據拿出來用。你不能把FileChannel註冊到Selector上，你不能跟他說當前文件可讀的時候請你告訴我，當前文 件可寫的時候請你告訴我，文件何時可讀，他永遠的可讀，惟一區別是磁盤IO可能會受限於必定的IO速度，咱們磁盤的速度確定是低於 內存速度的，因此這個地方他必定是個阻塞狀態的。

• Selector SelectionKey Inetrest集合(當前全部的集合，你註冊一個Channel進去的時候，你不必定註冊一個事件，能夠註冊多個事件)、Ready集合(當前已經就緒的集合)。

• Channel集合。

• Selector選擇器。

• obj附加值。你能夠在註冊這個事件的時候，能夠傳一個事件的附加值進去，當觸發的時候，你能夠把這個附加值拿出來直接使用，好比你想要發送 一個數據，但此時IO寫並非可用的，你能夠去註冊一個說當你可用的時候告訴我，同時你把想要發送的數據放到obj裏面，當他可用的時候 obj就攜帶回來了剛剛你想要發送的數據，能夠直接把obj數據發送出去。

Channel輸出數據到Buffer，Channel他不必定對應到一個Buffer，他能夠輸出到多個不一樣的Buffer。 Channel從Buffer讀取數據也是同樣的，能夠從多個不一樣的Buffer都把數據寫給一個Channel。

現有線程模型

Selector進過accept以後出現A Channel和B Channel，這兩個鏈接創建好以後，看下線程消耗。首先第一個線程用來輪訓selector狀態，直到 有哪些客戶端進行鏈接，而後把鏈接爲SocketChannel，SocketChannel裏面有兩個東西，一個是用來讀的Thread和一個寫的Thread，因此一個 channel對應2個Thread，同理B Channel也同樣。在創建兩個鏈接的狀況下，咱們一共創建了5個線程。咱們在進行發送消息的時候，還有一個輪訓 和一個轉發。因此在線程消耗上能夠看出是很是高的。

單Thread模型

一個單線程就完成了全部的客戶端消息收發，可是他的麻煩點在於你只有一個線程，一旦這個線程正在處理某一個客戶端的讀取消息的時候，這個 時候咱們是沒法接受新的客戶端的鏈接，同時也沒法承擔對其餘客戶端的消息輸出，他必定是一個串行的。這個單線程是很是繁忙的，他幾乎佔用 了全部CPU的資源在進行一個輪訓，可是他的效率並不高效，由於CPU並非只有一個核心，並無發揮CPU多核的優點。同理，咱們由於輪訓是一 個串行的模式，就會致使咋們的後續的一些操做是否要阻塞，好比咱們在進行讀或者寫的時候，若是這時候耗費了大量時間，這會致使咋們新來的 鏈接沒法創建，甚至說咱們某些客戶端的一個等待處於一個長時的等待，這種狀況其實會致使不少問題，因此不建議採用單Thread模型方式。

監聽與數據處理線程分離

AccepterThread作的事情是監聽ServerSocketChannel新客戶端的鏈接，而且完成鏈接的過程。鏈接創建好以後就是SocketChannel，把Socket Channel的一系列IO輸出或者是輸入操做，咱們放到一個線程池當中，ProcessorThread是一個Processing loop操做，你可使用一個線程也 可使用線程池來作。使用一個線程就意味着大家全部客戶端的消息收發是串行的。那麼使用一個線程池呢，會盡量保證部分客戶端的處理是 一個分離的過程，但也並不能保證他必定是一個並行的過程。 此時若是有一個線程池有4個線程，有20個客戶端鏈接，而且同時具備20個客戶端 都在給你發消息，那麼這個時候，你的線程池僅僅只能處理4個線程，其餘的必需要等待前面的完成以後才能進入到線程池裏面處理，這個時候 也是一個並行與串行結合的一種東西。咱們不須要給全部的客戶端都分配一個線程，由於在某一個時刻，計算機網絡帶寬是有限制的，並非全部的 客戶端都須要在這一時刻處理數據，因此咱們僅僅只須要一個線程池儘量的處理高併發這樣一個客戶端之間的數據。