thinkeridea博客

【Go】四舍五入在go语言中为何如此困难

2021-01-02T03:57:22.000Z

四舍五入是一个非常常见的功能，在流行语言标准库中往往存在 Round 的功能，它最少支持常用的 Round half up 算法。

而在 Go 语言中这似乎成为了难题，在 stackoverflow 上搜索 [go] Round 会存在大量相关提问，Go 1.10 开始才出现 math.Round 的身影，本以为 Round 的疑问就此结束，但是一看函数注释 Round returns the nearest integer, rounding half away from zero ，这是并不常用的 Round half away from zero 实现呀，说白了就是我们理解的 Round 阉割版，精度为 0 的 Round half up 实现，Round half away from zero 的存在是为了提供一种高效的通过二进制方法得结果，可以作为 Round 精度为 0 时的高效实现分支。

带着对 Round 的‘敬畏’，我在 stackoverflow 翻阅大量关于 Round 问题，开启寻求最佳的答案，本文整理我认为有用的实现，简单分析它们的优缺点，对于不想逐步了解，想直接看结果的小伙伴，可以直接看文末的最佳实现，或者跳转 exmath.Round 直接看源码和使用吧！

Round 第一弹

在 stackoverflow 问题中的最佳答案首先获得我的关注，它在 mathx.Round 被开源，以下是代码实现：

//source: https://github.com/icza/gox/blob/master/mathx/mathx.go
package mathx

import "math"

// Round returns x rounded to the given unit.
// Tip: x is "arbitrary", maybe greater than 1.
// For example:
//     Round(0.363636, 0.001) // 0.364
//     Round(0.363636, 0.01)  // 0.36
//     Round(0.363636, 0.1)   // 0.4
//     Round(0.363636, 0.05)  // 0.35
//     Round(3.2, 1)          // 3
//     Round(32, 5)           // 30
//     Round(33, 5)           // 35
//     Round(32, 10)          // 30
//
// For details, see https://stackoverflow.com/a/39544897/1705598
func Round(x, unit float64) float64 {
return math.Round(x/unit) * unit
}

这个实现非常的简洁，借用了 math.Round，由此看来 math.Round 还是很有价值的，大致测试了它的性能一次运算大概 0.4ns，这非常的快。

但是我也很快发现了它的问题，就是精度问题，这个是问题中一个回答的解释让我有了警觉，并开始了实验。他认为使用浮点数确定精度（mathx.Round的第二个参数）是不恰当的，因为浮点数本身并不精确，例如 0.05 在64位IEEE浮点数中，可能会将其存储为0.05000000000000000277555756156289135105907917022705078125。

//source: https://play.golang.org/p/0uN1kEG30kI
package main

import (
"fmt"
"math"
)

func main() {
f := 12.15807659924030304
fmt.Println(Round(f, 0.0001)) // 12.158100000000001

f = 0.15807659924030304
fmt.Println(Round(f, 0.0001)) // 0.15810000000000002
}

func Round(x, unit float64) float64 {
return math.Round(x/unit) * unit
}

以上代码可以在 Go Playground 上运行，得到结果并非如期望那般，这个问题主要出现在 math.Round(x/unit) 与 unit 运算时，math.Round 运算后一定会是一个精确的整数，但是 0.0001 的精度存在误差，所以导致最终得到的结果精度出现了偏差。

格式化与反解析

在这个问题中也有人提出了先用 fmt.Sprintf 对结果进行格式化，然后再采用 strconv.ParseFloat 反向解析，Go Playground 代码在这个里。

source: https://play.golang.org/p/jxILFBYBEF
package main

import (
"fmt"
"strconv"
)

func main() {
fmt.Println(Round(0.363636, 0.05)) // 0.35
fmt.Println(Round(3.232, 0.05))    // 3.25
fmt.Println(Round(0.4888, 0.05))   // 0.5
}

func Round(x, unit float64) float64 {
var rounded float64
if x > 0 {
rounded = float64(int64(x/unit+0.5)) * unit
} else {
rounded = float64(int64(x/unit-0.5)) * unit
}
formatted, err := strconv.ParseFloat(fmt.Sprintf("%.2f", rounded), 64)
if err != nil {
return rounded
}
return formatted
}

这段代码中有点问题，第一是结果不对，和我们理解的存在差异，后来一看第二个参数传错了，应该是 0.01，我想试着调整调整精度吧，我改成了 0.0001 之后发现一直都是保持小数点后两位，我细细研究了下这段代码的逻辑，发现 fmt.Sprintf("%.2f", rounded) 中写死了保留的位数，所以它并不通用，我尝试如下简单调整一下使其生效。

package main

import (
"fmt"
"strconv"
)

func main() {
f := 12.15807659924030304
fmt.Println(Round(f, 0.0001)) // 12.1581

f = 0.15807659924030304
fmt.Println(Round(f, 0.0001)) // 0.1581

fmt.Println(Round(0.363636, 0.0001)) // 0.3636
fmt.Println(Round(3.232, 0.0001))    // 3.232
fmt.Println(Round(0.4888, 0.0001))   // 0.4888
}

func Round(x, unit float64) float64 {
var rounded float64
if x > 0 {
rounded = float64(int64(x/unit+0.5)) * unit
} else {
rounded = float64(int64(x/unit-0.5)) * unit
}

var precision int
for unit < 1 {
precision++
unit *= 10
}

formatted, err := strconv.ParseFloat(fmt.Sprintf("%."+strconv.Itoa(precision)+"f", rounded), 64)
if err != nil {
return rounded
}
return formatted
}

确实获得了满意的精准度，但是其性能也非常客观，达到了 215ns/op，暂时看来如果追求精度，这个算法目前是比较完美的。

大道至简

很快我发现了另一个极简的算法，它的精度和速度都非常的高，实现还特别精简：

package main

import (
"fmt"

"github.com/thinkeridea/go-extend/exmath"
)

func main() {
    f := 0.15807659924030304
    fmt.Println(float64(int64(f*10000+0.5)) / 10000) // 0.1581
}

这并不通用，除非像以下这么包装：

1
2
3

func Round(x, unit float64) float64 {
return float64(int64(x*unit+0.5)) / unit
}

unit 参数和之前的概念不同了，保留一位小数 uint =10，只是整数 uint=1, 想对整数部分进行精度控制 uint=0.01 例如： Round(1555.15807659924030304, 0.01) = 1600，Round(1555.15807659924030304, 1) = 1555，Round(1555.15807659924030304, 10000) = 1555.1581。

这似乎就是终极答案了吧，等等……

终极方案

上面的方法够简单，也够高效，但是 api 不太友好，第二个参数不够直观，带了一定的心智负担，其它语言都是传递保留多少位小数，例如 Round(1555.15807659924030304, 0) = 1555，Round(1555.15807659924030304, 2) = 1555.16，Round(1555.15807659924030304, -2) = 1600，这样的交互才符合人性啊。

别急我在 go-extend 开源了 exmath.Round，其算法符合通用语言 Round 实现，且遵循 Round half up 算法要求，其性能方面在 3.50ns/op, 具体可以参看调优exmath.Round算法，具体代码如下：

//source: https://github.com/thinkeridea/go-extend/blob/main/exmath/round.go

package exmath

import (
"math"
)

// Round 四舍五入，ROUND_HALF_UP 模式实现
// 返回将 val 根据指定精度 precision（十进制小数点后数字的数目）进行四舍五入的结果。precision 也可以是负数或零。
func Round(val float64, precision int) float64 {
p := math.Pow10(precision)
return math.Floor(val*p+0.5) / p
}

总结

Round 功能虽简单，但是受到 float 精度影响，仍然有很多人在四处寻找稳定高效的算法，参阅了大多数资料后精简出 exmath.Round 方法，期望对其他开发者有所帮助，至于其精度使用了大量的测试用例，没有超过 float 精度范围时并没有出现精度问题，未知问题等待社区检验，具体测试用例参见 round_test。

【Go】我与sync.Once的爱恨纠缠

2021-01-01T07:26:31.000Z

官方描述 Once is an object that will perform exactly one action, 即 Once 是一个对象,它提供了保证某个动作只被执行一次功能，最典型的场景就是单例模式，Once 可用于任何符合 “exactly once” 语义的场景。

sync.Once 的用法

在多数情况下，sync.Once 被用于控制变量的初始化，这个变量的读写通常遵循单例模式，满足这三个条件：

当且仅当第一次读某个变量时，进行初始化（写操作）
变量被初始化过程中，所有读都被阻塞（读操作；当变量初始化完成后，读操作继续进行）
变量仅初始化一次，初始化完成后驻留在内存里

在标准库中不乏有大量 sync.Once 的使用案例，在 strings 包中 replace.go 里实现字符串批量替换功能时，需要预编译生成替换规则，即采用不同的替换算法并创建相关算法实例，因 strings.Replacer 实现是线程安全且支持规则复用，在第一次解析替换规则并创建对应算法实例后，可以并发的进行字符串替换操作，避免多次解析替换规则浪费资源。

先看一下 strings.Replacer 的结构定义：

// source: strings/replace.go
type Replacer struct {
once   sync.Once // guards buildOnce method
r      replacer
oldnew []string
}

这里定义了 once sync.Once 用来控制 r replacer 替换算法初始化，当我们使用 strings.NewReplacer 创建 strings.Replacer 时，这里采用惰性算法，并没有在这时进行 build 解析替换规则并创建对应算法实例，而是在执行替换时( Replacer.Replace 和 Replacer.WriteString)进行的, r.once.Do(r.buildOnce) 使用 sync.Once 的 Do 方法保证只有在首次执行时才会执行 buildOnce 方法，而在 buildOnce 中调用 build 解析替换规则并创建对应算法实例，在 buildOnce 中进行赋值。

// source: strings/replace.go
func NewReplacer(oldnew ...string) *Replacer {
if len(oldnew)%2 == 1 {
panic("strings.NewReplacer: odd argument count")
}
return &Replacer{oldnew: append([]string(nil), oldnew...)}
}

func (r *Replacer) buildOnce() {
r.r = r.build()
r.oldnew = nil
}

func (b *Replacer) build() replacer {
    ....
}

func (r *Replacer) Replace(s string) string {
r.once.Do(r.buildOnce)
return r.r.Replace(s)
}

func (r *Replacer) WriteString(w io.Writer, s string) (n int, err error) {
r.once.Do(r.buildOnce)
return r.r.WriteString(w, s)
}

简单来说，once.Do 中的函数只会执行一次，并保证 once.Do 返回时，传入 Do 的函数已经执行完成。多个 goroutine 同时执行 once.Do 的时候，可以保证抢占到 once.Do 执行权的 goroutine 执行完 once.Do 后，其他 goroutine 才能得到返回。

once.Do 接收一个函数作为参数，该函数不接受任何参数，不返回任何参数。具体做什么由使用方决定，错误处理也由使用方控制，对函数初始化的结果也由使用方进行保存。

这给出了一种错误处理的例子 exec.closeOnce，exec.closeOnce 保证了重复关闭文件，永远只执行一次，并且总是返回首次关闭产生的错误信息：

// source: os/exec/exec.go
type closeOnce struct {
*os.File

once sync.Once
err  error
}

func (c *closeOnce) Close() error {
c.once.Do(c.close)
return c.err
}

func (c *closeOnce) close() {
c.err = c.File.Close()
}

对 sync.Once 的爱与恨

Once 的实现非常的灵活、简洁、高效，排除注释部分 Once 仅用 17 行实现，且单次执行时间在 0.3ns 左右。这让我十分敬佩，对它可谓喜爱至极，但因为它的通用性，在使用 Once 时给我带来了一些小小的负担，这也成了我极少的使用它的原因。

Once 只保证调用安全性（即线程安全以及只执行一次动作函数），但是细心的朋友一定发现了我们往往需要配对定义 Once 和业务实例变量，极少使用的情况下（如上述两个例子）看起来并没有什么负担，但是如果我们项目中有大量实例进行管理时（一般是集中管理，便于解决依赖问题），这时就会变得有点丑陋。

一个实际的业务场景，我有一个 http 服务，它有数百个组件实例，我们创建了一个 APP 用来管理所有实例的初始化、依赖关系，从而保证各个组件依赖其接口，相互之间进行解耦，也使得每个组件的配置（初始化参数）、依赖易于管理，不过我们常常对单例实例在 http 服务启动时进行初始化，这样避免使用 Once，且可以在 http 服务启动时暴露外部依赖问题（数据库、其它服务等）。

这个 http 服务需要很多辅助命令，每个命令负责极少的工作，如果我在命令启动时使用 APP 初始化所有组件，这造成了大量的资源浪费。我单独实现一个 Command 依赖管理组件，它大量使用 Once 保证各个组件只在第一次使用时进行初始化，这给我带来了一些困扰，我大量定义 Once 的实例，且它和具体的组件实例没有关联，我在使用时需要非常的小心。

使用过 go-extend/pool 中的 pool.BufferPool 的朋友如果留意其源码的话会发现其中定义了一些 sync.Once 的实例，这相对上诉场景却是相对少的，以下便是 pool.BufferPool 中的部分代码：

// source: https://github.com/thinkeridea/go-extend/blob/v1.1.2/pool/buffer.go

package pool

import (
"bytes"
"sync"
)

var (
buff64   *sync.Pool
buff128  *sync.Pool
buff512  *sync.Pool
buff1024 *sync.Pool
buff2048 *sync.Pool
buff4096 *sync.Pool
buff8192 *sync.Pool

buff64One   sync.Once
buff128One  sync.Once
buff512One  sync.Once
buff1024One sync.Once
buff2048One sync.Once
buff4096One sync.Once
buff8192One sync.Once
)

type pool sync.Pool

// BufferPool bytes.Buffer 的 sync.Pool 接口
// 可以直接 Get *bytes.Buffer 并 Reset Buffer
type BufferPool interface {

// Get 从 Pool 中获取一个 *bytes.Buffer 实例, 该实例已经被 Reset
Get() *bytes.Buffer
// Put 把 *bytes.Buffer 放回 Pool 中
Put(*bytes.Buffer)
}

func newBufferPool(size int) *sync.Pool {
return &sync.Pool{
New: func() interface{} {
return bytes.NewBuffer(make([]byte, size))
},
}
}

// GetBuff64 获取一个初始容量为 64 的 *bytes.Buffer Pool
func GetBuff64() BufferPool {
buff64One.Do(func() {
buff64 = newBufferPool(64)
})

return (*pool)(buff64)
}

上诉代码中定义了 buff64One 到 buff8192One 7个 Once 的实例，且对应的存在 buff64 到 buff8192 的业务实例，我在 GetBuff64 中必须小心使用 Once 实例，避免错误使用导致对应的实例未被初始化，而且上诉的代码看起来还有一些丑陋。

探寻缓和与 sync.Once 的尴尬

鉴于我对 sync.Once 灵活、简洁、高效的喜爱，不能仅仅因为它的“吝啬”（极简的功能）便与之诀别，促使我开启了探寻缓和与 sync.Once 关系之路。

首先我想到的是对 sync.Once 的二次包装，使其可以保存一个数据，这样我就可以只定义 Once 的实例，由 Once 负责存储初始化的结果。exsync.Once 这是我的第一个实验，它的实现非常简洁：

// source: https://github.com/thinkeridea/go-extend/blob/efa13c9456cb4ce97c16824de2996c84fa285fc3/exsync/once.go
type Once struct {
once sync.Once
v    interface{}
}

func (o *Once) Do(f func() interface{}) interface{} {
o.once.Do(func() {
o.v = f()
})

return o.v
}

它嵌套一个 sync.Once 实例，并覆盖其 Do 函数，使其接收一个 func() interface{} 函数，它要求初始化函数返回其结果，结果保存在 Once.v ，每次调用 Do 它便返回自己保存的结果，这使用起来就变得简单许多，改造之前 exec.closeOnce 例子：

type closeOnce struct {
*os.File

once exsync.Once
}

func (c *closeOnce) Close() error {
return c.once.Do(c.close).(error)
}

func (c *closeOnce) close() interface{} {
return c.File.Close()
}

这减少了一个业务层的数据定义，如果包含多个数据，可以使用自定义 struct 或者 []interface{} 进行数据保存，一个简单打开文件的例子：

type openOnce struct {
file exsync.Once
}

func (c *openOnce) Open(name string) (*os.File, error) {
f := c.file.Do(func() interface{} {
f, err := os.Open(name)
return []interface{}{f, err}
}).([]interface{})

return f[0].(*os.File), f[1].(error)
}

这看起来使初始化的代码变得复杂了一些，对多返回值的问题暂时没有更好的实现，我会在后续逐渐考虑这类问题的处理方式，单个值时它使我得到一些惊喜和便捷。即使这样我随后发现它相对 sync.Once 的性能大幅度下降，达到10倍之多，起初我认为是 interface 的带来的，我立刻实现了一个 exsync.OncePointer 以期许它可以在性能上给我一个惊喜：

// source: https://github.com/thinkeridea/go-extend/blob/efa13c9456cb4ce97c16824de2996c84fa285fc3/exsync/once.go
type OncePointer struct {
once sync.Once
v    unsafe.Pointer
}

func (o *OncePointer) Do(f func() unsafe.Pointer) unsafe.Pointer {
o.once.Do(func() {
o.v = f()
})

return o.v
}

使用 unsafe.Pointer 存储实例，让其在编译时确定类型，来提升其性能，使用示例如下：

type closeOnce struct {
*os.File

once exsync.OncePointer
}

func (c *closeOnce) Close() error {
return *(*error)(c.once.Do(c.close))
}

func (c *closeOnce) close() unsafe.Pointer {
err := c.File.Close()
return unsafe.Pointer(&err)
}

尴尬的是这并没有使其性能有极大提升，仅仅只是稍微提升一些，难道我要和 sync.Once 就此诀别，还是凑合过……

转机的到来

我本已放弃优化，即使其性能极大下降，但是它仍然可以在 3ns 内完成任务，这并不会形成瓶颈。但多少内心还是有些不甘，仅仅只是包装使其保存一个值不应该导致性能下降如此严重，究竟是什么导致其性能如此严重下降的，仔细做了分析发现由于 sync.Once 非常的高效，且代码简洁，我嵌套包装使其多了一层调用，且可能导致其无法内联，这对一些性能不高的组件影响极小，但是像 sync.Once 这样高效任何小小的损耗表现都十分明显。

我直接拷贝 sync.Once 中的代码到 exsync.Once 及 exsync.OncePointer 实现中，这让我得到与 sync.Once 接近的性能，exsync.OncePointer 的实现甚至总是好于 sync.Once。

以下是性能测试的结果，其代码位于 exsync/benchmark/once_test.go:

goos: darwin
goarch: amd64
pkg: github.com/thinkeridea/go-extend/exsync/benchmark
BenchmarkSyncOnce-8      1000000000         0.391 ns/op       0 B/op       0 allocs/op
BenchmarkOnce-8          1000000000         0.407 ns/op       0 B/op       0 allocs/op
BenchmarkOncePointer-8   1000000000         0.389 ns/op       0 B/op       0 allocs/op
PASS
ok  github.com/thinkeridea/go-extend/exsync/benchmark1.438s

得到这个结果后我毫不犹豫、马不停蹄的改变了 pool.BufferPool 中的代码，这使 pool.BufferPool 变得简洁许多：

package pool

import (
"bytes"
"sync"
"unsafe"

"github.com/thinkeridea/go-extend/exsync"
)

var (
buff64   exsync.OncePointer
buff128  exsync.OncePointer
buff512  exsync.OncePointer
buff1024 exsync.OncePointer
buff2048 exsync.OncePointer
buff4096 exsync.OncePointer
buff8192 exsync.OncePointer
)

type bufferPool struct {
sync.Pool
}

// BufferPool bytes.Buffer 的 sync.Pool 接口
// 可以直接 Get *bytes.Buffer 并 Reset Buffer
type BufferPool interface {

// Get 从 Pool 中获取一个 *bytes.Buffer 实例, 该实例已经被 Reset
Get() *bytes.Buffer
// Put 把 *bytes.Buffer 放回 Pool 中
Put(*bytes.Buffer)
}

func newBufferPool(size int) unsafe.Pointer {
return unsafe.Pointer(&bufferPool{
Pool: sync.Pool{
New: func() interface{} {
return bytes.NewBuffer(make([]byte, size))
},
},
})
}

// GetBuff64 获取一个初始容量为 64 的 *bytes.Buffer Pool
func GetBuff64() BufferPool {
return (*bufferPool)(buff64.Do(func() unsafe.Pointer {
return newBufferPool(64)
}))
}

总结

如此对 sync.Once 进行二次封装，使其通用性有所下降，并一定是一个好的方案，我乐于公开它，因为它在大多数时刻可以减少使用者的负担，使得代码变的简练。

后续的思考：

Once 永远只能执行一次，是否有安全快捷的方法可以使其重置。
出现错误时，能否提供一种重试机制，否者程序会一直无法得到正确的结果，比如建立数据库连接，某个时刻数据库出现故障，而恰恰这时首次执行了 Do 函数。
对多个值的调用方式上是否能提供简单的调用机制。

解决以上这些问题，可以使 sync.Once 应用在更多的场景中，但势必导致其性能有所下降，这需要一些实验和折中处理。

【Go】高效截取字符串的一些思考

2019-10-30T22:35:34.000Z

最近我在 Go Forum 中发现了 [SOLVED] String size of 20 character 的问题，“hollowaykeanho” 给出了相关的答案，而我从中发现了截取字符串的方案并非最理想的方法，因此做了一系列实验并获得高效截取字符串的方法，这篇文章将逐步讲解我实践的过程。

字节切片截取

这正是 “hollowaykeanho” 给出的第一个方案，我想也是很多人想到的第一个方案，利用 go 的内置切片语法截取字符串：

1 2	s := "abcdef" fmt.Println(s[1:4])

我们很快就了解到这是按字节截取，在处理 ASCII 单字节字符串截取，没有什么比这更完美的方案了，中文往往占多个字节，在 utf8 编码中是3个字节，如下程序我们将获得乱码数据：

1 2	s := "Go 语言" fmt.Println(s[1:4])

杀手锏 - 类型转换 []rune

“hollowaykeanho” 给出的第二个方案就是将字符串转换为 []rune，然后按切片语法截取，再把结果转成字符串。

1
2
3

s := "Go 语言"
rs := []rune(s)
fmt.Println(strings(rs[1:4]))

首先我们得到了正确的结果，这是最大的进步。不过我对类型转换一直比较谨慎，我担心它的性能问题，因此我尝试在搜索引擎和各大论坛查找答案，但是我得到最多的还是这个方案，似乎这已经是唯一的解。

我尝试写个性能测试评测它的性能：

package benchmark

import (
"testing"
)

var benchmarkSubString = "Go语言是Google开发的一种静态强类型、编译型、并发型，并具有垃圾回收功能的编程语言。为了方便搜索和识别，有时会将其称为Golang。"
var benchmarkSubStringLength = 20

func SubStrRunes(s string, length int) string {
if utf8.RuneCountInString(s) > length {
rs := []rune(s)
return string(rs[:length])
}

return s
}

func BenchmarkSubStrRunes(b *testing.B) {
for i := 0; i < b.N; i++ {
SubStrRunes(benchmarkSubString, benchmarkSubStringLength)
}
}

我得到了让我有些吃惊的结果：

goos: darwin
goarch: amd64
pkg: github.com/thinkeridea/go-extend/exunicode/exutf8/benchmark
BenchmarkSubStrRunes-8            872253              1363 ns/op             336 B/op          2 allocs/op
PASS
ok      github.com/thinkeridea/go-extend/exunicode/exutf8/benchmark     2.120s

对 69 个的字符串截取前 20 个字符需要大概 1.3 微秒，这极大的超出了我的心里预期，我发现因为类型转换带来了内存分配，这产生了一个新的字符串，并且类型转换需要大量的计算。

救命稻草 - utf8.DecodeRuneInString

我想改善类型转换带来的额外运算和内存分配，我仔细的梳理了一遍 strings 包，发现并没有相关的工具，这时我想到了 utf8 包，它提供了多字节计算相关的工具，实话说我对它并不熟悉，或者说没有主动（直接）使用过它，我查看了它所有的文档发现 utf8.DecodeRuneInString 函数可以转换单个字符，并给出字符占用字节的数量，我尝试了如此下的实验：

package benchmark

import (
"testing"
"unicode/utf8"
)

var benchmarkSubString = "Go语言是Google开发的一种静态强类型、编译型、并发型，并具有垃圾回收功能的编程语言。为了方便搜索和识别，有时会将其称为Golang。"
var benchmarkSubStringLength = 20

func SubStrDecodeRuneInString(s string, length int) string {
var size, n int
for i := 0; i < length && n < len(s); i++ {
_, size = utf8.DecodeRuneInString(s[n:])
n += size
}

return s[:n]
}

func BenchmarkSubStrDecodeRuneInString(b *testing.B) {
for i := 0; i < b.N; i++ {
SubStrDecodeRuneInString(benchmarkSubString, benchmarkSubStringLength)
}
}

运行它之后我得到了令我惊喜的结果：

goos: darwin
goarch: amd64
pkg: github.com/thinkeridea/go-extend/exunicode/exutf8/benchmark
BenchmarkSubStrDecodeRuneInString-8     10774401               105 ns/op               0 B/op          0 allocs/op
PASS
ok      github.com/thinkeridea/go-extend/exunicode/exutf8/benchmark     1.250s

较 []rune 类型转换效率提升了 13倍，消除了内存分配，它的确令人激动和兴奋，我迫不及待的回复了 “hollowaykeanho” 告诉他我发现了一个更好的方法，并提供了相关的性能测试。

我有些小激动，兴奋的浏览着论坛里各种有趣的问题，在查看一个问题的帮助时 (忘记是哪个问题了-_-||) ，我惊奇的发现了另一个思路。

良药不一定苦 - range 字符串迭代

许多人似乎遗忘了 range 是按字符迭代的，并非字节。使用 range 迭代字符串时返回字符起始索引和对应的字符，我立刻尝试利用这个特性编写了如下用例：

package benchmark

import (
"testing"
)

var benchmarkSubString = "Go语言是Google开发的一种静态强类型、编译型、并发型，并具有垃圾回收功能的编程语言。为了方便搜索和识别，有时会将其称为Golang。"
var benchmarkSubStringLength = 20

func SubStrRange(s string, length int) string {
var n, i int
for i = range s {
if n == length {
break
}

n++
}

return s[:i]
}

func BenchmarkSubStrRange(b *testing.B) {
for i := 0; i < b.N; i++ {
SubStrRange(benchmarkSubString, benchmarkSubStringLength)
}
}

我尝试运行它，这似乎有着无穷的魔力，结果并没有令我失望。

goos: darwin
goarch: amd64
pkg: github.com/thinkeridea/go-extend/exunicode/exutf8/benchmark
BenchmarkSubStrRange-8          12354991                91.3 ns/op             0 B/op          0 allocs/op
PASS
ok      github.com/thinkeridea/go-extend/exunicode/exutf8/benchmark     1.233s

它仅仅提升了13%，但它足够的简单和易于理解，这似乎就是我苦苦寻找的那味良药。

如果你以为这就结束了，不、这对我来只是探索的开始。

终极时刻 - 自己造轮子

喝了 range 那碗甜的腻人的良药，我似乎冷静下来了，我需要造一个轮子，它需要更易用，更高效。

于是乎我仔细观察了两个优化方案，它们似乎都是为了查找截取指定长度字符的索引位置，如果我可以提供一个这样的方法，是否就可以提供用户一个简单的截取实现 s[:strIndex(20)] ，这个想法萌芽之后我就无法再度摆脱，我苦苦思索两天来如何来提供易于使用的接口。

之后我创造了 exutf8.RuneIndexInString 和 exutf8.RuneIndex 方法，分别用来计算字符串和字节切片中指定字符数量结束的索引位置。

我用 exutf8.RuneIndexInString 实现了一个字符串截取测试：

package benchmark

import (
"testing"
"unicode/utf8"

"github.com/thinkeridea/go-extend/exunicode/exutf8"
)

