Go游戏服务器开发的一些思考（五）：goroutine看似美好的陷阱

goroutine是什么

先来看一段摘自go官方《Go 语言之旅》中对goroutine的描述：

goroutine 是由 Go 运行时环境管理的轻量级线程。go f(x, y, z)开启一个新的 goroutine 执行f(x, y, z)f ， x ， y 和 z 是当前 goroutine 中定义的，但是在新的 goroutine 中运行 `f`。goroutine 在相同的地址空间中运行，因此访问共享内存必须进行同步。sync 提供了这种可能，不过在 Go 中并不经常用到，因为有其他的办法。（在接下来的内容中会涉及到。）

有以上内容，我们可以得到很明确的几个信息：

• 轻量级
• 并发的
• 访问共享内存必须进行同步
• 提供了几种同步机制

来至Go的迷信

通过第一章中对 goroutine 的总结，它的好处是轻量级，更好用。用大白话说就是更高效，编写更无障碍。不像C中写个多线程还要了解一系列 thread api。

但是它在并发编程上还是绕不开并发的根源问题。即并发编程上最重要也是最难处理的部分：

• 同步问题
• 同步不当造成的死锁问题
• 同步不当多并发变摆设问题

逻辑串行 + IO并发

游戏服务端编程中，很多框架都流行这样一种模式： 逻辑串行 + IO并发。这种模式的提出 以及流行，不是空穴来风的。游戏服务端底层搭建到一定程度后，基本上就是业务逻辑开发了。如果业务逻辑程序员（往往是初级程序员），在开发有个功能时，都要时刻注意自己读写某个内存变量是否需要做同步处理时，这简直就是个灾难。

那个 逻辑串行 看上去 是否真的没什么效率呢。主要有以下原因：

• 逻辑运算再复杂也不会阻塞
• 对CPU的运行能力来说，不是大头
• IO、阻塞相关的底层库提供并发
• 复杂的游戏逻辑做并发开发，是个灾难
• 某些复杂的多方交互逻辑，到 ‘逻辑串行’这层，已经按序。不用 逻辑程序员处理 消息到达的时序问题

总结

Go语言很好用，这点毋庸置疑。但是Go语言没有脱离高级语言的范畴；同时 goroutine 也没有脱离并发编程的范畴。更好用的便利，负面影响就是毫无禁忌的滥用。这点是需要警惕的。

后记

随着对Go语言的goroutine 逐步加深了解，本篇文章所描述的是片面的。上述担心的问题，可以使用 go chan来避免掉。之后会写一篇博客，来介绍常见的几种使用go chan的模式来规避互斥量的使用。而goroutine的方便使用，对游戏服务端架构也会产生影响，适度的并发，可以让CPU的利用率得到更好的提升及编程上的便利。