在游戲服務器中，線程的管理是重中之重，因為線程數量不能太多，所以為了提高游戲服務器并發(fā)性，就需要在線程處理業(yè)務的速度要快，不能長時間卡住線程，比如，不能有網絡io,磁盤IO等耗時的操作。所以我們會把有限的線程數進配按需分配。線程的主要分配方式如下：

1，與客戶端的IO線程

負責接收客戶端消息，和向客戶端發(fā)送消息。

2，處理玩家業(yè)務的邏輯線程

負責業(yè)務邏輯的處理與計算。

3，處理rpc或數據庫同步的網絡線程。

負責不同服務之間的通信

4，處理日志的磁盤IO 線程

相應的線程分別做自己該做的時間。但是這時候問題來了，既然按用途分配了這些線程，那不可免費的就會出現不同線程之間的數據交互了。舉個例子來說，比如玩家登陸和排隊，假如說一個區(qū)一臺物理機，處理與客戶端的IO線程占1個，業(yè)務邏輯線程16個，請求數據庫的線程3個。其它的先忽略不算。這個時候，服務器收到客戶端登陸的請求，業(yè)務線程收到這個請求，第一件事情是去數據庫查用戶的信息，因為業(yè)務邏輯線程是多個用戶之間共用的，所以你不能在這里等待數據庫請求的返回，要不然會卡別的業(yè)務邏輯處理。最好的做法就是，把這個請求封裝成一個事件，發(fā)送到數據庫同步線程中去處理這個事。等待數據庫線程處理完了，再把結果告訴業(yè)務邏輯線程，然后再處理業(yè)務，這個時候處理的數據都在內存中了，所以速度非�？欤�處理完之后再返回客戶端。

有人說，那這樣還不是卡登陸嗎?是的，必卡登陸，因為處理數據庫的線程就那么3個。對于mysql的查詢性能測試如下：

我們3個線程按1500個計算，那么也只有登陸并發(fā)達到1500的時候，才會覺得服務慢一些，(實際情況可能會再底一些)，如果并發(fā)能達到這么高，說明游戲很火了，可以等待數錢了。如果再多的人，我們就可以使用排隊的功能的。可以查詢到數據庫線程中正在等待執(zhí)行任務的數量，如果達到某個值，就可以在業(yè)務服務中給客戶端返回正在排隊的，讓客戶端過一會再來請求即可。

回到正題，那么游戲服務器線程之間該如何傳遞數據呢，可能每個人的做法不一樣，這里只列舉中一個，希望給大家給帶來些參考，就當是交流學習了。如果你有更好的方法，也希望您評論分享。

在Java中，多線程之間交互數據，即A線程給B線程一個請求事件，A線程還要獲取B線程的執(zhí)行結果，比如登陸，請數據庫線程去查庫，查完之后告訴邏輯線程。Java提供了一個Future/Callable的機制，詳細大家可以自動百度它們的用法，但是它們有一個缺點，就是A線程在獲取結果時(調用future.get())的時候是同步的，如果B線程沒有執(zhí)行完，還是會卡A線程。這顯示不是我們想要的。對于這一點，我們偉大的異步框架，netty的作者給出了一個解決方法，那就是Future / promise模式。這里對它的源碼暫不做分皙了，有時間另寫文章說明吧，有興趣的同學可以自己查看。這里只說一下它的用法。

此代碼只是模擬，真實應用中還需要自己設計，首先是數據庫查詢的管理類：

然后是業(yè)務管理類：

通過這個例子，其它關于多線程交互數據的功能實現，大家就可以舉一返回三了。

天下數據為網絡游戲營運公司提供了高性能、高可用、可伸縮性、高性價比的IDC數據中心解決方案！詳詢在線客服！

本文鏈接：http://m.51huadong.com/servernews/11002736.html