背景

上周我写了一篇文章Go 每日一库之 ants,深入剖析了ants这个 goroutine 池的实现。在反复阅读了多遍panjf2000关于ants的起源的文章——GMP 并发调度器深度解析之手撸一个高性能 goroutine pool,我感觉收获满满。这篇文章对于理解 Go 的 goroutine 并发机制有很大的参考价值,强烈建议一读。然后我花了几个小时时间详细阅读了ants的源码,代码写的很棒,非常优美。而后我写了一遍文章分析了ants的源码,见ants源码赏析。在写介绍ants的文章和深入阅读源码过程中,网上的资料提及 Go 语言中 goroutine 池的实现,时常会带上tunny这个库。于是,我又去研究了tunny的源码,产出一篇文章Go 每日一库之 tunny

在阅读tunny源码时,我发现有个方法的实现有些问题。我也在Go 每日一库之 tunny中也指出了:

原理

我们知道 slice 结构中有一个指向数组的指针。假设一开始tunny中有 5 个 worker,示意图如下:

数组中每个元素都是一个指针,指向一个worker结构。然后我们使用s := s[:4]缩容了,进变成了下面这样:

现在最后一个元素无法通过切片访问了,但是又被底层数组引用着,无法被 Go 运行时的 gc 清理掉,360 软件管家都不行。这就有内存泄漏了。虽然这个泄漏并不严重,一是因为量不可能很大,因为 worker 数量有限,二是下次扩容后位置被覆盖就可以释放原 worker 了(因为没有引用它的指针了)。

ants源码中也有类似的操作,但是会将缩容掉的元素置为nil。例如worker_stack.go中的reset()方法:

1
2
3
4
5
6
7
func (wq *workerStack) reset() {
  for i := 0; i < wq.len(); i++ {
    wq.items[i].task <- nil
    wq.items[i] = nil
  }
  wq.items = wq.items[:0]
}

PR

确定了问题。我先 fork 了tunny的仓库。点击 fork 按钮:

而后将 fork 后的我自己的仓库下载:

1
$ git clone git@github.com:darjun/tunny.git

修改代码,commit,push 到我的远程仓库。下面是我所做的改动:

然后去tunny源仓库,点击Pull Request按钮。然后点击右侧的New pull request按钮:

新建一个 PR,然后点击compare across forks,选择我的 fork:

选择我做修改的那次提交,然后填写信息,提交,由于我已经提交了 PR。这次比较就没有差异了。

然后等待作者合并。一天后,作者合并了这次修改:

总结

GitHub 提交 PR 并不难,大到新增特性,小到一个拼写错误,都可以提 PR。相信不少人都听说过,Linus Torvalds 亲自合并了一个来自 11 岁小孩提交的关于 Linux 源码注释中拼写错误的 PR。

GitHub 上 star 很多的项目并非完美,肯定也有很多值得改进的地方。所以阅读源码时需要带有一定的怀疑精神,不要把什么奉为圭臬。

大家如果发现好玩、好用的 Go 语言库,欢迎到 Go 每日一库 GitHub 上提交 issue😄

参考

  1. tunny GitHub:github.com/Jeffail/tunny
  2. ants GitHub:github.com/panjf2000/ants
  3. Go 每日一库 GitHub:https://github.com/darjun/go-daily-lib

我的博客:https://darjun.github.io

欢迎关注我的微信公众号【GoUpUp】,共同学习,一起进步~