var benchmarkSubString = "Go语言是Google开发的一种静态强类型、编译型、并发型，并具有垃圾回收功能的编程语言。为了方便搜索和识别，有时会将其称为Golang。"
var benchmarkSubStringLength = 20

func SubStrRuneIndexInString(s string, length int) string {
n, _ := exutf8.RuneIndexInString(s, length)
return s[:n]
}

func BenchmarkSubStrRuneIndexInString(b *testing.B) {
for i := 0; i < b.N; i++ {
SubStrRuneIndexInString(benchmarkSubString, benchmarkSubStringLength)
}
}

尝试运行它，我对结果感到十分欣慰：

goos: darwin
goarch: amd64
pkg: github.com/thinkeridea/go-extend/exunicode/exutf8/benchmark
BenchmarkSubStrRuneIndexInString-8      13546849                82.4 ns/op             0 B/op          0 allocs/op
PASS
ok      github.com/thinkeridea/go-extend/exunicode/exutf8/benchmark     1.213s

性能较 range 提升了 10%，让我很欣慰可以再次获得新的提升，这证明它是有效的。

它足够的高效，但是却不够易用，我截取字符串需要两行代码，如果我想截取 10~20之间的字符就需要4行代码，这并不是用户易于使用的接口，我参考了其它语言的 sub_string 方法，我想我应该也设计一个这个样的接口给用户。

exutf8.RuneSubString 和 exutf8.RuneSub 是我认真思索后编写的方法：

func RuneSubString(s string, start, length int) string

它有三个参数：

s : 输入的字符串
start : 开始截取的位置，如果 start 是非负数，返回的字符串将从 string 的 start 位置开始，从 0 开始计算。例如，在字符串 “abcdef” 中，在位置 0 的字符是 “a”，位置 2 的字符串是 “c” 等等。如果 start 是负数，返回的字符串将从 string 结尾处向前数第 start 个字符开始。如果 string 的长度小于 start，将返回空字符串。
length：截取的长度，如果提供了正数的 length，返回的字符串将从 start 处开始最多包括 length 个字符（取决于 string 的长度）。如果提供了负数的 length，那么 string 末尾处的 length 个字符将会被省略（若 start 是负数则从字符串尾部算起）。如果 start 不在这段文本中，那么将返回空字符串。如果提供了值为 0 的 length，返回的子字符串将从 start 位置开始直到字符串结尾。

我为他们提供了别名，根据使用习惯大家更倾向去 strings 包寻找这类问题的解决方法，我创建了exstrings.SubString 和 exbytes.Sub 作为更易检索到的别名方法。

最后我需要再做一个性能测试，确保它的性能：

package benchmark

import (
"testing"

"github.com/thinkeridea/go-extend/exunicode/exutf8"
)

var benchmarkSubString = "Go语言是Google开发的一种静态强类型、编译型、并发型，并具有垃圾回收功能的编程语言。为了方便搜索和识别，有时会将其称为Golang。"
var benchmarkSubStringLength = 20

func SubStrRuneSubString(s string, length int) string {
return exutf8.RuneSubString(s, 0, length)
}

func BenchmarkSubStrRuneSubString(b *testing.B) {
for i := 0; i < b.N; i++ {
SubStrRuneSubString(benchmarkSubString, benchmarkSubStringLength)
}
}

运行它，不会让我失望：

goos: darwin
goarch: amd64
pkg: github.com/thinkeridea/go-extend/exunicode/exutf8/benchmark
BenchmarkSubStrRuneSubString-8          13309082                83.9 ns/op             0 B/op          0 allocs/op
PASS
ok      github.com/thinkeridea/go-extend/exunicode/exutf8/benchmark     1.215s

虽然相较 exutf8.RuneIndexInString 有所下降，但它提供了易于交互和使用的接口，我认为这应该是最实用的方案，如果你追求极致仍然可以使用 exutf8.RuneIndexInString，它依然是最快的方案。

总结

当看到有疑问的代码，即使它十分的简单，依然值得深究，并不停的探索它，这并不枯燥和乏味，反而会有极多收获。

从起初 []rune 类型转换到最后自己造轮子，不仅得到了16倍的性能提升，我还学习了utf8包、加深了range 遍历字符串的特性以及为 go-extend 仓库收录了多个实用高效的解决方案，让更多 go-extend 的用户得到成果。

go-extend 是一个收录实用、高效方法的仓库，读者们如果好的函数和通用高效的解决方案，期待你们不吝啬给我发送 Pull request，你也可以使用这个仓库加快功能实现及提升性能。

【ChatOps系列】GitLab系列环境准备

2019-07-27T02:18:01.000Z

在搭建 GitLab 系列 ChatOps 时需要掌握一些基础的技能知识，整个 ChatOps 涉及到很多方面，我们至少需要掌握以下技能：

Linux 示例中我们主要以 CentOS 7 为主，但是容器内的系统会多种多样
Docker 所有的环境都整合在 Docker 容器中，这能简化搭建的过程以及提升交流的效率
Docker Compose 所有的容器我们均使用 Docker Compose 进行构建，很方便分享
Python 这个很重要，不能忽视它，整个自动部署均是 Pyhon 实现
Fabric 这个是 Python 基于 SSH 的应用部署和系统管理的库，我们基于这库实现从部署机到服务器
JavaScript/CoffeeScript 机器人 hubot 需要这些语言知识来扩展，当然还有一些其它地方会用到这些。
VMware/VirtualBox 需要搭建本地虚拟机模拟环境，示例使用 VirtualBox 演示

需要掌握的技能会很多，如果你已经掌握，那么跟着教程可以很快的完成 ChatOps 的部署，如果还没有掌握，可以找时间简单学习一下。其中一些组件是可以替换的，比如：Fabric 就有很多选择，例如：Ansible、Shell 等可以用来操作远程机器的工具。当然也可以使用机器人连接 Jenkins、Kubernetes 等支持自动部署的服务，本系列中使用 hubot-gitlab-deploy 结合 Fabric 来实现自动部署。

虚拟机搭建

我下载的是 CentOS7 Minimal ISO 版本的镜像，如果对 linux 比较熟悉，那么安装任何版本系统都是可以的，这里并不详细讲解 Liunx 的全部安装过程，只讲解虚拟机配置及系统相关配置，供大家搭建时做参考。

VirtualBox 分配 4G 内存、500G 磁盘，同时添加两块网卡，一个是 Host-Only 模式，一个是 NAT 模式。

Host-Only 模式网卡可以给主机和虚拟机之间提供私有的虚拟网络，我们实验环境需要一个稳定的不受实际网络影响的虚拟网络，我是笔记本经常办公司到家里，网络环境会改变，但是我主机和虚拟机通信网络不会变化。

NAT 模式网卡是为了虚拟机可以上网，实际 Host-Only 的网卡也可以上网，但是它只能是使用有线连接时可以，我的笔记本大多数都是 WiFi 连接网络，这导致我没有办法上网，增加这块网卡可以实现上网，但是主机无法访问虚拟机，所以我需要两块网卡结合使用。

大家只需要能够让主机访问虚拟机，虚拟机可以访问虚拟机，虚拟机可以访问网络（我们需要安装一些东西）。

系统分区可以根据自己的喜好进行，我尽量模拟真实的生成环境，一个较小的系统盘，阿里云服务器是 40G，一块数据盘，我把其它容量都分配给 /data 数据盘。

$ df -h
文件系统        容量  已用  可用 已用% 挂载点
/dev/sda1        40G  1.2G   39G    3% /  # 系统盘
devtmpfs        1.9G     0  1.9G    0% /dev
tmpfs           1.9G     0  1.9G    0% /dev/shm
tmpfs           1.9G  8.5M  1.9G    1% /run
tmpfs           1.9G     0  1.9G    0% /sys/fs/cgroup
/dev/sda3       452G   33M  452G    1% /data  # 数据盘
tmpfs           379M     0  379M    0% /run/user/0

安装完成系统，登陆之后需要给虚拟机设置一个固定 ip。使用 ip address 查看网卡信息，找到 192.168.*.* 的网卡，记录下网卡名称，我的是 enp0s3，然后编辑网卡对应的配置文件 /etc/sysconfig/network-scripts/ifcfg-enp0s3，具体如下：

TYPE="Ethernet"
PROXY_METHOD="none"
BROWSER_ONLY="no"
BOOTPROTO="static"  # 使用静态网络
DEFROUTE="yes"
IPV4_FAILURE_FATAL="no"
IPV6INIT="yes"
IPV6_AUTOCONF="yes"
IPV6_DEFROUTE="yes"
IPV6_FAILURE_FATAL="no"
IPV6_ADDR_GEN_MODE="stable-privacy"
NAME="enp0s3"
UUID="6f19c6e8-87de-42a5-afdb-2fe8a8bc74a8"
DEVICE="enp0s3"
ONBOOT="yes" # 开机启动
IPADDR=192.168.56.6  # 网络地址，根据之前查询的网段分配
NETMASK=255.255.255.0 # 子网掩码
#GATEWAY=192.168.56.1 #默认网关，如果和我的网络配置一致就不用配置了
#DNS1=192.168.7.1 #DNS 配置，如果和我的网络配置一致就不用配置了

重启网卡 systemctl restart network 使配置生效，然后在主机使用 ssh 登陆虚拟机，确定网络畅通，ssh root@192.168.56.6。

之后我们就可以使用 “无界面” 启动虚拟机，使用 ssh 登陆虚拟机进行配置。

Docker 环境安装

官网有完整的安装教程在：https://docs.docker.com/install/linux/docker-ce/centos/ ，有两种安装方式，我使用在线安装的方式，由于官方镜像无法访问，这里采用阿里云的镜像，只需要执行以下命令即可：

$ yum install -y yum-utils device-mapper-persistent-data lvm2
......
$ yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
......
$ yum install docker-ce docker-ce-cli containerd.io
......
$ systemctl enable docker
......
$ systemctl start docker
......
$ docker version
Client: Docker Engine - Community
 Version:           19.03.1
 API version:       1.40
 Go version:        go1.12.5
 Git commit:        74b1e89
 Built:             Thu Jul 25 21:21:07 2019
 OS/Arch:           linux/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.1
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.5
  Git commit:       74b1e89
  Built:            Thu Jul 25 21:19:36 2019
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.2.6
  GitCommit:        894b81a4b802e4eb2a91d1ce216b8817763c29fb
 runc:
  Version:          1.0.0-rc8
  GitCommit:        425e105d5a03fabd737a126ad93d62a9eeede87f
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

Docker 已经安装完成了，但是还需要配置一下，首先建议去阿里云申请一个 Docker 镜像加速器地址，去 https://cr.console.aliyun.com/undefined/instances/mirrors 申请，然后配置 /etc/docker/daemon.json 文件：

$ vi /etc/docker/daemon.json
{
"data-root": "/data/docker",
"registry-mirrors": [
"https://yourcode.mirror.aliyuncs.com" # 替换成你申请到地址
]
}

$ make /data/docker
$ systemctl restart docker

Docker Compose 安装

相关的文档在 https://docs.docker.com/compose/install/ ，安装比较简单，执行下面的命令即可：

$ curl -L "https://github.com/docker/compose/releases/download/1.24.1/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose

$ chmod +x /usr/local/bin/docker-compose

$ docker-compose version
docker-compose version 1.24.1, build 4667896b
docker-py version: 3.7.3
CPython version: 3.6.8
OpenSSL version: OpenSSL 1.1.0j  20 Nov 2018

总结

基础环境配置还是比较简单的，配置过程中遇到任何问题多 google 或者在文末留言。

整个体系涉及的技术点比较宽泛，学习者需要多准备和学习。

【ChatOps系列】ChatOps简介

2019-07-21T08:17:01.000Z

要说 ChatOps 就不得不说 DevOps，DevOps 是来源于 Development 和 Operations 的一个组合词，顾名思义，是一系列过程、方法与系统的统称，旨在促进开发、测试和运维人员之间的沟通与协作。简单来说，是通过引入一系列的「工具」，通过三种不同角色的开发成员间的「协作」而实现的一种「自动化」的工作模式。这种工作方式带来的好处显而易见：

实现持续快速交付
能够降低人力成本

但很大程度上，DevOps 更多是指开发群体之间的一种协作模式（通常也在开发人员中实施），随着全行业的发展和人力成本的攀升，在团队所有角色间贯通的升级版「DevOps」逐渐登场，也就是我们将要重点介绍的 ChatOps。

ChatOps介绍

ChatOps 的历史相对短暂，2013 年 GitHub 内部最早开始推行 ChatOps，希望能以聊天的方式更容易更快速的去完成 DevOps 承载的工作。

ChatOps 以聊天室，即沟通平台为中心，通过一系列的机器人去对接后台的各种服务，工作人员只需要在聊天窗口中与机器人对话，即可与后台服务进行交互，整个工作的展开就像是使唤一个智能助手那样简单自然。

ChatOps 站在巨人的肩膀上发展，也为工作带来了显而易见的好处：

公开透明。所有的工作消息都在同一个聊天平台中沉淀并公开给所有相关成员，消除沟通壁垒，工作历史有迹可循，团队合作更加顺畅。
上下文共享。减少因工作台切换等对消息的截断，保证消息的完整性，让工作承接有序，各角色，各工具都成为完成工作流中的一环，打造真正流畅的工作体验。
移动友好。只需要在前台与预设好的机器人对话即可完成与后台工具、系统的交互，在移动环境下无需再与众多复杂的工具直接对接，大大提升移动办公的可行性。
DevOps 文化打造。用与机器人对话这种简单的方式降低 DevOps 的接受门槛，让这种自动化办公的理念更容易的扩展到团队的每一个角落。

ChatOps 主要由三个部分构成：聊天室（控制中心）、机器人（连接中心）、基础设施，基础设施主要是支撑我们业务运行的各种服务与工具，在构建 ChatOps 时主要需要选择聊天室和机器人，国外早期的工作沟通工具 HipChat，新秀 Slack 都是作为 ChatOps 承载平台的好选择，在中文的环境下，则可以选择 BearyChat（倍洽）等等。

聊天室选择：

功能完备
操作交互友好
多平台支持
API 丰富
三方工具支持丰富
机器人支持程度

机器人选择：

功能完备
易扩展（我们可能需要根据基础设施编写大量机器人扩展）
编程语言熟悉（因为我们需要编写扩展）
开源扩展丰富（可以极大减少开发工作量）

聊天室主要有：Slack、HipChat、BearyChat（倍洽）、Rocket.Chat、钉钉（机器人支持程度不够，不太支持）。机器人主要有：Hubot（javascript/CoffeeScript）、Lita（Ruby），Errbot（python）。

机器人我推荐使用 Hubot，后面所有的实验都使用 Hubot 展开。 GitHub 团队内部实现的 ChatOps 与一个叫做 Hubot 的机器人框架密切相关，Hubot 提供很多聊天机器人所需的基础设施，借助 Hubot 框架能比较方便的和自己编写的功能或自己的系统对接。目前，Hubot 已经发展出了较好的生态圈，有很多开源插件可以借用。

ChatOps实现

本系列专题主要讲两种实现，一种是基于 GitHub+Hubot+Slack 实现，一种基于开源体系的 GitLab + Hubot + Rocket.Chat，它们功能完善且有良好的扩展及丰富的API，只要爱倒腾一定会有意想不到的收获。

GitHub 体系：

slack 聊天室
Hubot 机器人
GitHub 代码管理
Travis CI 自动化测试
heaven 自动部署
hubot-deploy 连接 Hubot 与 heaven

GitLab 体系：

Recket.chat 聊天室
Hubot 机器人
GitLab 代码管理
GitLab CI 自动化测试
hubot-gitlab-deploy 自动化部署（计划重构中）
fabric-deploy-script 基于配置的 fabric 自动部署实现 (计划开源中)

本系列会介绍各种设计服务安装、配置，以及各种服务组件之间连接配置等，同时会涉及到项目配置管理、密钥管理等相关知识。

计划

本系列主要涉及 ChatOps 环境搭建、工具配置，以及项目的持续集成、持续部署的实现，持续部署过程会涉及到密钥管理、配置管理等等。

本系列计划一至两周一篇文章，每篇文章介绍一个点，两种体系都会讲到，大约20~30篇文章，优先讲解开源体系的 GitLab 篇。

在这期间会开发相关机器人脚本及相关服务组件，可以形成项目会发布在 GitHub 上，不能形成项目的会在文章中，最后所有实验相关代码均可在 GitHub 上 chatops_experiment 中获取。

测试中需要自动部署的项目会单独存储在一个账号/组织下面，具体详见每个章节。

【Go】类似csv的数据日志组件设计

2019-07-16T22:52:34.000Z

我们业务每天需要记录大量的日志数据，且这些数据十分重要，它们是公司收入结算的主要依据，也是数据分析部门主要得数据源，针对这么重要的日志，且高频率的日志，我们需要一个高性能且安全的日志组件，能保证每行日志格式完整性，我们设计了一个类 csv 的日志拼接组件，它的代码在这里 datalog。

它是一个可以保证日志各列完整性且高效拼接字段的组件，支持任意列和行分隔符，而且还支持数组字段，可是实现一对多的日志需求，不用记录多个日志，也不用记录多行。它响应一个 []byte 数据，方便结合其它主键写入数据到日志文件或者网络中。

使用说明

API 列表

NewRecord(len int) Record 创建长度固定的日志记录
NewRecordPool(len int) *sync.Pool 创建长度固定的日志记录缓存池
ToBytes(sep, newline string) []byte 使用 sep 连接 Record，并在末尾添加 newline 换行符
ArrayJoin(sep string) string 使用 sep 连接 Record，其结果作为数组字段的值
ArrayFieldJoin(fieldSep, arraySep string) string 使用 fieldSep 连接 Record，其结果作为一个数组的单元
Clean() 清空 Record 中的所有元素，如果使用 sync.Pool 在放回 Pool 之前应该清空 Record，避免内存泄漏
UnsafeToBytes(sep, newline string) []byte 使用 sep 连接 Record，并在末尾添加 newline 换行符，使用原地替换会破坏日志字段引用的字符串
UnsafeArrayFieldJoin(fieldSep, arraySep string) string 使用 fieldSep 连接 Record，其结果作为一个数组的单元，使用原地替换会破坏日志字段引用的字符串

底层使用 type Record []string 字符串切片作为一行或者一个数组字段，在使用时它应该是定长的，因为数据日志往往是格式化的，每列都有自己含义，使用 NewRecord(len int) Record 或者 NewRecordPool(len int) *sync.Pool 创建组件，我建议每个日志使用 NewRecordPool 在程序初始化时创建一个缓存池，程序运行时从缓存次获取 Record 将会更加高效，但是每次放回 Pool 时需要调用 Clean 清空 Record 避免引用字符串无法被回收，而导致内存泄漏。

实践

我们需要保证日志每列数据的含义一至，我们创建了定长的 Record，但是如何保证每列数据一致性，利用go 的常量枚举可以很好的保证，例如我们定义日志列常量：

const (
LogVersion = "v1.0.0"
)
const (
LogVer = iota
LogTime
LogUid
LogUserName
LogFriends

LogFieldNumber
)

LogFieldNumber 就是日志的列数量，也就是 Record 的长度，之后使用 NewRecordPool 创建缓存池，然后使用常量名称作为下标记录日志，这样就不用担心因为检查或者疏乎导致日志列错乱的问题了。

var w bytes.Buffer // 一个日志写组件
var pool = datalog.NewRecordPool(LogFieldNumber) // 创建一个缓存池

func main() {
  r := pool.Get().(datalog.Record)
  r[LogVer] = LogVersion
  r[LogTime] = time.Now().Format("2006-01-02 15:04:05")
  // 检查用户数据是否存在
  //if user ！=nil{
    r[LogUid] = "Uid"
    r[LogUserName] = "UserNmae"
  //}

  // 拼接一行日志数据
  data := r.Join(datalog.FieldSep, datalog.NewLine)
  r.Clean() // 清空 Record
  pool.Put(r) // 放回到缓存池

  // 写入到日志中
  if _, err := w.Write(data); err != nil {
    panic(err)
  }

  // 打印出日志数据
  fmt.Println("'" + w.String() + "'")
}

以上程序运行会输出：

因为分隔符是不可见字符，下面使用,代替字段分隔符，使用;\n代替换行符，使用/代替数组字段分隔符，是-代替数组分隔符。

1	'v1.0.0,2019-07-18,11:39:09,Uid,UserNmae,;\n'

即使我们没有记录 LogFriends 列的数据，但是在日志中它仍然有一个占位符，如果 user 是 nil，LogUid 和 LogUserName 不需要特殊处理，也不需要写入数据，它依然占据自己的位置，不用担心日志因此而错乱。

使用 pool 可以很好的利用内存，不会带来过多的内存分配，而且 Record 的每个字段值都是字符串，简单的赋值并不会带来太大的开销，它会指向字符串本身的数据，不会有额外的内存分配，详细参见string 优化误区及建议。
使用 Record.Join 可以高效的连接一行日志记录，便于我们快速的写入的日志文件中，后面设计讲解部分会详细介绍 Join 的设计。

包含数组的日志

有时候也并非都是记录一些单一的值，比如上面 LogFriends 会记录当前记录相关的朋友信息，这可能是一组数据，datalog 也提供了一些简单的辅助函数，可以结合下面的实例实现：

// 定义 LogFriends 数组各列的数据
const (
LogFriendUid = iota
LogFriendUserName

LogFriendFieldNumber
)

var w bytes.Buffer // 一个日志写组件
var pool = datalog.NewRecordPool(LogFieldNumber) // 每行日志的 pool
var frPool = datalog.NewRecordPool(LogFriendFieldNumber) // LogFriends 数组字段的 pool

func main(){
  // 程序运行时
  r := pool.Get().(datalog.Record)
  r[LogVer] = LogVersion
  r[LogTime] = time.Now().Format("2006-01-02 15:04:05")
  // 检查用户数据是否存在
  //if user ！=nil{
    r[LogUid] = "Uid"
    r[LogUserName] = "UserNmae"
  //}

  // 拼接一个数组字段，其长度是不固定的
  r[LogFriends] = GetLogFriends(rand.Intn(3))
  // 拼接一行日志数据
  data := r.Join(datalog.FieldSep, datalog.NewLine)
  r.Clean() // 清空 Record
  pool.Put(r) // 放回到缓存池

  // 写入到日志中
  if _, err := w.Write(data); err != nil {
    panic(err)
  }

  // 打印出日志数据
  fmt.Println("'" + w.String() + "'")
}

// 定义一个函数来拼接 LogFriends 
func GetLogFriends(friendNum int) string {
  // 根据数组长度创建一个 Record，数组的个数往往是不固定的，它整体作为一行日志的一个字段，所以并不会破坏数据
fs := datalog.NewRecord(friendNum) 
 // 这里只需要中 pool 中获取一个实例，它可以反复复用
fr := frPool.Get().(datalog.Record)
for i := 0; i < friendNum; i++ {
    // fr.Clean() 如果不是每个字段都赋值，应该在使用前或者使用后清空它们便于后面复用
fr[LogFriendUid] = "FUid"
fr[LogFriendUserName] = "FUserName"
    
     // 连接一个数组中各个字段，作为一个数组单元
fs[i] = fr.ArrayFieldJoin(datalog.ArrayFieldSep, datalog.ArraySep)
}
fr.Clean() // 清空 Record
frPool.Put(fr)  // 放回到缓存池

  // 连接数组的各个单元，返回一个字符串作为一行日志的一列
return fs.ArrayJoin(datalog.ArraySep)
}

以上程序运行会输出：

因为分隔符是不可见字符，下面使用,代替字段分隔符，使用;\n代替换行符，使用/代替数组字段分隔符，是-代替数组分隔符。

1	'v1.0.0,2019-07-18,11:39:09,Uid,UserNmae,FUid/FUserName-FUid/FUserName;\n'

这样在解析时可以把某一字段当做数组解析，这极大的极大的提高了数据日志的灵活性，
但是并不建议使用过多的层级，数据日志应当清晰简洁，但是有些特殊场景可以使用一层嵌套。

最佳实践

使用 ToBytes 和 ArrayFieldJoin 时会把数据字段中的连接字符串替换一个空字符串，所以在 datalog 里面定义了4个分隔符，它们都是不可见字符，极少会出现在数据中，但是我们还需要替换数据中的这些连接字符，避免破坏日志结构。

虽然组件支持各种连接符，但是为了避免数据被破坏，我们应该选择一些不可见且少见的单字节字符作为分隔符。换行符比较特殊，因为大多数日志读取组件都是用 \n 作为行分隔符，如果数据中极少出现 \n 那就可以使用 \n， datalog 中定义 \x03\n 作为换行符，它兼容一般的日志读取组件，只需要我们做少量的工作就可以正确的解析日志了。

UnsafeToBytes 和 UnsafeArrayFieldJoin 性能会更好，和它们的名字一样，他们并不安全，因为它们使用 exbytes.Replace 做原地替换分隔符，这会破坏数据所指向的原始字符串。除非我们日志数据中会出现极多的分隔符需要替换，否者并不建议使用它们，因为它们只在替换时提升性能。

我在服务中大量使用 UnsafeToBytes 和 UnsafeArrayFieldJoin ，我总是在一个请求结束时记录日志，我确保所有相关的数据不会再使用，所以不用担心原地替换导致其它数据被无感知改变的问题，这也许是一个很好的实践，但是我仍然不推荐使用它们。

设计讲解

datalog 并没有提供太多的约束很功能，它仅仅包含一种实践和一组辅助工具，在使用它之前，我们需要了解这些实践。

它帮我们创建一个定长的日志行或者一个sync.Pool，我们需要结合常量枚举记录数据，它帮我们把各列数据连接成记录日志需要的数据格式。

它所提供的辅助方法都经过实际项目的考验，考量诸多细节，以高性能为核心目标所设计，使用它可以极大的降低相关组件的开发成本，接下来这节将分析它的各个部分。

我认为值得说道的是它提供的一个 Join 方法，相对于 strings.Join 可以节省两次的内存分配，现从它开始分析。

// Join 使用 sep 连接 Record， 并在末尾追加 suffix
// 这个类似 strings.Join 方法，但是避免了连接后追加后缀（往往是换行符）导致的内存分配
// 这个方法直接返回需要的 []byte 类型， 可以减少类型转换，降低内存分配导致的性能问题
func (l Record) Join(sep, suffix string) []byte {
if len(l) == 0 {
return []byte(suffix)
}

n := len(sep) * (len(l) - 1)
for i := 0; i < len(l); i++ {
n += len(l[i])
}

n += len(suffix)
b := make([]byte, n)
bp := copy(b, l[0])
for i := 1; i < len(l); i++ {
bp += copy(b[bp:], sep)
bp += copy(b[bp:], l[i])
}
copy(b[bp:], suffix)
return b
}

日志组件往往输入的参数是 []byte 类型，所以它直接返回一个 []byte ，而不像 strings.Join 响应一个字符串，在末尾是需要对内部的 buf 进行类型转换，导致额外的内存开销。我们每行日志不仅需要使用分隔符连接各列，还需要一个行分隔符作为结尾，它提供一个后缀 suffix，不用我们之后在 Join 结果后再次拼接行分隔符，这样也能减少一个额外的内存分配。

这恰恰是 datalog 设计的精髓，它并没有大量使用标准库的方法，而是设计更符合该场景的方法，以此来获得更高的性能和更好的使用体验。

// ToBytes 使用 sep 连接 Record，并在末尾添加 newline 换行符
// 注意：这个方法会替换 sep 与 newline 为空字符串
func (l Record) ToBytes(sep, newline string) []byte {
   for i := len(l) - 1; i >= 0; i-- {
      // 提前检查是否包含特殊字符，以便跳过字符串替换
      if strings.Index(l[i], sep) < 0 && strings.Index(l[i], newline) < 0 {
         continue
      }

      b := []byte(l[i]) // 这会重新分配内存，避免原地替换导致引用字符串被修改
      b = exbytes.Replace(b, exstrings.UnsafeToBytes(sep), []byte{' '}, -1)
      b = exbytes.Replace(b, exstrings.UnsafeToBytes(newline), []byte{' '}, -1)
      l[i] = exbytes.ToString(b)
   }

   return l.Join(sep, newline)
}

