Golang on CctoctoFX

Profiling a Go Service in Production

Wed, 07 Apr 2021 11:25:18 +0800

参考

Julia Evans: Profiling Go programs with pprof

How I investigated memory leaks in Go using pprof on a large codebase

Memory Profiling a Go Service

Russ Cox: Profling Go Programs

Package pprof overview

github: pprof

Issue: Why ‘Total MB’ in golang heap profile is less than ‘RES’ in top?

Issue: Cannot free memory once occupied by bytes.Buffer

Issue: FreeOSMemory() in production

Issue: Is this an idiomatic worker thread pool in Go?

Life of an HTTP request in a Go server

Sat, 20 Feb 2021 11:22:18 +0800

这篇文章的启发是我在阅读Go的http源码时获得的，之前对这块缺乏深入的了解，这篇文章会结合源码讨论包括典型http request的路由，还会涉及到一些并发和中间件的issue。

我们先从一个简单的go server谈起，下面的代码从https://gobyexample.com/http-servers 截取：

package main

import (
  "fmt"
  "net/http"
)

func hello(w http.ResponseWriter, req *http.Request) {
  fmt.Fprintf(w, "hello\n")
}

func headers(w http.ResponseWriter, req *http.Request) {
  for name, headers := range req.Header {
    for _, h := range headers {
      fmt.Fprintf(w, "%v: %v\n", name, h)
    }
  }
}

func main() {
  http.HandleFunc("/hello", hello)
  http.HandleFunc("/headers", headers)

  http.ListenAndServe(":8090", nil)
}

追踪请求的生命周期我们从http.ListenAndServe这个方法开始，下面的图示说明了这一层的调用关系:

这里实际上inlined了一些代码，因为初始的代码有很多其他的细节不好追踪。

A Million WebSocket and Go

Sat, 16 Jan 2021 11:22:18 +0800

这篇文章是我研究高负载网络服务器架构看到的的一个有趣的story，添加了我自身学习websocket的感受和记录，希望我能在飞机落地前写完:-)

Preface

我们先描述一个问题作为讨论的中心：用户邮件的存储方法。

对于这种主题，有很多种方式在系统内对邮件状态进行持续的追踪，比如系统事件是一个方式，另一种方式可以通过定期的系统轮询有关状态变化。

这两种方式各有利弊，不过当我们讨论到邮件的时候，用户希望收到新邮件的速度越快越好。邮件轮询每秒约有50000个HTTP请求，其中60%返回304状态，也就是邮箱内没有任何修改。

因此，为了减少服务器的负载并加快向用户传递邮件的速度，我们决定通过编写publisher-subscriber服务器(即bus, message broker, event channel)来重新发明轮子。一方面接受有关状态变更的通知，另外一个方面接受此类通知的订阅。

改进前：

+--------------+     (2)    +-------------+      (1)    +-----------+
|              | <--------+ |             |  <--------+ |           |
|    Storage   |            |     API     |     HTTP    |  Browser  |
|              | +--------> |             |  +--------> |           |
+--------------+     (3)    +-------------+      (4)    +-----------+

改进后:

+--------------+            +-------------+   WebSocket  +-----------+
|    Storage   |            |     API     | +----------> |  Browser  |
+--------------+            +-------------+      (3)     +-----------+
       +                           ^
       | (1)                       | (2)
       v                           +
+-----------------------------------------+
|                  Bus                    |
+-----------------------------------------+

改进前的方案也就是browser定期去查询api并访问存储更改

fasthttp对性能的优化压榨

Sun, 10 Jan 2021 11:22:18 +0800

最近在看网络模型和go net的源码，以及各web框架例如fasthttp, weaver, gnet(更轻量)源码。fasthttp在github上已经写上了一个go开发的best practices examples,这里我也记录一些在源码中看到的一些技巧

`[]byte` buffer的tricks

下面的一些tricks在fasthttp中被使用，自己的代码也可以用

标准Go函数能够处理nil buffer

var (
	// both buffers are uninitialized
	dst []byte
	src []byte
)
dst = append(dst, src...)  // is legal if dst is nil and/or src is nil
copy(dst, src)  // is legal if dst is nil and/or src is nil
(string(src) == "")  // is true if src is nil
(len(src) == 0)  // is true if src is nil
src = src[:0]  // works like a charm with nil src

