hanjm's blog

纠结于[]struct还是[]*struct
直接make([]struct,0) 后append 还是用sync.Pool make([]struct,100)

写段代码跑个分, 结论是

[]*struct的要比[]struct多n次取指针的内存分配, 所有更慢, 如果不用修改结构体元素内的值, 没有必要用指针切片
append[]*struct要比[]struct慢
sync.Pool效果明显

benchmark结果

BenchmarkStructSliceWithoutPool-8                 200000              5458 ns/op           16320 B/op          8 allocs/op
BenchmarkStructPointerSliceWithoutPool-8          200000              6045 ns/op            8504 B/op        109 allocs/op
BenchmarkStructSliceWithPool-8                   1000000              1287 ns/op              32 B/op          1 allocs/op
BenchmarkStructPointerSliceWithPool-8             300000              4910 ns/op            6498 B/op        102 allocs/op

benchmark代码

package main

import (
	"sync"
	"testing"
)

var structSlicePool = sync.Pool{
	New: func() interface{} {
		return make([]Basic, 100)
	},
}

var structPointerSlicePool = sync.Pool{
	New: func() interface{} {
		return make([]*Basic, 100)
	},
}

type Basic struct {
	Id, N1, N2, N3, N4, N5 int
	Name                   string
}

func BenchmarkStructSliceWithoutPool(b *testing.B) {
	for i := 0; i < b.N; i++ {
		var list []Basic
		for j := 0; j < 101; j++ {
			var data = Basic{Id: j, Name: "Name"}
			list = append(list, data)
		}
	}
}

func BenchmarkStructPointerSliceWithoutPool(b *testing.B) {
	for i := 0; i < b.N; i++ {
		var list []*Basic
		for j := 0; j < 101; j++ {
			var data = Basic{Id: j, Name: "Name"}
			list = append(list, &data)
		}
	}
}

func BenchmarkStructSliceWithPool(b *testing.B) {
	for i := 0; i < b.N; i++ {
		list := structSlicePool.Get().([]Basic)
		initLen := len(list)
		for j := 0; j < 101; j++ {
			var data = Basic{Id: j, Name: "Name"}
			if j < initLen {
				list[j] = data
			} else {
				list = append(list, data)
			}
		}
		structSlicePool.Put(list)
	}
}

func BenchmarkStructPointerSliceWithPool(b *testing.B) {
	for i := 0; i < b.N; i++ {
		list := structPointerSlicePool.Get().([]*Basic)
		initLen := len(list)
		for j := 0; j < 101; j++ {
			var data = Basic{Id: j, Name: "Name"}
			if j < initLen {
				list[j] = &data
			} else {
				list = append(list, &data)
			}
		}
		structPointerSlicePool.Put(list)
	}

}

来自NSQ

nsq的官方文档的Dsign中提到一个PPThttps://speakerdeck.com/snakes/nsq-nyc-golang-meetup, 里面有这样一段话

总结一下.

don’t be afraid of sync package
sync包里有

sync.Mutex(互斥锁,一读一写)
sync.RWMutex(读写锁,可以多读一写)
sync.Pool(对象池, 合理利用可以减少内存分配, 降低GC压力, 稍后写一篇博客说说)
sync.Once(并发控制. 适用于开几个goroutines去执行一个只执行一次的任务, 比如单例模式)
sync.Cond(并发控制, cond.Wait()阻塞至其他goroutie运行到cond.Signal())
sync.WaitGroup(并发控制. 通常用法 wg.Add增加任务数量 goroutie完成任务后执行wg.Done,任务数量减1 wg.Wait等待wg任务数量为0)

goroutines are cheap not free
这句话在其他地方也看过, go func()简单好用, 创建开销也很小, 但也是有开销的. 很多情况下开固定数量worker, 用channel传递数据, 效果会更好.
go-apns2中的example是个非常好的例子.https://github.com/sideshow/apns2/blob/master/_example/channel/main.go

注意一个问题, go里面一个goroutine panic了, 会导致进程退出, 所以go func()时第一行带上