ToBytes 作为很重要的交互函数，也是该组件使用频率最高的函数，它在连接各个字段之前替换每个字段中的字段和行分隔符，这里提前做了一个检查字段中是否包含分隔符，如果包含使用 []byte(l[i]) 拷贝该列的数据，然后使用 exbytes.Replace 提供高性能的原地替换，因为输入数据是拷贝重新分配的，所以不用担心原地替换会影响其它数据。

之后使用之前介绍的 Join 方法连接各列数据，如果使用 strings.Join 将会是 []byte(strings.Join([]string(l), sep) + newline) 这其中会增加很多次内存分配，该组件通过巧妙的设计规避这些额外的开销，以提升性能。

// UnsafeToBytes 使用 sep 连接 Record，并在末尾添加 newline 换行符
// 注意：这个方法会替换 sep 与 newline 为空字符串，替换采用原地替换，这会导致所有引用字符串被修改
// 必须明白其作用，否者将会导致意想不到的结果。但是这会大幅度减少内存分配，提升程序性能
// 我在项目中大量使用，我总是在请求最后记录日志，这样我不会再访问引用的字符串
func (l Record) UnsafeToBytes(sep, newline string) []byte {
   for i := len(l) - 1; i >= 0; i-- {
      b := exstrings.UnsafeToBytes(l[i])
      b = exbytes.Replace(b, exstrings.UnsafeToBytes(sep), []byte{' '}, -1)
      b = exbytes.Replace(b, exstrings.UnsafeToBytes(newline), []byte{' '}, -1)
      l[i] = exbytes.ToString(b)
   }

   return l.Join(sep, newline)
}

UnsafeToBytes 和 ToBytes 相似只是没有分割符检查，因为exbytes.Replace 中已经包含了检查，而且直接使用 exstrings.UnsafeToBytes 把字符串转成 []byte 这不会发生数据拷贝，非常的高效，但是它不支持字面量字符串，不过我相信日志中的数据均来自运行时分配，如果不幸包含字面量字符串，也不用太过担心，只要使用一个特殊的字符作为分隔符，往往我们编程字面量字符串并不会包含这些字符，执行 exbytes.Replace 没有发生替换也是安全的。

// Clean 清空 Record 中的所有元素，如果使用 sync.Pool 在放回 Pool 之前应该清空 Record，避免内存泄漏
// 该方法没有太多的开销，可以放心的使用，只是为 Record 中的字段赋值为空字符串，空字符串会在编译时处理，没有额外的内存分配
func (l Record) Clean() {
   for i := len(l) - 1; i >= 0; i-- {
      l[i] = ""
   }
}

Clean 方法更简单，它只是把各个列的数据替换为空字符串，空字符串做为一个特殊的字符，会在编译时处理，并不会有额外的开销，它们都指向同一块内存。

// ArrayJoin 使用 sep 连接 Record，其结果作为数组字段的值
func (l Record) ArrayJoin(sep string) string {
   return exstrings.Join(l, sep)
}

// ArrayFieldJoin 使用 fieldSep 连接 Record，其结果作为一个数组的单元
// 注意：这个方法会替换 fieldSep 与 arraySep 为空字符串，替换采用原地替换
func (l Record) ArrayFieldJoin(fieldSep, arraySep string) string {
   for i := len(l) - 1; i >= 0; i-- {
      // 提前检查是否包含特殊字符，以便跳过字符串替换
      if strings.Index(l[i], fieldSep) < 0 && strings.Index(l[i], arraySep) < 0 {
         continue
      }

      b := []byte(l[i]) // 这会重新分配内存，避免原地替换导致引用字符串被修改
      b = exbytes.Replace(b, exstrings.UnsafeToBytes(fieldSep), []byte{' '}, -1)
      b = exbytes.Replace(b, exstrings.UnsafeToBytes(arraySep), []byte{' '}, -1)
      l[i] = exbytes.ToString(b)
   }

   return exstrings.Join(l, fieldSep)
}

ArrayFieldJoin 在连接各个字符串时会直接替换数组单元分隔符，之后直接使用 exstrings.Join 进行连接字符串，exstrings.Join 相对 strings.Join 的一个改进函数，因为它只有一次内存分配，较 strings.Join 节省一次，有兴趣可以去看它的源码实现。

总结

datalog 提供了一种实践以及一些辅助工具，可以帮助我们快速的记录数据日志，更关心数据本身。具体程序性能可以交给 datalog 来实现，它保证程序的性能。

后期我会计划提供一个高效的日志读取组件，以便于读取解析数据日志，它较与一般文件读取会更加高效且便捷，有针对性的优化日志解析效率，敬请关注吧。

【Go】使用压缩文件优化io (二)

2019-07-07T09:32:51.000Z

上一篇文章《使用压缩文件优化io (一)》中记录了日志备份 io 优化方案，使用文件流数据压缩方案优化 io 性能，效果十分显著。这篇文章记录数据分析前置清洗、格式化数据的 io 优化方案，我们有一台专用的日志前置处理服务器，所有业务日志通过这台机器从 OSS 拉取回来清洗、格式化，最后进入到数据仓储中便于后续的分析。

随着业务扩展这台服务器压力越来越大，高峰时数据延迟越来越厉害，早期也是使用 Python 脚本 + awk 以及一些 shell 命令完成相关工作，在数据集不是很大的时候这种方案很好，效率也很高，随着数据集变大，发现服务器负载很高，经过分析是还是 io 阻塞，依旧采用对数据流进行处理的方案优化io，以下记录优化的过程。

背景介绍

服务器配置：4 核 8G；磁盘：1T

分析前置服务会根据业务不同分为十分钟、一小时两个阶段拉取分析日志，每隔一个阶段会去 OSS 拉取日志回到服务器进行处理，处理过程因 io 阻塞，导致 CPU 和 load 异常高，且处理效率严重下降，这次优化主要就是降低 io 阻塞，提升 CPU 利用率 (处理业务逻辑而不是等待 io) 和处理效率。

后文中会详细描述优化前后的方案，并用 go 编写测试，使用一台 2 核4G的服务器进行测试，测试数据集大小为：

文件数量：432个
压缩文件：17G
解压后文件：63G
压缩方案：lzo
Goroutine 数量：20

优化前

优化前日志处理流程：

获取待处理文件列表
拉取 OSS 日志到本地磁盘 (压缩文件)
解压缩日志文件
读取日志数据
业务处理……
导入到数据仓储中

导致 io 阻塞的部分主要是：拉取 OSS 日志、解压缩日志文件及读取日志数据，优化也主要从这三块着手。

这里有一段公共的日志读取方法，该方法接收一个 io.Reader，并按行读取日志，并简单切分日志字段，并没有实质的处理日志数据，后面的优化方案也将使用这个方法读取日志。

package main

import (
"bufio"
"bytes"
"io"

"github.com/thinkeridea/go-extend/exbytes"
)

func Read(r io.Reader) {
rawBuffer := make([]byte, 512)
buf := bufio.NewReader(r)
for {
line, ok, err := readLine(buf, rawBuffer)
if err == io.EOF {
return
}

if err != nil {
panic(nil)
}

if ok {
rawBuffer = line
}

c := bytes.Count(line, []byte{'\x01'})
if c != 65 {
panic("无效的行")
}
}
}

func readLine(r *bufio.Reader, rawBuffer []byte) ([]byte, bool, error) {
var ok bool
line, err := r.ReadSlice('\n')
if (err == bufio.ErrBufferFull || len(line) < 3 || exbytes.ToString(line[len(line)-3:]) != "\r\r\n") && err != io.EOF {
rawBuffer = append(rawBuffer[:0], line...)
for (err == bufio.ErrBufferFull || len(line) < 3 || exbytes.ToString(line[len(line)-3:]) != "\r\r\n") && err != io.EOF {
line, err = r.ReadSlice('\n')
rawBuffer = append(rawBuffer, line...)
}
line = rawBuffer
ok = true
}

if len(line) > 0 && err == io.EOF {
err = nil
}

return line, ok, err
}

日志按 \r\r\n 分隔行，使用 \x01 切分字段，读取方法使用 bufio.ReadSlice 方法，避免内存分配，且当 bufio 缓冲区满之后使用 rwaBuffer 作为本地可扩展缓冲，每次扩展之后会保留最大的扩展空间，因为业务日志每行大小差不多，这样可以极大的减少内存分配，效率是 bufio.ReadLine 方法的好几倍。

package main

import (
"fmt"
"os"
"os/exec"
"path/filepath"
"strings"
"sync"
"time"

".../pkg/aliyun_oss" // 虚假的包
)

func main() {
var oss *aliyun_oss.AliyunOSS // 对接阿里云 OSS，需要自行封装
files := list()               // 这是一个虚构的方法，用来获取待处理的文件列表

fmt.Printf("待处理文件数量：%d\n", len(files))

start := time.Now()
defer func(t time.Time) {
fmt.Printf("共耗时：%0.6f\n", time.Now().Sub(t).Seconds())
}(start)

// 下载日志文件
n := 20
var wg sync.WaitGroup
c := make(chan string)
wg.Add(n)
for i := 0; i < n; i++ {
go func() {
defer wg.Done()
for {
f, ok := <-c
if !ok {
return
}

if _, err := os.Stat(f); err == nil {
return
} else if !os.IsNotExist(err) {
panic(err)
}

dir := filepath.Dir(f)
err := os.MkdirAll(dir, 0755)
if err != nil {
panic(err)
}

err = oss.GetObjectToFile(f, f)
if err != nil {
panic(err)
}
}
}()
}

for _, f := range files {
c <- f
}

close(c)
wg.Wait()

fmt.Printf("下载文件耗时：%0.6f\n", time.Now().Sub(start).Seconds())

// 解压日志文件
start = time.Now()
shell := exec.Command("/bin/bash", "-c", "lzop -df logs/*/*/*/*/*/*.lzo")
err := shell.Run()
if err != nil {
panic(err)
}

fmt.Printf("解压文件耗时：%0.6f\n", time.Now().Sub(start).Seconds())

// 读取日志文件
start = time.Now()
c = make(chan string)
wg.Add(n)
for i := 0; i < n; i++ {
go func() {
defer wg.Done()
for {
file, ok := <-c
if !ok {
return
}
f, err := os.Open(file)
if err != nil {
panic(err)
}

Read(f)
f.Close()
}
}()
}

for _, f := range files {
c <- strings.TrimRight(f, ".lzo")
}

close(c)
wg.Wait()

fmt.Printf("读取文件耗时：%0.6f\n", time.Now().Sub(start).Seconds())
}

运行程序输出如下：

待处理文件数量：432
下载文件耗时：303.562865
解压文件耗时：611.236232
读取文件耗时：460.371245
共耗时：1375.187261

通过 iostat -m -x 5 10000 分析各个阶段结果如下：

下载时：

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
   7.85    0.00   16.44   11.24    0.00   64.48

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     0.00   80.40    7.80     8.98     0.04   209.36     0.40    4.57    4.64    3.77   0.50   4.44
vdb               1.40   761.20  247.60  264.00    14.70    60.92   302.72     9.17   17.92   10.36   25.00   0.52  26.52

解压时：

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
   8.54    0.00    8.33   68.39    0.00   14.74

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     1.20    3.40   11.80     0.01     0.05     8.95     0.30   20.03    0.41   25.68   0.55   0.84
vdb               0.00 22037.80  107.80  243.20    26.45   107.01   778.71    83.52  236.68   74.31  308.65   2.52  88.54

读取时：

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
   2.74    0.00    5.07   92.19    0.00    0.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     2.40    3.80   23.60     0.01     0.14    11.85     0.12    4.48    1.95    4.89   0.33   0.90
vdb               1.80     4.60  347.20    6.20   139.97     0.08   811.60   126.62  358.04  360.79  203.48   2.83 100.00

通过 iostat 结果可以看出，在解压和读取日志时 io 阻塞比较严重，且运行时间较长，下载时 io 阻塞也存在，但还可以接受，通过下面两个方案逐渐消除掉 io。

优化方案一

优化前的方案反应出在解压和读取日志时 io 阻塞比较严重，那么是否可以通过读取 lzo 压缩文件，以此来消除解压缩日志耗时太大、io 太高的问题呢？并且读取 lzo 压缩文件远比解压后文件小，来降低读取日志耗时太大、io 太高的问题呢？

优化后日志处理流程：

获取待处理文件列表
拉取 OSS 日志到本地磁盘 (压缩文件)
读取压缩日志数据
业务处理……
导入到数据仓储中

package main

import (
"fmt"
"os"
"path/filepath"
"sync"
"time"

".../pkg/aliyun_oss" // 虚假的包
"github.com/cyberdelia/lzo"
)

func main() {
var oss *aliyun_oss.AliyunOSS // 对接阿里云 OSS，需要自行封装
files := list()               // 这是一个虚构的方法，用来获取待处理的文件列表

fmt.Printf("待处理文件数量：%d\n", len(files))
start := time.Now()
defer func(t time.Time) {
fmt.Printf("共耗时：%0.6f\n", time.Now().Sub(t).Seconds())
}(start)

// 下载日志文件
n := 20
var wg sync.WaitGroup
c := make(chan string)
wg.Add(n)
for i := 0; i < n; i++ {
go func() {
defer wg.Done()
for {
f, ok := <-c
if !ok {
return
}

if _, err := os.Stat(f); err == nil {
return
} else if !os.IsNotExist(err) {
panic(err)
}

dir := filepath.Dir(f)
err := os.MkdirAll(dir, 0755)
if err != nil {
panic(err)
}

err = oss.GetObjectToFile(f, f)
if err != nil {
panic(err)
}
}
}()
}

for _, f := range files {
c <- f
}

close(c)
wg.Wait()

fmt.Printf("下载文件耗时：%0.6f\n", time.Now().Sub(start).Seconds())

start = time.Now()
c = make(chan string)
wg.Add(n)
for i := 0; i < n; i++ {
go func() {
defer wg.Done()
for {
file, ok := <-c
if !ok {
return
}
f, err := os.Open(file)
if err != nil {
panic(err)
}

r, err := lzo.NewReader(f)
if err != nil {
panic(err)
}

Read(r)
r.Close()
f.Close()
}
}()
}

for _, f := range files {
c <- f
}

close(c)
wg.Wait()

fmt.Printf("读取文件耗时：%0.6f\n", time.Now().Sub(start).Seconds())
}

这个方案消除了解压缩日志，并且直接读取压缩日志，使用 github.com/cyberdelia/lzo 包对压缩文件数据流进行边读取边解压，这次不用单独封装新的方法了，直接使用 lzo 包中的接口即可。

程序运行结果如下：

待处理文件数量：432
下载文件耗时：286.146603
读取文件耗时：132.787345
共耗时：418.942862

这个方案效果非常明显，总耗时从 1375.187261 降低到 418.942862 提升了 3 倍的效率，不仅消除了压缩的时间，还大大缩短了读取文件耗时，成果显著。

通过 iostat -m -x 5 10000 分析各个阶段结果如下：

下载时：

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
   5.08    0.00   13.24   29.34    0.00   52.33

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     2.80    1.40   11.80     0.01     0.07    12.00     0.02    1.85    1.14    1.93   0.18   0.24
vdb               0.00 17207.60    0.60  212.40     0.00    75.06   721.74    55.81  236.34   84.33  236.77   2.49  53.14

读取时：

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
  80.66    0.00    4.83   14.50    0.00    0.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     0.00    6.20    0.20     0.06     0.00    20.00     0.01    1.69    1.71    1.00   0.62   0.40
vdb               0.00     6.80  390.40   19.20   118.78     0.23   595.04    74.87  190.55  197.95   40.08   1.85  75.90

通过 iostat 结果分析，下载时 io 阻塞和优化前波动不是很大，读取时的 io 优化已经非常好了，iowait 从 92.19% 降低到 14.5% ，CPU 更多的任务用来处理解压缩日志，而不是处理 io 阻塞。

优化方案二

本来优化到上面的效果已经非常满意了，不过既然开始做优化就不能草草结束了，仔细思考业务场景，需要本地 lzo 文件？重新处理日志的频率高吗？本地 lzo 日志清理方便吗？

通过上面的几个问题发现，除非程序出现问题或者数据存储出现故障，否者极少需要重新处理日志，一年里面这种情况也是极少的，甚至不会发生。

那么思考一下，不下载日志，直接读取网络数据流，实现边下边解压边读取，这样岂不是没有 io 了吗?

优化后日志处理流程：

获取待处理文件列表
拉取 OSS 日志，在内存中解压并读取分析日志
业务处理……
导入到数据仓储中

具体实现如下：

package main

import (
"fmt"
"sync"
"time"

".../pkg/aliyun_oss" // 虚假的包
"github.com/cyberdelia/lzo"
)

func main() {
var oss *aliyun_oss.AliyunOSS // 对接阿里云 OSS，需要自行封装
files := list()               // 这是一个虚构的方法，用来获取待处理的文件列表

fmt.Printf("待处理文件数量：%d\n", len(files))

start := time.Now()
defer func(t time.Time) {
fmt.Printf("共耗时：%0.6f\n", time.Now().Sub(t).Seconds())
}(start)

n := 20
var wg sync.WaitGroup
c := make(chan string)
wg.Add(n)
for i := 0; i < n; i++ {
go func() {
defer wg.Done()
for {
f, ok := <-c
if !ok {
return
}

r1, err := oss.GetObject(f)
if err != nil {
panic(err)
}

r, err := lzo.NewReader(r1)
if err != nil {
panic(err)
}

Read(r)
r.Close()
r1.Close()
}
}()
}

for _, f := range files {
c <- f
}

close(c)
wg.Wait()

fmt.Printf("读取文件耗时：%0.6f\n", time.Now().Sub(start).Seconds())
}

优化后只有一个流程了，代码简洁了不少，看看效率如何吧！

程序运行结果如下：

1
2
3

待处理文件数量：432
读取文件耗时：285.993661
共耗时：285.993717

天啊发生了什么，我使劲擦了擦眼睛，太不可思议了，居然只消耗了下载日志的耗时，较上一个方案总耗时从 418.942862 降低到 285.993717，提升了近 2 倍的效率，让我们看看上个方案下载文件耗时 286.146603 ，而新方案总耗时是 285.993717 居然只用了上个优化版本的下载时间，究竟发生了什么？

通过 iostat -m -x 5 10000 分析结果如下：

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
  43.73    0.00    9.64    0.31    0.00   46.32

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     1.20    4.40    3.80     0.02     0.03    10.93     0.01    1.49    0.59    2.53   0.71   0.58
vdb               0.00     6.80    0.00   24.60     0.00     0.27    22.83     0.02    0.84    0.00    0.84   0.28   0.68

通过 iostat 结果分析，在程序运行期间没有任何 io 开销，CPU 居然还有一半的空闲，前面两个版本 CPU 是没有空闲的啊，由此看来之前 CPU 更多的消耗在 io 阻塞上了，并没有用来处理业务逻辑。

由此来看也就不足为奇了，为啥优化后只需要下载日志的时间就能处理完所有日志了，没有了 io 阻塞，CPU 更多了用来处理业务，把之前下载时写文件 io 的耗时，用来解压缩数据，读取数据，且还有更多的空闲，跑出这样的结果也就很正常了。

总结

从优化前耗时 1375.187261 秒到 285.993717 秒，性能提升 80%，从 iowait 92.19% 到 0.31% 提升近 100%，从没有任何 CPU 空闲到有一半空闲，这个过程中有很多值得总结的事情。

io 对性能的影响非常大，对 CPU 占用非常严重，导致 CPU 处理业务逻辑的时间片非常少。从 io 转移到 CPU 对性能提升非常明显。CPU 计算效率十分的高，从 io 密集到密集计算，只要符合业务场景，往往能给我们带来意想不到的效果。

往往优化业务并不需要十分高大上的技术，只是转变一下思路，不仅代码更少，且程序更简短、好维护、逻辑更清晰。

一定要结合实际业务场景进行思考，减少理所当然和业务无关的中间环节，往往就可以极大的提升程序效率。

【Go】使用压缩文件优化io (一)

2019-06-30T11:02:57.000Z

最近遇到一个日志备份 io 过高的问题，业务日志每十分钟备份一次，本来是用 Python 写一个根据规则扫描备份日志问题不大，但是随着业务越来越多，单机上的日志文件越来越大，文件数量也越来越多，导致每每备份的瞬间 io 阻塞严重， CPU 和 load 异常的高，好在备份速度很快，对业务影响不是很大，这个问题会随着业务增长，越来越明显，这段时间抽空对备份方式做了优化，效果十分显著，整理篇文章记录一下。

背景说明

服务器配置：4 核 8G；磁盘：500G
每十分钟需要上传：18 个文件，高峰时期约 10 G 左右

业务日志为了保证可靠性，会先写入磁盘文件，每10分钟切分日志文件，然后在下十分钟第一分时备份日志到 OSS，数据分析服务会从在备份完成后拉取日志进行分析，日志备份需要高效快速，在最短的时间内备份完，一般备份均能在几十秒内完成。

备份的速度和效率并不是问题，足够的快，但是在备份时 io 阻塞严重导致的 CPU 和 load 异常，成为业务服务的瓶颈，在高峰期业务服务仅消耗一半的系统资源，但是备份时 CPU 经常 100%，且 iowait 可以达到 70 多，空闲资源非常少，这样随着业务扩展，日志备份虽然时间很短，却成为了系统的瓶颈。

后文中会详细描述优化前后的方案，并用 go 编写测试，使用一台 2 核4G的服务器进行测试，测试数据集大小为：

文件数：336
原始文件：96G
压缩文件：24G
压缩方案：lzo
Goroutine 数量：4

优化前

优化前日志备份流程：

根据备份规则扫描需要备份的文件
使用 lzop 命令压缩日志
上传压缩后的日志到 OSS

下面是代码实现，这里不再包含备份文件规则，仅演示压缩上传逻辑部分，程序接受文件列表，并对文件列表压缩上传至 OSS 中。

.../pkg/aliyun_oss 是我自己封装的基于阿里云 OSS 操作的包，这个路径是错误的，仅做演示，想运行下面的代码，OSS 交互这部分需要自己实现。

package main

import (
"bytes"
"fmt"
"os"
"os/exec"
"path/filepath"
"sync"
"time"

".../pkg/aliyun_oss"
)

func main() {
var oss *aliyun_oss.AliyunOSS
files := os.Args[1:]
if len(files) < 1 {
fmt.Println("请输入要上传的文件")
os.Exit(1)
}

fmt.Printf("待备份文件数量：%d\n", len(files))

startTime := time.Now()
defer func(startTime time.Time) {
fmt.Printf("共耗时：%s\n", time.Now().Sub(startTime).String())
}(startTime)

var wg sync.WaitGroup
n := 4
c := make(chan string)

// 压缩日志
wg.Add(n)
for i := 0; i < n; i++ {
go func() {
defer wg.Done()
for file := range c {
cmd := exec.Command("lzop", file)
cmd.Stderr = &bytes.Buffer{}
err := cmd.Run()
if err != nil {
panic(cmd.Stderr.(*bytes.Buffer).String())
}
}
}()
}

for _, file := range files {
c <- file
}

close(c)
wg.Wait()
fmt.Printf("压缩耗时：%s\n", time.Now().Sub(startTime).String())

// 上传压缩日志
startTime = time.Now()
c = make(chan string)
wg.Add(n)
for i := 0; i < n; i++ {
go func() {
defer wg.Done()
for file := range c {
name := filepath.Base(file)
err := oss.PutObjectFromFile("tmp/"+name+".lzo", file+".lzo")
if err != nil {
panic(err)
}
}
}()
}

for _, file := range files {
c <- file
}

close(c)
wg.Wait()
fmt.Printf("上传耗时：%s\n", time.Now().Sub(startTime).String())
}

程序运行时输出：

待备份文件数量：336
压缩耗时：19m44.125314226s
上传耗时：6m14.929371103s
共耗时：25m59.118002969s

从运行结果中可以看出压缩文件耗时很久，实际通过 iostat 命令分析也发现，压缩时资源消耗比较高，下面是 iostat -m -x 5 10000 命令采集各个阶段数据。

程序运行前

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           2.35    0.00    2.86    0.00    0.00   94.79

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
vdb               0.00     0.60    0.00    0.60     0.00     4.80    16.00     0.00    0.67    0.00    0.67   0.67   0.04

压缩日志时

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          10.84    0.00    6.85   80.88    0.00    1.43

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     0.00    0.60    0.00     2.40     0.00     8.00     0.00    0.67    0.67    0.00   0.67   0.04
vdb              14.80  5113.80 1087.60   60.60 78123.20 20697.60   172.13   123.17  106.45  106.26  109.87   0.87 100.00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          10.06    0.00    7.19   79.06    0.00    3.70

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     0.00    1.60    0.00   103.20     0.00   129.00     0.01    3.62    3.62    0.00   0.50   0.08
vdb              14.20  4981.20  992.80   52.60 79682.40 20135.20   190.97   120.34  112.19  110.60  142.17   0.96 100.00

上传日志时

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           6.98    0.00    7.81    7.71    0.00   77.50

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     0.00   13.40    0.00   242.40     0.00    36.18     0.02    1.63    1.63    0.00   0.19   0.26
vdb               0.40     2.40  269.60    1.20 67184.80    14.40   496.30     4.58   15.70   15.77    0.33   1.39  37.74

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           7.06    0.00    8.00    4.57    0.00   80.37

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     0.00    0.60    0.00    75.20     0.00   250.67     0.00    2.67    2.67    0.00   2.00   0.12
vdb               0.20     0.00  344.80    0.00 65398.40     0.00   379.34     5.66   16.42   16.42    0.00   1.27  43.66

从 iostat 的结果中发现，压缩时程序 r_await 和 w_await 都到了一百多，且 iowait 高达 80.88%，几乎耗尽了所有的 CPU，上传时 iowait 是可以接受的，因为只是单纯的读取压缩文件，且压缩文件也很小。

分析问题

上述结果中发现程序主要运行消耗在压缩日志，那优化也着重日志压缩的逻辑上。

压缩时日志会先压缩成 lzo 文件，然后再上传 lzo 文件到阿里云 OSS 上，这中间发生了几个过程：

读取原始日志文件
压缩数据
写入 lzo 文件
读取 lzo 文件
http 发送读取的内容

压缩时 r_await 和 w_await 都很高，主要发生在读取原始日志文件，写入 lzo 文件，怎么优化呢？

先想一下原始需求，读取原始文件 -> 上传数据。但是直接上传原始文件，文件比较大，网络传输慢，而且存储费用也比较高，怎么办呢？

这个时候我们期望可以上传的是压缩文件，所以就有了优化前的逻辑，这里面产生了一个中间过程，即使用 lzop 命令压缩文件，而且产生了一个中间文件 lzo 文件。

读取原始文件和上传数据是必须的，那么可以优化的就是压缩的流程了，所以 r_await 是没有办法优化的，那么只能优化 w_await，w_await 是怎么产生的呢，恰恰是写入lzo 时产生的，可以不要 lzo 文件吗？这个文件有什么作用？

如果我们压缩文件数据流，在读取原始文件 -> 上传数据流程中对上传的数据流进行实时压缩，把压缩的内容给上传了，实现边读边压缩，对数据流进行处理，像是一个中间件，这样就不用写 lzo 文件了，那么 w_await 就被完全优化没了。

lzo 文件有什么作用？我想只有在上传失败之后可以节省一次文件压缩的消耗。上传失败的次数多吗？我用阿里云 OSS 好几年了，除了一次内网故障，再也没有遇到过上传失败的文件，我想是不需要这个文件的，而且生成 lzo 文件还需要占用磁盘空间，定时清理等等，增加了资源消耗和维护成本。

优化后

根据之前的分析看一下优化之后备份文件需要哪些过程：