// this for loop doesn't panic if src is nil
for i, ch := range src {
	doSomething(i, ch)
}

所以可以去掉一些对[]bytebuffer的nil校验:

[源码分析]sync pool

Fri, 01 Jan 2021 11:22:18 +0800

- 当多个goroutine都需要创建同一个对象，如果gorountine数过多，导致对象的创建数目剧增，进而导致GC压力增大，形成“并发大-占用内存大-GC缓慢-并发处理能力弱-并发更大”这样的恶性循环
- 在这个时候，需要一个对象池，每个goroutine不再自己单独创建对象，而是从对象池中取出一个对象（如果池中已有）

[自建轮]高性能Goroutine Pool

Wed, 30 Dec 2020 11:22:18 +0800

高性能Goroutine Pool

go调度器没有限制对goroutine的数量，在goroutine瞬时大规模爆发的场景下来不及复用goroutine从而导致大量goroutine被创建，会导致大量的系统资源占用，尝试池化。

go调度器本身不应该对goroutine数量有限制，因为语言层面无法界定需要限制多少，毕竟程序跑在不同性能的环境，在并发规模不太大的场景做限制甚至会降低性能，原生支持限制goroutine数量无疑是得不偿失的。如果只是中等规模和比较小规模的并发场景其实pool的性能并没有优势

目前设计上还需要加上周期性对空闲队列的prune，等写完再加看看benchmark会提升多少。目前来说对大规模goroutine异步并发的场景(1M, 10M)内存优化(10倍往上)和吞吐量优化效果(2-6倍)非常好。

需求场景与目标

限制并发goroutine的数量
复用goroutine，减轻runtime调度压力，提升程序性能
规避过多的goroutine创建侵占系统资源，cpu&内存

关键技术

锁同步: golang有CAS机制，用spin-lock替代mutex 原理，讨论
LIFO/FIFO队列: LIFO队列能直接有时间排序功能，方便对需要关联入队时间的操作进行处理
Pool容量限制和弹性伸缩

代码实现

pool.go

package go_pool

import (
	"errors"
	"sync"
	"sync/atomic"
	"time"
)

const(
	OPEN = iota
	CLOSED
)

var (
	ErrPoolClosed = errors.New("this pool has been closed")
	ErrPoolOverload = errors.New("too many goroutines blocked on submit or Nonblocking is set")
	ErrInvalidExpiryTime = errors.New("invalid expiration time")
	ErrInvalidPoolCapacity = errors.New("invalid pool capacity")
	DefaultScanInterval = time.Second
)

type Pool struct {
	capacity int32

	running int32

	lock sync.Locker

	scanDuration time.Duration

	blockingTasksNum int

	maxBlockingTasks int

	state int32

	cond *sync.Cond

	workers WorkerQueue   // LIFO queue

	workerCache sync.Pool

}


func (p *Pool) Submit(task func()) error{
	if atomic.LoadInt32(&p.state) == CLOSED{
		return ErrPoolClosed
	}
	// retrieve worker to do the task
	// return error if no workers available
	var w *Worker
	if w = p.retrieveWorker(); w == nil{
		return ErrPoolOverload
	}
	w.task <- task
	return nil
}

func (p *Pool) Shutdown() {
	atomic.StoreInt32(&p.state, CLOSED)
	p.lock.Lock()
	// reset worker queue
	p.workers.reset()
	p.lock.Unlock()
}

func (p *Pool) isClosed() bool{
	return atomic.LoadInt32(&p.state) == CLOSED
}

// change the capacity of the pool
func (p *Pool) Resize(size int){
	if p.Cap() == size{
		return
	}
	atomic.StoreInt32(&p.capacity, int32(size))
	// need to stop certain workers if #running_workers > #new_capacity
	diff := p.Running() - size
	if diff > 0{
		for i := 0; i< diff; i++{
			p.retrieveWorker().task <- nil
		}
	}
}

func (p *Pool) Reboot() {
	if atomic.CompareAndSwapInt32(&p.state, CLOSED, OPEN){
		// initialize the purging go routine
		go p.scavengerRoutine()
	}
}

