为何游戏服务端用 C++ 来写，是历史原因还是性能方面的考虑？

游戏也分不同领域，不同的游戏之间业务逻辑和适用架构区别很大，并不能一概而论。

比如对于大部分手游、页游来说，追求短平快的开发节奏也不要求太高的实时性和计算效率，C++在这些领域的使用属于杀鸡用牛刀。国内这些领域还采用 C++ 的团队，要么是技术决策者视野狭窄；要么是大厂成熟团队已有完善的遗留技术栈、工具链和人才储备，迁移到其他语言的收益相对不高，或是怕担转型决策风险等等；再有就是从大厂出去创业顺走了技术框架或迷信大厂经验的团队等。

题主特别提到 MMORPG ，此处就 MMORPG 这一领域为何普遍使用 C++ 进行简单讨论。

MMORPG主要是指在地图上实时战斗一类（比如 WOW、传奇等），不包括回合制 MMORPG （神仙道、梦幻西游等）。

常见 MMORPG 服务器在技术层面的特性需求：

• 网络IO密集。高频率的视野同步消息（一般在 10-60Hz 之间），与玩家数量的关系是 O(n^2) 的复杂度，对于一些侧重国战等玩法的 MMORPG 尤其压力山大。通常都需要配合相关视野管理算法来减少消息发包数量，甚至需要配合架构做广播的负载分流。
• CPU密集。MMORPG 的玩法规则都需要服务器做权威性的计算，简单些的也需要大量怪物的 AI 和寻路计算，以及实时战斗的逻辑和技能运算等等；一些先进的 3D MMORPG 服务器甚至整合了物理引擎，来做碰撞检测和校验。
• 实时性。此类游戏侧重实时战斗和交互体验，能容忍的响应延迟通常在 200ms 以内，即使可以通过客户端预演算进行缓和。考虑到网络延迟这个不能通过语言和架构来解决的要素，两次游戏逻辑更新发包的间隔最好控制在几十毫秒这一量级。（所以一些 GC 不太注重实时性的语言，可能会有潜在的负面体验影响）。
• 稳定性和容灾。常 Crash 的服务器，轻则影响玩家体验，重则导致公司倒闭。
• 开发效率。这个方面除了受语言特性本身影响，还需要考量其它要素，比如生态圈丰富程度（需要的功能可以容易找到稳定好用的库）、周边工具链完善程度、人员补充难易程度（是否是学校培训的主力语言、是否是领域比较主流的语言，或者是否足够简单好培训）、现有遗留人力和技术资源的价值等等。

C++ 和其它候选语言的比较

C++：

• 网络 IO：历史上这方面曾经是考量的主要因素，近年来几乎所有主流后端语言都封装有高效的网络 IO 库，C++ 已不具备独特优势。
• CPU 利用率：C++ 在这方面的优势不需要讨论了吧...
• 实时性：无 GC，内存分配延迟可控（内存池、预分配等），毫秒级延迟需求的高频交易都在用。
• 稳定性和容灾：用 C++ 写出长期稳定运行的服务器程序，对开发团队而言是件要求比较高的事情，尤其在逻辑复杂又变更频繁的前提下。语言本身也不保证内存访问的安全性，如果有内存写越界导致的 Crash 也很难定位。国内某大厂采用了分离数据和逻辑进程，通过进程间共享内存来通信的方式，来实现逻辑进程崩溃重启不丢失数据。不过这种做法有一定门槛，存在性能开销，而且对开发效率和灵活性也有比较大的约束，也不易整合第三方库，不能算是通用的最佳实践。
• 开发效率：如果有良好的内力和 C++ 编程素养，并且配合现代 C++ 的一些语法（auto、lambda、智能指针等），开发效率尚可算是勉强及格，但相对以下讨论的其他语言来说仍处于劣势，然而达到上述水准的人力资源成本却要比其它语言要高出不少（人员补充速度、培训周期和薪资）。综合而言，这方面可算 C++ 的一大短板。

那么，假设不采用混合语言的方案（C++ 配合 Lua 或 Python，或者多服架构不同服务器用不通语言 等），除了 C++ 之外还有哪些语言值得考虑？

考虑到 MMORPG 在 CPU 计算方面的压力，解释型语言暂且可以排除。

目前考察过的备选方案，主要有 Java、C#、Go、Rust。

Java：

优点：