读取原始日志
在内存中压缩数据流
http 发送压缩后的内容

这个流程节省了两个步骤，写入 lzo 文件和读取 lzo 文件，不仅没有 w_await，就连 r_await 也得到了小幅度的优化。

优化方案确定了，可是怎么实现 lzo 对文件流进行压缩呢，去 Github 上找一下看看有没有 lzo 的压缩算法库，发现 github.com/cyberdelia/lzo ，虽然是引用 C 库实现的，但是经典的两个算法（lzo1x_1 和 lzo1x_999）都提供了接口，貌似 Go 可以直接用了也就这一个库了。

发现这个库实现了 io.Reader 和 io.Writer 接口，io.Reader 读取压缩文件流，输出解压缩数据，io.Writer 实现输入原始数据，并写入到输入的 io.Writer。

想实现压缩数据流，看来需要使用 io.Writer 接口了，但是这个输入和输出都是 io.Writer，这可为难了，因为我们读取文件获得是 io.Reader，http 接口输入也是 io.Reader，貌似没有可以直接用的接口，没有办法实现了吗，不会我们自已封装一下，下面是封装的 lzo 数据流压缩方法：

package lzo

import (
"bytes"
"io"

"github.com/cyberdelia/lzo"
)

type Reader struct {
r    io.Reader
rb   []byte
buff *bytes.Buffer
lzo  *lzo.Writer
err  error
}

func NewReader(r io.Reader) *Reader {
z := &Reader{
r:    r,
rb:   make([]byte, 256*1024),
buff: bytes.NewBuffer(make([]byte, 0, 256*1024)),
}

z.lzo, _ = lzo.NewWriterLevel(z.buff, lzo.BestSpeed)
return z
}

func (z *Reader) compress() {
if z.err != nil {
return
}

var nr, nw int
nr, z.err = z.r.Read(z.rb)
if z.err == io.EOF {
if err := z.lzo.Close(); err != nil {
z.err = err
}
}

if nr > 0 {
nw, z.err = z.lzo.Write(z.rb[:nr])
if z.err == nil && nr != nw {
z.err = io.ErrShortWrite
}
}
}

func (z *Reader) Read(p []byte) (n int, err error) {
if z.err != nil {
return 0, z.err
}

if z.buff.Len() <= 0 {
z.compress()
}

n, err = z.buff.Read(p)
if err == io.EOF {
err = nil
} else if err != nil {
z.err = err
}

return
}

func (z *Reader) Reset(r io.Reader) {
z.r = r
z.buff.Reset()
z.err = nil
z.lzo, _ = lzo.NewWriterLevel(z.buff, lzo.BestSpeed)
}

这个库会固定消耗 512k 内存，并不是很大，我们需要创建一个读取 buf 和一个压缩缓冲 buf，都是256k的大小，实际压缩缓冲的 buf 并不需要 256k，毕竟压缩后数据会比原始数据小，考虑空间并不是很大，直接分配 256k 避免运行时分配。

实现原理当 http 从输入的 io.Reader (实际就是我们上面封装的 lzo 库)，读取数据时，这个库检查压缩缓冲是否为空，为空的情况会从文件读取 256k 数据并压缩输入到压缩缓冲中，然后从压缩缓冲读取数据给 http 的 io.Reader，如果压缩缓冲区有数据就直接从压缩缓冲区读取压缩数据。

这并不是线程安全的，并且固定分配 512k 的缓冲，所以也提供了一个 Reset 方法，来复用这个对象，避免重复分配内存，但是需要保证一个 lzo 对象实例只能被一个 Goroutine 访问，这可以使用 sync.Pool 来保证，下面的代码我用另一种方法来保证。

package main

import (
"fmt"
"os"
"path/filepath"
"sync"
"time"

".../pkg/aliyun_oss"
".../pkg/lzo"
)

func main() {
var oss *aliyun_oss.AliyunOSS
files := os.Args[1:]
if len(files) < 1 {
fmt.Println("请输入要上传的文件")
os.Exit(1)
}

fmt.Printf("待备份文件数量：%d\n", len(files))

startTime := time.Now()
defer func() {
fmt.Printf("共耗时：%s\n", time.Now().Sub(startTime).String())
}()

var wg sync.WaitGroup
n := 4
c := make(chan string)

// 压缩日志
wg.Add(n)
for i := 0; i < n; i++ {
go func() {
defer wg.Done()
var compress *lzo.Reader

for file := range c {
r, err := os.Open(file)
if err != nil {
panic(err)
}

if compress == nil {
compress = lzo.NewReader(r)
} else {
compress.Reset(r)
}

name := filepath.Base(file)
err = oss.PutObject("tmp/"+name+"1.lzo", compress)
r.Close()
if err != nil {
panic(err)
}
}
}()
}

for _, file := range files {
c <- file
}

close(c)
wg.Wait()
}

程序为每个 Goroutine 分配一个固定的 compress ，当需要压缩文件的时候判断是创建还是重置，来达到复用的效果。

该程序运行输出:

1 2	待备份文件数量：336 共耗时 18m20.162441931s

实际耗时比优化前提升了 28%, 实际通过 iostat 命令分析也发现，资源消耗也有了明显的改善，下面是 iostat -m -x 5 10000 命令采集各个阶段数据。

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          15.72    0.00    6.58   74.10    0.00    3.60

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
vdb               3.80     3.40 1374.20    1.20 86484.00    18.40   125.79   121.57   87.24   87.32    1.00   0.73 100.00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          26.69    0.00    8.42   64.27    0.00    0.62

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00     0.20  426.80    0.80  9084.80     4.00    42.51     2.69    6.29    6.30    1.00   0.63  26.92
vdb               1.80     0.00 1092.60    0.00 72306.40     0.00   132.36   122.06  108.45  108.45    0.00   0.92 100.02

通过 iostat 发现只有 r_await， w_await 被完全优化，iowait 有明显的改善，运行时间更短了，效率更高了，对 io 产生影响的时间也更短了。

优化期间遇到的问题

首先对找到的 lzo 算法库进行测试，确保压缩和解压缩没有问题，并且和 lzop 命令兼容。

在这期间发现使用压缩的数据比 lzop 压缩数据大了很多，之后阅读了源码实现，并没有发现任何问题，尝试调整缓冲区大小，发现对生成的压缩文件大小有明显改善。

这个发现让我也很为难，究竟多大的缓冲区合适呢，只能去看 lzop 的实现了，发现 lzop 默认压缩块大小为 256k, 实际 lzo 算法支持的最大块大小就是 256k，所以实现 lzo 算法包装是创建的是 256k 的缓冲区的，这个缓冲区的大小就是压缩块的大小，大家使用的时候建议不要调整了。

总结

这个方案上线之后，由原来需要近半分钟上传的，改善到大约只有十秒（Go 语言本身效率也有很大帮助），而且 load 有了明显的改善。

优化前每当运行日志备份，CPU 经常爆表，优化后备份时 CPU 增幅 20%，可以从容应对业务扩展问题了。

测试是在一台空闲的机器上进行的，实际生产服务器本身 w_await 会有 20 左右，如果使用固态硬盘，全双工模式，读和写是分离的，那么优化掉 w_await 对业务的帮助是非常大的，不会阻塞业务日志写通道了。

当然我们服务器是高速云盘(机械盘)，由于机械盘物理特征只能是半双工，要么读、要么写，所以优化掉 w_await 确实效率会提升很多，但是依然会对业务服务写有影响。

【Go】获取用户真实的ip地址

2019-03-27T23:02:57.000Z

用户请求到达提供服务的服务器中间有很多的环节，导致服务获取用户真实的 ip 非常困难，大多数的框架及工具库都会封装各种获取用户真实 ip 的方法，在 exnet 包中也封装了各种 ip 相关的操作，其中就包含获取客户端 ip 的方法，比较实用的方法如下：

func ClientIP(r *http.Request) string ClientIP 尽最大努力实现获取客户端 IP 的算法。解析 X-Real-IP 和 X-Forwarded-For 以便于反向代理（nginx 或 haproxy）可以正常工作。
func ClientPublicIP(r *http.Request) string ClientPublicIP 尽最大努力实现获取客户端公网 IP 的算法。解析 X-Real-IP 和 X-Forwarded-For 以便于反向代理（nginx 或 haproxy）可以正常工作。
func HasLocalIP(ip net.IP) bool HasLocalIP 检测 IP 地址是否是内网地址
func HasLocalIPddr(ip string) bool HasLocalIPddr 检测 IP 地址字符串是否是内网地址
func RemoteIP(r *http.Request) string RemoteIP 通过 RemoteAddr 获取 IP 地址，只是一个快速解析方法。

获取用户真实ip地址

ClientIP 方法与 ClientPublicIP 方法的实现类似，只是一个按照 http 协议约定获取客户端 ip，一个按照约定格式查找到公网 ip。

在网络与服务架构、业务逻辑复杂的环境中，按照 http 协议约定的方式，并非总能获取到真实的 ip，在我们的业务中用户流量经由三方多层级转发(都是三方自己实现的http client) ，难免会出现一些纰漏，这时越往后的服务获取用户真实 ip 越加困难，你甚至不知道自己获取的 ip 是否是真实的。

但是我们的客户经由三方转发而来的流量，那么客户极大多数甚至排除测试之外都是公网用户，结合使用 ClientPublicIP 和 ClientIP 方法总能更好的获取用户的真实 ip。

// var r *http.Request
ip := exnet.ClientPublicIP(r)
if ip == ""{
  ip = exnet.ClientIP(r)
}

用上面的方法总能有效的获取用户真实的 ip 地址，下面分析下两个方法的具体实现。

// ClientIP 尽最大努力实现获取客户端 IP 的算法。
// 解析 X-Real-IP 和 X-Forwarded-For 以便于反向代理（nginx 或 haproxy）可以正常工作。
func ClientIP(r *http.Request) string {
xForwardedFor := r.Header.Get("X-Forwarded-For")
ip := strings.TrimSpace(strings.Split(xForwardedFor, ",")[0])
if ip != "" {
return ip
}

ip = strings.TrimSpace(r.Header.Get("X-Real-Ip"))
if ip != "" {
return ip
}

if ip, _, err := net.SplitHostPort(strings.TrimSpace(r.RemoteAddr)); err == nil {
return ip
}

return ""
}

ClientIP 首先读取 X-Forwarded-For header 中用 , 分隔的第一个ip地址，如果这个地址不存在，就会从 X-Real-Ip header 中获取，如果还是不存在，说明流量并非是由反向代理转发而来，而是客户端直接请求服务，这时通过 http.Request.RemoteAddr 字段截取除去端口号的 ip 地址。

这个方法很简单，就是按照 http 约定的格式获取，其中 X-Forwarded-For 和 X-Real-Ip header 由反向代理填充，例如 nginx 或 haproxy。

// ClientPublicIP 尽最大努力实现获取客户端公网 IP 的算法。
// 解析 X-Real-IP 和 X-Forwarded-For 以便于反向代理（nginx 或 haproxy）可以正常工作。
func ClientPublicIP(r *http.Request) string {
var ip string
for _, ip = range strings.Split(r.Header.Get("X-Forwarded-For"), ",") {
ip = strings.TrimSpace(ip)
if ip != "" && !HasLocalIPddr(ip) {
return ip
}
}

ip = strings.TrimSpace(r.Header.Get("X-Real-Ip"))
if ip != "" && !HasLocalIPddr(ip) {
return ip
}

if ip, _, err := net.SplitHostPort(strings.TrimSpace(r.RemoteAddr)); err == nil {
if !HasLocalIPddr(ip) {
return ip
}
}

return ""
}

ClientPublicIP 很简单，和 ClientIP 方法的读取顺序一样，只是试图中 X-Forwarded-For 列表中找到一个公网ip，如果没有检查 X-Real-Ip 是否是一个公网 ip，其次检查 http.Request.RemoteAddr 是否是公网ip，如果没有找到公网 ip 这返回一个空字符串。

这个方法可以让我们有机会优先获取到用户的公网 ip，往往公网 ip 对我们来说更有价值。

检查ip对否是内网地址

exnet 中还提供了检查 ip 地址是否是内网地址，这在有些情况下非常有用，比如：服务中有些接口只能内网访问，也就是只允许管理员访问（例如动态设定日志级别、查看服务 pprof 信息）；我们想隐藏后端服务，只暴露给用户负载均衡(反向代理)，用户无法直接访问我们的服务，这些方法及其有用，下面看看具体实现。

我的服务提供了动态设置日志级别，以便服务出现问题，可以第一时间查看调试日志分析具体原因，但是这个接口很危险，不应该暴露给公网，所以会用路由中间件检查请求是否来自公网，来自公网则返回 404。

该方法认为如下地址段都是内网地址：

10.0.0.0/8
169.254.0.0/16
172.16.0.0/12
172.17.0.0/12
172.18.0.0/12
172.19.0.0/12
172.20.0.0/12
172.21.0.0/12
172.22.0.0/12
172.23.0.0/12
172.24.0.0/12
172.25.0.0/12
172.26.0.0/12
172.27.0.0/12
172.28.0.0/12
172.29.0.0/12
172.30.0.0/12
172.31.0.0/12
192.168.0.0/16

// HasLocalIPddr 检测 IP 地址字符串是否是内网地址
func HasLocalIPddr(ip string) bool {
return HasLocalIP(net.ParseIP(ip))
}

// HasLocalIP 检测 IP 地址是否是内网地址
func HasLocalIP(ip net.IP) bool {
for _, network := range localNetworks {
if network.Contains(ip) {
return true
}
}

return ip.IsLoopback()
}

两个检查方法实现差异仅接受参数类型不一致，检查过程都是逐个对比内网 ip 段是否包含该ip地址，如果不包含则判断该地址是否是回环地址。

获取反向代理ip

如何判断改地址来自反向代理服务器呢，不同的反向代理实现都有些差异，4 层反向代理甚至可以提供用户的真实 ip（http.Request.RemoteAddr 是用户的ip，而不是反向代理的），而隐藏自己的ip，这里说一下常见的方法。

往往 http.Request.RemoteAddr 保存最后一个连接服务的客户端 ip，我们获取反向代理的ip地址，最简单有效的方法就是通过 http.Request.RemoteAddr 获取， exnet 中提供了 RemoteIP 的快捷方法，实现如下：

// RemoteIP 通过 RemoteAddr 获取 IP 地址， 只是一个快速解析方法。
func RemoteIP(r *http.Request) string {
if ip, _, err := net.SplitHostPort(strings.TrimSpace(r.RemoteAddr)); err == nil {
return ip
}

return ""
}

这是一个非常方便的脚手架，它仅仅切分 http.Request.RemoteAddr 的 ip 和端口，并返回有效的ip地址，但却可以简化我们的编写业务代码。

【Go】IP地址转换：数字与字符串之间的转换

2019-03-24T23:34:57.000Z

IP 地址库中 IP 地址的保存格式一般有两种，一种是点分十进制形式(192.168.1.1)，另一种是数字形式(3232235777)，应用中，经常需要在这两种格式之间做转换。

针对这一个问题我在 exnet 扩展包里面实现可两者的转换的快捷方法：

func IP2Long(ip net.IP) (uint, error) IP2Long 把 net.IP 转为数值
func Long2IP(i uint) (net.IP, error) Long2IP 把数值转为 net.IP
func IPString2Long(ip string) (uint, error) IPString2Long 把 ip 字符串转为数值
func Long2IPString(i uint) (string, error) Long2IPString 把数值转为 ip 字符串

使用示例：

package main

import (
"fmt"
"net"
"reflect"

"github.com/thinkeridea/go-extend/exnet"
)

func main() {
ip := "192.168.1.1"

n, _ := exnet.IPString2Long(ip)
s, _ := exnet.Long2IPString(n)

fmt.Println(n, s == ip)

Ip1 := net.ParseIP(ip) // 会得到一个16字节的byte，主要为了兼容ipv6
n, _ = exnet.IP2Long(Ip1)

Ip2, _ := exnet.Long2IP(n)

fmt.Println(n, reflect.DeepEqual(Ip1[12:], Ip2))
}

那么是如何将点分十进制的IP地址转为数字？
IPv4 地址有4个字节，样式如下：
MSB————–LSB
b4 b3 b2 b1

每个字节表示的范围：

byte4: 4294967296(1<<32)
byte3: 16777216(1<<24)
byte2: 65536(1<<16)
byte1: 256(1<<8)

通用公式：b4<<24 | b3<<16 | b2<<8 | b1
例如，222.173.108.86
转换方法：222<<24 | 173<<16 | 108<<8 | 86 = 3735907414
再例如，1.0.1.1
转换方法：1<<24 | 0<<16 | 1<<8 | 1 = 16777473

exnet 中实现如下：

// IPString2Long 把ip字符串转为数值
func IPString2Long(ip string) (uint, error) {
b := net.ParseIP(ip).To4()
if b == nil {
return 0, errors.New("invalid ipv4 format")
}

return uint(b[3]) | uint(b[2])<<8 | uint(b[1])<<16 | uint(b[0])<<24, nil
}

把数值转换为字符串的逻辑翻转过来即可， exnet 中实现如下：

// Long2IPString 把数值转为ip字符串
func Long2IPString(i uint) (string, error) {
if i > math.MaxUint32 {
return "", errors.New("beyond the scope of ipv4")
}

ip := make(net.IP, net.IPv4len)
ip[0] = byte(i >> 24)
ip[1] = byte(i >> 16)
ip[2] = byte(i >> 8)
ip[3] = byte(i)

return ip.String(), nil
}

【Go】go get 自动代理

2019-03-20T23:34:57.000Z

最近发现技术交流群里很多人在询问 go get 墙外包失败的问题，大家给了很多解决方案：

从 Github 的代码库 clone
设置 GOPROXY 环境变量配置代理, 例如：GOPROXY=https://goproxy.io
配置命令行代理，https_proxy 环境变量
使用 go mod replace
使用 Gopm 类似的工具
……

Go 的社区很活跃，国内 gopher 对 Go 的热情不会因为墙的存在而减少，从社区想到这么多翻墙方案就能看出来了。

上面的方法都是可行的，但是总有一些不尽人意，社区也一直在找更好的方法，我一直使用自动代理的方式获取墙外的包，可以支持所有 Go 原生拉取包操作，比如 go get、go mod、dep、godep、glide 等各种方法，只需要配置一次，只要在任何原生命令前加前缀运行命令即可，效率很高。

实战操作

工具类就先不讲原理，想直接获取方法的同学看这一部分即可，想了解原理的同学可以看后面的原理部分。

你需要准备如下工具：

一个 http 代理
Git
Github 账号设置好 ssh
其它 git 相关服务设置好 ssh (例如自建 gitlab)
一个可以运行shell的环境 (linux、Mac、windows 可以使用 git bash)

具体步骤

首先通过 git 设置需要不代理的网站，以 Github 为例，执行 git config --global url.git@github.com:.insteadof https://github.com/ 从 https 转到 ssh 协议，这样会使我们设置的 https 代理不作用在 ssh 协议上，如果有自建的服务只要更换地址就可以了。

新建一个脚本 (proxy)，修改里面的代理地址为自己的代理地址，如下：

#!/usr/bin/env bash 
# 如果你的系统没有bash，或者没有 /usr/bin/env ，请修改上一行指令为你的环境
export http_proxy=http://127.0.0.1:1087  # 代理地址需要换成自己的
export https_proxy=http://127.0.0.1:1087
export ftp_proxy=http://127.0.0.1:1087

exec ${@:1}

给 shell 脚本设置可执行权限，然后放到 path 环境变量路径下。
测试 proxy curl https://www.google.com 和 curl https://www.google.com 第一个命令可以获取到结果，第二个命令不可以。
测试 proxy go get -v golang.org/x/text/… 可以正常下载包，其它任何拉取包命令都可以添加 proxy 前缀执行，比如 proxy dep ensure -v

截止当前你就配置了一个 go get 自动代理的环境，以后需要翻墙操作的指令运行时加 proxy 就可以了，该方法并不只适用于 go get，任何需要命令行代理都可以使用。

原理篇

实际原理简单，找到这种方法也是一种巧合，在入坑 Go 之前我经常用 linux，当时有一些需求需要命令行翻墙，找到了三个环境变量 http_proxy、https_proxy、ftp_proxy，但是全局设置导致很多请求变慢，如果在一个窗口临时设置就导致需要记住那个窗口设置了代理，切换窗口成本也比较高，后来根据 shell 的特性，任何一个脚本都有自己独立的环境变量，所以用一个脚本设置代理环境变量，exec ${@:1} 可以执行脚本后面的指令，也就是我们实际需要运行的指令，这样在需要代理的命令前就加上这个脚本前缀就好了，单行命令代理就这么简单的配置好了。

前期我使用 go 的时候遇到下载不了的包时，就会在 go get 前加上 proxy 指令，但是我发现拉取 Github 包的效率非常低，本身国内现在访问 Github 已经很快了。也是一个巧合，当时我公司 Go 项目迁移到 Github 上，所有项目全部是私有项目，有同事提供了一个 git https 转 ssh 协议的操作，git config --global url.git@….:.insteadof https://…./，这个操作让我看到一个隐性福利，之前的代理只会代理 https 并不能代理 ssh 协议，那么使用这个指令把不需要代理的网站全部转成 ssh 协议，然后加上 proxy 运行 go get 就成了自动代理了，尝试之后确实效率很高，至此一直使用到今天。

【Go】那么多数值类型，应该选哪个？

2019-03-18T23:34:57.000Z

Go 内置很多种数值类型，往往初学者不知道编写程序如何选择，使用哪种数值类型更有优势。

内置的数值类型有：uint8、 uint16、 uint32、 uint64、 uint、 int8、 int16、 int32、 int64、 int。

从类型名称上可以很好了解到类型的大小，这个非常直观，uint 和 int 这两种类型是不带大小的，那么它们的大小会根据编译参数 GOARCH=amd64 平台决定的。

我最早设计的一个go的项目，当时设计系统使用采用最小类型原则，几乎使用了大多数数值类型，很少使用 uint 和 int 类型，后来遇到很多问题，标准库和三方库函数都接收 int、 uint、 int64、uint64, 一些代码生成工具, 比如 protobuf 生成类型是 int32，一些三方系统大多数也是 int 类型，这时候与其它组件件的交互就需要类型转换, 类型转换成本是很高的，导致程序性能并没有预期的好。

上面一个小故事(事故)警醒大家不要一味的根据数据的大小选择数值类型，而要考虑数值的用来做什么，后面会有哪些交互，需要调用哪些函数等等，是不是选择数值具体使用什么类型很复杂呢？并不是这样，考虑的越少，选择越简单，下面有一些近些年的总结。

需要原子操作的数值根据数据大小选择 int32、 int64、 uint32、uint64。因为原子类型的操作包天生支持这些类型。
需要与代码生成的交互的数据，可以看生成的代码具体使用哪种类型，做一下参考。
需要调用大多数标准库函数进行处理，选这个 int (我们的程序大多数跑在64位系统上，如果运行在32系统，且类型可能会超过 int32 可以选择 int64) 。
有些时候可能我们需要一个无符号数据且比较大优先选用 uint 和 uint64 。
只和自己的函数交互以及一些不关注具体类型的包(json、fmt)交互式时，按数值使用范围选择最小类型。

我现在写代码一些特殊场景如原子操作会针对使用的包选择具体类型，偶尔会使用uint64，往往是一些按位做一些复杂计算的数据，也都局限在局部逻辑上，与其它模块或者系统交互的都会使用 int 类型，这样可以大幅度降低数值类型的类型转换问题，从而从空间换取时间，获得更好的程序性能。

不得不说说 Go 语言神奇的 int 类型，为什么需要这样一个编程是无法确定具体长度的类型呢，而需要在编译时确定呢，有什么好处呢。

往往我们写程序是不太关注数值类型的，或者说我们程序中很多数值不会超过 int32 的最大值（往往我们的程序运行在 32 或 64位平台上），这个时候很多三方库都可以使用 int 作为交互类型，不用把一个函数为每种类型数值都写一遍，能简化标准库。我们也能写出更容易维护、简洁的系统。

【Go】string 优化误区及建议

2019-02-22T22:34:57.000Z

本文原标题为《string 也是引用类型》，经过郝林大佬指点原标题存在诱导性，这里解释一下 “引用类型” 有两个特征：1、多个变量引用一块内存数据，不创建变量的副本，2、修改任意变量的数据，其它变量可见。显然字符串只满足了 “引用类型” 的第一个特点，不能满足第二个特点，顾不能说字符串是引用类型，感谢大佬指正。

初学 Go 语言的朋友总会在传 []byte 和 string 之间有着很多纠结，实际上是没有了解 string 与 slice 的本质，而且读了一些程序源码，也发现很多与之相关的问题，下面类似的代码估计很多初学者都写过，也充分说明了作者当时内心的纠结：

package main

import "bytes"

func xx(s []byte) []byte{
    ....
    
    return s
}

func main(){
    s := "xxx"
    
    s = string(xx([]byte(s)))
    
    s = string(bytes.Replace([]byte(s), []byte("x"), []byte(""), -1))
}

虽然这样的代码并不是来自真实的项目，但是确实有人这样设计，单从设计上看就很糟糕了，这样设计的原因很多人说：“slice 是引用类型，传递引用类型效率高呀”，主要原因不了解两者的本质。

上面这个例子如果觉得有点基础和可爱，下面这个例子貌似并不那么容易说明其存在的问题了吧。

package main

func xx(s *string) *string{
    ....
    return s
}

func main(){
    s := "xx"
    
    s = *xx(&s)
    
    ss :=[]*string{}
    
    ss = append(ss, &s)
}

指针效率高，我就用指针多好，可以减少内存分配呀，设计函数都接收指针变量，程序性能会有很大提升，在实际的项目中这种例子也不少见，我想通过这篇文档来帮助初学者走出误区，减少适得其反的优化技巧。

slice 的定义

在之前 “【Go】深入剖析slice和array” 一文中说了 slice 在内存中的存储模式，slice 本身包含一个指向底层数组的指针，一个 int 类型的长度和一个 int 类型的容量，这就是 slice 的本质， []byte 本身也是一个 slice，只是底层数组存储的元素是 byte。下面这个图就是 slice 的在内存中的状态：

看一下 reflect.SliceHeader 如何定义 slice 在内存中的结构吧：

type SliceHeader struct {
Data uintptr
Len  int
Cap  int
}

slice 是引用类型是 slice 本身会包含一个地址，在传递 slice 时只需要分配 SliceHeader 就好了，而 SliceHeader 只包含了三个 int 类型，相当于传递一个 slice 就只需要拷贝 SliceHeader，而不用拷贝整个底层数组，所以才说 slice 是引用类型的。

那么字符串呢，计算机中我们处理的大多数问题都和字符串有关，难道传递字符串真的需要那么高的成本，需要借助 slice 和指针来减少内存开销吗。

string 的定义

reflect 包里面也定义了一个 StringHeader 看一下吧：

type StringHeader struct {
Data uintptr
Len  int
}

字符串只包含了两个 int 类型的数据，其中一个是指针，一个是字符串的长度，从 StringHeader 定义来看 string 并不会发生拷贝的，传递 string 只会拷贝 StringHeader 而已。

借助 unsafe 来分析一下情况是不是这样吧：

package main

import (
"reflect"
"unsafe"

"github.com/davecgh/go-spew/spew"
)

func xx(s string) {
sh := *(*reflect.StringHeader)(unsafe.Pointer(&s))
spew.Dump(sh)
}

func main() {
s := "xx"

sh := *(*reflect.StringHeader)(unsafe.Pointer(&s))
spew.Dump(sh)

xx(s)
xx(s[:1])
xx(s[1:])
}

上面这段代码的输出如下：

(reflect.StringHeader) {
 Data: (uintptr) 0x10f5ee0,
 Len: (int) 2
}
(reflect.StringHeader) {
 Data: (uintptr) 0x10f5ee0,
 Len: (int) 2
}
(reflect.StringHeader) {
 Data: (uintptr) 0x10f5ee0,
 Len: (int) 1
}
(reflect.StringHeader) {
 Data: (uintptr) 0x10f5ee1,
 Len: (int) 1
}

