在如今的部署環境處處充滿多cpu如果項目之中不帶幾個執行緒都不好意思說自己寫的代碼可以高效率的執行。 特別是在遊戲服務端方面的。
那我們先來看看多執行緒如何在項目中得以進化的。
1， 最初的遊戲伺服器模型的單進程單執行緒模型
也就是說該模式下的服務連結是當用戶端client_1連結進去之後伺服器變阻塞處理client_1的業務直到完成返回並關閉連接， 這時下一個玩家才能連進來進行操作， 說白了跟單機遊戲沒什麼區別， 只要第一個玩家不下線， 下個玩家就沒法連進來， 一服一玩家這和單機沒多大的區別。
2， 執行緒的引入。 瞭解了單進程單執行緒模型的弊端之後開發人員開始引入了多執行緒模型， 就是每一個連結進來的使用者在服務端都為該連結開啟一個執行緒去執行
如此一來連結之間便不會相互阻塞等待， 這樣就解決了一服一玩家的尷尬局面。 但這又真的完美嗎？每當一個使用者連結進來就創建一條執行緒， 使用者斷開連結就關閉執行緒， 執行緒的開啟和關閉帶來的性能消耗其實是非常之大的， 這是該模式下的一個弊端。 還有一個便是一人一執行緒當人數很多時比如1000人那麼就得要創建1000條執行緒出來處理， 而一個伺服器不可能提供那麼多的執行緒給你使用， 相反如果執行緒數量過多其執行緒的上下文切換與其執行緒開啟關閉帶來的性能消耗遠大與多執行緒帶來的好處。
3， 引入執行緒池。 執行緒池的引入就是為了解決開啟、關閉、執行緒過多等問題。 執行緒池顧名思義就是提供一個池子裡面裝的都是執行緒， ， 執行緒的開啟、關閉都由執行緒池來處理， 但執行緒池中的開啟關閉執行緒並不是真的開啟和關閉， 而是一開始的時候就為執行緒池初始化一定數量的執行緒， 當有使用者的連結和操作時都只能共用這池子中的執行緒， 每當有用戶端進來就到池子中拿到當前空閒的執行緒來處理， 這個也就對應了執行緒的創建步驟， 而當每個操作完成或者有使用者關閉連結時就將執行緒回收放入執行緒池空閒著，
到目前為止很多的專案依然採用這種執行緒模式。
4， netty執行緒模型，
那既然執行緒池為我們提供了那麼多便利為什麼還要講netty的執行緒模型呢？
在這裡我們就不得不引入執行緒資料安全這個在多執行緒中無法避免又處處存在的話題， 我們先來看看2和3在執行緒安全問題上是怎麼處理的？
2的模式下因為一個使用者連結就創建一條執行緒， 也就是說該使用者從連結到關閉這整一個過程所有的操作都只有一條單獨的執行緒來服務，
我們會看到六個使用者連結共用一個裡面有兩條執行緒的執行緒池， 而這又是怎麼分配的呢？看下帶顏色的連線我們會發現當使用者連結進來的時候netty會均勻的從執行緒池中取出一條執行緒進行分配， 不管當前執行緒是否空閒。 這樣一來執行緒1以後就專門為用戶1， 3， 5的所有操作， 注意這裡是所有操作， 所有操作， 所有操作進行服務， 而執行緒2專門為2， 4，6使用者的所有操作進行服務，這樣一來每個使用者從連結到關閉過程中的所有操作都有且只有一條執行緒為其進行服務，這來也就解決了執行緒資料安全這一問題，又引入了執行緒池管理執行緒這一機制。看到這裡是不是感覺netty棒棒達？
簡單點，說話的方式簡單點，netty執行緒模型簡單來說就是一條執行緒服務多個連結，一個連結只有一個執行緒服務。一對多，多對一？
這一節我們先講講理論，下一節我們就上上真機貼貼netty執行緒模型應用到專案中的代碼吧！
最後 如果有什麼地方講的不對，你們來打的呀！^_^
4，6使用者的所有操作進行服務，這樣一來每個使用者從連結到關閉過程中的所有操作都有且只有一條執行緒為其進行服務，這來也就解決了執行緒資料安全這一問題，又引入了執行緒池管理執行緒這一機制。看到這裡是不是感覺netty棒棒達？簡單點，說話的方式簡單點，netty執行緒模型簡單來說就是一條執行緒服務多個連結，一個連結只有一個執行緒服務。一對多，多對一？
這一節我們先講講理論，下一節我們就上上真機貼貼netty執行緒模型應用到專案中的代碼吧！
最後 如果有什麼地方講的不對，你們來打的呀！^_^