前端就不说了，基本问题不评价，仅尝试分析后端几个可能的原因
- 技术栈传承问题，游戏服务器出现的很早很古老，过去很多公司都有一些自己封装的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内做）等等都是特定的。