可以发现前三个输出的指针都是同一个地址，第四个的地址发生了一个字节的偏移，分析来看传递字符串确实没有分配新的内存，同时和 slice 一样即使传递字符串的子串也不会分配新的内存空间，而是指向原字符串的中的一个位置。

这样说来把 string 转成 []byte 还浪费的一个 int 的空间呢，需要分配更多的内存，真是适得其反呀，而且类型转换会发生内存拷贝，从 string 转为 []byte 才是真的把 string 底层数据全部拷贝一遍呢，真是得不偿失呀。

string 的两个小特性

字符串还有两个小特性，针对字面量(就是直接写在程序中的字符串)，会创建在只读空间上，并且被复用，看一下下面的一个小例子：

package main

import (
"reflect"
"unsafe"

"github.com/davecgh/go-spew/spew"
)

func main() {
a := "xx"
b := "xx"
c := "xxx"
spew.Dump(*(*reflect.StringHeader)(unsafe.Pointer(&a)))
spew.Dump(*(*reflect.StringHeader)(unsafe.Pointer(&b)))
spew.Dump(*(*reflect.StringHeader)(unsafe.Pointer(&c)))
}

从输出可以了解到，相同的字面量会被复用，但是子串是不会复用空间的，这就是编译器给我们带来的福利了，可以减少字面量字符串占用的内存空间。

(reflect.StringHeader) {
 Data: (uintptr) 0x10f5ea0,
 Len: (int) 2
}
(reflect.StringHeader) {
 Data: (uintptr) 0x10f5ea0,
 Len: (int) 2
}
(reflect.StringHeader) {
 Data: (uintptr) 0x10f5f2e,
 Len: (int) 3
}

另一个小特性大家都知道，就是字符串是不能修改的，如果我们不希望调用函数修改我们的数据，最好传递字符串，高效有安全。

不过有了 unsafe 这个黑魔法，字符串的这一个特性也就不那么可靠了。

package main

import (
"fmt"
"reflect"
"strings"
"unsafe"
)

func main() {
a := strings.Repeat("x", 10)

fmt.Println(a)
strHeader := *(*reflect.StringHeader)(unsafe.Pointer(&a))

sliceHeader := reflect.SliceHeader{
Data: strHeader.Data,
Len:  strHeader.Len,
Cap:  strHeader.Len,
}

b := *(*[]byte)(unsafe.Pointer(&sliceHeader))

b[1] = 'a'

fmt.Println(a)
}

从输出里面居然发现字符串被修改了, 我们没有办法直接修改字符串，但是可以利用 slice 和 string 本身结构的特性，创建一个 slice 让它的指针指向 string 的指针位置，然后借助 unsafe 把这个 SliceHeader 转成 []byte 来修改字符串，字符串确实被修改了。

1 2	xxxxxxxxxx xaxxxxxxxx

看了上面的例子是不是开始担心把字符串传给其它函数真的不会更改吗？感觉很不放心的样子，难道使用任何函数都要了解它的内部实现吗，其实这种情况极少发生，还记得之前说的那个字符串特性吗，字面量字符串会放到只读空间中，这个很重要，可以保证不是任何函数想修改我们的字符串就可以修改的。

package main

import (
"reflect"
"unsafe"
)

func main() {
defer func() {
recover()
}()

a := "xx"

strHeader := *(*reflect.StringHeader)(unsafe.Pointer(&a))
sliceHeader := reflect.SliceHeader{
Data: strHeader.Data,
Len:  strHeader.Len,
Cap:  strHeader.Len,
}
b := *(*[]byte)(unsafe.Pointer(&sliceHeader))
b[1] = 'a'
}

运行上面的代码发生了一个运行时不可修复的错误，就是这个特性其它函数不能确保输入字符串是否是字面量，也是不会恶意修改我们字符串的了。

unexpected fault address 0x1095dd5
fatal error: fault
[signal SIGBUS: bus error code=0x2 addr=0x1095dd5 pc=0x106c804]

goroutine 1 [running]:
runtime.throw(0x1095fde, 0x5)
/usr/local/go/src/runtime/panic.go:608 +0x72 fp=0xc000040700 sp=0xc0000406d0 pc=0x10248d2
runtime.sigpanic()
/usr/local/go/src/runtime/signal_unix.go:387 +0x2d7 fp=0xc000040750 sp=0xc000040700 pc=0x1037677
main.main()
/Users/qiyin/project/go/src/github.com/yumimobi/test/a.go:22 +0x84 fp=0xc000040798 sp=0xc000040750 pc=0x106c804
runtime.main()
/usr/local/go/src/runtime/proc.go:201 +0x207 fp=0xc0000407e0 sp=0xc000040798 pc=0x1026247
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:1333 +0x1 fp=0xc0000407e8 sp=0xc0000407e0 pc=0x104da51

关于字符串转 []byte 在 go-extend 扩展包中有直接的实现，这种用法在 go-extend 内部方法实现中也有大量使用，实际上因为原数据类型和处理数据的函数类型不一致，使用这种方法转换字符串和 []byte 可以极大的提升程序性能

exbytes.ToString 零成本的把 []byte 转为 string。
exstrings.UnsafeToBytes 零成本的把 []byte 转为 string。

上面这两个函数用的好，可以极大的提升我们程序的性能，关于 exstrings.UnsafeToBytes 我们转换不确定是否是字面量的字符串时就需要确保调用的函数不会修改我们的数据，这往常在调用 bytes 里面的方法十分有效。

传字符串和字符串指针的区别

之前分析了传递 slice 并没有 string 高效，何况转换数据类型本身就会发生数据拷贝。

那么在这篇文章的第二个例子，为什么说传递字符串指针也不好呢，要了解指针在底层就是一个 int 类型的数据，而我们字符串只是两个 int 而已，另外如果了解 GC 的话，GC 只处理堆上的数据，传递指针字符串会导致数据逃逸到堆上，阅读标准库的代码会有很多注释说明避免逃逸到堆上，这样会极大的增加 GC 的开销，GC 的成本可谓是很高的呀。

疑惑

这篇文章说 “传递 slice 并没有 string 高效”，为什么还会有 bytes 包的存在呢，其中很多函数的功能和 strings 包的功能一致，只是把 string 换成了 []byte，既然传递 []byte 没有 string 效率好，这个包存在的意义是什么呢。

我们想一下转换数据类型是会发生数据拷贝，这个成本可是大的多呀，如果我们数据本身就是 []byte 类型，使用 strings 包就需要转换数据类型了。

另外我们对比两个函数来看下一下即使传递 []byte 没有 string 效率好，但是标准库实现上却会导致两个函数有很大的性能差异的。

strings.Repeat 函数：

func Repeat(s string, count int) string {
// Since we cannot return an error on overflow,
// we should panic if the repeat will generate
// an overflow.
// See Issue golang.org/issue/16237
if count < 0 {
panic("strings: negative Repeat count")
} else if count > 0 && len(s)*count/count != len(s) {
panic("strings: Repeat count causes overflow")
}

b := make([]byte, len(s)*count)
bp := copy(b, s)
for bp < len(b) {
copy(b[bp:], b[:bp])
bp *= 2
}
return string(b)
}

bytes.Repeat 函数：

func Repeat(b []byte, count int) []byte {
// Since we cannot return an error on overflow,
// we should panic if the repeat will generate
// an overflow.
// See Issue golang.org/issue/16237.
if count < 0 {
panic("bytes: negative Repeat count")
} else if count > 0 && len(b)*count/count != len(b) {
panic("bytes: Repeat count causes overflow")
}

nb := make([]byte, len(b)*count)
bp := copy(nb, b)
for bp < len(nb) {
copy(nb[bp:], nb[:bp])
bp *= 2
}
return nb
}

上面两个函数的实现非常相似，除了类型不同 strings 包在处理完数据发生了一次类型转换，使用 bytes 只有一次内存分配，而 strings 是两次。

我们可以借助 exbytes.ToString 函数把 bytes.Repeat 的返回没有任何成本的转换会我们需要的字符串，如果我们输入也是一个字符串的话，还可以借助 exstrings.UnsafeToBytes 来转换输入的数据类型。

例如：

1	s := exbytes.ToString(bytes.Repeat(exstrings.UnsafeToBytes("x"), 10))

不过这样写有点太麻烦了，实际上 exstrings 包里面正在修改 strings 里面一些类似函数的问题，所有的实现基本和标准库一致，只是把其中类型转换的部分用 exbytes.ToString 优化了一下，可以提升性能，也能提升开发效率。

exstrings.UnsafeRepeat 函数：

func UnsafeRepeat(s string, count int) string {
// Since we cannot return an error on overflow,
// we should panic if the repeat will generate
// an overflow.
// See Issue golang.org/issue/16237
if count < 0 {
panic("strings: negative Repeat count")
} else if count > 0 && len(s)*count/count != len(s) {
panic("strings: Repeat count causes overflow")
}

b := make([]byte, len(s)*count)
bp := copy(b, s)
for bp < len(b) {
copy(b[bp:], b[:bp])
bp *= 2
}
return exbytes.ToString(b)
}

如果用上面的函数只需要下面这样写就可以了：

1	s:=exstrings.UnsafeRepeat("x", 10)

go-extend 里面还收录了很多实用的方法，大家也可以多关注。

总结

千万不要为了使用 []byte 来优化 string 传递，类型转换成本很高，且 slice 本身也比 string 更大一些。
程序中是使用 string 还是 []byte 需要根据数据来源和处理数据的函数来决定，一定要减少类型转换。
关于使用 strings 还是 bytes 包的问题，主要关注点是数据原始类型以及想获得的数据类型来选择。
减少使用字符串指针来优化字符串，这会增加 GC 的开销，具体可以参考大堆中避免大量的GC开销一文。

【Go】strings.Replace 与 bytes.Replace 调优

2019-02-01T22:34:57.000Z

标准库中函数大多数情况下更通用，性能并非最好的，还是不能过于迷信标准库，最近又有了新发现，strings.Replace 这个函数自身的效率已经很好了，但是在特定情况下效率并不是最好的，分享一下我如何优化的吧。

我的服务中有部分代码使用 strings.Replace 把一个固定的字符串删除或者替换成另一个字符串，它们有几个特点：

旧的字符串大于或等于新字符串 (len(old) >= len(new)
源字符串的生命周期很短，替换后就不再使用替换前的字符串
它们都比较大，往往超过 2k~4k

本博文中使用函数均在 go-extend 中，优化后的函数在 exbytes.Replace 中。

发现问题

近期使用 pprof 分析内存分配情况，发现 strings.Replace 排在第二，占 7.54%, 分析结果如下：

go tool pprof allocs
File: xxx
Type: alloc_space
Time: Feb 1, 2019 at 9:53pm (CST)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) top
Showing nodes accounting for 617.29GB, 48.86% of 1263.51GB total
Dropped 778 nodes (cum <= 6.32GB)
Showing top 10 nodes out of 157
      flat  flat%   sum%        cum   cum%
  138.28GB 10.94% 10.94%   138.28GB 10.94%  logrus.(*Entry).WithFields
   95.27GB  7.54% 18.48%    95.27GB  7.54%  strings.Replace
   67.05GB  5.31% 23.79%   185.09GB 14.65%  v3.(*v3Adapter).parseEncrypt
   57.01GB  4.51% 28.30%    57.01GB  4.51%  bufio.NewWriterSize
   56.63GB  4.48% 32.78%    56.63GB  4.48%  bufio.NewReaderSize
   56.11GB  4.44% 37.23%    56.11GB  4.44%  net/url.unescape
   39.75GB  3.15% 40.37%    39.75GB  3.15%  regexp.(*bitState).reset
   36.11GB  2.86% 43.23%    38.05GB  3.01%  des3_and_base64.(*des3AndBase64).des3Decrypt
   36.01GB  2.85% 46.08%    36.01GB  2.85%  des3_and_base64.(*des3AndBase64).base64Decode
   35.08GB  2.78% 48.86%    35.08GB  2.78%  math/big.nat.make

标准库中最常用的函数，居然……，不可忍必须优化，先使用 list strings.Replace 看一下源码什么地方分配的内存。

(pprof) list strings.Replace
Total: 1.23TB
ROUTINE ======================== strings.Replace in /usr/local/go/src/strings/strings.go
   95.27GB    95.27GB (flat, cum)  7.54% of Total
         .          .    858:} else if n < 0 || m < n {
         .          .    859:n = m
         .          .    860:}
         .          .    861:
         .          .    862:// Apply replacements to buffer.
   47.46GB    47.46GB    863:t := make([]byte, len(s)+n*(len(new)-len(old)))
         .          .    864:w := 0
         .          .    865:start := 0
         .          .    866:for i := 0; i < n; i++ {
         .          .    867:j := start
         .          .    868:if len(old) == 0 {
         .          .    869:if i > 0 {
         .          .    870:_, wid := utf8.DecodeRuneInString(s[start:])
         .          .    871:j += wid
         .          .    872:}
         .          .    873:} else {
         .          .    874:j += Index(s[start:], old)
         .          .    875:}
         .          .    876:w += copy(t[w:], s[start:j])
         .          .    877:w += copy(t[w:], new)
         .          .    878:start = j + len(old)
         .          .    879:}
         .          .    880:w += copy(t[w:], s[start:])
   47.81GB    47.81GB    881:return string(t[0:w])
         .          .    882:}

从源码发现首先创建了一个 buffer 来起到缓冲的效果，一次分配足够的内存，这个在之前【Go】slice的一些使用技巧里面有讲到，另外一个是 string(t[0:w]) 类型转换带来的内存拷贝，buffer 能够理解，但是类型转换这个不能忍，就像凭空多出来的一个数拷贝。

既然类型转换这里有点浪费空间，有没有办法可以零成本转换呢，那就使用 go-extend 这个包里面的 exbytes.ToString 方法把 []byte 转换成 string，这个函数可以零分配转换 []byte 到 string。 t 是一个临时变量，可以安全的被引用不用担心，一个小技巧节省一倍的内存分配，但是这样真的就够了吗？

我记得 bytes 标准库里面也有一个 bytes.Replace 方法，如果直接使用这种方法呢就不用重写一个 strings.Replace了，使用 go-extend 里面的两个魔术方法可以一行代码搞定上面的优化效果 s = exbytes.ToString(bytes.Replace(exstrings.UnsafeToBytes(s), []byte{' '}, []byte{''}, -1))，虽然是一行代码搞定的，但是有点长，exstrings.UnsafeToBytes 方法可以极小的代价把 string 转成 bytes，但是 s 不能是标量或常量字符串，必须是运行时产生的字符串否者可能导致程序奔溃。

这样确实减少了一倍的内存分配，即使只有 47.46GB 的分配也足以排到前十了，不满意这个结果，分析代码看看能不能更进一步减少内存分配吧。

分析代码

使用火焰图看看究竟什么函数在调用 strings.Replace 呢：

这里主要是两个方法在使用，当然我记得还有几个地方有使用，看来不在火焰图中应该影响比较低，看一下代码吧（简化的代码不一定完全合理）：

// 第一部分
func (v2 *v2Adapter) parse(s string) (*AdRequest, error) {
s = strings.Replace(s, " ", "", -1)
requestJSON, err := v2.paramCrypto.Decrypt([]byte(s))
if err != nil {
return nil, err
}

request := v2.getDefaultAdRequest()
if err := request.UnmarshalJSON(requestJSON); err != nil {
return nil, err
}
return request, nil
}

// 第二部分
func (v3 *v3Adapter) parseEncrypt(s []byte) ([]byte, error) {
    ss := strings.Replace(string(s), " ", "", -1)
    requestJSON, err := v3.paramCrypto.Decrypt([]byte(ss))
if err != nil {
return nil, error
}

return requestJSON, nil
}

// 通过搜索找到的第三部分
type LogItems []string

func LogItemsToBytes(items []string, sep, newline string) []byte {
for i := range items {
items[i] = strings.Replace(items[i], sep, " ", -1)
}
str := strings.Replace(strings.Join(items, sep), newline, " ", -1)

return []byte(str + newline)
}

通过分析我们发现前两个主要是为了删除一个字符串，第三个是为了把一个字符串替换为另一个字符串，并且源数据的生命周期很短暂，在执行替换之后就不再使用了，能不能原地替换字符串呢，原地替换的就会变成零分配了，尝试一下吧。

优化

先写一个函数简单实现原地替换，输入的 len(old) < len(new) 就直接调用 bytes.Replace 来实现就好了。

func Replace(s, old, new []byte, n int) []byte {
if n == 0 {
return s
}

if len(old) < len(new) {
return bytes.Replace(s, old, new, n)
}

if n < 0 {
n = len(s)
}

var wid, i, j int
for i, j = 0, 0; i < len(s) && j < n; j++ {
wid = bytes.Index(s[i:], old)
if wid < 0 {
break
}

i += wid
i += copy(s[i:], new)
s = append(s[:i], s[i+len(old)-len(new):]...)
}

return s
}

写个性能测试看一下效果：

$ go test -bench="." -run=nil -benchmem
goos: darwin
goarch: amd64
pkg: github.com/thinkeridea/go-extend/exbytes/benchmark
BenchmarkReplace-8                  500000      3139 ns/op     416 B/op       1 allocs/op
BenchmarkBytesReplace-8            1000000      2032 ns/op     736 B/op       2 allocs/op

使用这个新的函数和 bytes.Replace 对比，内存分配是少了，但是性能却下降了那么多，崩溃…. 啥情况呢，对比 bytes.Replace 的源码发现我这个代码里面 s = append(s[:i], s[i+len(old)-len(new):]...) 每次都会移动剩余的数据导致性能差异很大，可以使用 go test -bench="." -run=nil -benchmem -cpuprofile cpu.out -memprofile mem.out 的方式来生成 pprof 数据，然后分析具体有问题的地方。

找到问题就好了，移动 wid 之前的数据，这样每次移动就很少了，和 bytes.Replace 的原理类似。

func Replace(s, old, new []byte, n int) []byte {
if n == 0 {
return s
}

if len(old) < len(new) {
return bytes.Replace(s, old, new, n)
}

if n < 0 {
n = len(s)
}

var wid, i, j, w int
for i, j = 0, 0; i < len(s) && j < n; j++ {
wid = bytes.Index(s[i:], old)
if wid < 0 {
break
}

w += copy(s[w:], s[i:i+wid])
w += copy(s[w:], new)
i += wid + len(old)
}

w += copy(s[w:], s[i:])
return s[0:w]
}

在运行一下性能测试吧：

$ go test -bench="." -run=nil -benchmem
goos: darwin
goarch: amd64
pkg: github.com/thinkeridea/go-extend/exbytes/benchmark
BenchmarkReplace-8                 1000000      2149 ns/op     416 B/op       1 allocs/op
BenchmarkBytesReplace-8            1000000      2231 ns/op     736 B/op       2 allocs/op

运行性能差不多，而且更好了，内存分配也减少，不是说是零分配吗，为啥有一次分配呢？

var replaces string
var replaceb []byte

func init() {
replaces = strings.Repeat("A BC", 100)
replaceb = bytes.Repeat([]byte("A BC"), 100)
}

func BenchmarkReplace(b *testing.B) {
for i := 0; i < b.N; i++ {
exbytes.Replace([]byte(replaces), []byte(" "), []byte(""), -1)
}
}

func BenchmarkBytesReplace(b *testing.B) {
for i := 0; i < b.N; i++ {
bytes.Replace([]byte(replaces), []byte(" "), []byte(""), -1)
}
}

可以看到使用了 []byte(replaces) 做了一次类型转换，因为优化的这个函数是原地替换，执行过一次之后后面就发现不用替换了，所以为了公平公正两个方法每次都转换一个类型产生一个新的内存地址，所以实际优化后是没有内存分配了。

之前说写一个优化 strings.Replace 函数，减少一次内存分配，这里也写一个这样函数，然后增加两个性能测试函数，对比一下效率性能测试代码：

$ go test -bench="." -run=nil -benchmem
goos: darwin
goarch: amd64
pkg: github.com/thinkeridea/go-extend/exbytes/benchmark
BenchmarkReplace-8                 1000000      2149 ns/op     416 B/op       1 allocs/op
BenchmarkBytesReplace-8            1000000      2231 ns/op     736 B/op       2 allocs/op
BenchmarkStringsReplace-8          1000000      2260 ns/op    1056 B/op       3 allocs/op
BenchmarkUnsafeStringsReplace-8    1000000      2522 ns/op     736 B/op       2 allocs/op
PASS
ok  github.com/thinkeridea/go-extend/exbytes/benchmark10.260s

运行效率上都相当，优化之后的 UnsafeStringsReplace 函数减少了一次内存分配只有一次，和 bytes.Replace 相当。

修改代码

有了优化版的 Replace 函数就替换到项目中吧：

// 第一部分
func (v2 *v2Adapter) parse(s string) (*AdRequest, error) {
b := exbytes.Replace(exstrings.UnsafeToBytes(s), []byte(" "), []byte(""), -1)
requestJSON, err := v2.paramCrypto.Decrypt(b)
if err != nil {
return nil, err
}
request := v2.getDefaultAdRequest()
if err := request.UnmarshalJSON(requestJSON); err != nil {
return nil, err
}

return request, nil
}

// 第二部分
func (v3 *v3Adapter) parseEncrypt(s []byte) ([]byte, error) {
s = exbytes.Replace(s, []byte(" "), []byte(""), -1)
requestJSON, err := v3.paramCrypto.Decrypt(s)
if err != nil {
return nil, err
}

return requestJSON, nil
}

// 第三部分
type LogItems []string

func LogItemsToBytes(items []string, sep, newline string) []byte {
for i := range items {
items[i] = exbytes.ToString(exbytes.Replace(exstrings.UnsafeToBytes(items[i]), []byte(sep), []byte(" "), -1))
}
b := exbytes.Replace(exstrings.UnsafeToBytes(strings.Join(items, sep)), []byte(newline), []byte(" "), -1)
return append(b, newline...)
}

上线后性能分析

$ go tool pprof allocs2
File: xx
Type: alloc_space
Time: Feb 2, 2019 at 5:33pm (CST)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) top exbytes.Replace
Focus expression matched no samples
Active filters:
   focus=exbytes.Replace
Showing nodes accounting for 0, 0% of 864.21GB total
      flat  flat%   sum%        cum   cum%
(pprof)

居然在 allocs 上居然找不到了，确实是零分配。

优化前 profile ：

$ go tool pprof profile
File: xx
Type: cpu
Time: Feb 1, 2019 at 9:54pm (CST)
Duration: 30.08s, Total samples = 12.23s (40.65%)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) top strings.Replace
Active filters:
   focus=strings.Replace
Showing nodes accounting for 0.08s, 0.65% of 12.23s total
Showing top 10 nodes out of 27
      flat  flat%   sum%        cum   cum%
     0.03s  0.25%  0.25%      0.08s  0.65%  strings.Replace
     0.02s  0.16%  0.41%      0.02s  0.16%  countbody
     0.01s 0.082%  0.49%      0.01s 0.082%  indexbytebody
     0.01s 0.082%  0.57%      0.01s 0.082%  memeqbody
     0.01s 0.082%  0.65%      0.01s 0.082%  runtime.scanobject

优化后 profile ：

$ go tool pprof profile2
File: xx
Type: cpu
Time: Feb 2, 2019 at 5:33pm (CST)
Duration: 30.16s, Total samples = 14.68s (48.68%)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) top exbytes.Replace
Active filters:
   focus=exbytes.Replace
Showing nodes accounting for 0.06s, 0.41% of 14.68s total
Showing top 10 nodes out of 18
      flat  flat%   sum%        cum   cum%
     0.03s   0.2%   0.2%      0.03s   0.2%  indexbytebody
     0.02s  0.14%  0.34%      0.05s  0.34%  bytes.Index
     0.01s 0.068%  0.41%      0.06s  0.41%  github.com/thinkeridea/go-extend/exbytes.Replace

通过 profile 来分配发现性能也有一定的提升，本次 strings.Replace 和 bytes.Replace 优化圆满结束。

本博文中使用函数均在 go-extend 中，优化后的函数在 exbytes.Replace 中。

【Go】优雅的读取http请求或响应的数据-续

2019-02-01T08:43:26.000Z

之前发布【Go】优雅的读取http请求或响应的数据文章，网友 “wxe” 咨询：“优化前后的请求耗时变化有多大”，之前只分析了内存分配，这篇文章用单元测试的方式分析优化前后的耗时情况，本文源码。

非常感谢 “wxe” 网友的提问，让我在测试过程中发现一个 json 序列化的问题。

之前我们优化了两个部分，json 与 ioutil.ReadAll，先对比 ioutil.ReadAll, 这里测试的代码分成两个部分做对比，一部分单纯对比 ioutil.ReadAll 和 io.Copy + sync.Pool，另一部分增加 jsoniter.Unmarshal 来延迟 pool.Put(buffer) 的执行, 源码。

package iouitl_readall

import (
"bytes"
"io"
"io/ioutil"
"sync"

jsoniter "github.com/json-iterator/go"
)

var pool = sync.Pool{
New: func() interface{} {
return bytes.NewBuffer(make([]byte, 4096))
},
}

func IoCopyAndJson(r io.Reader) error {
buffer := pool.Get().(*bytes.Buffer)
buffer.Reset()
defer pool.Put(buffer)

res := Do(r)
_, err := io.Copy(buffer, res)
if err != nil {
return err
}

m := map[string]string{}
err = jsoniter.Unmarshal(buffer.Bytes(), &m)
return err
}

func IouitlReadAllAndJson(r io.Reader) error {
res := Do(r)
data, err := ioutil.ReadAll(res)
if err != nil {
return err
}

m := map[string]string{}
err = jsoniter.Unmarshal(data, &m)
return err
}

func IoCopy(r io.Reader) error {
buffer := pool.Get().(*bytes.Buffer)
buffer.Reset()
defer pool.Put(buffer)

res := Do(r)
_, err := io.Copy(buffer, res)
if err != nil {
return err
}

return err
}

func IouitlReadAll(r io.Reader) error {
res := Do(r)
data, err := ioutil.ReadAll(res)
if err != nil {
return err
}
_ = data
return err
}

测试代码如下源码:

package iouitl_readall

import (
"bytes"
"testing"
)

var data = bytes.Repeat([]byte("ABCD"), 1000)

func BenchmarkIouitlReadAll(b *testing.B) {
b.RunParallel(func(pb *testing.PB) {
for pb.Next() {
err := IouitlReadAll(bytes.NewReader(data))
if err != nil {
b.Error(err.Error())
}
}
})
}

func BenchmarkIoCopy(b *testing.B) {
b.RunParallel(func(pb *testing.PB) {
for pb.Next() {
err := IoCopy(bytes.NewReader(data))
if err != nil {
b.Error(err.Error())
}
}
})
}

func BenchmarkIouitlReadAllAndJson(b *testing.B) {
b.RunParallel(func(pb *testing.PB) {
for pb.Next() {
err := IouitlReadAllAndJson(bytes.NewReader(data))
if err != nil {
b.Error(err.Error())
}
}
})
}

func BenchmarkIoCopyAndJson(b *testing.B) {
b.RunParallel(func(pb *testing.PB) {
for pb.Next() {
err := IoCopyAndJson(bytes.NewReader(data))
if err != nil {
b.Error(err.Error())
}
}
})
}

测试结果如下:

goos: darwin
goarch: amd64
pkg: github.com/thinkeridea/example/iouitl_readall
BenchmarkIouitlReadAll-8            500000      2752 ns/op   14496 B/op       6 allocs/op
BenchmarkIoCopy-8                 20000000        65.2 ns/op      48 B/op       1 allocs/op
BenchmarkIouitlReadAllAndJson-8     100000     20022 ns/op   46542 B/op     616 allocs/op
BenchmarkIoCopyAndJson-8            100000     17615 ns/op   32102 B/op     611 allocs/op

结论：

