本文永久链接 – https://tonybai.com/2021/08/09/when-variables-captured-by-closures-are-recycled-in-go 1. Go函数闭包 Go语言原生提供了对闭包(closure)的支持。在Go语言中，闭包就是函数字面值。Go规范中是这样诠释闭包的： 函数字面值(function literals)是闭包：它们可以引用其包裹函数(surrounding function)中定义的变量。然后，这些变量在包裹函数和函数字面值之间共享，只要它们可以被访问，它们就会继续存在。 ...
本文永久链接 – https://tonybai.com/2021/07/31/io-multiplexing-model-tcp-stream-protocol-parsing-practice-in-go 在《Go经典阻塞式TCP协议流解析的实践》一文中，我们基于Go经典的阻塞I/O模型实现了一个基于TCP流的自定义协议的解析。这种one-connection-per-goroutine模型的优点就是简单、好写以及好理解，降低开发者心智负担。但一旦连接数上来，goroutine的数量就会线性增加。当面对海量连接的场景，这种模型将力不从心：系统中将存在大量goroutine，goroutine调度和切换的开销过多。 那么面对海量连接场景，应该如何解决呢？业界成熟方案：使用I/O多路复用模型。了解Go net包实现的朋友想必都知晓Go在运行时底层使用的也是I/O多路复用，其实现为runtime中的netpoll。goroutine层面获得的net.Conn(无论是Accept的，还是Dial得到的)都展现出“阻塞”的特征，但这些net.Conn底层实现的fd(文件描述符)在netpoll中都是non-blocking(非阻塞)的，Go运行时负责调用epoll等多路复用机制监视这些fd是否可读或可写，并适时唤醒goroutine继续网络I/O操作，这种方式减少了系统调用，也减少了运行Goroutine的M(操作系统线程)因系统调用陷入内核态等待的频率以及因阻塞失去M而不得不去创建新线程的数量。 ...
本文永久链接 – https://tonybai.com/2021/07/28/classic-blocking-network-tcp-stream-protocol-parsing-practice-in-go 1. Go经典阻塞I/O的TCP网络编程模型 Go语言诞生十多年来取得了飞速发展，并得到了全世界开发者的广泛接纳和应用，其应用领域广泛，包括：Web服务、数据库、网络编程、系统编程、DevOps、安全检测与管控、数据科学以及人工智能等。下面是2020年Go官方开发者调查的部分结果： 图：2020年Go官方开发者调查之Go语言的应用领域(对比2019) 我们看到**“Web编程”和“网络编程”**分别位列第一名和第四名，这个应用领域数据分布与Go语言最初的面向大规模分布式网络服务的设计目标十分契合。网络通信这块是服务端程序必不可少也是至关重要的一部分。Go标准库的net包是在Go中进行网络编程的基础。即便您没有直接使用到net包中有关TCP Socket方面的函数/方法或接口，但net/http包想必大家总是用过的，http包实现的是HTTP这个应用层协议，其在传输层使用的依旧是TCP Socket。 ...
本文永久链接 – https://tonybai.com/2021/06/28/understand-go-execution-tracer-by-example Netflix（奈飞公司）的性能架构师Brendan Gregg在其《BPF Performance Tools》一书中对tracing、sampling等概念做了细致描述，以帮助开发人员理解这些概念，并基于这些概念对性能优化辅助工具进行分类，明确它们的适用场合。这里引用部分内容如下： ...
本文永久链接 – https://tonybai.com/2021/04/25/server-side-performance-nethttp-vs-fasthttp 1. 背景 Go初学者学习Go时，在编写了经典的“hello, world”程序之后，可能会迫不及待的体验一下Go强大的标准库，比如：用几行代码写一个像下面示例这样拥有完整功能的web server： ...
本文永久链接 – https://tonybai.com/2021/04/09/ten-commandments-of-go 本文翻译自John Arundel的《Ten commandments of Go》。全文如下： 作为一名全职的Go语言作家和老师，我花了很多时间和学生们一起，帮助他们写出更清晰、更好、更有用的Go程序。我发现，我给他们的建议可以归纳总结为一套通用原则，在这里我将这些原则分享给大家。 1. 你应该是无聊的 Go社区喜欢共识(consensus)。比如：Go源代码有一个由gofmt强制执行的统一的代码格式规范。同样，无论你要解决什么问题，通常都有一个标准的、类似于Go行事风格的方法来解决。有时它是标准的方式，因为它是最好的方式，但通常它只是最好的方式，因为它是标准的方式。 ...
本文翻译自Rytis Bieliunas的文章《Darker Corners of Go》。 第一部分参见《Go语言的“黑暗角落”：盘点学习Go语言时遇到的那些陷阱[译]（第一部分）》 7. 字符串和字节数组 1) Go中的字符串 Go字符串的内部定义如下所示： type StringHeader struct { Data uintptr Len int } 字符串本身是一个值类型，它具有一个指向字节数组的指针和固定长度。字符串中的“零字节”不像在C中那样标记着字符串的结尾。字符串内可以有任何数据。通常，该数据被编码为UTF-8字符串，但不一定如此。 ...
本文翻译自Rytis Bieliunas的文章《Darker Corners of Go》。 译注：若干年前，Kyle Quest曾发过一篇名为“50 Shades of Go: Traps, Gotchas, and Common Mistakes for New Golang Devs”的文章，仿效著名的《C Traps and Pitfalls》编写了50条Go语言的陷阱与缺陷，一时在Go社区广为流传。而本文是又一篇较为系统总结Go陷阱的文章，不同于50 Shades of Go的按初中高级陷阱的分类方式，本文是按类别对Go陷阱做讲解。 ...
1. 背景与选型 和《基于Redis Cluster的分布式锁实现以互斥方式操作共享资源》一文一样，今天要说的Go队列方案也是有一定项目背景的。 5G消息方兴未艾！前一段时间从事了一段时间5G消息网关的研发，但凡涉及类似消息业务的网关，我们一般都离不开队列这种数据结构的支持。这个5G消息网关项目采用的是Go技术栈开发，那么我们应该如何为它选择一个与业务模型匹配且性能不差的实现呢？ 如今一提到消息队列，大家第一个想到的一定是kafka，kafka的确是一款优秀的分布式队列中间件，但对于我们这个系统来说，它有些“重”，部署和运维都有门槛，并且项目组里也没有能很好维护它的专家，毕竟“可控”是技术选择的一个重要因素。除此之外，我们更想在Go技术栈的生态中挑选，但kafka是Java实现的。 ...
本文翻译自乔纳森·特纳（Jonathan Turner）和史蒂夫·弗朗西亚（Steve Francia）的文章《Rust vs. Go: Why They’re Better Together》。 ...