func (p *Pool) Running() int{
	return int(atomic.LoadInt32(&p.running))
}

func (p *Pool) Cap() int{
	return int(atomic.LoadInt32(&p.capacity))
}

func (p *Pool) Free() int{
	return p.Cap() - p.Running()
}

func (p *Pool) incRunning(){
	atomic.AddInt32(&p.running, 1)
}

func (p *Pool) decRunning(){
	atomic.AddInt32(&p.running, -1)
}

// put the worker back into the pool for recycling
func (p *Pool) recycleWorker(worker *Worker) bool{
	capacity := p.Cap()
	if p.isClosed() || (capacity >= 0 && p.Running() > capacity){
		return false
	}
	worker.recycleTime = time.Now()
	p.lock.Lock()
	// need to double check if state is CLOSED
	if p.isClosed(){
		p.lock.Unlock()
		return false
	}
	err := p.workers.add(worker)
	if err != nil{
		p.lock.Unlock()
		return false
	}

	// notify any request stuck in retrieveWorker that there is an available worker in pool
	p.cond.Signal()
	p.lock.Unlock()
	return true
}

func (p *Pool) spawnWorker() *Worker{
	worker := p.workerCache.Get().(*Worker)
	worker.Run()
	return worker
}

func (p *Pool) retrieveWorker() (worker *Worker){
	p.lock.Lock()
	worker = p.workers.detach()
	// get worker from queue successfully
	if worker != nil{
		p.lock.Unlock()
	}else if capacity := p.Cap();capacity == -1{
		p.lock.Unlock()
		// spawn worker
		return p.spawnWorker()
	}else if p.Running() < capacity{
		// infinite pool
		p.lock.Unlock()
		// spawn worker
		return p.spawnWorker()
	}else{
		// if the number of blocking tasks reaches the maximum blocking tasks threshold then returns nil
		// and throw the ErrPoolOverload error in Submit method
		if p.maxBlockingTasks != 0 && p.maxBlockingTasks <= p.blockingTasksNum{
			p.lock.Unlock()
			return
		}
		// the pool is full need to wait until worker is available for task handling
		Retry:
			// handle the number of blocking task handling requests
			// wait until condition being notified
			p.blockingTasksNum++
			p.cond.Wait()
			p.blockingTasksNum--
			// ensure there is a worker available because you don't know if the recycled worker being closed then
			if p.Running() == 0{
				p.lock.Unlock()
				// spawn worker
				return p.spawnWorker()
			}

			worker = p.workers.detach()
			if worker == nil{
				goto Retry
			}
			p.lock.Unlock()
	}

	return
}

func (p *Pool) scavengerRoutine(){
	heartbeat := time.NewTicker(p.scanDuration)
	defer heartbeat.Stop()
	for range heartbeat.C{
		if p.isClosed(){
			break
		}
		// all workers get cleaned up and some invokers still get stuck on cond.Wait()
		// we need to wake up all invokers in that situation.
		if p.Running() == 0{
			p.cond.Broadcast()
		}
	}
}

func NewPool(capacity int)(*Pool, error){
	if capacity <= 0{
		capacity = -1
	}

	pool := &Pool{
		capacity:  int32(capacity),
		lock: NewSpinLock(),
	}
	pool.workerCache.New = func() interface{}{
		return &Worker{
			pool: pool,
			task: make(chan func(), 1),
		}
	}
	pool.scanDuration = DefaultScanInterval
	// initialize the worker queue
	if capacity == -1{
		return nil, ErrInvalidPoolCapacity
	}
	pool.workers = NewWorkerQueue(0)

	pool.cond = sync.NewCond(pool.lock)

	// initialize the purging goroutine
	go pool.scavengerRoutine()

	return pool, nil
}

worker.go

package go_pool

import (
	"time"
)

type Worker struct{
	pool *Pool

	task chan func()
	
	recycleTime time.Time
}

func (w *Worker) Run(){
	w.pool.incRunning()
	go func(){
		defer func(){
			w.pool.decRunning()
			w.pool.workerCache.Put(w)
			// todo: panic recovery strategy
		}()
		for f := range w.task{
			// receiving nil indicates that the worker should stop and quit go routine
			if f == nil{
				return
			}
			f()
			// recycle worker back into the pool, if not success quit go routine
			if success := w.pool.recycleWorker(w); !success{
				return
			}
		}
	}()
}

