本文永久链接 – https://tonybai.com/2024/12/02/why-go-sucks 编程语言比较的话题总是能吸引程序员的眼球！ 近期外网的两篇编程语言对比的文章在国内程序员圈里引起热议。一篇是由Ben Dicken (@BenjDicken) 做的语言性能测试，对比了十多种主流语言在执行10亿次循环(一个双层循环：1万 * 10 万)的速度；另一篇则是一个名为hez2010的开发者做的内存开销测试，对比了多种语言在处理百万任务时的内存开销。 ...
本文永久链接 – https://tonybai.com/2021/08/19/go-module-changes-in-go-1-17 Go module的引入终于让Go语言有了自己的包依赖管理标准机制与工具，虽说它的引入与推广过程略显坎坷，但不得不承认Go 1.11及之后的每一次Go版本发布，Go module都在进步！在Go 1.17版本中亦是如此，本篇我们就来详细聊聊在Go 1.17版本中Go module都有哪些重要的变化。 ...
本文永久链接 – 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/06/04/go-source-analysis-with-functrace 在《像跟踪分布式服务调用那样跟踪Go函数调用链》一文中，我们介绍了一种跟踪函数调用链的思路，并给出了一种实现functrace：https://github.com/bigwhite/functrace。这个小工具不仅仅是分享给大家的，我自己在工作和学习时也在使用。最近发现这个小工具在阅读和分析某个Go项目源码时也能起到关键的辅助作用。这里就和大家简单讲解一下如何用functrace来辅助Go源码阅读和分析。 程序员的日常离不开“源码阅读和分析”，日常阅读代码的姿势无非是这么几种（或几种的组合）： 结合源码编辑器或IDE提供的强大的源码交叉索引和跳转功能在一个庞大的源码库中建立起代码间的联系； 将代码跑起来，在代码中加上一些print输出，跟踪执行流并画出； 也有人喜欢用调试器从一点（通常是main）开始单步跟踪执行流。 无论哪一种方式，最终只要时间够长，态度到位，总是会将代码分析出个七七八八的。 ...