前端就不說了，基本問題不評價，僅嘗試分析後端幾個可能的原因
- 技術棧傳承問題，遊戲伺服器出現的很早很古老，過去很多公司都有一些自己封裝的c++的網絡庫，其實大型遊戲遠比spring cloud這種更早就有了，中心排程伺服器+閘道器+各類互相依賴的業務伺服器了，內部協定也多從c++傳承過來的probuf或者就是把結構體傳來傳去的。過去top遊戲公司出來的人創業做遊戲開枝散葉等等，java根本沒機會。
- 過去java發展時期，還是多執行緒模型，nio+reactor是後來的事情，這個對於遊戲尤其是大型遊戲都是不可接受的，因為遊戲是標準的有狀態伺服器，解決問題的思路和 基於 JDBC做CRUD的業務系統完全不同。然後skynet等更優秀的框架也出現了，效能也很高。打個比方netty其實也不適合處理遊戲，要客製執行緒，比如業務執行緒不能簡單就一個執行緒池完事，netty的執行緒分配思路是一個連線一定是一個執行緒處理這樣可以避免使用者共享變量的沖突問題，但是對於遊戲而言，多使用者下房間，區域內的共享變量才是最關鍵的，最好都約束到一個執行緒來處理（僅簡單情況，更復雜的大型遊戲不了解不評論）。然後java這邊tomcat servlet spring之類的，對於遊戲並無明顯好處，tomcat預設是執行緒池模式就不是遊戲業務用的，spring這種預設new是單例的，其實和遊戲業務也完全不同，遊戲裏面存在的是大量有限狀態機物件，而不是CRUD裏面的單例service等等。
- 遊戲比較強調單機效能，因為是有狀態服務，對延遲也比較敏感，不適合業務系統的那種分布式，數據就在記憶體，往往一個區之類的就一個大記憶體多CPU的伺服器跑，為了延遲低，redis是極限，關系型數據庫一定是延遲寫的僅用來數據落盤，java 也許效能沒問題，但是同等的QPS下，用的記憶體和CPU一定比C++多。
- jvm的gc可能存在問題，但是其實是可能不一定，因為伺服器寫得好就可以做到少gc。但是gc會影響什麽呢？比如任何訊框同步的遊戲，肯定是不歡迎gc的，稍微長一點兒都有影響。
- 還有一些遊戲業務java能力不及（這部份是推測，實際的確沒測試過），比如碰撞檢測，java做的CPU和效率會比c++慢多少？c++必然有很多類似的基礎，java就算可以呼叫c++但是為何不直接用c++做？
當然現在java能不能承擔大型遊戲的後端呢？應該是可以的，畢竟java效能還及格，休閑棋牌即時性要求不高的其他遊戲必然是沒有問題的，但是大型遊戲行業慣性都不會采用java，一個專案組沈澱下來的東西很多，比如穩定的閘道器，大廳服，金幣/市場服，戰鬥服，充值閘道器，排程/中轉伺服器，內部自定的RPC協定，和客戶端的協定，防外掛的綜合機制和系列指令碼，開服關服運維流程與自動化指令碼等等，這些積累之前如果不是在java上，後面也很難改。至少我個人曾經見過類似的c++積累，不知道是來自於過去的巨人網絡還是什麽公司，網絡框架，定時器（遊戲和netty類似，定時器不可以跨執行緒，一般都是在loop內做）等等都是特定的。