worker_queue.go

package go_pool

type WorkerQueue interface {
	len() int
	isEmpty() bool
	add(worker *Worker) error
	detach() *Worker
	reset()
}

func NewWorkerQueue(size int) WorkerQueue{
	return NewSimpleWorkerQueue(size)
}

func NewSimpleWorkerQueue(size int) *simpleWorkerQueue{
	return &simpleWorkerQueue{
		size: size,
		workers: make([]*Worker, 0, size),
	}
}


type simpleWorkerQueue struct{
	workers []*Worker
	size int
}

func(sq *simpleWorkerQueue) len() int{
	return len(sq.workers)
}

func(sq *simpleWorkerQueue) isEmpty() bool{
	return sq.len() == 0
}

func (sq *simpleWorkerQueue) add(worker *Worker) error{
	sq.workers = append(sq.workers, worker)
	return nil
}

func (sq *simpleWorkerQueue) detach() *Worker{
	length := sq.len()
	if length == 0{
		return nil
	}
	worker := sq.workers[length - 1]
	sq.workers[length - 1] = nil // slice operation should avoid memory leak
	sq.workers = sq.workers[:length-1]
	return worker
}

func (sq *simpleWorkerQueue) reset(){
	for i := 0;i < sq.len(); i++{
		sq.workers[i].task <- nil
		sq.workers[i] = nil
	}
	sq.workers = sq.workers[:0]
}

lock.go

package go_pool

import (
	"runtime"
	"sync"
	"sync/atomic"
)

type spinLock uint32

func (sl *spinLock) Lock() {
	for !atomic.CompareAndSwapUint32((*uint32)(sl), 0, 1) {
		runtime.Gosched()
	}
}

func (sl *spinLock) Unlock() {
	atomic.StoreUint32((*uint32)(sl), 0)
}

// NewSpinLock instantiates a spin-lock.
func NewSpinLock() sync.Locker {
	return new(spinLock)
}

pool_test.go

package go_pool

import (
	"math"
	"runtime"
	"sync"
	"testing"
	"time"
)

const(
	_ = 1 << (10 * iota)
	KiB //1024
	MiB // 1048578
)

const (
	InfinitePoolSize = math.MaxInt32
	PoolSize        = 10000
	SleepTime       = 100
	OverSizeTaskNum = 10 * PoolSize
	UnderSizeTaskNum = 0.2 * PoolSize
)
var currentMem uint64

func demoTaskFunc(args interface{}){
	n := args.(int)
	time.Sleep(time.Duration(n) * time.Millisecond)
}


func TestPoolWaitToGetWorker(t *testing.T){
	var wg sync.WaitGroup
	p, err := NewPool(PoolSize)
	defer p.Shutdown()
	if err != nil {
		t.Errorf("err: %s", err.Error())
	}
	for i:=0; i< OverSizeTaskNum; i++{
		wg.Add(1)
		_ = p.Submit(func(){
			demoTaskFunc(SleepTime)
			wg.Done()
		})
	}
	wg.Wait()
	mem := runtime.MemStats{}
	runtime.ReadMemStats(&mem)
	currentMem = mem.TotalAlloc/KiB - currentMem
	t.Logf("memory usage: %d KB", currentMem)
}

func TestPoolGetWorkerFromCache(t *testing.T){
	var currentMem uint64
	var wg sync.WaitGroup
	p, err := NewPool(PoolSize)
	defer p.Shutdown()
	if err != nil {
		t.Errorf("err: %s", err.Error())
	}
	for i:=0; i< UnderSizeTaskNum; i++{
		wg.Add(1)
		_ = p.Submit(func(){
			demoTaskFunc(SleepTime)
			wg.Done()
		})
	}
	wg.Wait()
	mem := runtime.MemStats{}
	runtime.ReadMemStats(&mem)
	currentMem = mem.TotalAlloc/KiB - currentMem
	t.Logf("memory usage: %d KB", currentMem)
}