• 生态圈成熟，库丰富。
• Netty 网络库性能强悍。
• 不爽语法还可以用 scala 和 kotlin...

缺点：

• 除了原始类型外，不支持自定义值类型。而且泛型是以类型擦除的方式实现。这样的特性导致了：1.难以把数据连续紧凑地进行表示来优化算法的缓存命中率，比如2D地图的每个格子坐标都是个object，寻路算法呵呵。3D 场景的碰撞体每个顶点都是个object，物理引擎呵呵。2.对原本对实时性不甚友好的 GC 造成了更大压力。
• 成熟的 JVM 实现并不怎么侧重 GC 的实时性。如果触发了百毫秒以上的世界冻结 GC 延迟，所有在线玩家都会受到影响。
• JIT 在预热不足的情况下，偶尔会导致性能曲线不平滑，引入预料之外的响应延迟。

C#：

优点：

• 开发友好，语法糖甜。
• 有真正的泛型和值类型。特定算法好优化。

缺点：

• 微软家的。微软家的。微软家的。跑在 Windows Server 下没什么问题，然而抛开授权费不谈，大部分主流的开源好物都是优先考虑 Unix / Linux，比如 Redis（长期没有 Windows 版本的官方支持）、MongoDB（Windows 下性能要弱于 Linux 下），而且 Windows Server 的网络性能也要弱一些。除非解决方案都用微软全家桶，不然部署和运维就需要同时维护两个平台...至于 Mono，跟 JVM 比起来就像玩具。只能期待 Rosalyn 成熟了。（目前项目正在用 .Net Core，实现游戏逻辑跑在Linux下问题不大，一些跟操作系统联系比较紧密的底层功能还是用了C++）
• GC 实时性类似 Java。

Go：

优点：

• 语法简单易掌握。
• 开发体验友好。
• 有值类型。
• 新版本的 Go，GC 实时性良好（1.8 号称 STW 控制在 1ms 以内）。

缺点：

• 没有范型，某些地方需要转型成 interface{}，不过编译器会做逃逸分析，不必要的地方不会自动 boxing，影响不算太严重。

Rust：

优点：

• 运行效率比肩 C++。
• 语言特性优秀。
• 编译期保证了内存安全，没有 GC 开销。
• 编译期保证线程安全，可以放心大胆地并发，容易写出高效的多线程代码（不过死锁是需要自己避免的）。

缺点：

• 上手曲线较陡。
• 太年轻，生态圈尚未成熟。
• 较小众，人员补充困难。

大部分 MMORPG 主要采用 C++ 并不是没有原因 ，虽然历史原因的比重不小。然而如果要在什么都没有的情况下，从零开始开发 MMORPG 服务器，采用 C++ 并无必要。抛开人才储备的方面不谈，Go 算是目前开发 MMORPG 服务器各方面特性都比较匹配的选择：无论开发效率还是运行效率，以及工具和人员培训速度等等。如果是技术导向的团队，可以试试 Rust。C# 和 Java 也是不错的选择，虽然有些特性不是很好满足，但也足够支撑一款游戏成功了（如果不追求提供极致的平滑体验的话）。

至于 C++，在具备一些前提条件的情况下可以考虑采用：已有成熟 C++ MMORPG 代码框架；已有 C++ 写得 666 的技术团队；不差钱也不赶进度，就要质量稍高一些的流畅体验；需要整合一些 C++ 库等。不过即使如此，C++ 也推荐搭配其它语言使用（比如早几年常见搭配 Lua，主要用来提高迭代速度和开发效率，并且一定程度上可以支持热更）。

目前几乎没有纯粹的 C/C++开发游戏服务端的。

早年开发游戏必须用C++，这没得说，2000-2004年，java还没有nio，其他动态语言不抗重负，只能C/C++能开发出完整可用的游戏服务端。直到2005年，韩国的游戏很多都还是纯C++写服务端，金山之前也开发过很多纯粹C++的游戏服务端，后来大家都切了。

现代选择有很多：java + javascript, c+python, c+lua, scala, go, erlang。面向性能的服务器用 java，面向逻辑服务器 python，面向高并发的会选择 scala，次一级高并发或者性能测试程序（机器人）会选择 gevent。那是不是就不用C++呢？用 C来做网络，不用C++，但是C的比例在所有代码中占比有限。