可以发现 IoCopy 方法是 IouitlReadAll 方法效率的 40 倍，内存分配也很少，而 IoCopyAndJson 和 IouitlReadAllAndJson 的效率差异极小仅有 2407ns，大约是 1.13倍，不过内存分配还是少了很多的，为什么会这样呢，这就是 sync.Pool 的导致的，sync.Pool 每次获取使用时间越短，命中率就越高，就可以减少创建新的缓存，这样效率就会大大提高，而 jsoniter.Unmarshal 很耗时，就导致 sync.Pool 的命中率降低了，所以性能下降极其明显.

使用 io.Copy + sync.Pool 表面上执行效率不会有很大提升，但是会大幅度减少内存分配，从而可以减少 GC 的负担，在单元测试中我们并没有考虑 GC 的问题，而 GC 能带来的性能提升会更有优势。

在看一下 json 使用 sync.Pool 的效果吧源码

package iouitl_readall

import (
"bytes"
"encoding/json"

jsoniter "github.com/json-iterator/go"
)

func Json(r map[string]string) error {
data, err := json.Marshal(r)
if err != nil {
return err
}

_ = data
return nil
}

func JsonPool(r map[string]string) error {
buffer := pool.Get().(*bytes.Buffer)
buffer.Reset()
defer pool.Put(buffer)

e := json.NewEncoder(buffer)
err := e.Encode(r)
if err != nil {
return err
}

return nil
}

func JsonIter(r map[string]string) error {
data, err := jsoniter.Marshal(r)
if err != nil {
return err
}

_ = data
return nil
}

func JsonIterPool(r map[string]string) error {
buffer := pool.Get().(*bytes.Buffer)
buffer.Reset()
defer pool.Put(buffer)

e := jsoniter.NewEncoder(buffer)
err := e.Encode(r)
if err != nil {
return err
}

return nil
}

性能测试代码源码:

package iouitl_readall

import (
"strconv"
"strings"
"testing"
)

var request map[string]string

func init() {
request = make(map[string]string, 100)
for i := 0; i < 100; i++ {
request["X"+strconv.Itoa(i)] = strings.Repeat("A", i/2)
}
}
func BenchmarkJson(b *testing.B) {
b.RunParallel(func(pb *testing.PB) {
for pb.Next() {
err := Json(request)
if err != nil {
b.Error(err.Error())
}
}
})
}

func BenchmarkJsonIter(b *testing.B) {
b.RunParallel(func(pb *testing.PB) {
for pb.Next() {
err := JsonIter(request)
if err != nil {
b.Error(err.Error())
}
}
})
}

func BenchmarkJsonPool(b *testing.B) {
b.RunParallel(func(pb *testing.PB) {
for pb.Next() {
err := JsonPool(request)
if err != nil {
b.Error(err.Error())
}
}
})
}

func BenchmarkJsonIterPool(b *testing.B) {
b.RunParallel(func(pb *testing.PB) {
for pb.Next() {
err := JsonIterPool(request)
if err != nil {
b.Error(err.Error())
}
}
})
}

测试结果如下:

goos: darwin
goarch: amd64
pkg: github.com/thinkeridea/example/iouitl_readall
BenchmarkJson-8                     100000     13297 ns/op   13669 B/op     207 allocs/op
BenchmarkJsonPool-8                 100000     13310 ns/op   10218 B/op     206 allocs/op
BenchmarkJsonIter-8                 500000      2948 ns/op    3594 B/op       4 allocs/op
BenchmarkJsonIterPool-8             200000      6126 ns/op    6040 B/op     144 allocs/op
PASS
ok  github.com/thinkeridea/example/iouitl_readall12.716s

这里使用了两个 json 包，一个是标准库的，一个是 jsoniter (也是社区反馈效率最高的)，对比两个包使用 sync.Pool 和不使用之间的差异，发现标准库 json 包使用后内存有少量减少，但是运行效率稍微下降了，差异不是很大，jsoniter 包差异之所谓非常明显，发现使用 sync.Pool 之后不仅内存分配更多了，执行效率也大幅度下降，差了将近3倍有余。

是不是很奔溃，这是啥情况 jsoniter 本身就使用了 sync.Pool 作缓冲，我们使用 jsoniter.NewEncoder(buffer) 创建一个序列化实例，但是其内部并没有直接使用 io.Writer 而是先使用缓冲序列化数据，之后写入 io.Writer, 具体代码如下：

// Flush writes any buffered data to the underlying io.Writer.
func (stream *Stream) Flush() error {
if stream.out == nil {
return nil
}
if stream.Error != nil {
return stream.Error
}
n, err := stream.out.Write(stream.buf)
if err != nil {
if stream.Error == nil {
stream.Error = err
}
return err
}
stream.buf = stream.buf[n:]
return nil
}

这样一来我们使用 buffer 做 json 序列化优化效果就大打折扣，甚至适得其反了。

再次感谢 “wxe” 网友的提问，这里没有使用实际的应用场景做性能测试，主要发现在性能测试中使用 http 服务会导致 connect: can't assign requested address 问题，所以测试用使用了函数模拟，如果有朋友有更好的测试方法欢迎一起交流。

【Go】优雅的读取http请求或响应的数据

2019-01-26T08:43:26.000Z

从 http.Request.Body 或 http.Response.Body 中读取数据方法或许很多，标准库中大多数使用 ioutil.ReadAll 方法一次读取所有数据，如果是 json 格式的数据还可以使用 json.NewDecoder 从 io.Reader 创建一个解析器，假使使用 pprof 来分析程序总是会发现 bytes.makeSlice 分配了大量内存，且总是排行第一，今天就这个问题来说一下如何高效优雅的读取 http 中的数据。

背景介绍

我们有许多 api 服务，全部采用 json 数据格式，请求体就是整个 json 字符串，当一个请求到服务端会经过一些业务处理，然后再请求后面更多的服务，所有的服务之间都用 http 协议来通信(啊，为啥不用 RPC，因为所有的服务都会对第三方开放，http + json 更好对接)，大多数请求数据大小在 1K~~4K，响应的数据在 1K~~8K，早期所有的服务都使用 ioutil.ReadAll 来读取数据，随着流量增加使用 pprof 来分析发现 bytes.makeSlice 总是排在第一，并且占用了整个程序 1/10 的内存分配，我决定针对这个问题进行优化，下面是整个优化过程的记录。

pprof 分析

这里使用 https://github.com/thinkeridea/go-extend/blob/master/exnet/exhttp/expprof/pprof.go 中的 API 来实现生产环境的 /debug/pprof 监测接口，没有使用标准库的 net/http/pprof 包因为会自动注册路由，且长期开放 API，这个包可以设定 API 是否开放，并在规定时间后自动关闭接口，避免存在工具嗅探。

服务部署上线稳定后(大约过了一天半)，通过 curl 下载 allocs 数据，然后使用下面的命令查看分析。

$ go tool pprof allocs
File: xxx
Type: alloc_space
Time: Jan 25, 2019 at 3:02pm (CST)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) top
Showing nodes accounting for 604.62GB, 44.50% of 1358.61GB total
Dropped 776 nodes (cum <= 6.79GB)
Showing top 10 nodes out of 155
      flat  flat%   sum%        cum   cum%
  111.40GB  8.20%  8.20%   111.40GB  8.20%  bytes.makeSlice
  107.72GB  7.93% 16.13%   107.72GB  7.93%  github.com/sirupsen/logrus.(*Entry).WithFields
   65.94GB  4.85% 20.98%    65.94GB  4.85%  strings.Replace
   54.10GB  3.98% 24.96%    56.03GB  4.12%  github.com/json-iterator/go.(*frozenConfig).Marshal
   47.54GB  3.50% 28.46%    47.54GB  3.50%  net/url.unescape
   47.11GB  3.47% 31.93%    48.16GB  3.55%  github.com/json-iterator/go.(*Iterator).readStringSlowPath
   46.63GB  3.43% 35.36%   103.04GB  7.58%  handlers.(*AdserviceHandler).returnAd
   42.43GB  3.12% 38.49%    84.62GB  6.23%  models.LogItemsToBytes
   42.22GB  3.11% 41.59%    42.22GB  3.11%  strings.Join
   39.52GB  2.91% 44.50%    87.06GB  6.41%  net/url.parseQuery

从结果中可以看出采集期间一共分配了 1358.61GB top 10 占用了 44.50% 其中 bytes.makeSlice 占了接近 1/10，那么看看都是谁在调用 bytes.makeSlice 吧。

1	(pprof) web bytes.makeSlice

从上图可以看出调用 bytes.makeSlice 的最终方法是 ioutil.ReadAll, (受篇幅影响就没有截取 ioutil.ReadAll 上面的方法了)，而 90% 都是 ioutil.ReadAll 读取 http 数据调用，找到地方先别急想优化方案，先看看为啥 ioutil.ReadAll 会导致这么多内存分配。

func readAll(r io.Reader, capacity int64) (b []byte, err error) {
var buf bytes.Buffer
// If the buffer overflows, we will get bytes.ErrTooLarge.
// Return that as an error. Any other panic remains.
defer func() {
e := recover()
if e == nil {
return
}
if panicErr, ok := e.(error); ok && panicErr == bytes.ErrTooLarge {
err = panicErr
} else {
panic(e)
}
}()
if int64(int(capacity)) == capacity {
buf.Grow(int(capacity))
}
_, err = buf.ReadFrom(r)
return buf.Bytes(), err
}

func ReadAll(r io.Reader) ([]byte, error) {
return readAll(r, bytes.MinRead)
}

以上是标准库 ioutil.ReadAll 的代码，每次会创建一个 var buf bytes.Buffer 并且初始化 buf.Grow(int(capacity)) 的大小为 bytes.MinRead, 这个值呢就是 512，按这个 buffer 的大小读取一次数据需要分配 2~16 次内存，天啊简直不能忍，我自己创建一个 buffer 好不好。

看一下火焰图🔥吧，其中红框标记的就是 ioutil.ReadAll 的部分，颜色比较鲜艳。

优化读取方法

自己创建足够大的 buffer 减少因为容量不够导致的多次扩容问题。

buffer := bytes.NewBuffer(make([]byte, 4096))
_, err := io.Copy(buffer, request.Body)
if err !=nil{
    return nil, err
}

恩恩这样应该差不多了，为啥是初始化 4096 的大小，这是个均值，即使比 4096 大基本也就多分配一次内存即可，而且大多数数据都是比 4096 小的。

但是这样真的就算好了吗，当然不能这样，这个 buffer 个每请求都要创建一次，是不是应该考虑一下复用呢，使用 sync.Pool 建立一个缓冲池效果就更好了。

以下是优化读取请求的简化代码：

package adapter

import (
"bytes"
"io"
"net/http"
"sync"

"github.com/json-iterator/go"
"github.com/sirupsen/logrus"
"github.com/thinkeridea/go-extend/exbytes"
)

type Adapter struct {
pool sync.Pool
}

func New() *Adapter {
return &Adapter{
pool: sync.Pool{
New: func() interface{} {
return bytes.NewBuffer(make([]byte, 4096))
},
},
}
}

func (api *Adapter) GetRequest(r *http.Request) (*Request, error) {
buffer := api.pool.Get().(*bytes.Buffer)
buffer.Reset()
defer func() {
if buffer != nil {
api.pool.Put(buffer)
buffer = nil
}
}()

_, err := io.Copy(buffer, r.Body)
if err != nil {
return nil, err
}

request := &Request{}
if err = jsoniter.Unmarshal(buffer.Bytes(), request); err != nil {
logrus.WithFields(logrus.Fields{
"json": exbytes.ToString(buffer.Bytes()),
}).Errorf("jsoniter.UnmarshalJSON fail. error:%v", err)
return nil, err
}
api.pool.Put(buffer)
buffer = nil

// ....

return request, nil
}

使用 sync.Pool 的方式是不是有点怪，主要是 defer 和 api.pool.Put(buffer)；buffer = nil 这里解释一下，为了提高 buufer 的复用率会在不使用时尽快把 buffer 放回到缓冲池中，defer 之所以会判断 buffer != nil 主要是在业务逻辑出现错误时，但是 buffer 还没有放回缓冲池时把 buffer 放回到缓冲池，因为在每个错误处理之后都写 api.pool.Put(buffer) 不是一个好的方法，而且容易忘记，但是如果在确定不再使用时 api.pool.Put(buffer)；buffer = nil 就可以尽早把 buffer 放回到缓冲池中，提高复用率，减少新建 buffer。

这样就好了吗，别急，之前说服务里面还会构建请求，看看构建请求如何优化吧。

package adapter

import (
"bytes"
"fmt"
"io"
"io/ioutil"
"net/http"
"sync"

"github.com/json-iterator/go"
"github.com/sirupsen/logrus"
"github.com/thinkeridea/go-extend/exbytes"
)

type Adapter struct {
pool sync.Pool
}

func New() *Adapter {
return &Adapter{
pool: sync.Pool{
New: func() interface{} {
return bytes.NewBuffer(make([]byte, 4096))
},
},
}
}

func (api *Adapter) Request(r *Request) (*Response, error) {
var err error
buffer := api.pool.Get().(*bytes.Buffer)
buffer.Reset()
defer func() {
if buffer != nil {
api.pool.Put(buffer)
buffer = nil
}
}()

e := jsoniter.NewEncoder(buffer)
err = e.Encode(r)
if err != nil {
logrus.WithFields(logrus.Fields{
"request": r,
}).Errorf("jsoniter.Marshal failure: %v", err)
return nil, fmt.Errorf("jsoniter.Marshal failure: %v", err)
}

data := buffer.Bytes()
req, err := http.NewRequest("POST", "http://xxx.com", buffer)
if err != nil {
logrus.WithFields(logrus.Fields{
"data": exbytes.ToString(data),
}).Errorf("http.NewRequest failed: %v", err)
return nil, fmt.Errorf("http.NewRequest failed: %v", err)
}

req.Header.Set("User-Agent", "xxx")

httpResponse, err := http.DefaultClient.Do(req)
if httpResponse != nil {
defer func() {
io.Copy(ioutil.Discard, httpResponse.Body)
httpResponse.Body.Close()
}()
}

if err != nil {
logrus.WithFields(logrus.Fields{
"url": "http://xxx.com",
}).Errorf("query service failed %v", err)
return nil, fmt.Errorf("query service failed %v", err)
}

if httpResponse.StatusCode != 200 {
logrus.WithFields(logrus.Fields{
"url":         "http://xxx.com",
"status":      httpResponse.Status,
"status_code": httpResponse.StatusCode,
}).Errorf("invalid http status code")
return nil, fmt.Errorf("invalid http status code")
}

buffer.Reset()
_, err = io.Copy(buffer, httpResponse.Body)
if err != nil {
return nil, fmt.Errorf("adapter io.copy failure error:%v", err)
}

respData := buffer.Bytes()
logrus.WithFields(logrus.Fields{
"response_json": exbytes.ToString(respData),
}).Debug("response json")

res := &Response{}
err = jsoniter.Unmarshal(respData, res)
if err != nil {
logrus.WithFields(logrus.Fields{
"data": exbytes.ToString(respData),
"url":  "http://xxx.com",
}).Errorf("adapter jsoniter.Unmarshal failed, error:%v", err)
return nil, fmt.Errorf("adapter jsoniter.Unmarshal failed, error:%v", err)
}

api.pool.Put(buffer)
buffer = nil

// ...
return res, nil
}

这个示例和之前差不多，只是不仅用来读取 http.Response.Body 还用来创建一个 jsoniter.NewEncoder 用来把请求压缩成 json 字符串，并且作为 http.NewRequest 的 body 参数，如果直接用 jsoniter.Marshal 同样会创建很多次内存，jsoniter 也使用 buffer 做为缓冲区，并且默认大小为 512, 代码如下：

func (cfg Config) Froze() API {
api := &frozenConfig{
sortMapKeys:                   cfg.SortMapKeys,
indentionStep:                 cfg.IndentionStep,
objectFieldMustBeSimpleString: cfg.ObjectFieldMustBeSimpleString,
onlyTaggedField:               cfg.OnlyTaggedField,
disallowUnknownFields:         cfg.DisallowUnknownFields,
}
api.streamPool = &sync.Pool{
New: func() interface{} {
return NewStream(api, nil, 512)
},
}
// .....
return api
}

而且序列化之后会进行一次数据拷贝：

func (cfg *frozenConfig) Marshal(v interface{}) ([]byte, error) {
stream := cfg.BorrowStream(nil)
defer cfg.ReturnStream(stream)
stream.WriteVal(v)
if stream.Error != nil {
return nil, stream.Error
}
result := stream.Buffer()
copied := make([]byte, len(result))
copy(copied, result)
return copied, nil
}

既然要用 buffer 那就一起吧^_^，这样可以减少多次内存分配，下读取 http.Response.Body 之前一定要记得 buffer.Reset()，这样基本就已经完成了 http.Request.Body 和 http.Response.Body 的数据读取优化了，具体效果等上线跑一段时间稳定之后来查看吧。

效果分析

上线跑了一天，来看看效果吧

$ go tool pprof allocs2
File: connect_server
Type: alloc_space
Time: Jan 26, 2019 at 10:27am (CST)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) top
Showing nodes accounting for 295.40GB, 40.62% of 727.32GB total
Dropped 738 nodes (cum <= 3.64GB)
Showing top 10 nodes out of 174
      flat  flat%   sum%        cum   cum%
   73.52GB 10.11% 10.11%    73.52GB 10.11%  git.tvblack.com/tvblack/connect_server/vendor/github.com/sirupsen/logrus.(*Entry).WithFields
   31.70GB  4.36% 14.47%    31.70GB  4.36%  net/url.unescape
   27.49GB  3.78% 18.25%    54.87GB  7.54%  git.tvblack.com/tvblack/connect_server/models.LogItemsToBytes
   27.41GB  3.77% 22.01%    27.41GB  3.77%  strings.Join
   25.04GB  3.44% 25.46%    25.04GB  3.44%  bufio.NewWriterSize
   24.81GB  3.41% 28.87%    24.81GB  3.41%  bufio.NewReaderSize
   23.91GB  3.29% 32.15%    23.91GB  3.29%  regexp.(*bitState).reset
   23.06GB  3.17% 35.32%    23.06GB  3.17%  math/big.nat.make
   19.90GB  2.74% 38.06%    20.35GB  2.80%  git.tvblack.com/tvblack/connect_server/vendor/github.com/json-iterator/go.(*Iterator).readStringSlowPath
   18.58GB  2.56% 40.62%    19.12GB  2.63%  net/textproto.(*Reader).ReadMIMEHeader

哇塞 bytes.makeSlice 终于从前十中消失了，真的太棒了，还是看看 bytes.makeSlice 的其它调用情况吧。

1	(pprof) web bytes.makeSlice

从图中可以发现 bytes.makeSlice 的分配已经很小了，且大多数是 http.Request.ParseForm 读取 http.Request.Body 使用 ioutil.ReadAll 原因，这次优化的效果非常的好。

看一下更直观的火焰图🔥吧，和优化前对比一下很明显 ioutil.ReadAll 看不到了

优化期间遇到的问题

比较惭愧在优化的过程出现了一个过失，导致生产环境2分钟故障，通过自动部署立即回滚才得以快速恢复，之后分析代码解决之后上线才完美优化，下面总结一下出现的问题吧。

在构建 http 请求时我分了两个部分优化，序列化 json 和读取 http.Response.Body 数据，保持一个观点就是尽早把 buffer 放回到缓冲池，因为 http.DefaultClient.Do(req) 是网络请求会相对耗时，在这个之前我把 buffer 放回到缓冲池中，之后读取 http.Response.Body 时在重新获取一个 buffer，大概代码如下：

package adapter

import (
"bytes"
"fmt"
"io"
"io/ioutil"
"net/http"
"sync"

"github.com/json-iterator/go"
"github.com/sirupsen/logrus"
"github.com/thinkeridea/go-extend/exbytes"
)

type Adapter struct {
pool sync.Pool
}

func New() *Adapter {
return &Adapter{
pool: sync.Pool{
New: func() interface{} {
return bytes.NewBuffer(make([]byte, 4096))
},
},
}
}

func (api *Adapter) Request(r *Request) (*Response, error) {
var err error
buffer := api.pool.Get().(*bytes.Buffer)
buffer.Reset()
defer func() {
if buffer != nil {
api.pool.Put(buffer)
buffer = nil
}
}()

e := jsoniter.NewEncoder(buffer)
err = e.Encode(r)
if err != nil {
return nil, fmt.Errorf("jsoniter.Marshal failure: %v", err)
}

data := buffer.Bytes()
req, err := http.NewRequest("POST", "http://xxx.com", buffer)
if err != nil {
return nil, fmt.Errorf("http.NewRequest failed: %v", err)
}

req.Header.Set("User-Agent", "xxx")

api.pool.Put(buffer)
buffer = nil

httpResponse, err := http.DefaultClient.Do(req)


// ....

buffer = api.pool.Get().(*bytes.Buffer)
buffer.Reset()
defer func() {
if buffer != nil {
api.pool.Put(buffer)
buffer = nil
}
}()
_, err = io.Copy(buffer, httpResponse.Body)
if err != nil {
return nil, fmt.Errorf("adapter io.copy failure error:%v", err)
}

// ....

api.pool.Put(buffer)
buffer = nil

// ...
return res, nil
}

上线之后马上发生了错误 http: ContentLength=2090 with Body length 0 发送请求的时候从 buffer 读取数据发现数据不见了或者数据不够了，我去这是什么鬼，马上回滚恢复业务，然后分析 http.DefaultClient.Do(req) 和 http.NewRequest，在调用 http.NewRequest 是并没有从 buffer 读取数据，而只是创建了一个 req.GetBody 之后在 http.DefaultClient.Do 是才读取数据，因为在 http.DefaultClient.Do 之前把 buffer 放回到缓冲池中，其它 goroutine 获取到 buffer 并进行 Reset 就发生了数据争用，当然会导致数据读取不完整了，真实汗颜，对 http.Client 了解太少，争取有空撸一遍源码。

总结

使用合适大小的 buffer 来减少内存分配，sync.Pool 可以帮助复用 buffer，一定要自己写这些逻辑，避免使用三方包，三方包即使使用同样的技巧为了避免数据争用，在返回数据时候必然会拷贝一个新的数据返回，就像 jsoniter 虽然使用了 sync.Pool 和 buffer 但是返回数据时还需要拷贝，另外这种通用包并不能给一个非常贴合业务的初始 buffer 大小，过小会导致数据发生拷贝，过大会太过浪费内存。

程序中善用 buffer 和 sync.Pool 可以大大的改善程序的性能，并且这两个组合在一起使用非常的简单，并不会使代码变的复杂。

【Go】slice的一些使用技巧

2019-01-22T22:34:57.000Z

slice 是 Go 语言十分重要的数据类型，它承载着很多使命，从语言层面来看是 Go 语言的内置数据类型，从数据结构来看是动态长度的顺序链表，由于 Go 不能直接操作内存（通过系统调用可以实现，但是语言本身并不支持），往往 slice 也可以用来帮助开发者申请大块内存实现缓冲、缓存等功能。

在 Go 语言项目中大量的使用 slice, 我总结三年来对 slice 的一些操作技巧，以方便可以高效的使用 slice，并使用 slice 解决一些棘手的问题。

slice 的基本操作

先熟悉一些 slice 的基本的操作, 对最常规的 : 操作就可玩出很多花样。

s=ss[:] 引用一个切片或数组
s=s[:0] 清空切片
s=s[:10] s=s[10:] s=s[10:20] 截取接片
s=ss[0:10:20] 从切片或数组引用指定长度和容量的切片

下标索引操作的一些误区 s[i:l:c] i 是起始偏移的起始位置，l 是起始偏移的长度结束位置， l-i 就是新 slice 的长度， c 是起始偏移的容量结束位置，c-i 就是新 slice 的容量。其中 i 、l 、c 并不是当前 slice 的索引，而是引用底层数组相对当前 slice 起始位置的偏移量，所以是可超出当前 slice 的长度的，但不能超出当前 slice 的容量，如下操作是合法的：

package main

import (
"fmt"
)

func main() {
s := make([]int, 100)
s[20] = 100
s1 := s[10:10]
s2 := s1[10:20]
fmt.Println(s1)
fmt.Println(s2)
}

其中 s1 是 []；s2 是 [100 0 0 0 0 0 0 0 0 0], 这里并不会发生下标越界的情况，一个更好的例子在 csv reader 中的一个例子

创建 slice

创建切片的方法有很多，下面罗列一些常规的：

var s []int 创建 nil切片
s := make([]int, 0, 0) 、 s=[]int{} 创建无容量空切片
s:= make([]int, 0, 100) 创建有容量空切片
s:=make([]int, 100) 创建零值切片
s:=array[:] 引用数组创建切片

内置函数

len(s) 获取切片的长度
cap(s) 获取切片的容量
append(s, ...) 向切片追加内容
copy(s, s1) 向切片拷贝内容

一个缓冲的简单示例

遇到过很多拼接字符串的方法，各种各样的都有 fmt builder buffer + 等等，实际上 builder 和 buffer 都是使用 []byte 的切片作为缓冲来实现的，fmt 往往性能最差，原因是它主要功能不是连接字符串而是格式化数据会用到反射等等操作。+ 操作在大量拼接时性能也是很差，不过小字符串少量拼接效果很理想，builder 往往性能不如 buffer 特别是在较短字符串拼接上，实际 builder 和 buffer 实现原理非常类似，builder 在转成字符串时使用了 unsafe 减少了一次内存分配，因为小字符串因为扩容机制不如 buffer 灵活，所以性能有所不如，大字符串降低一次大的内存分配就显得很明显了。

经常遇到一个需求就是拼接 []int 中个各个元素，很多种实现都有人用，都是需要遍历转换 int 到 string，但是拼接方法千奇百怪，以下提供两种方法对比（源码在GitHub）。

package slice

import (
"strconv"
"unsafe"
)

func SliceInt2String1(s []int) string {
if len(s) < 1 {
return ""
}

ss := strconv.Itoa(s[0])
for i := 1; i < len(s); i++ {
ss += "," + strconv.Itoa(s[i])
}

return ss
}

func SliceInt2String2(s []int) string {
if len(s) < 1 {
return ""
}

b := make([]byte, 0, 256)
b = append(b, strconv.Itoa(s[0])...)
for i := 1; i < len(s); i++ {
b = append(b, ',')
b = append(b, strconv.Itoa(s[i])...)
}

return string(b)
}

func SliceInt2String3(s []int) string {
if len(s) < 1 {
return ""
}

b := make([]byte, 0, 256)
b = append(b, strconv.Itoa(s[0])...)
for i := 1; i < len(s); i++ {
b = append(b, ',')
b = append(b, strconv.Itoa(s[i])...)
}

return *(*string)(unsafe.Pointer(&b))
}

SliceInt2String1 使用原始的 + 操作，因为是较小的字符串拼接，使用 + 主要是因为在小字符串拼接性能优于其它几种方法，SliceInt2String2 与 SliceInt2String3 都使用了一个 256 容量的 []byte 作为缓冲，唯一的区别是在返回时一个使用 string 转换类型，一个使用 unsafe 转换类型。

写了一个性能测试（源码在GitHub），看一下效果吧:

goos: darwin
goarch: amd64
pkg: github.com/thinkeridea/example/slice
BenchmarkSliceInt2String1-8    3000000       461 ns/op     144 B/op       9 allocs/op
BenchmarkSliceInt2String2-8   20000000       117 ns/op      32 B/op       1 allocs/op
BenchmarkSliceInt2String3-8   10000000       144 ns/op     256 B/op       1 allocs/op
PASS
ok  github.com/thinkeridea/example/slice5.928s

明显可以看得出 SliceInt2String2 的性能是 SliceInt2String1 7倍左右，提升很明显，SliceInt2String2 与 SliceInt2String3 差异很小，主要是因为使用 unsafe 转换类型导致大内存无法释放，实际这个测试中连接字符串只需要 32 个字节，使用 unsafe 却导致 256 个字节无法被释放，这也正是 builder 和 buffer 的差别，所以小字符串拼接 buffer 性能往往更好。在这里简单的通过 []byte 减少内存分配次数来实现缓冲。