func TestNoPool(t *testing.T){
	var wg sync.WaitGroup
	for i:=0; i<UnderSizeTaskNum; i++{
		wg.Add(1)
		go func(){
			defer wg.Done()
			demoTaskFunc(SleepTime)
		}()
	}
	wg.Wait()
	mem := runtime.MemStats{}
	runtime.ReadMemStats(&mem)
	currentMem = mem.TotalAlloc/KiB - currentMem
	t.Logf("memory usage: %d KB", currentMem)
}

func TestWithInfinitePool(t *testing.T){
	var wg sync.WaitGroup
	p, err := NewPool(InfinitePoolSize)
	defer p.Shutdown()
	if err != nil {
		t.Errorf("err: %s", err.Error())
	}
	for i:=0; i< UnderSizeTaskNum; i++{
		wg.Add(1)
		_ = p.Submit(func(){
			demoTaskFunc(SleepTime)
			wg.Done()
		})
	}
	wg.Wait()
	mem := runtime.MemStats{}
	runtime.ReadMemStats(&mem)
	currentMem = mem.TotalAlloc/KiB - currentMem
	t.Logf("memory usage: %d KB", currentMem)
}

pool_benchmark_test.go

package go_pool

import (
	"testing"
	"time"
)

const (
	RunTimes = 5000000
	BenchParam = 10
	BenchPoolSize = 200000
)

func demoFunc() {
	time.Sleep(time.Duration(BenchParam) * time.Millisecond)
}

func BenchmarkPoolThroughput(b *testing.B) {
	p, _ := NewPool(BenchPoolSize)
	defer p.Shutdown()
	b.StartTimer()
	for i := 0; i < b.N; i++ {
		for j := 0; j < RunTimes; j++ {
			_ = p.Submit(demoFunc)
		}
	}
	b.StopTimer()
}

func BenchmarkGoroutinesThroughput(b *testing.B) {
	for i := 0; i < b.N; i++ {
		for j := 0; j < RunTimes; j++ {
			go demoFunc()
		}
	}
}

Possible Memory Leak

Fri, 25 Dec 2020 11:22:18 +0800

实际上对于一个有GC的语言，我们不必太多关心内存泄漏的问题，因为程序的runtime帮我们很好地额回收不再使用的内存。但是，我们还是得了解一些特殊的场景，这些场景会产生暂时性或者永久性的内存泄漏。

待开坑...

Close Channels Gracefully

Thu, 24 Dec 2020 11:22:18 +0800

优雅地关闭通道

场景一：M个接收者和一个发送者。发送者通过关闭用来传输数据的通道来传递发送结束信号

这是最简单的一种情形。当发送者欲结束发送，让它关闭用来传输数据的通道即可。

package main

import (
	"time"
	"math/rand"
	"sync"
	"log"
)

func main() {
	rand.Seed(time.Now().UnixNano())
	log.SetFlags(0)

	// ...
	const Max = 100000
	const NumReceivers = 100

	wgReceivers := sync.WaitGroup{}
	wgReceivers.Add(NumReceivers)

	// ...
	dataCh := make(chan int)

	// 发送者
	go func() {
		for {
			if value := rand.Intn(Max); value == 0 {
				// 此唯一的发送者可以安全地关闭此数据通道。
				close(dataCh)
				return
			} else {
				dataCh <- value
			}
		}
	}()

	// 接收者
	for i := 0; i < NumReceivers; i++ {
		go func() {
			defer wgReceivers.Done()

			// 接收数据直到通道dataCh已关闭
			// 并且dataCh的缓冲队列已空。
			for value := range dataCh {
				log.Println(value)
			}
		}()
	}

	wgReceivers.Wait()
}

场景二：一个接收者和N个发送者，此唯一接收者通过关闭一个额外的信号通道来通知发送者不要在发送数据了

此情形比上一种情形复杂一些。我们不能让接收者关闭用来传输数据的通道来停止数据传输，因为这样做违反了通道关闭原则。但是我们可以让接收者关闭一个额外的信号通道来通知发送者不要在发送数据了。

Channels Concurrency Work-Around

Tue, 22 Dec 2020 11:22:18 +0800

记录了一些channels常见的场景，以及自己的一些感受：

使用通道进行异步和并发编程是简单和惬意的；
通道同步技术比被很多其它语言采用的其它同步方案（比如角色模型和async/await模式）有着更多的应用场景和更多的使用变种。

