发表于 | 分类于
| 字数统计: 1.3k

题图

本文基于Go 1.13

创建系统线程以及在系统线程间切换，会对程序的内存和性能造成较大的开销。Go的目标是尽量利用CPU多核资源。设计之初就考虑了高并发性。

M，P，G 模型

为了达到这个目标，Go拥有一个将协程调度到系统线程执行的调度器。这个调度器定义了三个核心概念，在Go源码中是这样解释的：

G - goroutinue. 协程
M - worker thread, or machine. 工作线程
P - processor, 执行Go代码时所必须的一种资源。
M必须有一个相关联的P才能执行Go代码。

以下是 P，M，G 模型的示意图：

P,G,M模型

每个协程（G）在一个分配给逻辑processor（P）的系统线程（M）上运行。来看一个小例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
func main() {
   var wg sync.WaitGroup
   wg.Add(2)

   go func() {
      println(`hello`)
      wg.Done()
   }()

   go func() {
      println(`world`)
      wg.Done()
   }()

   wg.Wait()
}

首先，Go会根据当前机器的逻辑CPU个数来创建相应数量的P，并将它们存放在一张空闲P列表中：

P初始化

然后，新创建并等待被运行的协程会唤醒一个P来执行这个任务，这个P会创建一个和系统线程相关联的M：

创建系统线程

和P一样，如果一个M没有工作可做了，该M会被放入空闲M链表中：

M,P空闲列表

在程序启动时，Go会预先创建一些系统线程以及相关联的M。在上面的小例子中，第一个打印hello的协程会使用主协程，而第二个打印world的协程会从空闲列表中获取到一个M和一个P：

从空闲列表获取M,P

以上，我们有了一张管理协程和系统线程的全局图，让我们进一步看看Go在什么情况下会使用更多的M和P，以及调用系统调用时协程是如何被管理的。

系统调用

Go对系统调用做了优化，具体做法是在运行时对系统调用做了封装（不管系统调用是否会造成阻塞）。该部分封装代码会自动将P与线程M解除绑定，使得另一个线程M可以在这个P上运行。让我们来看一个读取文件的例子：

1
2
3
4
5
6
7
8
9
func main() {
   buf := make([]byte, 0, 2)

   fd, _ := os.Open("number.txt")
   fd.Read(buf)
   fd.Close()

   println(string(buf)) // 42
}

以下是打开文件的流程：

syscall移交P

现在，P0被放入空闲列表中，可被使用。当系统调用结束之后，Go顺序执行如下流程直到其中一条规则被满足：

  • 试图获取同一个P，在我们上面的例子就是P0，如果获取到，则恢复执行
  • 试图在空闲列表中获取一个P，如果获取到，则恢复执行
  • 将协程放入全局队列中，将相关的M放入空闲列表中

并且，Go使用非阻塞I/O模式，对资源还没有就绪的情况也做了处理，比如说http请求。这种情况下首先也遵循上面所说的系统调用的流程，之后如果底层的系统调用由于资源没有就绪而返回失败时，Go会强制使用network poller，并且将该协程挂起。以下是例子：

1
2
3
func main() {
   http.Get(`https://httpstat.us/200`)
}

当底层的系统调用返回并且显式表示资源没有就绪时，协程将被挂起，直到network poller通知它资源已经就绪。这种情况下，线程M不会被阻塞：

Network poller等待资源就绪

当Go调度器重新调度时，之前的那个协程将被重新运行。调度器会询问network poller是否存在之前在等待资源并且现在资源已经就绪的协程：

nope

如果有多个协程就绪了，其它的协程会被放入全局等待执行队列中，稍后会被调度执行。

关于系统线程数的限制

当使用了系统调用时，Go并不限制这些可能被阻塞的系统线程的数量，以下是Go代码中的注释说明：

GOMAXPROCS变量限制的是用户层面Go代码的系统线程数量。对于可能造成阻塞的系统调用的线程数是不做限制的；它们不计算在GOMAXPROCS限制之中。

