这次去 Gopher China 和不少老朋友见了个面，还有不少在微信上意识已久，始终没见过面的网友。同时也和各个公司的一线开发们聊了聊，相互交换了彼此应用 Go 时的一些心得和痛点。
综合近期理解的一些相干分享，我把到目前为止见到的，不那么常见的，各方对 Go 的优化和 hack 集中在这篇文章里。因为思考到一些公司状况比拟非凡，所以本文中列出的点就不标记是哪个公司做的了。将来他们感觉时机成熟应该也会本人进去做一些分享。
网络方面
以后 Go 的网络形象在效率上有些低，每一个连贯至多要有一个 goroutine 来保护，有些协定实现可能有两个。因而 goroutine 总数 = 连接数 1 or 连接数 2。当连接数超过 10w 时，goroutine 栈自身带来的内存耗费就有几个 GB。
大量的 goroutine 也会给调度和 GC 均带来很大压力。Go 底层的网络库和加密库效率也不是很高，所以在同类利用上和 C++ 等语言有较大性能差距 (内存、吞吐量)。
社区有不少应用裸调 Epoll 实现优化的库，就不给他们打广告了。因为用户的 syscall.EpollWait 是运行在一个没有任何优先级的 goroutine 中，当 CPU idle 较低时，零碎整体的提早不可控，比规范库的提早还要高很多。之前集体做过相干的测试，外围数的减少也会使零碎相应的提早大幅回升。
接下来不同的公司的优化思路就走向了两个方向：
- 批改 runtime，在 runtime 减少用户 Epoll 函数的回调。相似 runtime 本人实现的 netpoll 那样。这种形式会导致 Go 自身难以降级，必须跟着有 hack 的版本走。当遇到 Go 的 bug 时会比拟难堪。
- 把 c 实现的网络库当作根底组件，把 Go 实现的业务逻辑作为业务嫁接在 c 库之上。
Go 语言的强项就是在网络编程上，当初却逼得大家为了优化都须要去做对 runtime 的 hack，甚至嫁接其它语言，这不能不说有点悲痛。还是心愿将来官网可能有更好的底层根底工具来反对这种超高连接数的场景。
cgo
因为 c 历史悠久，所以对 cgo 的应用是难以避免的，集体见到比拟多的，比方做国际化需要必须要用到的 icu 库，只能用 cgo 来调。或者做 cv 的 opencv，也只能用 cgo。或者一些国密场景，也只能用 cgo。
但从 go 调用到 c，有一次栈切换，老本有些高，所以有公司实现了从 go 切换到 c 不须要切换栈的神奇调用形式，同时在栈上打标记，让 GC 只扫描 Go 的栈而不扫描 c 的栈。
go-plugin
官网提供的 go plugin 还是比拟难用的，比方要求编译版本必须对立；加载后无奈卸载等。
当初有公司基于 .got 表，实现了比官网的 plugin 更灵便的热加载，热卸载的动静库。
（这条我不太懂，所以只是据说，有问题欢送指出
汇编优化
Go 语言的编译后端都是 Go 本人实现的，没有借助以往的平台，如 LLVM。
有人将 C 语言编写的等价代码用较高的优化级别，如 clang -o3，编译为高度优化的汇编，再翻译为 plan9 汇编，整合成函数供 Go 利用调用，这样相当于在 Go 里享受了 llvm 平台的后端优化成绩。
runtime 批改
除了后面提到的网络编程时，epollwait 须要高优先级的 goroutine，在其它一些波及到工作散发，工作解决的应用程序中也须要相似的高优先级 goroutine。
所以有公司间接在 runtime 提供了接口，让用户能够通过接口来创立非凡优先级的 goroutine。
除了裸露接口外，对 runtime 的实现代码也是要做不少批改的。
通过 SSA 进行的动态查看
咱们晓得，以后社区的 golangci-lint 大多是用 Go 内置的编译前端来实现的，在编译后的 ast 上做一些逻辑，来提醒用户代码中可能存在的问题。
在一些较底层的编程场景，心愿可能毁灭所有的堆调配，所以他们通过查看生成的 SSA 中是否有 newobject 的调用来辅助进行代码的优化。
垃圾回收
Go 语言的垃圾回收没有分代，分代会波及到不同代际之间的对象挪动，从 Go 官网历史上的分享来看，Go 的开发者们对 non-moving 比拟执著。因为如果堆上对象会 move 的话，须要在读对象时开启 read barrier，简直所有场景都是读多写少的场景，这样会极大影响程序性能，所以官网当初在分代的研发上处于停滞状态。
国内某公司在之前官网分代 GC CL 的根底上实现了分代垃圾回收，不过因为看不到代码，不太分明他们最终在生产环境是否可能达到较好的性能改善。
总结
本篇中的内容都是简略的介绍，没有太多细节，如果感兴趣的读者比拟多的话，咱们后续把每一点都开展来讲讲~