通道作为同步手段，并非在任何情况下都是最佳的同步技术，本文也会补充原子操作和sync包内其他的技术作为参考。

将通道用做future/promise

很多其它流行语言支持future/promise来实现异步（并发）编程。 Future/promise常常用在请求/回应场合。

返回单向接收通道做为函数返回结果

在下面这个例子中，sumSquares函数调用的两个实参请求并发进行。每个通道读取操作将阻塞到请求返回结果为止。两个实参总共需要大约3秒钟（而不是6秒钟）准备完毕（以较慢的一个为准）。

package main

import (
	"time"
	"math/rand"
	"fmt"
)

func longTimeRequest() <-chan int32 {
	r := make(chan int32)

	go func() {
		time.Sleep(time.Second * 3) // 模拟一个工作负载
		r <- rand.Int31n(100)
	}()

	return r
}

func sumSquares(a, b int32) int32 {
	return a*a + b*b
}

func main() {
	rand.Seed(time.Now().UnixNano())

	a, b := longTimeRequest(), longTimeRequest()
	fmt.Println(sumSquares(<-a, <-b))
}

将单向发送通道类型用做函数实参

和上例一样，在下面这个例子中，sumSquares函数调用的两个实参的请求也是并发进行的。和上例不同的是longTimeRequest函数接收一个单向发送通道类型参数而不是返回一个单向接收通道结果。

Golang TDD

Sat, 19 Dec 2020 11:22:18 +0800

Preface

本文整理golang编码的单元测试常用示例，以及TDD的简要流程。

单元测试基础

单元测试文件以_test.go结尾，需要记住以下原则：

文件名必须是_test.go结尾的，这样在执行go test的时候才会执行到相应的代码
你必须import testing这个包
所有的测试用例函数必须是Test开头
测试用例会按照源代码中写的顺序依次执行
测试函数TestXxx()的参数是testing.T，我们可以使用该类型来记录错误或者是测试状态
测试格式：func TestXxx (t *testing.T),Xxx部分可以为任意的字母数字的组合，但是首字母不能是小写字母[a-z]，例如Testintdiv是错误的函数名。
函数中通过调用testing.T的Error, Errorf, FailNow, Fatal, FatalIf方法，说明测试不通过，调用Log方法用来记录测试的信息。

Table-Driven-Testing

测试讲究 case 覆盖，当我们要覆盖更多 case 时，显然通过修改代码的方式很笨拙。这时我们可以采用 Table-Driven 的方式写测试，标准库中有很多测试是使用这种方式写的。

func TestFib(t *testing.T) {
    var fibTests = []struct {
        in       int // input
        expected int // expected result
    }{
        {1, 1},
        {2, 1},
        {3, 2},
        {4, 3},
        {5, 5},
        {6, 8},
        {7, 13},
    }

    for _, tt := range fibTests {
        actual := Fib(tt.in)
        if actual != tt.expected {
            t.Errorf("Fib(%d) = %d; expected %d", tt.in, actual, tt.expected)
        }
    }
}

由于我们使用的是 t.Errorf，即使其中某个 case 失败，也不会终止测试执行。

Golang并发调度

Thu, 17 Dec 2020 11:22:18 +0800

性能提升不会凭空出现，它总是伴随着代码复杂度的上升。
The performance improvement does not materialize from the air, it comes with code complexity increase.

– Dmitry Vyukov

Go 语言的调度器我认为应该是整个运行时最有趣的组件了。对于Go本身，它的设计和实现直接牵动了Go运行时的其他组件，也是和用户态代码直接打交道的部分；对于Go用户而言，调度器将其极为复杂的运行机制隐藏在了简单的关键字go下。为了保证高性能，调度器必须有效得利用计算的并行性和局部性原理；为了保证用户态的简洁，调度器必须高效得对调度用户态不可见的网络轮训器、垃圾回收器进行调度；为了保证代码执行的正确性，必须严格实现用户态代码的内存顺序等。总而言之，调度器的设计直接决定了Go运行时源码的表现形式。

设计原理

数据结构: MPG

调度器启动

创建Goroutine

调度循环

触发调度

线程管理

总结