go func(){
	defer func(){
		if err:=recover(); err!=nil{
		}
	}()
}()

是安全的做法, worker channel法时类似

package main

import (
	"fmt"
	"log"
	"time"
)

func main() {
	ch := make(chan int, 10)

	for i := 0; i < 2; i++ {
		go worker(ch, i)
	}

	for i := 0; i < 3; i++ {
		ch <- i
		ch <- -1
	}

	time.Sleep(time.Second * 5)
}

func worker(ch <-chan int, goId int) {

	log.Printf("worker%d running", goId)
	for data := range ch {
		func() {
			defer func() {
				if err := recover(); err != nil {
					log.Printf("worker%d recover error:%s", goId, err)
				}
			}()
			log.Printf("worker%d received data:%d", goId, data)
			if data == -1 {
				panic(fmt.Errorf("worker%d panic", goId))
			}
		}()
	}
}

fasthttp之所以快, 其中一个原因就是net/http是来一个连接就创建一个goroutie, 而fasthttp用了池复用了goroutines.

watch your allocations (string() is costly, re-user buffers)
go里面 []byte和string互转是会发生复制的, 开销明显, 如果代码里频繁互转, 考虑使用bytes.buffer 和 sync.Pool
use anonymous structs for arbitrary JSON
在写http api时, parse body这种事情, 如果只是纯粹取body里的json数据, 没必要单独定义结构体, 在函数里定义一个匿名结构体就好. var s struct { A int}
no built-in per-request HTTP timeouts
这是说要注意默认的httpClient没有超时
synchronizing goroutine exit is hard - log each cleanup step in long-running goroutines
同步化的goroutine一不小心就没有退出, 如果你写一个长期运行的服务, 用logger记录每一个goroutine的清理退出, 防止goroutine泄露
select skips nil channels

select语句是会跳过nil的channels的. 因为在Go里往已经close掉的channel里发送数据是会panic的, 可以利用select语句.
附: channel操作导致panic的情况有: 关闭一个nil的channel, 关闭一个已经关闭的channel( j,ok:= <- ch, ok为false时代表ch已经关闭了), 往一个已经关闭的channel里发送数据(从已经关闭的channel里读数据是OK的, 如果这个channel是带缓冲的, 那么可以读到所有数据)

来自GO箴言

Python有import this的zen of Python, 想不到Go也有箴言
https://speakerdeck.com/ajstarks/go-proverbs

在go里, goroutines之间通信不要用共享内存的方式实现, 应该用channel来实现
并发不是并行
channel是编排, mutexs是串行
interface定义越多的方法, 抽象程度越低. Go提倡用接口组合的方式实现更大的接口
零值, 猜测这里说的是struct{}吧, struct{}是一个不占内存的空结构体, 在用map实现set, channel发送无额外意义的signal时能降低内存分配
提倡gofmt
一点点复制比一点点依赖好. 官方包里有时能见到一些复制的代码, 这是为了不互相依赖
syscall每个平台实现不一样, 要加build tags
cgo每个平台的lib不一样, 要加build tags
Cgo不是go
unsafe包不提供保障
简洁胜过高效
error是值可以用值的方式去处理错误: 传递, 比较
不用仅检查错误, 要优雅地处理
多花精力设计架构, 模块命名, 写详细的文档
写良好的文档给用户
对于普通错误, 应该用多值返回错误, 而不是手动panic

实践

写可重复使用的函数, 接收接口类型, 返回具体类型
写可扩展便于二次包装的函数, 接收接口类型, 返回接口类型. 如标准库的database/sql包

传值还是传指针

指针仅用于要修改值的场景和反射, 其他场景尽可能地用值传递, 能让变量尽可能分配在栈上, 减少GC压力, 提高性能. 还能减少nil 参考 https://segment.com/blog/allocation-efficiency-in-high-performance-go-services/

Golang Github

https://github.com/golang/go/wiki/CodeReviewComments

Go sync.Pool Slice Benchmark

Go最佳实践

来自NSQ

来自GO箴言

实践

传值还是传指针

Golang Github