如果连续拼接一组这样的操作，比如输入 [][]int, 输出 []string （源码在GitHub）：

package slice

import (
"strconv"
"unsafe"
)

func SliceInt2String4(s [][]int) []string {
res := make([]string, len(s))
for i, v := range s {
if len(v) < 1 {
res[i] = ""
continue
}

res[i] += strconv.Itoa(v[0])
for j := 1; j < len(v); j++ {
res[i] += "," + strconv.Itoa(v[j])
}
}

return res
}

func SliceInt2String5(s [][]int) []string {
res := make([]string, len(s))
b := make([]byte, 0, 256)
for i, v := range s {
if len(v) < 1 {
res[i] = ""
continue
}

b = b[:0]
b = append(b, strconv.Itoa(v[0])...)
for j := 1; j < len(v); j++ {
b = append(b, ',')
b = append(b, strconv.Itoa(v[j])...)
}

res[i] = string(b)
}

return res
}

SliceInt2String5 中使用 b = b[:0] 来促使达到反复使用一块缓冲区，写了一个性能测试（源码在GitHub），看一下效果吧:

goos: darwin
goarch: amd64
pkg: github.com/thinkeridea/example/slice
BenchmarkSliceInt2String4-8     300000      4420 ns/op    1440 B/op      82 allocs/op
BenchmarkSliceInt2String5-8    1000000      1102 ns/op     432 B/op      10 allocs/op
PASS
ok  github.com/thinkeridea/example/slice8.364s

较 + 版本提升接近4倍的性能，这是使用 slice 作为缓冲区极好的技巧，使用非常方便，并不用使用 builder 和 buffer， slice 操作非常的简单实用。

append 与 copy

如果合并多个 slice 为一个，有三种方式来合并，主要合并差异来源于创建新 slice 的方法，使用 var news []int 或者 news:=make([]int, 0, len(s1)+len(s2)....) 的方式创建的新变量就需要使用 append 来合并，如果使用 news:=make([]int, len(s1)+len(s2)....) 就需要使用 copy 来合并。不同的方法也有差异，append 和 copy 在这个例子中主要差异在于 append 适用于零长度的初始化 slice， copy 适用于确定长度的 slice。

写了一个测试来看看两者的差异吧（源码在GitHub）：

func BenchmarkExperiment3Append1(b *testing.B) {
for i := 0; i < b.N; i++ {
var s []int
for j := 0; j < 20; j++ {
s = append(s, []int{j, j + 1, j + 2, j + 3, j + 4}...)
}
}
}

func BenchmarkExperiment3Append2(b *testing.B) {
for i := 0; i < b.N; i++ {
s := make([]int, 0, 100)
for j := 0; j < 20; j++ {
s = append(s, []int{j, j + 1, j + 2, j + 3, j + 4}...)
}
}
}

func BenchmarkExperiment3Copy(b *testing.B) {
for i := 0; i < b.N; i++ {
s := make([]int, 100)
n := 0
for j := 0; j < 20; j++ {
n += copy(s[n:], []int{j, j + 1, j + 2, j + 3, j + 4})
}
}
}

测试结果如下：

goos: darwin
goarch: amd64
pkg: github.com/thinkeridea/example/slice
BenchmarkExperiment3Append1-8    2000000       782 ns/op    3024 B/op       6 allocs/op
BenchmarkExperiment3Append2-8   10000000       192 ns/op       0 B/op       0 allocs/op
BenchmarkExperiment3Copy-8      10000000       217 ns/op       0 B/op       0 allocs/op
PASS
ok  github.com/thinkeridea/example/slice6.926s

从结果上来看使用没有容量的 append 性能真的很糟糕，实际上不要对没有任何容量的 slice 进行 append 操作是最好的实践，在准备用 append 的时候应该预先给定一个容量，哪怕这个容量并不是确定的，像前面缓存连接字符串时一样，并不能明确使用的空间，先分配256个字节，这样的好处是可以减少系统调用分配内存的次数，即使空间不能用完，也不用太过担心浪费，append 本身扩容机制也会导致空间不是刚刚好用完的，而初始化的容量往往结合业务场景给的一个均值，这是很好的。

append 和 copy 在预先确定长度和容量时 append 效果更好一些，主要原因是 copy 需要一个变量来记录位置。如果使用场景中没有强制限定长度，建议使用 append 因为 append 会根据实际情况再做内存分配，较 copy 也更加灵活一些，而 copy 往往用在长度固定的地方，可以防止数据长度溢出的问题，例如标准库中 strings.Repeat 函数，它采用指数增长的方式快速填充指定数量的字符，但是如果使用 append 就会发生多余的内存分配，导致长度溢出。

func Repeat(s string, count int) string {
b := make([]byte, len(s)*count)
bp := copy(b, s)
for bp < len(b) {
copy(b[bp:], b[:bp])
bp *= 2
}
return string(b)
}

csv reader 中的一个例子

官方标准库 csv 的读取性能极高，其中 reader 里面有使用 slice 极好的例子，以下是简略的代码，如果想要全面了解程序需要去看标准库的源码：

func (r *Reader) readRecord(dst []string) ([]string, error) {
line, errRead = r.readLine()
if errRead == io.EOF {
return nil, errRead
}
r.recordBuffer = r.recordBuffer[:0]
r.fieldIndexes = r.fieldIndexes[:0]
parseField:
for {
if r.TrimLeadingSpace {
line = bytes.TrimLeftFunc(line, unicode.IsSpace)
}
i := bytes.IndexRune(line, r.Comma)
field := line
if i >= 0 {
field = field[:i]
} else {
field = field[:len(field)-lengthNL(field)]
}

r.recordBuffer = append(r.recordBuffer, field...)
r.fieldIndexes = append(r.fieldIndexes, len(r.recordBuffer))
if i >= 0 {
line = line[i+commaLen:]
continue parseField
}
break parseField
}

if err == nil {
err = errRead
}

// Create a single string and create slices out of it.
// This pins the memory of the fields together, but allocates once.
str := string(r.recordBuffer) // Convert to string once to batch allocations
dst = dst[:0]
if cap(dst) < len(r.fieldIndexes) {
dst = make([]string, len(r.fieldIndexes))
}
dst = dst[:len(r.fieldIndexes)]
var preIdx int
for i, idx := range r.fieldIndexes {
dst[i] = str[preIdx:idx]
preIdx = idx
}
return dst, err
}

这里删除了极多的代码，但是能看懂大意，其中 line 是一段 bufio 中的一段引用，所以这块数据不能返回给用户，也不能进行并发读取操作。

r.recordBuffer 和 r.fieldIndexes 是 csv 的缓存，他们初始的时候容量是0，是不是会有些奇怪，之前还建议 slice 初始一个长度，来减少内存分配，csv 这个库的设计非常的巧妙，假设 csv 每行字段的个数一样，数据长度也相近，现实业务确实如此，所以只有读取第一行数据的时候才会发生大量的 slice 扩容，之后其它行扩容的可能性非常的小，整个文件读取完也不会发生太多次，不得不说设计的太妙了。

r.recordBuffer 用来存储行中除了分隔符的所有数据，r.fieldIndexes 用来存储每个字段数据在 r.recordBuffer 中的索引。每次都通过 r.recordBuffer[:0] 这个的数据获取，读取每行数据都反复使用这块内存，极大的减少内存开销。

更巧妙的设计是 str := string(r.recordBuffer) 源代码中也有详细的说明，一次性分配足够的内存，要知道类型转换是会发生内存拷贝的，分配新的内存，如果每个字段转换一次，会发生很多的内存拷贝和分配，之后通过 dst[i] = str[preIdx:idx] 引用 str 中的数据达到切分字段的效果，因为引用字符串并不会拷贝字符串（字符串不可变，引用字符串的子串是安全的）所以其代价非常的小。

这段源码中还有一个很多人都不知道的 slice 特性的例子，dst = dst[:0]; dst = dst[:len(r.fieldIndexes)] 这两句话放到一起是不是感觉很不可思议，明明 dst 的长度被清空了，dst[:len(r.fieldIndexes)] 不是会发生索引越界吗，很多人认为 s[i:l] 这种写法是当前 slice 的索引，实际并非如此，这里面的 i 和 j 是底层引用数组相对当前 slice 引用位置的索引，并不受当前 slice 的长度的影响。

这里只是简单引用 csv 源码中的一段分析其 slice 的巧妙用法，即把 slice 当做数据缓存，也作为分配内存的一种极佳的方法，这个示例中的关于 slice 的使用值得反复推敲。

内存池

早些时间阅读 GitHub 上的一些源码，发现一个实现内存次的例子，里面对 slice 的应用非常有特点，在这里拿来分析一下（GitHub源码）：

func NewChanPool(minSize, maxSize, factor, pageSize int) *ChanPool {
pool := &ChanPool{make([]chanClass, 0, 10), minSize, maxSize}
for chunkSize := minSize; chunkSize <= maxSize && chunkSize <= pageSize; chunkSize *= factor {
c := chanClass{
size:   chunkSize,
page:   make([]byte, pageSize),
chunks: make(chan []byte, pageSize/chunkSize),
}
c.pageBegin = uintptr(unsafe.Pointer(&c.page[0]))
for i := 0; i < pageSize/chunkSize; i++ {
// lock down the capacity to protect append operation
mem := c.page[i*chunkSize : (i+1)*chunkSize : (i+1)*chunkSize]
c.chunks <- mem
if i == len(c.chunks)-1 {
c.pageEnd = uintptr(unsafe.Pointer(&mem[0]))
}
}
pool.classes = append(pool.classes, c)
}
return pool
}

这里采用步进式分页，保证每页上的数据块大小相同，一次性创建整个页 make([]byte, pageSize) ，之后从页切分数据块 mem := c.page[i*chunkSize : (i+1)*chunkSize : (i+1)*chunkSize]，容量和数据块长度一致，创建一块较大的内存，减少系统调用，当然这个例子中还可以创建更大的内存，就是每页容量的总大小，避免创建更多页，所有的块数据都引用一块内存。

这里限制了每个块的容量，默认引用 slice 的容量是引用起始位置到底层数组的结尾，但是可以指定容量，这就保证了获取的数据块不会因为用户不遵守约定超出其大小导致数据写入到其它块中的问题，设定了容量用户使用超出容量后就会拷贝出去并创建新的 slice 实在的很妙的用法。

一次分配更大的内存可以减少内存碎片，更好的复用内存。

func (pool *ChanPool) Alloc(size int) []byte {
if size <= pool.maxSize {
for i := 0; i < len(pool.classes); i++ {
if pool.classes[i].size >= size {
mem := pool.classes[i].Pop()
if mem != nil {
return mem[:size]
}
break
}
}
}
return make([]byte, size)
}

获取内存池中的内存就非常简单，查找比需要大小更大的块并返回即可，这不失为一个较好的内存复用算法。

func (pool *ChanPool) Free(mem []byte) {
size := cap(mem)
for i := 0; i < len(pool.classes); i++ {
if pool.classes[i].size == size {
pool.classes[i].Push(mem)
break
}
}
}

当使用完释放内存时实现的并不是很好，应该判断释放的数据是否是当前内存的一部分，如果不是的就不能放回到内存池中，因为用户未按约定大小使用，导致大量扩容而使得内存池中的数据碎片化，当然用户一旦发生扩容就会导致内存池中的缓存块丢失，导致存在大块内存无法释放，却也没法使用的情况。

之所以分析这个例子主要是分析其使用 slice 的方法和技巧，并不推荐使用该方法管理内存。

拓展

更多关于 slice 应用的例子可以参考标准库 bytes 与 bufio， buffer 与 bufio 的使用极其相似，两个包都是使用 slice 来减少内存分配及系统调用来达到实现缓冲和缓存的例子。

【Go】深入剖析slice和array

2019-01-11T22:36:26.000Z

array 和 slice 看似相似，却有着极大的不同，但他们之间还有着千次万缕的联系 slice 是引用类型、是 array 的引用，相当于动态数组，
这些都是 slice 的特性，但是 slice 底层如何表现，内存中是如何分配的，特别是在程序中大量使用 slice 的情况下，怎样可以高效使用 slice？
今天借助 Go 的 unsafe 包来探索 array 和 slice 的各种奥妙。

数组

slice 是在 array 的基础上实现的，需要先详细了解一下数组。

** 维基上如此介绍数组：**

在计算机科学中，数组数据结构（英语：array data structure），简称数组（英语：Array），是由相同类型的元素（element）的集合所组成的数据结构，分配一块连续的内存来存储，利用元素的索引（index）可以计算出该元素对应的存储地址。
** 数组设计之初是在形式上依赖内存分配而成的，所以必须在使用前预先请求空间。这使得数组有以下特性：**
请求空间以后大小固定，不能再改变（数据溢出问题）；
在内存中有空间连续性的表现，中间不会存在其他程序需要调用的数据，为此数组的专用内存空间；
在旧式编程语言中（如有中阶语言之称的C），程序不会对数组的操作做下界判断，也就有潜在的越界操作的风险（比如会把数据写在运行中程序需要调用的核心部分的内存上）。

根据维基的介绍，了解到数组是存储在一段连续的内存中，每个元素的类型相同，即是每个元素的宽度相同，可以根据元素的宽度计算元素存储的位置。
通过这段介绍总结一下数组有一下特性：

分配在连续的内存地址上
元素类型一致，元素存储宽度一致
空间大小固定，不能修改
可以通过索引计算出元素对应存储的位置（只需要知道数组内存的起始位置和数据元素宽度即可）
会出现数据溢出的问题（下标越界）

Go 中的数组如何实现的呢，恰恰就是这么实现的，实际上几乎所有计算机语言，数组的实现都是相似的，也拥有上面总结的特性。
Go 语言的数组不同于 C 语言或者其他语言的数组，C 语言的数组变量是指向数组第一个元素的指针；
而 Go 语言的数组是一个值，Go 语言中的数组是值类型，一个数组变量就表示着整个数组，意味着 Go 语言的数组在传递的时候，传递的是原数组的拷贝。

在程序中数组的初始化有两种方法 arr := [10]int{} 或 var arr [10]int，但是不能使用 make 来创建，数组这节结束时再探讨一下这个问题。
使用 unsafe来看一下在内存中都是如何存储的吧：

package main

import (
"fmt"
"unsafe"
)

func main() {
var arr = [3]int{1, 2, 3}

fmt.Println(unsafe.Sizeof(arr))
size := unsafe.Sizeof(arr[0])

// 获取数组指定索引元素的值
fmt.Println(*(*int)(unsafe.Pointer(uintptr(unsafe.Pointer(&arr[0])) + 1*size)))

// 设置数组指定索引元素的值
*(*int)(unsafe.Pointer(uintptr(unsafe.Pointer(&arr[0])) + 1*size)) = 10

fmt.Println(arr[1])
}

这段代码的输出如下 (Go Playground)：

12
2
10

首先说 12 是 fmt.Println(unsafe.Sizeof(arr)) 输出的，unsafe.Sizeof 用来计算当前变量的值在内存中的大小，12 这个代表一个 int 有4个字节，3 * 4 就是 12。
这是在32位平台上运行得出的结果，如果在64位平台上运行数组的大小是 24。从这里可以看出 [3]int 在内存中由3个连续的 int 类型组成，且有 12 个字节那么长，这就说明了数组在内存中没有存储多余的数据，只存储元素本身。

size := unsafe.Sizeof(arr[0]) 用来计算单个元素的宽度，int在32位平台上就是4个字节，uintptr(unsafe.Pointer(&arr[0])) 用来计算数组起始位置的指针，1*size 用来获取索引为1的元素相对数组起始位置的偏移，unsafe.Pointer(uintptr(unsafe.Pointer(&arr[0])) + 1*size)) 获取索引为1的元素指针，*(*int) 用来转换指针位置的数据类型，因为 int 是4个字节，所以只会读取4个字节的数据，由元素类型限制数据宽度，来确定元素的结束位置，因此得到的结果是 2。

上一个步骤获取元素的值，其中先获取了元素的指针，赋值的时候只需要对这个指针位置设置值就可以了， *(*int)(unsafe.Pointer(uintptr(unsafe.Pointer(&arr[0])) + 1*size)) = 10 就是用来给指定下标元素赋值。

package main

import (
"fmt"
"unsafe"
)

func main() {
n:= 10
var arr = [n]int{}
fmt.Println(arr)
}

如上代码，动态的给数组设定长度，会导致编译错误 non-constant array bound n，由此推导数组的所有操作都是编译时完成的，会转成对应的指令，通过这个特性知道数组的长度是数组类型不可或缺的一部分，并且必须在编写程序时确定。
可以通过 GOOS=linux GOARCH=amd64 go tool compile -S array.go 来获取对应的汇编代码，在 array.go 中做一些数组相关的操作，查看转换对应的指令。

之前的疑问，为什么数组不能用 make 创建？上面分析了解到数组操作是在编译时转换成对应指令的，而 make 是在运行时处理（特殊状态下会做编译器优化，make可以被优化，下面 slice 分析时来讲）。

slice

因为数组是固定长度且是值传递，很不灵活，所以在 Go 程序中很少看到数组的影子。然而 slice 无处不在，slice 以数组为基础，提供强大的功能和遍历性。
slice 的类型规范是[]T，slice T元素的类型。与数组类型不同，slice 类型没有指定的长度。

** slice 申明的几种方法：**

s := []int{1, 2, 3} 简短的赋值语句
var s []int var 申明
make([]int, 3, 8) 或 make([]int, 3) make 内置方法创建
s := ss[:5] 从切片或者数组创建

** slice 有两个内置函数来获取其属性：**

len 获取 slice 的长度
cap 获取 slice 的容量

slice 的属性，这东西是什么，还需借助 unsafe 来探究一下。

package main

import (
"fmt"
"unsafe"
)

func main() {
s := make([]int, 10, 20)

s[2] = 100
s[9] = 200

size := unsafe.Sizeof(0)
fmt.Printf("%x\n", *(*uintptr)(unsafe.Pointer(&s)))
fmt.Println(*(*int)(unsafe.Pointer(uintptr(unsafe.Pointer(&s)) + size)))
fmt.Println(*(*int)(unsafe.Pointer(uintptr(unsafe.Pointer(&s)) + size*2)))

fmt.Println(*(*[20]int)(unsafe.Pointer(*(*uintptr)(unsafe.Pointer(&s)))))
}

这段代码的输出如下 (Go Playground)：

c00007ce90
10
20
[0 0 100 0 0 0 0 0 0 200 0 0 0 0 0 0 0 0 0 0]

这段输出除了第一个，剩余三个好像都能看出点什么， 10 不是创建 slice 的长度吗，20 不就是指定的容量吗，最后这个看起来有点像 slice 里面的数据，但是数量貌似有点多，从第三个元素和第十个元素来看，正好是给 slice 索引 2 和 10 指定的值，但是切片不是长度是 10 个吗，难道这个是容量，容量刚好是 20个。

第二和第三个输出很好弄明白，就是 slice 的长度和容量，最后一个其实是 slice 引用底层数组的数据，因为创建容量为 20，所以底层数组的长度就是 20，从这里了解到切片是引用底层数组上的一段数据，底层数组的长度就是 slice 的容量，由于数组长度不可变的特性，当 slice 的长度达到容量大小之后就需要考虑扩容，不是说数组长度不能变吗，那 slice 怎么实现扩容呢，其实就是在内存上分配一个更大的数组，把当前数组上的内容拷贝到新的数组上， slice 来引用新的数组，这样就实现扩容了。

说了这么多，还是没有看出来 slice 是如何引用数组的，额…… 之前的程序还有一个输出没有搞懂是什么，难道这个就是底层数组的引用。

package main

import (
"fmt"
"unsafe"
)

func main() {
arr := [10]int{1, 2, 3}
arr[7] = 100
arr[9] = 200

fmt.Println(arr)

s1 := arr[:]
s2 := arr[2:8]

size := unsafe.Sizeof(0)
fmt.Println("----------s1---------")
fmt.Printf("%x\n", *(*uintptr)(unsafe.Pointer(&s1)))
fmt.Printf("%x\n", uintptr(unsafe.Pointer(&arr[0])))

fmt.Println(*(*int)(unsafe.Pointer(uintptr(unsafe.Pointer(&s1)) + size)))
fmt.Println(*(*int)(unsafe.Pointer(uintptr(unsafe.Pointer(&s1)) + size*2)))

fmt.Println(s1)
fmt.Println(*(*[10]int)(unsafe.Pointer(*(*uintptr)(unsafe.Pointer(&s1)))))

fmt.Println("----------s2---------")
fmt.Printf("%x\n", *(*uintptr)(unsafe.Pointer(&s2)))
fmt.Printf("%x\n", uintptr(unsafe.Pointer(&arr[0]))+size*2)

fmt.Println(*(*int)(unsafe.Pointer(uintptr(unsafe.Pointer(&s2)) + size)))
fmt.Println(*(*int)(unsafe.Pointer(uintptr(unsafe.Pointer(&s2)) + size*2)))

fmt.Println(s2)
fmt.Println(*(*[8]int)(unsafe.Pointer(*(*uintptr)(unsafe.Pointer(&s2)))))
}

以上代码输出如下(Go Playground)：

[1 2 3 0 0 0 0 100 0 200]
———-s1———
c00001c0a0
c00001c0a0
10
10
[1 2 3 0 0 0 0 100 0 200]
[1 2 3 0 0 0 0 100 0 200]
———-s2———
c00001c0b0
c00001c0b0
6
8
[3 0 0 0 0 100]
[3 0 0 0 0 100 0 200]

这段输出看起来有点小复杂，第一行输出就不用说了吧，这个是打印整个数组的数据。先分析一下 s1 变量的下面的输出吧，s1 := arr[:] 引用了整个数组，所以在第5、6行输出都是10，因为数组长度为10，所有 s1 的长度和容量都为10，那第3、4行输出是什么呢，他们怎么都一样呢，之前分析数组的时候通过 uintptr(unsafe.Pointer(&arr[0])) 来获取数组起始位置的指针的，那么第4行打印的就是数组的指针，这么就了解了第三行输出的是上面了吧，就是数组起始位置的指针，所以 *(*uintptr)(unsafe.Pointer(&s1)) 获取的就是引用数组的指针，但是这个并不是数组起始位置的指针，而是 slice 引用数组元素的指针，为什么这么说呢？

接着看 s2 变量下面的输出吧，s2 := arr[2:8] 引用数组第3~8的元素，那么 s2 的长度就是 6。根据经验可以知道 s2 变量输出下面第3行就是 slice 的长度，但是为啥第4行是 8 呢，slice 应用数组的指定索引起始位置到数组结尾就是 slice 的容量，所以所以从第3个位置到末尾，就是8个容量。在看第1行和第2行的输出，之前分析数组的时候通过 uintptr(unsafe.Pointer(&arr[0]))+size*2 来获取数组指定索引位置的指针，那么这段第2行就是数组索引为2的元素指针，*(*uintptr)(unsafe.Pointer(&s2)) 是获取切片的指针，第1行和第2行输出一致，所以 slice 实际是引用数组元素位置的指针，并不是数组起始位置的指针。

** 总结：**

slice 是的起始位置是引用数组元素位置的指针。
slice 的长度是引用数组元素起始位置到结束位置的长度。
slice 的容量是引用数组元素起始位置到数组末尾的长度。

经过上面一轮分析了解到 slice 有三个属性，引用数组元素位置指针、长度和容量。实际上 slice 的结构像下图一样：

slice 增长

slice 是如何增长的，用 unsafe 分析一下看看：

package main

import (
"fmt"
"unsafe"
)

func main() {
s := make([]int, 9, 10)

// 引用底层的数组地址
fmt.Printf("%x\n", *(*uintptr)(unsafe.Pointer(&s)))

s = append(s, 1)

// 引用底层的数组地址
fmt.Printf("%x\n", *(*uintptr)(unsafe.Pointer(&s)))

s = append(s, 1)

// 引用底层的数组地址
fmt.Printf("%x\n", *(*uintptr)(unsafe.Pointer(&s)))
}

以上代码的输出(Go Playground):

c000082e90
9 10
c000082e90
10 10
c00009a000
11 20

从结果上看前两次地址是一样的，初始化一个长度为9，容量为10的 slice，当第一次 append 的时候容量是足够的，所以底层引用数组地址未发生变化，此时 slice 的长度和容量都为10，之后再次 append 的时候发现底层数组的地址不一样了，因为 slice 的长度超过了容量，但是新的 slice 容量并不是11而是20，这要说 slice 的机制了，因为数组长度不可变，想扩容 slice就必须分配一个更大的数组，并把之前的数据拷贝到新数组，如果一次只增加1个长度，那就会那发生大量的内存分配和数据拷贝，这个成本是很大的，所以 slice 是有一个增长策略的。

Go 标准库 runtime/slice.go 当中有详细的 slice 增长策略的逻辑：

func growslice(et *_type, old slice, cap int) slice {
    .....
    
    // 计算新的容量，核心算法用来决定slice容量增长
newcap := old.cap
doublecap := newcap + newcap
if cap > doublecap {
newcap = cap
} else {
if old.len < 1024 {
newcap = doublecap
} else {
for 0 < newcap && newcap < cap {
newcap += newcap / 4
}
if newcap <= 0 {
newcap = cap
}
}
}

    // 根据et.size调整新的容量
var overflow bool
var lenmem, newlenmem, capmem uintptr
switch {
case et.size == 1:
lenmem = uintptr(old.len)
newlenmem = uintptr(cap)
capmem = roundupsize(uintptr(newcap))
overflow = uintptr(newcap) > maxAlloc
newcap = int(capmem)
case et.size == sys.PtrSize:
lenmem = uintptr(old.len) * sys.PtrSize
newlenmem = uintptr(cap) * sys.PtrSize
capmem = roundupsize(uintptr(newcap) * sys.PtrSize)
overflow = uintptr(newcap) > maxAlloc/sys.PtrSize
newcap = int(capmem / sys.PtrSize)
case isPowerOfTwo(et.size):
var shift uintptr
if sys.PtrSize == 8 {
// Mask shift for better code generation.
shift = uintptr(sys.Ctz64(uint64(et.size))) & 63
} else {
shift = uintptr(sys.Ctz32(uint32(et.size))) & 31
}
lenmem = uintptr(old.len) << shift
newlenmem = uintptr(cap) << shift
capmem = roundupsize(uintptr(newcap) << shift)
overflow = uintptr(newcap) > (maxAlloc >> shift)
newcap = int(capmem >> shift)
default:
lenmem = uintptr(old.len) * et.size
newlenmem = uintptr(cap) * et.size
capmem = roundupsize(uintptr(newcap) * et.size)
overflow = uintptr(newcap) > maxSliceCap(et.size)
newcap = int(capmem / et.size)
}

    ......

var p unsafe.Pointer
if et.kind&kindNoPointers != 0 {
p = mallocgc(capmem, nil, false)  // 分配新的内存
memmove(p, old.array, lenmem) // 拷贝数据
memclrNoHeapPointers(add(p, newlenmem), capmem-newlenmem)
} else {
p = mallocgc(capmem, et, true) // 分配新的内存
if !writeBarrier.enabled {
memmove(p, old.array, lenmem)
} else {
for i := uintptr(0); i < lenmem; i += et.size {
typedmemmove(et, add(p, i), add(old.array, i)) // 拷贝数据
}
}
}

return slice{p, old.len, newcap} // 新slice引用新的数组，长度为旧数组的长度，容量为新数组的容量
}

基本呢就三个步骤，计算新的容量、分配新的数组、拷贝数据到新数组，社区很多人分享 slice 的增长方法，实际都不是很精确，因为大家只分析了计算 newcap 的那一段，也就是上面注释的第一部分，下面的 switch 根据 et.size 来调整 newcap 一段被直接忽略，社区的结论是：”如果 selic 的容量小于1024个元素，那么扩容的时候 slice 的 cap 就翻番，乘以2；一旦元素个数超过1024个元素，增长因子就变成1.25，即每次增加原来容量的四分之一” 大多数情况也确实如此，但是根据 newcap 的计算规则，如果新的容量超过旧的容量2倍时会直接按新的容量分配，真的是这样吗?