BDD: Ginkgo测试框架

Fri, 04 Dec 2020 11:22:18 +0800

Preface

BDD和TDD都是test case first的实现，无非是把后者的test改成前者的behavior。在TDD中，关注的核心点是function，即认为程序最基本单元是function，其test case可以认为是unit test，TDD和unit test的区别是TDD强调测试和开发结合而成的工作流: 写test case -> 写代码 -> 通过测试，继续写更多测试，写一次循环。

而BDD比TDD更关注高层的行为，而不是函数级别的行为，也就是在BDD中，不会强调函数的功能正确，这是unit test应该做的事。BDD更关注user story，即用户在特定场景，与软件交互发生的行为，这个behavior指的就是高层模块的行为。

如何区分BDD和TDD，简单理解，TDD是给programmer的，用来验证开发者的最基本模块的功能：在什么输入，应该产生什么输出，保证实现的边界，健全性。而BDD，其test case描述的是更高级的模块行为，脱离了具体的实现，容易用自然语言去描述，也就是BDD是给product manager的，告诉其系统的行为。

BDD in golang

实现的时候，我们需要把Given-When-Then这种story格式组织test case翻译为测试代码，通过一系列的assertion来检查实现是否符合test case的预期，我们完全可以直接通过golang自带的testing模块来实现，不过testing的功能有时候比较简陋，本文记录了用Ginkgo+Gomega来组织test case，让我们的测试语言更加接近自然语言。

二者结合的目的是，ginkgo实现了test case的组织，并加入了其他方便的功能: 初始化，后续处理，异步等等。而gomega设计的目的是与ginkgo一起工作，实现易读的assertion(ginkgo中称为match)功能。

Gomega is ginkgo's preferred matcher library

初始化

ginkgo依托golang原生testing框架，即可以用go test ./.. 执行，也可以通过ginkgo binrary安装go install github.com/onsi/ginkgo，封装了ginkgo测试框架的各种feature。

初始化首先进入待测试的package:

cd /path/to/package

执行初始化:

ginkgo bootstrap

生成以suite_test.go文件，接下来向suite添加测试specs，生成比如ginkgo_cart package测试文件。

ginkgo generate ginkgo_cart

运行

生成ginkgo_cart_test.go，注意测试文件在ginkgo_cart_testpackage，需要import package ginkgo_cart，即BDD层级高于unit test, 不应该了解package内部的具体实现，测试package的外部接口即可。编写测试代码，运行go test ./..即可。

Ginkgo Keyword

Ginkgo测试代码骨架由一系列keyword关联的闭包组成，常用的有：

Describe/Context/When: 测试逻辑块
BeforeEach/AfterEach/JustBeforeEach/JustAfterEach: 初始化测试用例块
It: 单一Spec，测试case

keyword的声明均为传入Body参数，比如Describe:

Golang内存管理

Wed, 02 Dec 2020 11:22:18 +0800

设计原则

现在我们来看 Go 中另一重要的关键组件：内存分配器。

Go 的内存分配器基于 Thread-Cache Malloc (tcmalloc) ，tcmalloc 为每个线程实现了一个本地缓存，区分了小对象（小于 32kb）和大对象分配两种分配类型，其管理的内存单元称为 span。

我们不再介绍更多 tcmalloc 的具体细节，因为 Go 的内存分配器与 tcmalloc 存在一定差异。这个差异来源于 Go 语言被设计为没有显式的内存分配与释放，完全依靠编译器与运行时的配合来自动处理，因此也就造就了内存分配器、垃圾回收器两大组件。

我们知道，在计算机领域中，无外乎时间换空间、空间换时间。统一管理内存会提前分配或一次性释放一大块内存，进而减少与操作系统沟通造成的开销，进而提高程序的运行性能。支持内存管理另一个优势就是能够更好的支持垃圾回收，这一点我们留到垃圾回收器的章节中进行讨论。

主要结构

Go 的内存分配器主要包含以下几个核心组件：

heapArena: 保留整个虚拟地址空间
mheap：分配的堆，在页大小为 8KB 的粒度上进行管理
mspan：是 mheap 上管理的一连串的页
mcentral：收集了给定大小等级的所有 span
mcache：为 per-P 的缓存。

