線程是服務器的一種希有資源，它的創建，銷毀，切換都需要很多服務器的其它資源。而在游戲服務器中，只要沒有在多線程之間有共享數據的操作，都是可以並發的，即可以是多線程操作的。比如不同用戶各自的操作處理，或同一個用戶的數據更新到數據庫的操作等等。那為了提高並發性，是不是線程越多越好呢？多少才合適呢？先不說游戲服務器的特殊性，就按普通的服務器業務來說，最合適的線程數是多少呢？說到線程，那一定是和cpu核數相關的。在其它的文章里面，我們可以看到這樣的結論：
一般說來，大家認為線程池的大小經驗值應該這樣設置：（其中N為CPU的個數）
如果是CPU密集型應用，則線程池大小設置為N+1
如果是IO密集型應用，則線程池大小設置為2N+1
但是，IO優化中，這樣的估算公式可能更適合：
最佳線程數目 = （（線程等待時間+線程CPU時間）/線程CPU時間 ）* CPU數目
因為很顯然，線程等待時間所占比例越高，需要越多線程。線程CPU時間所占比例越高，需要越少線程。
下面舉個例子：
比如平均每個線程CPU運行時間為0.5s，而線程等待時間（非CPU運行時間，比如IO）為1.5s，CPU核心數為8，那么根據上面這個公式估算得到：((0.5+1.5)/0.5)*8=32。這個公式進一步轉化為：
最佳線程數目 = （線程等待時間與線程CPU時間之比 + 1）* CPU數目
綜上所看，線程數並不是越多越好，而是要適量。比如如果游戲服務器是使用netty開發的，那么boss線程一般1~2個就足夠,而work線程可以根據服務器配置和上面的公式算出最合適的線程數。我們知道，在netty的業務操作中，也就是Channel的Handlerr操作中，不應該有IO操作，因為IO操作時間長，而所有的channel是共用work線程的，如果有IO操作，就會卡往其它的請求處理。所以一般來說，游戲服務器中的數據應該提前加載到內存中，這樣即可消除IO操作。
那么問題來了，游戲服務器中不可能沒有IO操作，比如登陸時數據庫的查詢，部分重要數據的即時更新到數據庫，或向其它服務發送http請求等等。這該怎么處理呢？其實我們發現，這些操作都是可以並行的，他們之間沒有依賴關系也沒有共享數據，即沒有什么順序要求（當前同一個用戶的對數據庫的操作應該是有序的，同一個用戶的操作應該放到同一個單線程池中處理，當然多個用戶可以共用這個單線程池，使用netty的線程模型即可，EventExecutor）。所以我們可以把這些操作放到一個線程池中。線程池的數量和每個線程池中的線程數我們可以很好的把控。這個可以封裝到服務器的框架里面。
技術交流，歡迎留言，也可添加QQ交流群：66728073，197321069