package main

import (
"fmt"
)

func main() {
s := make([]int, 10, 10)
fmt.Println(len(s), cap(s))
s2 := make([]int, 40)

s = append(s, s2...)
fmt.Println(len(s), cap(s))

}

以上代码的输出(Go Playground):

10 10
50 52

这个结果有点出人意料，如果是2倍增长应该是 10 * 2 * 2 * 2 结果应该是80，如果说新的容量高于旧容量的两倍但结果也不是50，实际上 newcap 的结果就是50，那段逻辑很好理解，但是switch 根据 et.size 来调整 newcap 后就是52了，这段逻辑走到了 case et.size == sys.PtrSize 这段，详细的以后做源码分析再说。

** 总结 **

当 slice 的长度超过其容量，会分配新的数组，并把旧数组上的值拷贝到新的数组
逐个元素添加到 slice 并操过其容量，如果 selic 的容量小于1024个元素，那么扩容的时候 slice 的 cap 就翻番，乘以2；一旦元素个数超过1024个元素，增长因子就变成1.25，即每次增加原来容量的四分之一。
批量添加元素，当新的容量高于旧容量的两倍，就会分配比新容量稍大一些，并不会按上面第二条的规则扩容。
当 slice 发生扩容，引用新数组后，slice 操作不会再影响旧的数组，而是新的数组（社区经常讨论的传递 slice 容量超出后，修改数据不会作用到旧的数据上），所以往往设计函数如果会对长度调整都会返回新的 slice，例如 append 方法。

slice 是引用类型？

slice 不发生扩容，所有的修改都会作用在原数组上，那如果把 slice 传递给一个函数或者赋值给另一个变量会发生什么呢，slice 是引用类型，会有新的内存被分配吗。

package main

import (
"fmt"
"strings"
"unsafe"
)

func main() {
s := make([]int, 10, 20)

size := unsafe.Sizeof(0)
fmt.Printf("%p\n", &s)
fmt.Printf("%x\n", *(*uintptr)(unsafe.Pointer(&s)))
fmt.Println(*(*int)(unsafe.Pointer(uintptr(unsafe.Pointer(&s)) + size)))
fmt.Println(*(*int)(unsafe.Pointer(uintptr(unsafe.Pointer(&s)) + size*2)))

slice(s)

s1 := s
fmt.Printf("%p\n", &s1)
fmt.Printf("%x\n", *(*uintptr)(unsafe.Pointer(&s1)))
fmt.Println(*(*int)(unsafe.Pointer(uintptr(unsafe.Pointer(&s1)) + size)))
fmt.Println(*(*int)(unsafe.Pointer(uintptr(unsafe.Pointer(&s1)) + size*2)))

fmt.Println(strings.Repeat("-", 50))

*(*int)(unsafe.Pointer(uintptr(unsafe.Pointer(&s1)) + size)) = 20

fmt.Printf("%x\n", *(*uintptr)(unsafe.Pointer(&s)))
fmt.Println(*(*int)(unsafe.Pointer(uintptr(unsafe.Pointer(&s)) + size)))
fmt.Println(*(*int)(unsafe.Pointer(uintptr(unsafe.Pointer(&s)) + size*2)))

fmt.Printf("%x\n", *(*uintptr)(unsafe.Pointer(&s1)))
fmt.Println(*(*int)(unsafe.Pointer(uintptr(unsafe.Pointer(&s1)) + size)))
fmt.Println(*(*int)(unsafe.Pointer(uintptr(unsafe.Pointer(&s1)) + size*2)))

fmt.Println(s)
fmt.Println(s1)
fmt.Println(strings.Repeat("-", 50))

s2 := s
s2 = append(s2, 1)

fmt.Println(len(s), cap(s), s)
fmt.Println(len(s1), cap(s1), s1)
fmt.Println(len(s2), cap(s2), s2)

}

func slice(s []int) {
size := unsafe.Sizeof(0)
fmt.Printf("%p\n", &s)
fmt.Printf("%x\n", *(*uintptr)(unsafe.Pointer(&s)))
fmt.Println(*(*int)(unsafe.Pointer(uintptr(unsafe.Pointer(&s)) + size)))
fmt.Println(*(*int)(unsafe.Pointer(uintptr(unsafe.Pointer(&s)) + size*2)))
}

这个例子(Go Playground)比较长就不逐一分析了，在这个例子里面调用函数传递 slice 其变量的地址发生了变化，但是引用数组的地址，slice 的长度和容量都没有变化，这说明是对 slice 的浅拷贝，拷贝 slice 的三个属性创建一个新的变量，虽然引用底层数组还是一个，但是变量并不是一个。

第二个创建 s1 变量，使用 s 为其赋值，发现 s1 和函数调用一样也是 s 的浅拷贝，之后修改 s1 的长度发现 s1 的长度发生变化，但是 s 的长度保持不变，这也说明 s1 就是 s 的浅拷贝。

这样设计有什么优势呢，第三步创建 s2 变量，并且 append 一个元素，发现 s2 的长度发生变化了， s 并没有，虽然这个数据就在底层数组上，但是用常规的方法 s 是看不到第11个位置上的数据的， s1 因为长度覆盖到第11个元素，所有能够看到这个数据的变化。这里能看到采用浅拷贝的方式可以使得切片的属性各自独立，而不会相互影响，这样可以有一定的隔离性，缺点也很明显，如果两个变量都引用同一个数组，同时 append，在不发生扩容的情况下，总是最后一个 append 的结果被保留，可能引起一些编程上疑惑。

** 总结 **

slice 是引用类型，但是和 C 传引用是有区别的， C 里面的传引用是在编译器对原变量数据引用，并不会发生内存分配，而 Go 里面的引用类型传递和赋值会进行浅拷贝，在32位平台上有12个字节的内存分配，在64位上有24字节的内存分配。

* 传引用和引用类型是有区别的， slice 是引用类型。*

slice 的三种状态

slice 有三种状态：零切片、空切片、nil切片。

零切片

所有的类型都有零值，如果 slice 所引用数组元素都没有赋值，就是所有元素都是类型零值，那这就是零切片。

package main

import "fmt"

func main() {
var s = make([]int, 10)
fmt.Println(s)

var s1 = make([]*int, 10)
fmt.Println(s1)

var s2 = make([]string, 10)
fmt.Println(s2)
}

以上代码输出(Go Playground):

[0 0 0 0 0 0 0 0 0 0]
[ ]
[ ]

零切片很好理解，数组元素都为类型零值即为零切片，这种状态下的 slice 和正常的 slice 操作没有任何区别。

空切片

空切片可以理解就是切片的长度为0，就是说 slice 没有元素。社区大多数解释空切片为引用底层数组为 zerobase 这个特殊的指针。但是从操作上看空切片所有的表现就是切片长度为0，如果容量也为零底层数组就会指向 zerobase ，这样就不会发生内存分配，如果容量不会零就会指向底层数据，会有内存分配。

package main

import (
"fmt"
"reflect"
"strings"
"unsafe"
)

func main() {
var s []int
s1 := make([]int, 0)
s2 := make([]int, 0, 0)
s3 := make([]int, 0, 100)

arr := [10]int{}
s4 := arr[:0]

fmt.Println(strings.Repeat("--s--", 10))
fmt.Println(*(*reflect.SliceHeader)(unsafe.Pointer(&s)))
fmt.Println(s)
fmt.Println(s == nil)

fmt.Println(strings.Repeat("--s1--", 10))
fmt.Println(*(*reflect.SliceHeader)(unsafe.Pointer(&s1)))
fmt.Println(s1)
fmt.Println(s1 == nil)

fmt.Println(strings.Repeat("--s2--", 10))
fmt.Println(*(*reflect.SliceHeader)(unsafe.Pointer(&s2)))
fmt.Println(s2)
fmt.Println(s2 == nil)

fmt.Println(strings.Repeat("--s3--", 10))
fmt.Println(*(*reflect.SliceHeader)(unsafe.Pointer(&s3)))
fmt.Println(s3)
fmt.Println(s3 == nil)

fmt.Println(strings.Repeat("--s4--", 10))
fmt.Println(*(*reflect.SliceHeader)(unsafe.Pointer(&s4)))
fmt.Println(s4)
fmt.Println(s4 == nil)
}

以上代码输出(Go Playground):

–s—-s—-s—-s—-s—-s—-s—-s—-s—-s–
{0 0 0}
[]
–s1—-s1—-s1—-s1—-s1—-s1—-s1—-s1—-s1—-s1–
{18349960 0 0}
[]
–s2—-s2—-s2—-s2—-s2—-s2—-s2—-s2—-s2—-s2–
{18349960 0 0}
[]
–s3—-s3—-s3—-s3—-s3—-s3—-s3—-s3—-s3—-s3–
{824634269696 0 100}
[]
–s4—-s4—-s4—-s4—-s4—-s4—-s4—-s4—-s4—-s4–
{824633835680 0 10}
[]

以上示例中除了 s 其它的 slice 都是空切片，打印出来全部都是 []，s 是nil切片下一小节说。要注意 s1 和 s2 的长度和容量都为0，且引用数组指针都是 18349960，这点太重要了，因为他们都指向 zerobase 这个特殊的指针，是没有内存分配的。

nil切片

什么是nil切片，这个名字说明nil切片没有引用任何底层数组，底层数组的地址为nil就是nil切片。上一小节中的 s 就是一个nil切片，它的底层数组指针为0，代表是一个 nil 指针。

总结

零切片就是其元素值都是元素类型的零值的切片。
空切片就是数组指针不为nil，且 slice 的长度为0。
nil切片就是引用底层数组指针为 nil 的 slice。

操作上零切片、空切片和正常的切片都没有任何区别，但是nil切片会多两个特性，一个nil切片等于 nil 值，且进行 json 序列化时其值为 null，nil切片还可以通过赋值为 nil 获得。

数组与 slice 大比拼

对数组和 slice 做了性能测试，源码在 GitHub。

对不同容量和数组和切片做性能测试，代码如下，分为：100、1000、10000、100000、1000000、10000000

func BenchmarkSlice100(b *testing.B) {
for i := 0; i < b.N; i++ {
s := make([]int, 100)
for i, v := range s {
s[i] = 1 + i
_ = v
}
}
}

func BenchmarkArray100(b *testing.B) {
for i := 0; i < b.N; i++ {
a := [100]int{}
for i, v := range a {
a[i] = 1 + i
_ = v
}
}
}

测试结果如下：

goos: darwin
goarch: amd64
pkg: github.com/thinkeridea/example/array_slice/test
BenchmarkSlice100-8 20000000 69.8 ns/op 0 B/op 0 allocs/op
BenchmarkArray100-8 20000000 69.0 ns/op 0 B/op 0 allocs/op
BenchmarkSlice1000-8 5000000 318 ns/op 0 B/op 0 allocs/op
BenchmarkArray1000-8 5000000 316 ns/op 0 B/op 0 allocs/op
BenchmarkSlice10000-8 200000 9024 ns/op 81920 B/op 1 allocs/op
BenchmarkArray10000-8 500000 3143 ns/op 0 B/op 0 allocs/op
BenchmarkSlice100000-8 10000 114398 ns/op 802816 B/op 1 allocs/op
BenchmarkArray100000-8 20000 61856 ns/op 0 B/op 0 allocs/op
BenchmarkSlice1000000-8 2000 927946 ns/op 8003584 B/op 1 allocs/op
BenchmarkArray1000000-8 5000 342442 ns/op 0 B/op 0 allocs/op
BenchmarkSlice10000000-8 100 10555770 ns/op 80003072 B/op 1 allocs/op
BenchmarkArray10000000-8 50 22918998 ns/op 80003072 B/op 1 allocs/op
PASS
ok github.com/thinkeridea/example/array_slice/test 23.333s

从上面的结果可以发现数组和 slice 在1000以内的容量上时性能机会一致，而且都没有内存分配，这应该是编译器对 slice 的特殊优化。
从10000~1000000容量时数组的效率就比slice好了一倍有余，主要原因是数组在没有内存分配做了编译优化，而 slice 有内存分配。
但是10000000容量往后数组性能大幅度下降，slice 是数组性能的两倍，两个都在运行时做了内存分配，其实这么大的数组还真是不常见，也没有比较做编译器优化了。

slice 与数组的应用场景总结

slice 和数组有些差别，特别是应用层上，特性差别很大，那什么时间使用数组，什么时间使用切片呢。
之前做了性能测试，在1000以内性能几乎一致，只有10000~1000000时才会出现数组性能好于 slice，由于数组在编译时确定长度，也就是再编写程序时必须确认长度，所有往常不会用到更大的数组，大多数都在1000以内的长度。我认为如果在编写程序是就已经确定数据长度，建议用数组，而且竟可能是局部使用的位置建议用数组（避免传递产生值拷贝），比如一天24小时，一小时60分钟，ip是4个 byte这种情况是可以用时数组的。

为什么推荐用数组，只要能在编写程序是确定数据长度我都会用数组，因为其类型会帮助阅读理解程序，dayHour := [24]Data 一眼就知道是按小时切分数据存储的，如要传递数组时可以考虑传递数组的指针，当然会带来一些操作不方便，往常我使用数组都是不需要传递给其它函数的，可能会在 struct 里面保存数组，然后传递 struct 的指针，或者用 unsafe 来反解析数组指针到新的数组，也不会产生数据拷贝，并且只增加一句转换语句。slice 会比数组多存储三个 int 的属性，而且指针引用会增加 GC 扫描的成本，每次传递都会对这三个属性进行拷贝，如果可以也可以考虑传递 slice 的指针，指针只有一个 int 的大小。

** 对于不确定大小的数据只能用 slice，否则就要自己做扩容很麻烦，对于确定大小的集合建议使用数组。**

【go】一次读锁重入导致的死锁故障

2018-12-25T14:30:10.000Z

在两天前第一次遇到自己的程序出现死锁，我一直非常的小心使用锁，了解死锁导致的各种可能性，
这次的经历让我未来会更加小心，下面来回顾一下死锁发生的过程与代码演进的过程吧。

简述业务背景及代码演进过程

我的程序中有一块缓存，数据会组织好放到内存中，会根据数据源（MySQL）更新而刷新缓存，是读多写少的应用场景。
内存中有一个很大数据列表，缓存模块会按数据维度进行分组，每次访问根据维度查找到这个列表里面的所有数据。
业务模块拿到数据后会根据业务需要再做一次筛选，选出N个符合条件的数据（具体多少个由业务模块的规则决定）。

以下是简化的代码：

package cache

import "sync"

type Cache struct {
lock sync.RWMutex
data []int // 实际数据比这个复杂很多有很多维度
}

func (c *Cache) Get() []int {
c.lock.RLock()
defer c.lock.RUnlock()

var res []int

// 筛选数据， 简单写一个筛选过程
for i := range c.data {
if c.data[i] > 10 {
res = append(res, c.data[i])
}
}

return res
}

这个方法返回的数据会很多，可实际业务需要的数据只有几个而已，那做一个优化吧，利用 go 的 chan 实现一个迭代生成器，每次只返回一个数据，业务端找到需要的数据后立即终止。

调整后的方法大致像下面这样:

package cache

import "sync"

type Cache struct {
lock sync.RWMutex
data []int // 实际数据比这个复杂很多有很多维度
}

func (c *Cache) Get(next chan struct{}) chan int {
ch := make(chan int, 1)

go func() {
c.lock.RLock()
defer c.lock.RUnlock()
defer close(ch)

// 筛选数据， 简单写一个筛选过程
for i := range c.data {
if c.data[i] > 10 {

ch <- i

if _, ok := <-next; !ok {
return
}
}
}
}()

return ch
}

调用端的代码类似下面这样：

data := make([]int, 0, 10)
c := Cache{}
next := make(chan struct{})
for i := range c.Get(next) {
    data = append(data, i)
    if len(data) >= 10 {
        close(next)
        break
    }

    next <- struct{}{}
}

这样调整后查看程序的内存分配显著降低，而且平安无事在生产环境运行了半个月^_^，当然截止当前还不会出现死锁的情况。
有一天业务调整了，在 cache 模块有另外一个方法，公用这个锁（实际我缓存模块为了统一，都使用一个锁，方便管理），下面的代码也写到这个 cache 组件里面。

以下代码只增加了改变的部分，.... 保持原来的代码不变。

package cache

import "sync"

type Cache struct {
....
x int
}

func (c *Cache) XX(i int) int{
c.lock.RLock()
defer c.lock.RUnlock()
    
if  i >c.x {
return i
}
return 0
} 

....

添加一个方法怎么就导致死锁了呢，主要是调用端的业务代码也发生变化了，更改如下：

data := make([]int, 0, 10)
c := Cache{}
next := make(chan struct{})
for i := range c.Get(next) {
    data = append(data, i)
    if c.XX(i) != i  { // 在这里调用了缓存模块的另一个方法
        close(next)
        break
    }

    next <- struct{}{}
}

修改后的代码上线存活了5天就挂了，实际是当时业务订单需求很少，只是有很多流量请求，并没有频繁访问这个方法，否者会在极短的时间导致死锁，
通过这块简化的代码，也很难分析出会导致死锁，真实的业务代码很多，而且调用关系比较复杂，我们通过代码审核并没有发现任何问题。

事故现场分析排查问题

上线5天后突然接到服务无法响应的报警，事故发生立即查看了 grafana 的监控数据，发现在极段时间内服务器资源消耗极速增长，然后就立即没有响应了

通过业务监控发现服务在极端的时间打开近10万个 goroutine 之后持续了很长一段时间，
cpu 占用和 gc 都很正常，内存方面可以看出短时间内分配了很多内存，但是没有被释放，gc 没法回收说明一直被占用，

看到这里我心里在想可能是有个 goroutine 因为什么原因导致无法结束造成的事故吧，
然后我再往下看（实际页面是在需要滚动屏幕，第一屏只显示了上面6个模块），发现 open files 和 goroutine 的情况一致，并且之后的数据突然中断，
中断是因为服务无法影响，也就无法采集服务的信息了。

goroutine 并不会占用 open files，一个http服务导致这种情况大概只能是网络连接过多，我们遭受攻击了吗……
显然是没有的不然cpu不能很正常，那就是有可能请求无法响应，什么原因导致呢？

查看日志发现大量 http: Accept error: accept tcp 172.17.191.231:8090: accept4: too many open files; retrying in 1s 错误。

这些数据帮助我快速定位确实是有请求发送到服务器，服务器无法响应导致短时间内占用很多文件打开数，导致系统限制无法建立新的连接。
这里要说一下，即使客户端断开连接了，服务器连接还是没有办法关闭，因为 goroutine 没有办法关闭，除非自己退出。

找到原因了，服务没法响应，没法通过现场查找问题了，先重新启动一下服务，恢复业务在查找代码问题。

接下来就是查找代码问题了，期间又出现了一次故障，立即重启服务，恢复业务。

分析解决问题

通过几个小时分析代码逻辑，终于有了进展，发现上面的示例代码逻辑块导致读锁重入，存在死锁风险，这种死锁的碰撞概率非常低，
之前说过我们的缓存是读多写少的场景，如果只是读取数据，上面的代码不会有任何问题，我们一天刷新缓存的次数也不过百余次而已。

看一下究竟发生了什么导致的死锁吧：

程序执行 cache.Get 获取一个 chan, 在 cache.Get 里面有一个 goroutine 读取数据只有加了读写锁，只有 goroutine 关闭才会释放
for i := range c.Get(next) { 遍历 chan 时 goroutine 不会结束，也就说读锁没有被释放
遍历时执行了 c.XX(i) 方法，在该方面里面也加了读锁，形成了读锁重入的场景，但是该放执行周期很短，执行完就会马上释放

好吧，这样的流程并没有形成死锁，什么情况下导致的死锁呢，接着看一下一个场景：

程序执行 cache.Get 获取一个 chan, 在 cache.Get 里面有一个 goroutine 读取数据只有加了读写锁，只有 goroutine 关闭才会释放
for i := range c.Get(next) { 遍历 chan 时 goroutine 不会结束，也就说读锁没有被释放
数据发生了改变，触发了缓存刷新，申请独占锁（写锁），等待所有读锁释放
遍历时执行 c.XX(i) 方法，该方法申请读锁，因为写锁在等待，所以任何读锁都将等待写锁释放后才能添加成功
for 循环被阻塞， cache.Get 里面的 goroutine 无法退出，无法释放读锁
写锁等待所有读锁释放
c.XX(i) 等待写锁释放
….

重点看第三步，这里是关键，因为在两个嵌套的读锁中间申请写锁，导致死锁发生，找到原因修复起来很简单的，

调整 cache.Get 加锁的方法，把 c.data 赋值给一个临时变量 data, 在这段代码前后加锁和释放锁，锁的代码块更小，时间更短

c.data 单独拷贝是安全的，那怕是指针数据，因为每次刷新缓存都会给 c.data 重新赋值，分配新的内存空间。

package cache

import "sync"

type Cache struct {
lock sync.RWMutex
data []int // 实际数据比这个复杂很多有很多维度
x int
}
    
func (c *Cache) XX(i int) int{
    c.lock.RLock()
    defer c.lock.RUnlock()
    
    if  i >c.x {
        return i
    }
    return 0
} 

func (c *Cache) Get(next chan struct{}) chan int {
ch := make(chan int, 1)

go func() {
defer close(ch)

c.lock.RLock()
data := c.data
c.lock.RUnlock()

// 筛选数据， 简单写一个筛选过程
for i := range data {
if data[i] > 10 {

ch <- i

if _, ok := <-next; !ok {
return
}
}
}
}()

return ch
}

修复之后的业务状态：

复现问题

用程序复现一下上面的场景可以吗，好像有点难，我写了一个简单的复现代码，如下：

package main

import (
"fmt"
"runtime"
"sync"
)

var l = sync.RWMutex{}

func main() {
var wg sync.WaitGroup
wg.Add(2)
c := make(chan int)
go func() {
l.RLock() // 读锁1
defer l.RUnlock()
fmt.Println(1)
c <- 1
fmt.Println(2)
runtime.Gosched()
fmt.Println(3)
b()
fmt.Println(4)
wg.Done()
}()

go func() {
fmt.Println(5)
<-c
fmt.Println(6)
l.Lock()
fmt.Println(7)
fmt.Println(8)
defer l.Unlock()
fmt.Println(9)
wg.Done()
}()

go func() {
i := 1
for {
i++
}
}()
wg.Wait()
}

func b() {
fmt.Println(10)
l.RLock() // 读锁2
fmt.Println(11)
defer l.RUnlock()
fmt.Println(12)
}

这段程序的输出(受 goroutine 运行时影响在输出数字3之前会有些许差异)：

分析一下这个运行流程吧:

首先加上读锁1，就是 fmt.Println(1) 之前，状态加读锁1
另外一个 goroutine 启动，fmt.Println(5)，状态加读锁1
发送数据 c <- 1 ，状态加读锁1
接受到数据 <-c fmt.Println(6)，状态加读锁1
输出 2 fmt.Println(2)，状态加读锁1
暂停当前 goroutine runtime.Gosched() ，状态加读锁1
申请写锁 l.Lock()，等待读锁1释放，状态加读锁1、写锁等待
切换 goroutine 执行 fmt.Println(3) 与 b()，状态加读锁1、写锁等待
输出10 fmt.Println(10)，申请读锁2，等待写锁释放，状态加读锁1、写锁等待、读锁2等待
支持程序永久阻塞……

分析读写锁实现

func (rw *RWMutex) RLock() {
if race.Enabled {
_ = rw.w.state
race.Disable()
}
if atomic.AddInt32(&rw.readerCount, 1) < 0 {
// A writer is pending, wait for it.
runtime_SemacquireMutex(&rw.readerSem, false)
}
if race.Enabled {
race.Enable()
race.Acquire(unsafe.Pointer(&rw.readerSem))
}
}

申请写锁时会在 rw.readerCount 读数量变量上自增加 1，如果结果小于 0，当前读锁进入修改等待读锁唤醒信号，
单独看着一个方法会比较懵，为啥读的数量会小于0呢，接着看写锁。

func (rw *RWMutex) Lock() {
if race.Enabled {
_ = rw.w.state
race.Disable()
}
// First, resolve competition with other writers.
rw.w.Lock()
// Announce to readers there is a pending writer.
r := atomic.AddInt32(&rw.readerCount, -rwmutexMaxReaders) + rwmutexMaxReaders
// Wait for active readers.
if r != 0 && atomic.AddInt32(&rw.readerWait, r) != 0 {
runtime_SemacquireMutex(&rw.writerSem, false)
}
if race.Enabled {
race.Enable()
race.Acquire(unsafe.Pointer(&rw.readerSem))
race.Acquire(unsafe.Pointer(&rw.writerSem))
}
}

申请写锁时会先加上互斥锁，也就是有其它写的客户端的话会等待写锁释放才能加上，具体实现看互斥锁的代码，
然后在 rw.readerCount 上自增一个极大的负数 1 << 30 ，读写锁这里也就限制了我们的同时读的进程不能超过这个值。
然后在结果上加上 rwmutexMaxReaders 也就是 atomic.AddInt32(&rw.readerCount, -rwmutexMaxReaders) + rwmutexMaxReaders 得到实际读客户端的数量
如果读的客户端不等于0，就在 rw.readerWait 自增读客户端的数量，之后陷入睡眠，等待 rw.writerSem 唤醒。

分析了这两段代码我们就能明白，写锁等待或者添加时，读锁没法添加上

func (rw *RWMutex) RUnlock() {
if race.Enabled {
_ = rw.w.state
race.ReleaseMerge(unsafe.Pointer(&rw.writerSem))
race.Disable()
}
if r := atomic.AddInt32(&rw.readerCount, -1); r < 0 {
if r+1 == 0 || r+1 == -rwmutexMaxReaders {
race.Enable()
throw("sync: RUnlock of unlocked RWMutex")
}
// A writer is pending.
if atomic.AddInt32(&rw.readerWait, -1) == 0 {
// The last reader unblocks the writer.
runtime_Semrelease(&rw.writerSem, false)
}
}
if race.Enabled {
race.Enable()
}
}

释放读锁，先在 rw.readerCount 减 1，然后检查读客户端是否小于0，如果小于0说明有写锁在等待，
在 rw.readerWait 上减1，这个变量记录的是写等待读客户端的数量，如果没有需要等待的读客户端了，就通知 rw.writerSem 唤醒写锁

func (rw *RWMutex) Unlock() {
if race.Enabled {
_ = rw.w.state
race.Release(unsafe.Pointer(&rw.readerSem))
race.Disable()
}

// Announce to readers there is no active writer.
r := atomic.AddInt32(&rw.readerCount, rwmutexMaxReaders)
if r >= rwmutexMaxReaders {
race.Enable()
throw("sync: Unlock of unlocked RWMutex")
}
// Unblock blocked readers, if any.
for i := 0; i < int(r); i++ {
runtime_Semrelease(&rw.readerSem, false)
}
// Allow other writers to proceed.
rw.w.Unlock()
if race.Enabled {
race.Enable()
}
}

写锁在释放时会给 rw.readerCount 自增 rwmutexMaxReaders 还原真实读客户端数量。
for i := 0; i < int(r); i++ { 用来唤醒所有的读客户端，因为在写锁的时候，申请读锁的客户端会被计数，但是都会陷入睡眠状态。

总结

以前特别强调过读锁重入导致死锁的问题，而且这个问题非常难在业务代码里面复现，触发几率很低，
编译和运行时都无法检测这种情况，所以千万不能陷入读锁重入的嵌套使用的情况，否者问题非常难以排查。

关于加锁的几个小经验：

运行时离开当前逻辑就释放锁。
锁的粒度越小越好，加锁后尽快释放锁。
尽量不用 defer 释放锁。
读锁不要嵌套。