其中页是向操作系统申请内存的最小单位，目前设计为 8KB。

每一个结构虽然不都像是调度器 M/P/G 结构那样的大部头，但初次阅读这些结构时想要理清他们之间的关系还是比较麻烦的。传统意义上的栈被 Go 的运行时霸占，不开放给用户态代码；而传统意义上的堆内存，又被 Go 运行时划分为了两个部分，一个是 Go 运行时自身所需的堆内存，即堆外内存；另一部分则用于 Go 用户态代码所使用的堆内存，也叫做 Go 堆。 Go 堆负责了用户态对象的存放以及 goroutine 的执行栈。

Arena

heapArena

Go 堆被视为由多个 arena 组成，每个 arena 在 64 位机器上为 64MB，且起始地址与 arena 的大小对齐，所有的 arena 覆盖了整个 Go 堆的地址空间。

Golang逃逸分析

Mon, 23 Nov 2020 11:22:18 +0800

问题： golang函数传参是不是应该和c一样，尽量不要直接传结构体，而是要传结构体指针？

逃逸分析

逃逸分析指的是，在计算机语言编译器优化原理中，分析指针动态范围的方法，和编译器优化原理的指针分析和外形分析相关联。当变量（或者对象）在方法中被分配后，其指针有可能被返回或者被全局引用，这种现象就是指针（或引用）的逃逸（Escape）。

其实在java概念中有一个误解 — new出来的东西都在堆上，栈上存的是它的引用。这句话在现代JVM上有问题，就是因为逃逸分析机制。简单来说，就是JVM的逃逸分析会在运行时(runtime)检测当前方法栈帧(frame)内new出来的对象的引用，是否被传出当前的栈帧。如果传出，就会发生逃逸，没有传出则不会。对于未发生逃逸的变量，则会直接在栈上分配内存。因为栈上内存由在函数返回时自动回收，而堆上的的内存需要gc去回收，如果程序中有大量逃逸的对象，那么势必会增加gc的压力。

public void test(){
  List<Integer> a = new ArrayList<>();
  a.add(1); // a 未逃逸，在栈上分配
}

public List<Integer> test1(){
  List<Integer> a = new ArrayList<>();
  a.add(1);
  return a // 发生逃逸，因此分配在堆上
}

区别

不同于JVM运行时的逃逸分析，Golang的逃逸分析是在编译期完成。
golang的逃逸分析只针对指针。一个值引用变量如果没有被取址，那么它永远不可能逃逸。

go version go1.13.4 darwin/amd64

验证某个函数的变量是否发生逃逸的方法：

go run -gcflags “-m -l” (-m打印逃逸分析信息，-l禁止内联编译)

Golang on CctoctoFX

Profiling a Go Service in Production

参考

Life of an HTTP request in a Go server

A Million WebSocket and Go

Preface

fasthttp对性能的优化压榨

[]byte buffer的tricks

[源码分析]sync pool

[自建轮]高性能Goroutine Pool

高性能Goroutine Pool

需求场景与目标

关键技术

代码实现

pool.go

worker.go

worker_queue.go

lock.go

pool_test.go

pool_benchmark_test.go

Possible Memory Leak

Close Channels Gracefully

优雅地关闭通道

场景一：M个接收者和一个发送者。发送者通过关闭用来传输数据的通道来传递发送结束信号

场景二： 一个接收者和N个发送者，此唯一接收者通过关闭一个额外的信号通道来通知发送者不要在发送数据了

Channels Concurrency Work-Around

将通道用做future/promise

返回单向接收通道做为函数返回结果

将单向发送通道类型用做函数实参

Golang TDD

Preface

单元测试基础

Table-Driven-Testing

Golang并发调度

设计原理

数据结构: MPG

调度器启动

创建Goroutine

调度循环

触发调度

线程管理

总结

BDD: Ginkgo测试框架

Preface

BDD in golang

初始化

运行

Ginkgo Keyword

Golang内存管理

设计原则

主要结构

Arena

heapArena

Golang逃逸分析

逃逸分析

区别

`[]byte` buffer的tricks

场景二：一个接收者和N个发送者，此唯一接收者通过关闭一个额外的信号通道来通知发送者不要在发送数据了