这是否意味可以放弃C/C++了？也不是：C语言是一把锋利的匕首，而现代动态语言是一把长剑。平时匕首可以藏在身上，大部分时候用长剑披荆斩棘就够了，但当碰到坚硬的石头，长剑不管用了，那么拿出匕首来果断的切碎他。

对于一个成熟领域而言，建议是尽量用更高级一点的开发语言，因为游戏开发很多核心技术都有了较为妥当的解决方法。大量的服务端逻辑其实都是在等待，等待网络，等待数据库，这种情况下用C得不偿失。但是服务端有一些地方还是躲不开C/C++，比如当服务器涉及到 3D计算的话（国内很多2D服务端，国外很多3D服务端），大量的矢量矩阵，除了用C++封装出一套好用的数学库外，即便直接用java写，那也是很麻烦的。再比如现在快速动作越来越多，为了让玩家操作更流畅，需要基于 UDP快速可靠协议，协议开发用 java或者scala，性能上是没办法满足要求的，况且协议实现后要和客户端通信，没法让所有客户端跟着一起用java/scala。再比如某些cpu密集的抽象度高的模块，如 aoi或者 ai模块。

对于一个新兴领域而言，C/C++很多情况下是别无选择的东西。比如移动化浪潮刚起步的时候，还没有啥 cocos或者 unity真要开发游戏，必须迅速的使用起 OpenGL ES和 OpenSL，然后再叠加某一脚本，以快制胜，第一批移动浪潮上发财的就是这些游戏。又或者，可以根本躲开，先不介入，等到几年后cocos和 unity成熟了，在介入用lua / C#写程序。再比如服务端如果离开熟悉的游戏和web，去开发一个陌生的领域，如流媒体服务，会发现这怎么和10年前的游戏一样呀，什么高级工具都不给用用，这时可以再等个四五年应该高级工具会出现，异或想领先别人时，就果断的拿出 C/C++来解决之，这就是C独有的开拓新领域能力。

大部分答案都是非黑即白，非此即彼。不要只会C不会动态语言，避免成为一个傻逼；也不要只会动态语言不会C，避免离开熟悉的温室就活不下去。对于一个新手而言，如果什么都没学过，建议是先用快速开发的东西，把项目弄起来再说，有精力有机会的情况下，也不能完全放弃一些基础的东西，让自己残缺了。

PS：在相同架构下，就纯粹性能而言，各种语言性能差距到底是多少呢？如果只开发回合制这些慢节奏游戏，或者HTTP接口，大部分情况都在等待数据库等待用户消息的话，差别确实不大，的确可能5%都不到。如果cpu密集了，那么可以参考下面的图表，总体来说是10-50倍的性能差别：

有人问，说了半天，这个也不行，那个也不完美，而时间有限，有没有一个更经济实惠的方法呀？如何才一次性达到彼岸呀？时间有限项目吃紧有没有更好的选择？说有！那就是 java。国内游戏开发绕来绕去还是脚本+C+erlang+go，难道大家就不会其他东西了么？大部分可以的情况下，除了非用C/C++，推荐各位认真考虑下 java，这个性能上最接近C的东西，能承当大部分cpu密集型事务，却又不会象c那样 crash了找都找不到问题在哪里。同时面向高并发时基于原生jvm的 scala可以提供类似 erlang的简单方式，函数式编程 & 大规模并发协程 & actor；同时 java可以很方便的同 javascript结合，js的速度应该是动态语言里面最快的吧。再者 java还有 groovy，可以提供 python/ruby的泛型编程，用超高的开发效率和 python/ruby媲美，同时还能和 scala 结合实现高并发。最重要的是写 java好招聘，到处都是写 java的工程师，大部分语言级的培训都可以省略了。

国内游戏开发者很多拒绝学习 java，因为很多开发者自己是碰都没碰过。现在拒绝 java的人，大部分只是在游戏圈子里面打转的人，偶尔开发下 web，缺乏其他行业和领域的经验。看看除游戏外，当今多少世界级的开源服务器是用 java开发的？游戏就真有那么特殊么？看不是，国外大把java开发的游戏服务端，各位如果知道游戏服务端领域有啥 java技术栈解决不了的事情，麻烦告诉一声。再看看java上下游的 scala, javascript, groovy这些东西。所以建议各位，有空有条件的情况下，认真考虑下 java技术栈，世界很大，不是只有游戏；即便游戏，现在的开发方法真的对吗？