以下是一个例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
func main() {
   var wg sync.WaitGroup

   for i := 0;i < 100 ;i++  {
      wg.Add(1)

      go func() {
         http.Get(`https://httpstat.us/200?sleep=10000`)

         wg.Done()
      }()
   }

   wg.Wait()
}

以下是使用tracing工具，查看程序创建的线程数量：

nope

值得一提，由于Go可以复用系统线程，所以工具查看到的线程数要小于例子中for循环的次数。

英文原文地址：Go: Goroutine, OS Thread and CPU Management

原文链接： https://pengrl.com/p/29953/
原文出处： yoko blog (https://pengrl.com)
原文作者： yoko
版权声明： 本文欢迎任何形式转载，转载时完整保留本声明信息（包含原文链接、原文出处、原文作者、版权声明）即可。本文后续所有修改都会第一时间在原始地址更新。

发表于 | 分类于
| 字数统计: 2.4k

Go创建对象时，如何优雅的传递初始化参数？这里所说的优雅，指的是：

  1. 支持传递多个参数
  2. 参数个数、类型发生变化时，尽量保持接口的兼容性
  3. 参数支持默认值
  4. 具体的参数可根据调用方需关心的程度，决定是否提供默认值

Go并不像c++和python那样，支持函数默认参数。所以使用Go时，我们需要一种方便、通用的手法来完成这件事。

Go的很多开源项目都使用Option模式，但各自的实现可能有些许细微差别。

本文将通过一个渐进式的demo示例来介绍Option模式，以及相关的一些思考。本文将内容切分为10个小模块，如果觉得前面的铺垫冗余，想直接看Option模式的介绍，可以从小标题七开始阅读。

零

阅读全文 »

发表于 | 分类于
| 字数统计: 2.6k

几天前，我读了一篇关于BigCache的文章，我对它是如何做到以下两点十分感兴趣：

  • 加速并发访问
  • 避免高额的GC开销

于是我去阅读了它的代码。我觉得它的做法很赞，所以我写了这篇文章来与你分享。

BigCache 是一个快速，支持并发访问，自淘汰的内存型缓存，可以在存储大量元素时依然保持高性能。BigCache将元素保存在堆上却避免了GC的开销。 —— 摘自《BigCache README 中的简介》

1
2
3
4
5
6
7
8
9
10
// BigCache README 中的简单使用示例

import "github.com/allegro/bigcache"

cache, _ := bigcache.NewBigCache(bigcache.DefaultConfig(10 * time.Minute))

cache.Set("my-unique-key", []byte("value"))

entry, _ := cache.Get("my-unique-key")
fmt.Println(string(entry))

BigCache github地址

并发访问

阅读全文 »

发表于 | 分类于
| 字数统计: 1.5k

先看效果

1
2
3
4
5
6
$./myapp -v
GitCommitLog=d97d098e5bb4ad38a2a7968f273a256e10a0108f mod bininfo comment
GitStatus=cleanly
BuildTime=2019.10.26.194341
GoVersion=go version go1.13 darwin/amd64
runtime=darwin/amd64

myapp 是一个演示用的 demo 程序，输入 -v 参数运行时，打印出程序的一些信息。以上信息对应的说明如下：

阅读全文 »

发表于 | 分类于
| 字数统计: 1.8k

关于两个队列

整体流程图

首先我们必须明白，处于“LISTENING”状态的TCP socket，有两个独立的队列：

  • SYN队列（SYN Queue）
  • Accept队列（Accept Queue）

这两个术语有时也被称为“reqsk_queue”，“ACK backlog”，“listen backlog”，甚至“TCP backlog”，但是这篇文章中我们使用上面两个术语以免造成混淆。

SYN队列

阅读全文 »

发表于 | 分类于
| 字数统计: 1.7k

Go标准库中的bytes.Buffer（下文用Buffer表示）类似于一个FIFO的队列，它是一个流式字节缓冲区。

我们可以持续向Buffer尾部写入数据，从Buffer头部读取数据。当Buffer内部空间不足以满足写入数据的大小时，会自动扩容。

伸缩策略

阅读全文 »
0%