[TOC]

疑问：

1. 为什么append要返回一个切片？

```go
var a = make([]int, 1, 2)
fmt.Printf("%v\t\t%v\n", a, (*reflect.SliceHeader)(unsafe.Pointer(&a)))
a = append(a, 2)
fmt.Printf("%v\t\t%v\n", a, (*reflect.SliceHeader)(unsafe.Pointer(&a)))
a = append(a, 3, 4, 5)
fmt.Printf("%v\t%v\n", a, (*reflect.SliceHeader)(unsafe.Pointer(&a)))
// [0] &{824634327040 1 2}
// [0 2] &{824634327040 2 2}
// [0 2 3 4 5] &{824634368000 5 6}
```

- 如果切片容量不足的话，go扩容切片需要重新申请内存，内存地址会发生变化

- 如果切片容量充足,go不需要扩容，底层数组data内存地址也不会发生变化，`func append(slice []Type, elems ...Type) []Type` 传入的切片也是复制(切片数据结构), 函数的参数是传值, 底层数组部分是通过隐式指针传递(指针本身依然是传值的，但是指针指向的却是同一份的数据)，所以被调用函数是可以通过指针修改掉调用参数切片中的数据。除了数据之外，切片结构还包含了切片长度和切片容量信息，这2个信息也是传值的。如果被调用函数中修改了`Len`或`Cap`信息的话，就无法反映到调用参数的切片中，这时候一般会通过返回修改后的切片来更新之前的切片。

2. 这里注意一下切片a的容量是6，按照我们之前的说法，newcap > 2倍容量时, 取newcap为最终容量，但这里5 > 2 * 2，为什么这里是6呢？内存对齐，最后会解释一下这里的原因

# Go语言程序的初始化

执行从main.main开始，如果main导入了其他的包，会按照顺序将他们包含进mian包里

- 如果某个包被多次导入的话，只会导入的时候只会执行一次
- 当一个包被导入的时候如果还导入了其他的包，则会将其他的包先导入进来，创建和初始化常量和变量，再调用包里的init函数
- 如果一个包里的有多个init函数，调用顺序未定义，同一个文件内的init函数则是以顺序依次调用
- 最后，当main包的所有包级变量、常量创建初始化完成，init函数执行之后才会进入main.main

![](/images/blog/golang/assert/数组切片引用.png)

# 函数

```go
// 具名函数
func Add(a, b int) int {
 return a+b
}

// 匿名函数
var Add = func(a, b int) int {
 return a+b
}

func Inc() (v int) {
 // 闭包，什么是闭包
 defer func() {v++}()
 return 42
}
// 43，这里为什么是43而不是42

func main() {
 for i := 0; i < 3; i++ {
 defer func(){ println(i) } ()
 }
}
// Output:
// 3
// 3
// 3
```

- 函数有具名函数和匿名函数之分，包级一般都是具名函数，具名函数是匿名函数的一种特例。
- 当匿名函数引用了外部作用域中的变量时就成了闭包函数，闭包函数是函数式编程语言的核心。
- 函数可以有多个参数和返回值，参数和返回值都是以传值的方式和被调用者交换数据，支持可变参数传值，可变参数必须是最后一个参数，可变数量的参数其实是一个切片类型的参数。
- 函数不仅参数可以有名字，也可以给返回值命名。
- 闭包函数对外部捕获的变量不是以传值方式而是以引用方式传参
- 不建议for循环内部使用defer语句
- 任何可以通过函数参数修改调用参数的情形，是因为函数参数中显式或隐式的传入指针参数

# 方法

```go
// 关闭文件
func (f *File) Close() error {
 // ...
}
// 读文件数据
func (f *File) Read(offset int64, data []byte) int {
 // ...
}
```

- Go语言中，将第一个函数参数移动到函数前面 - 方法
- Go语言中，通过在结构体内置匿名的成员来实现继承
- Go语言中，方法是编译时静态绑定的

# 接口

Go语言在提供严格的类型检查的同时，通过接口类型实现了对鸭子类型的支持，使得安全动态的编程变得相对容易。

> 鸭子类型 - 当看到一只鸟走起来像鸭子、游泳起来像鸭子、叫起来也像鸭子，那么这只鸟就可以被称为鸭子。
>
> 在鸭子类型中，关注点在于对象的行为，能作什么；而不是关注对象所属的类型。例如，在不使用鸭子类型的语言中，我们可以编写一个函数，它接受一个类型为"鸭子"的对象，并调用它的"走"和"叫"方法。在使用鸭子类型的语言中，这样的一个函数可以接受一个任意类型的对象，并调用它的"走"和"叫"方法。如果这些需要被调用的方法不存在，那么将引发一个运行时错误。任何拥有这样的正确的"走"和"叫"方法的对象都可被函数接受的这种行为引出了以上表述，这种决定类型的方式因此得名。- 维基百科



在Go语言中，对于基础类型（非接口类型）不支持隐式转换，无法将一个int类型的值直接赋值给int64类型的变量，也无法将int的值赋值给底层是int类型新定义命名类型的变量，go语言对类型的一致性要求非常严格，但是对接口转化则是非常的灵活，对象和接口之间的转换、接口和接口之间的转换都可能是隐式的转换。

有时候对象和接口之间太灵活了，导致我们需要人为地限制这种无意之间的适配。常见的做法是定义一个含特殊方法来区分接口。比如`runtime`包中的`Error`接口就定义了一个特有的`RuntimeError`方法，用于避免其它类型无意中适配了该接口：

```go
type runtime.Error interface {
 error
 // RuntimeError is a no-op function but
 // serves to distinguish types that are run time
 // errors from ordinary errors: a type is a
 // run time error if it has a RuntimeError method.
 RuntimeError()
}

type testing.TB interface {
 Error(args ...interface{})
 Errorf(format string, args ...interface{})
 ...

 // A private method to prevent users implementing the
 // interface and so future additions to it will not
 // violate Go 1 compatibility.
 private()
}
```

扩容和内存对齐

```go
// 这个例子 讲讲扩容或内存
var a = make([]int, 1, 1)
fmt.Printf("%v\t%v\n", a, (*reflect.SliceHeader)(unsafe.Pointer(&a)))
a = append(a, 2, 3, 4, 5)
fmt.Printf("%v\t%v\n", a, (*reflect.SliceHeader)(unsafe.Pointer(&a)))
// [0] &{824634335232 1 1}
// [0 2 3 4 5] &{824634368000 5 6}
```

按照扩容的第二条，大于两倍旧容量，按理说应该是5但这里是6，那就是接下来的内存对齐了

- capmem = roundupsize(uintptr(newcap) * sys.PtrSize)
- newcap 我们计算出来是5, uintptr(newcap) * sys.PtrSize -> 5 * 8 = 40; roundupsize(40)
- (size+smallSizeDiv-1)/smallSizeDiv] -> (40 + 8 - 1)/8 = 5（这里是因为int存储的，后面小数都是截取）class_to_size[size_to_class8[5]] -> 48 
- 48 / 8 = 6 所以最终cap为6

记一下学习心得，写写来的踏实

go 函数方法接口

[TOC]

版本:

- go 1.13.4
- tcmalloc gperftools 2.7

我是学习go源码时看到go内存分配使用tcmalloc,早在看redis源码时就了解到tcmalloc了，redis支持zmalloc、tcmalloc、jemalloc几种内存分配，之前只是看了redis自带的zmalloc,没深入了解一下tcmalloc。看来存在必有其道理，不定啥时候就用到

- https://github.com/gperftools/gperftools
- [TCMalloc : Thread-Caching Malloc](http://goog-perftools.sourceforge.net/doc/tcmalloc.html)

学习内存分配，就要先了解一下物理内存的相关概念和描述：

- [linux物理内存描述](http://www.ilinuxkernel.com/files/Linux_Physical_Memory_Description.pdf)
- [Linux物理内存页面分配](http://www.ilinuxkernel.com/files/Linux_Physical_Memory_Page_Allocation.pdf)
- [linux内存地址映射](http://www.ilinuxkernel.com/files/Linux_Memory_Address_Mapping.pdf)

看完这些以后总结了几个问题：

- 什么是逻辑地址、线性地址、物理地址，linux是如何进行地址映射的？

- linux是管理内存的(NUMA), 节点(node)、区域(zone)、page(页面)？

- 为什么一个16G的内存，内核需要160M维护page_table？

- 什么是缺页异常？（给顶的逻辑地址不合法，逻辑页面没有对应的物理页面，MMU将会产生中断，向核心发出信号）


# 基础知识

## 堆栈

![](/images/blog/golang/assert/堆栈.png)

进程如何分配内存：

1. static alloction: 声明全局变量时属于静态分配，该空间只会分配一次，并且永远不会释放。
2. automatic allocation: 声明函数参数/局部变量 的复合语句会自动栈空间，复合语句推出时会自动释放变量
3. dynamic allocation: malloc/free

# TCMalloc

1. **TCMalloc要比操作系统提供glibc 2.3 malloc（ptmalloc2）内存分配快**。内存的分配速度和合适的大小对于开发者来说非常重要，如果满足不了开发者的需求可能更倾向于自己实现内存分配规则
2. **TCMalloc减少了多线程之间的锁竞争**。对于小对象分配，几乎是0竞争，对于大对象，TCMalloc使用避免上下文切换的自旋锁，ptmalloc2使用per thread arenas(每个线程都会有自己的锁，避免线程之间的竞争)，问题是内存无法从arenas移动到另外一个arenas。例如：线程一申请一块300M内存，任务完成后。线程二在相同的地址空间启动，如果两个线程绑定了不同arena,线程一申请的300M内存就无法复用，必须重新申请，导致内存爆炸。
3. **TCMalloc另一个优势是对琐碎内存的高效利用**。
> 自旋锁：多线程同步的一种锁，线程反复检查锁变量是否可用。由于线程在这一过程中保持执行，因此是一种忙等待。一旦获取了自旋锁，线程会一直保持该锁，直至显式释放自旋锁。自旋锁避免了进程上下文的调度开销，因此对于线程只会阻塞很短时间的场合是有效的 - [摘自维基百科](https://zh.wikipedia.org/wiki/自旋锁)

## 概述

基本思想: 小内存通过线程层次缓存分配(无锁，速度快)，分配失败后请求上层补一批，前面分配了过多的内存则回收

线程:

ThreadCache: 每个线程私有一份，尺寸小于256K的小内存申请均由ThreadCache进行分配，线程之间不需要竞争，非常高效。节省了加锁释放锁的时间。

全局: 

PageHeap: 中央堆处理器，被所有线程共享（分配需要锁定），负责和操作系统申请、释放内存，大尺寸内存申请直接通过PageHeap分配，

CentralCache: 作为PageHeap和ThreadCache的中间人，负责将PageHeap的内存切分为小块，恰当时机分配给ThreadCache，回收ThreadCache的内存并部分返还给PageHeap

span: 一块连续的内存页。
object: object是由span切分成的小块，object预设了一些规则，如8byte、16byte、32bbyte..., 同一个span切出来的object都是相同的规格，object不大于256k，超大内存直接分配span使用\

ThreadCache、CentralCache管理object, PageHeap管理的是span

## PageHeap 大内存分配

大对象（>32k）对齐内存页面4k(4的倍数)， 由central page heap处理，central page heap也是一个数组

k个pages分配过程：

1. 查看k个页面的空闲列表（free_list）。
2. 如果free_list为空，看下一个空闲列表是否有，如此循环
3. 最终，查询到最后一个空闲列表
4. 如果匹配失败，会从操作系统申请
5. 如果有大于k个page的空闲列表，会分配k给当前申请，剩下的pages会重新插入到相应的空闲列表中。

```c++
// 根据起始page的位置和长度确定span的范围
struct Span {
 PageID start; // Starting page number
 Length length; // Number of pages in span
 Span* next; // 注意，这里span结构一个双向链表
 Span* prev; // 
 union {
 void* objects; // Span会在CentralFreeList中拆分成由object组成的free list
 char span_iter_space[sizeof(SpanSet::iterator)];
 };
 unsigned int refcount : 16; // span的object被引用次数，refcount = 0时表示此span没有被使用
 unsigned int sizeclass : 8; // span被切分的object属于哪个级别的sizeClass
 unsigned int location : 2; // Span在的位置IN_USE？normal？returned？
 unsigned int sample : 1; // Sampled jobject?
 bool has_span_iter : 1; 
 // What freelist the span is on: IN_USE if on none, or normal or returned
 enum { IN_USE, ON_NORMAL_FREELIST, ON_RETURNED_FREELIST };
};
```
- IN_USE：正在使用 ON_NORMAL_FREELIST：未被使用 ON_RETURNED_FREELIST：用户已经归还

> refcount、sizeclass、objects数据CentralFreeList管理的内存

PageHeap维护了
- page和span的关系
- 空闲span的伙伴关系

PageHeap结构体

```c++
class PERFTOOLS_DLL_DECL PageHeap {
 PageMap pagemap_;
 struct SpanList {
 Span normal;
 Span returned;
 };
 SpanSet large_normal_;
 SpanSet large_returned_;

 SpanList free_[kMaxPages];
};
```

- PageMap pagemap_ 维护id和Page的映射关系
- 大于kMaxPages页面统一存放在large_normal_中，不在按照页面数目区分

## CentralCache
CentralCache是由size_class个CentralFreeList组成的数组由Static(static_vars.h)类管理
```c++
class CentralFreeList {
 SpinLock lock_;
 // We keep linked lists of empty and non-empty spans.
 size_t size_class_; // size-class span切分尺寸，每个span只能按同一种size-class切分
 Span empty_; // 未分配Span
 Span nonempty_; // 已分配Span
}
```
CentralFreeList作为中间人，从PageHeap中取出部分span并按照预定大小将其拆分为大小固定的object供ThreadCache共享。CentralFreelist是全局的，除了构造函数，其余操作都需加锁。

## ThreadCache 小内存分配

**小对象分配**

1. 将其大小映射到相应的大小object
2. 在本地thread_cached中相应的free_list查找
3. 如果free_list不为空，从列表中删除第一个对象并返回它

**thread_cache free_list为空**

1. 从此大小类的central cache的free_list中获取一堆object
2. 将获取到的object放到thread_cache的free_list中
3. 将新获取的object其中一个返回

**central_cache free_list为空**

1. 从central page allocator中申请一批page
2. 拆分为该大小级别（size_class）的一组object
3. 新对象(object)放置在中央缓存（central cache）的空闲列表（free_list）中

每个thread独立维护了各自的离散式空闲列表

```c++
// https://github.com/gperftools/gperftools/blob/master/src/thread_cache.h
// https://github.com/gperftools/gperftools/blob/master/src/thread_cache.cc
class ThreadCache {
 class FreeList {
 void* list_; // 链表第一个节点
 uint32_t length_; // 当前长度
 int32_t size_;
 }
 ThreadCache* next_;
 ThreadCache* prev_;
 // kClassSizesMax 96
 FreeList list_[96]; // size_class 数组，可用链表
 int32 size_; // 可用内存大小
 int32 max_size_; // size_ > max_size_ --> Scavenge()
 pthread_t tid_; // 属于哪个线程
}
```
ThreadCache list_变量即为size class的实现，在实现free list时没有使用next来指针指向下一个位置，而是直接使用 void* list_, 将下一个object的地址直接存储在上个前8个字节中，可以模拟单向链表，object分配个应用程序后可以直接覆盖前8个字节，节省了一个指针的空间。

![object](/images/blog/golang/assert/tcmalloc-object.png)

## size-class
```c++
 // 1. Sizes <= 1024 have an alignment >= 8. ceil(size/8)
 // 2. Sizes > 1024 have an alignment >= 128. ceil(size/128).

 // Size Expression Index
 // -------------------------------------------------------
 // 0 (0 + 7) / 8 0
 // 1 (1 + 7) / 8 1
 // ...
 // 1024 (1024 + 7) / 8 128
 // 1025 (1025 + 127 + (120<<7)) / 128 129
 // ...
 // 32768 (32768 + 127 + (120<<7)) / 128 376
```



# go 内存分配

go在程序启动时会分配一块虚拟内存地址是连续的内存, 结构如下

![](/images/blog/golang/assert/go-内存布局.png)

## 布局

### spans

是page和其管理对象的反查表，在回收时，从哪来回哪去。利用该表可访问地址相邻大块内存使用状态，以便将多个相邻内存合并成更大的内存，减少碎片，更好适应分配需求。

### bitemap

和gc有关，先不做过多深入，研究gc时候会深入理解

栈(stack)、全局变量和静态变量（.data/.bss）占用1bit，0: gc不需要关心是否回收，1: 需要分析是否需要回收

堆(heap) 需要占用2bit

### arena

用户对象分配区域，就是通常说的堆(heap)，go从heap中申请的内存就是在这个区域。

### 逃逸分析

什么时候从heap分配对象，go会自动确定哪些对象应该放在栈上，哪些应该放在堆上。简单的说：当一个对象的内容可能在生成该对象的函数结束后被访问，那么这个对象就会被分配在堆上。

**返回对象指针**

```go
func foo() *string {
	str := "Hello world"
	return &str
}
func main() {
	fmt.Println(foo())
}
```

```shell
$ git:(master) ✗ go run -gcflags '-m -l' bar.go
# command-line-arguments
./bar.go:7:9: &str escapes to heap
./bar.go:6:2: moved to heap: str
./bar.go:11:17: foo() escapes to heap
./bar.go:11:13: main ... argument does not escape
0xc0000101e0
```

**传递了对象的指针到其他函数**

```go
func greeter(name *string) {
	 *name = "hello " + *name
}
func main() {
	name := "douyacun"
	greeter(&name)
	fmt.Println(name)
}
```

```shell
➜ bar git:(master) ✗ go run -gcflags '-m -l' bar.go
# command-line-arguments
./bar.go:6:20: "hello " + *name escapes to heap
./bar.go:5:14: greeter name does not escape
./bar.go:12:13: name escapes to heap
./bar.go:11:10: main &name does not escape
./bar.go:12:13: main ... argument does not escape
hello douyacun
```

**在闭包中使用了对象并且需要修改对象**

```go
func main() {
	name := "douyacun"
	greeter := func() {
		name = "hello " + name
	}
	greeter()
	fmt.Println(name)
}
```

```shell
➜ bar git:(master) ✗ go run -gcflags '-m -l' bar.go
# command-line-arguments
./bar.go:11:13: name escapes to heap
./bar.go:8:19: "hello " + name escapes to heap
./bar.go:7:13: main func literal does not escape
./bar.go:11:13: main ... argument does not escape
hello douyacun
```

**使用new**

```go
func main() {
	name := new([]string)
	fmt.Println(name)
}
```

```shell
➜ bar git:(master) ✗ go run -gcflags '-m -l' bar.go
# command-line-arguments
./bar.go:7:13: name escapes to heap
./bar.go:6:13: new([]string) escapes to heap
./bar.go:7:13: main ... argument does not escape
&[]
```

## 小对象分配过程

这里翻译了一下源代码的注释，描述的很清楚`runtime/mheap.go`

**mcache分配**

1. 将尺寸四舍五入到small size classes的一种
2. 在 **P** 的 mcache中查看相应的mspan
3. 扫描mspan的bitmap查找空闲坑位
4. 如果有空闲坑位，分配这个坑位，这个过程不需要获取锁

> P是协程中的用于运行go代码的虚拟资源,同一时间只能有一个线程访问同一个P,所以p的资源不需要锁

**mcentral分配**

1. mcache没有空闲坑位
2. 从有坑位的mcentral列表中获取一个新的mspan
3. 获得这个mspan需要锁定mcentral，mcentral是在线程的共享空间中，会有竞争

**mheap分配**

1. mcentral没有坑位
2. 从mheap申请一批page，切分为mspan
3. 这个过程需要加锁
4. 如果mheap没有坑位，从操作系统申请

小对象分3个阶段获取可用的span，然后从span中分配对象

![](/images/blog/golang/assert/go-内存分配-三阶段分配.png)



## 大对象分配

分配大内存直接通过mhe

ap获取，绕过mcache/mcentral, 大对象分配时会四舍五入(8kb)，在包含k个页面的空闲列表中寻找第K个条目，如果他是空的，向上查找，直到找到，如果失败，从操作系统查看早

go内存分配原理

[TOC]

版本:

- go 1.13.4
- tcmalloc gperftools 2.7

我是学习go源码时看到go内存分配使用tcmalloc,早在看redis源码时就了解到tcmalloc了，redis支持zmalloc、tcmalloc、jemalloc几种内存分配，之前只是看了redis自带的zmalloc,没深入了解一下tcmalloc。看来存在必有其道理，不定啥时候就用到

- https://github.com/gperftools/gperftools
- [TCMalloc : Thread-Caching Malloc](http://goog-perftools.sourceforge.net/doc/tcmalloc.html)

学习内存分配，就要先了解一下物理内存的相关概念和描述：

- [linux物理内存描述](http://www.ilinuxkernel.com/files/Linux_Physical_Memory_Description.pdf)
- [Linux物理内存页面分配](http://www.ilinuxkernel.com/files/Linux_Physical_Memory_Page_Allocation.pdf)
- [linux内存地址映射](http://www.ilinuxkernel.com/files/Linux_Memory_Address_Mapping.pdf)

看完这些以后总结了几个问题：

- 什么是逻辑地址、线性地址、物理地址，linux是如何进行地址映射的？

- linux是管理内存的(NUMA), 节点(node)、区域(zone)、page(页面)？

- 为什么一个16G的内存，内核需要160M维护page_table？

- 什么是缺页异常？（给顶的逻辑地址不合法，逻辑页面没有对应的物理页面，MMU将会产生中断，向核心发出信号）


# 基础知识

## 堆栈

![](/images/blog/1/golang/assert/堆栈.png)

进程如何分配内存：

1. static alloction: 声明全局变量时属于静态分配，该空间只会分配一次，并且永远不会释放。
2. automatic allocation: 声明函数参数/局部变量 的复合语句会自动栈空间，复合语句推出时会自动释放变量
3. dynamic allocation: malloc/free

# TCMalloc

1. **TCMalloc要比操作系统提供glibc 2.3 malloc（ptmalloc2）内存分配快**。内存的分配速度和合适的大小对于开发者来说非常重要，如果满足不了开发者的需求可能更倾向于自己实现内存分配规则
2. **TCMalloc减少了多线程之间的锁竞争**。对于小对象分配，几乎是0竞争，对于大对象，TCMalloc使用避免上下文切换的自旋锁，ptmalloc2使用per thread arenas(每个线程都会有自己的锁，避免线程之间的竞争)，问题是内存无法从arenas移动到另外一个arenas。例如：线程一申请一块300M内存，任务完成后。线程二在相同的地址空间启动，如果两个线程绑定了不同arena,线程一申请的300M内存就无法复用，必须重新申请，导致内存爆炸。
3. **TCMalloc另一个优势是对琐碎内存的高效利用**。
> 自旋锁：多线程同步的一种锁，线程反复检查锁变量是否可用。由于线程在这一过程中保持执行，因此是一种忙等待。一旦获取了自旋锁，线程会一直保持该锁，直至显式释放自旋锁。自旋锁避免了进程上下文的调度开销，因此对于线程只会阻塞很短时间的场合是有效的 - [摘自维基百科](https://zh.wikipedia.org/wiki/自旋锁)

## 概述

基本思想: 小内存通过线程层次缓存分配(无锁，速度快)，分配失败后请求上层补一批，前面分配了过多的内存则回收

线程:

ThreadCache: 每个线程私有一份，尺寸小于256K的小内存申请均由ThreadCache进行分配，线程之间不需要竞争，非常高效。节省了加锁释放锁的时间。

全局: 

PageHeap: 中央堆处理器，被所有线程共享（分配需要锁定），负责和操作系统申请、释放内存，大尺寸内存申请直接通过PageHeap分配，

CentralCache: 作为PageHeap和ThreadCache的中间人，负责将PageHeap的内存切分为小块，恰当时机分配给ThreadCache，回收ThreadCache的内存并部分返还给PageHeap

span: 一块连续的内存页。
object: object是由span切分成的小块，object预设了一些规则，如8byte、16byte、32bbyte..., 同一个span切出来的object都是相同的规格，object不大于256k，超大内存直接分配span使用\

ThreadCache、CentralCache管理object, PageHeap管理的是span

## PageHeap 大内存分配

大对象（>32k）对齐内存页面4k(4的倍数)， 由central page heap处理，central page heap也是一个数组

k个pages分配过程：

1. 查看k个页面的空闲列表（free_list）。
2. 如果free_list为空，看下一个空闲列表是否有，如此循环
3. 最终，查询到最后一个空闲列表
4. 如果匹配失败，会从操作系统申请
5. 如果有大于k个page的空闲列表，会分配k给当前申请，剩下的pages会重新插入到相应的空闲列表中。

```c++
// 根据起始page的位置和长度确定span的范围
struct Span {
 PageID start; // Starting page number
 Length length; // Number of pages in span
 Span* next; // 注意，这里span结构一个双向链表
 Span* prev; // 
 union {
 void* objects; // Span会在CentralFreeList中拆分成由object组成的free list
 char span_iter_space[sizeof(SpanSet::iterator)];
 };
 unsigned int refcount : 16; // span的object被引用次数，refcount = 0时表示此span没有被使用
 unsigned int sizeclass : 8; // span被切分的object属于哪个级别的sizeClass
 unsigned int location : 2; // Span在的位置IN_USE？normal？returned？
 unsigned int sample : 1; // Sampled jobject?
 bool has_span_iter : 1; 
 // What freelist the span is on: IN_USE if on none, or normal or returned
 enum { IN_USE, ON_NORMAL_FREELIST, ON_RETURNED_FREELIST };
};
```
- IN_USE：正在使用 ON_NORMAL_FREELIST：未被使用 ON_RETURNED_FREELIST：用户已经归还

> refcount、sizeclass、objects数据CentralFreeList管理的内存

PageHeap维护了
- page和span的关系
- 空闲span的伙伴关系

PageHeap结构体

```c++
class PERFTOOLS_DLL_DECL PageHeap {
 PageMap pagemap_;
 struct SpanList {
 Span normal;
 Span returned;
 };
 SpanSet large_normal_;
 SpanSet large_returned_;

 SpanList free_[kMaxPages];
};
```

- PageMap pagemap_ 维护id和Page的映射关系
- 大于kMaxPages页面统一存放在large_normal_中，不在按照页面数目区分

## CentralCache
CentralCache是由size_class个CentralFreeList组成的数组由Static(static_vars.h)类管理
```c++
class CentralFreeList {
 SpinLock lock_;
 // We keep linked lists of empty and non-empty spans.
 size_t size_class_; // size-class span切分尺寸，每个span只能按同一种size-class切分
 Span empty_; // 未分配Span
 Span nonempty_; // 已分配Span
}
```
CentralFreeList作为中间人，从PageHeap中取出部分span并按照预定大小将其拆分为大小固定的object供ThreadCache共享。CentralFreelist是全局的，除了构造函数，其余操作都需加锁。

## ThreadCache 小内存分配

**小对象分配**

1. 将其大小映射到相应的大小object
2. 在本地thread_cached中相应的free_list查找
3. 如果free_list不为空，从列表中删除第一个对象并返回它

**thread_cache free_list为空**

1. 从此大小类的central cache的free_list中获取一堆object
2. 将获取到的object放到thread_cache的free_list中
3. 将新获取的object其中一个返回

**central_cache free_list为空**

1. 从central page allocator中申请一批page
2. 拆分为该大小级别（size_class）的一组object
3. 新对象(object)放置在中央缓存（central cache）的空闲列表（free_list）中

每个thread独立维护了各自的离散式空闲列表

```c++
// https://github.com/gperftools/gperftools/blob/master/src/thread_cache.h
// https://github.com/gperftools/gperftools/blob/master/src/thread_cache.cc
class ThreadCache {
 class FreeList {
 void* list_; // 链表第一个节点
 uint32_t length_; // 当前长度
 int32_t size_;
 }
 ThreadCache* next_;
 ThreadCache* prev_;
 // kClassSizesMax 96
 FreeList list_[96]; // size_class 数组，可用链表
 int32 size_; // 可用内存大小
 int32 max_size_; // size_ > max_size_ --> Scavenge()
 pthread_t tid_; // 属于哪个线程
}
```
ThreadCache list_变量即为size class的实现，在实现free list时没有使用next来指针指向下一个位置，而是直接使用 void* list_, 将下一个object的地址直接存储在上个前8个字节中，可以模拟单向链表，object分配个应用程序后可以直接覆盖前8个字节，节省了一个指针的空间。

![object](/images/blog/1/golang/assert/tcmalloc-object.png)

## size-class
```c++
 // 1. Sizes <= 1024 have an alignment >= 8. ceil(size/8)
 // 2. Sizes > 1024 have an alignment >= 128. ceil(size/128).

 // Size Expression Index
 // -------------------------------------------------------
 // 0 (0 + 7) / 8 0
 // 1 (1 + 7) / 8 1
 // ...
 // 1024 (1024 + 7) / 8 128
 // 1025 (1025 + 127 + (120<<7)) / 128 129
 // ...
 // 32768 (32768 + 127 + (120<<7)) / 128 376
```



# go 内存分配

go在程序启动时会分配一块虚拟内存地址是连续的内存, 结构如下

![](/images/blog/1/golang/assert/go-内存布局.png)

## 布局

### spans

是page和其管理对象的反查表，在回收时，从哪来回哪去。利用该表可访问地址相邻大块内存使用状态，以便将多个相邻内存合并成更大的内存，减少碎片，更好适应分配需求。

### bitemap

和gc有关，先不做过多深入，研究gc时候会深入理解

栈(stack)、全局变量和静态变量（.data/.bss）占用1bit，0: gc不需要关心是否回收，1: 需要分析是否需要回收

堆(heap) 需要占用2bit

### arena

用户对象分配区域，就是通常说的堆(heap)，go从heap中申请的内存就是在这个区域。

### 逃逸分析

什么时候从heap分配对象，go会自动确定哪些对象应该放在栈上，哪些应该放在堆上。简单的说：当一个对象的内容可能在生成该对象的函数结束后被访问，那么这个对象就会被分配在堆上。

**返回对象指针**

```go
func foo() *string {
	str := "Hello world"
	return &str
}
func main() {
	fmt.Println(foo())
}
```

```shell
$ git:(master) ✗ go run -gcflags '-m -l' bar.go
# command-line-arguments
./bar.go:7:9: &str escapes to heap
./bar.go:6:2: moved to heap: str
./bar.go:11:17: foo() escapes to heap
./bar.go:11:13: main ... argument does not escape
0xc0000101e0
```

**传递了对象的指针到其他函数**

```go
func greeter(name *string) {
	 *name = "hello " + *name
}
func main() {
	name := "douyacun"
	greeter(&name)
	fmt.Println(name)
}
```

```shell
➜ bar git:(master) ✗ go run -gcflags '-m -l' bar.go
# command-line-arguments
./bar.go:6:20: "hello " + *name escapes to heap
./bar.go:5:14: greeter name does not escape
./bar.go:12:13: name escapes to heap
./bar.go:11:10: main &name does not escape
./bar.go:12:13: main ... argument does not escape
hello douyacun
```

**在闭包中使用了对象并且需要修改对象**

```go
func main() {
	name := "douyacun"
	greeter := func() {
		name = "hello " + name
	}
	greeter()
	fmt.Println(name)
}
```

```shell
➜ bar git:(master) ✗ go run -gcflags '-m -l' bar.go
# command-line-arguments
./bar.go:11:13: name escapes to heap
./bar.go:8:19: "hello " + name escapes to heap
./bar.go:7:13: main func literal does not escape
./bar.go:11:13: main ... argument does not escape
hello douyacun
```

**使用new**

```go
func main() {
	name := new([]string)
	fmt.Println(name)
}
```

```shell
➜ bar git:(master) ✗ go run -gcflags '-m -l' bar.go
# command-line-arguments
./bar.go:7:13: name escapes to heap
./bar.go:6:13: new([]string) escapes to heap
./bar.go:7:13: main ... argument does not escape
&[]
```

## 小对象分配过程

这里翻译了一下源代码的注释，描述的很清楚`runtime/mheap.go`

**mcache分配**

1. 将尺寸四舍五入到small size classes的一种
2. 在 **P** 的 mcache中查看相应的mspan
3. 扫描mspan的bitmap查找空闲坑位
4. 如果有空闲坑位，分配这个坑位，这个过程不需要获取锁

> P是协程中的用于运行go代码的虚拟资源,同一时间只能有一个线程访问同一个P,所以p的资源不需要锁

**mcentral分配**

1. mcache没有空闲坑位
2. 从有坑位的mcentral列表中获取一个新的mspan
3. 获得这个mspan需要锁定mcentral，mcentral是在线程的共享空间中，会有竞争

**mheap分配**

1. mcentral没有坑位
2. 从mheap申请一批page，切分为mspan
3. 这个过程需要加锁
4. 如果mheap没有坑位，从操作系统申请

小对象分3个阶段获取可用的span，然后从span中分配对象

![](/images/blog/1/golang/assert/go-内存分配-三阶段分配.png)



## 大对象分配

分配大内存直接通过mhe

ap获取，绕过mcache/mcentral, 大对象分配时会四舍五入(8kb)，在包含k个页面的空闲列表中寻找第K个条目，如果他是空的，向上查找，直到找到，如果失败，从操作系统查看早

# go 拼接数组为字符串的几种方式
1. `+` 拼接 最慢 少量比较推荐
2. `strings.join` 拼接 其次-推荐
3. `buffers.NewBufferString` 拼接 最快，需要自己实现

```go
package main

import (
	"bytes"
	"fmt"
	"strconv"
	"strings"
	"sync"
	"time"
	"unsafe"
)

func main() {
	a := make([]string, 100000)
	for i := 1; i <= 100000; i++ {
		a = append(a, strconv.Itoa(i))
	}
	fmt.Println(unsafe.Sizeof(a))
	wg := sync.WaitGroup{}
	wg.Add(3)
	go plus(&wg, a)
	go join(&wg, a)
	go buffer(&wg, a)
	wg.Wait()
}

func plus(wg *sync.WaitGroup, a []string) {
	defer wg.Done()
	start := time.Now()
	var str string
	for _, i := range a {
		str = str + i
	}
	latency := time.Now().Sub(start)
	fmt.Printf("plus latency: %s len: %d\n", latency, len(str))
}

func join(wg *sync.WaitGroup, a []string) {
	defer wg.Done()
	start := time.Now()
	str := strings.Join(a, "")
	latency := time.Now().Sub(start)
	fmt.Printf("join latency: %s len: %d\n", latency, len(str))
}

func buffer(wg *sync.WaitGroup, a []string) {
	defer wg.Done()
	start := time.Now()
	var str = bytes.NewBufferString("")
	for _, i := range a {
		str.WriteString(i)
	}
	latency := time.Now().Sub(start)
	fmt.Printf("buffer latency: %s len: %d\n", latency, len(str.String()))
}
```

结果：
```shell
24
join latency: 2.536645ms len: 488895
buffer latency: 2.392455ms len: 488895
plus latency: 3.759257148s len: 488895

Process finished with exit code 0
```

- 推荐思考一下 	fmt.Println(unsafe.Sizeof(a)) 结果为啥是24，了解一下背后的数据结构

整理一下如何拼接字符串及几种方式的使用场景

go拼接字符串的方式以及性能比较

疑问：

1. 系统线程和goroutine有哪些区别？
2. 什么原子操作，系统线程和goroutine是如何进行原子操作？

# 目录

[TOC]

# thread

先说一下线程出现的背景，也就是有了进程为什么还需要多线程的原因，首先在许多应用同时发生着多种活动（并行），某种活动会随着时间推移会被阻塞，将这些应用程序分解成可以准并行运行的多个顺序线程，程序设计模型会变得更简单。其次由于线程比进程更轻量级，它们比进程更容易创建和销毁。第三个就是性能的比较，如果是CPU密集型，多线程并不能获得性能上的提升，但如果是I/O密集型或者计算密集型的，多个线程会允许彼此重叠运行，加快应用程序执行的速度

POSIX（pthread）线程库，C/C++标准线程API,线程比fork新的进程开销更少，是因为系统不会为进程初始化新的虚拟内存空间和环境，进程中所有线程共享相同的地址空间，通过定义一个函数及其将在线程中处理的参数来生成一个线程。在软件中使用POSIX线程库的目的是更快地执行软件。

基础知识:

- 线程操作包括线程创建，终止，同步（连接、阻塞），调度，数据管理和进程交互
- 线程不维护以创建线程的列表，也不知道它创建的线程
- 进程中所有的线程共享相同的地址空间
- 同一进程中的线程共享:
 - 流程
 - 大多数数据
 - 打开的文件描述符
 - 信号和信号处理程序
 - 当前的工作目录
 - 用户和组id
- 每个线程独享：
 - 线程id
 - 寄存器集，堆栈指针
 - 堆栈用于局部变量，返回地址
 - 信号掩码
 - 优先级
 - 返回值：errno（错误码）
- Pthread 函数返回0表示成功

## C - Basic Thread Routines

```c
#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>
void *print_message_func(void *ptr);
int main()
{
 pthread_t thread1, thread2;//线程id
 int iret1, iret2;
 char *message1 = "Thread 1";
 char *message2 = "Thread 2";

 iret1 = pthread_create(&thread1, NULL, print_message_func, (void *) message1);
 iret2 = pthread_create(&thread2, NULL, print_message_func, (void *) message2);

 pthread_join(thread1, NULL);
 pthread_join(thread2, NULL);
 printf("Thread 1 return %d\n", iret1);
 printf("Thread 2 return %d\n", iret2);
		exit(0);
}
void *print_message_func(void *ptr)
{
 char *message;
 message = (char *)ptr;
 printf("%s\n", message);
}
// 输出
// Thread 2
// Thread 1
// Thread 1 return 0
// Thread 2 return 0

// gdb 调试打印一下thread1、thread2
// (gdb) p thread2
// $5 = 140737337296640
// (gdb) p thread1
// $6 = 140737345689344
// (gdb)
```

### creation

```c
int pthread_create(pthread_t * thread, 
 const pthread_attr_t * attr,
 void * (*start_routine)(void *), 
 void *arg);
```

- pthread_t：在 `/usr/include/bits/pthreadtypes.h` 中定义`typedef unsigned long int pthread_t;`
- pthread_attr_t：

| **属性** | **值** | **结果** |
| -------------- | :----------------------------------------------------------- | :----------------------------------------------------------- |
| __scope | `PTHREAD_SCOPE_SYSTEM`: 与系统中所有线程一起竞争CPU时间 `PTHREAD_SCOPE_PROCESS:` 仅与同进程中的线程竞争CPU | 竞争CPU的范围,缺省值`PTHREAD_SCOPE_SYSTEM` |
| __detachstate | `PTHREAD_CREATE_DETACHED`: 新线程与其他线程脱离同步，不能使用pthread_join来同步 `PTHREAD_CREATE_JOINABLE`: 新线程与其他线程同步，新线程创建后可以使用pthread_detached来脱离同步 | 新线程是否与进程中其他线程脱离同步，缺省值为`PTHREAD_CREATE_JOINABLE` |
| __stackaddr | `NULL` | 新线程具有系统分配的栈地址。 |
| __stacksize | | 新线程具有系统定义的栈大小。默认2M |
| __schedpolicy | `SCHED_OTHER`：正常、非实时 `SCHED_RR`: 实时、轮转法 `SCHED_FIFO`： 实时、先入先出 | 线程的调度策略，缺省值为`SCHED_OTHER` |
| __inheritsched | `PTHREAD_EXPLICIT_SCHED`: 显示式指定调度策略和调度参数 `PTHREAD_INHERIT_SCHED`: 继承调用者线程的值 | 新线程是否继承父线程调度优先级。 |

- `void * (*start_routine)` 指向线程运行的函数，函数有一个参数执行`void *`
- `void *arg`执行函数参数的指针，如果传递多个参数，发送指向结构体的指针

### Termination

```c
void pthread_exit（void *retval）;
```

- retval 函数的返回值

一般情况下，进程中各个线程的运行都是相互独立的，线程的终止并不会通知，也不会影响其他线程，终止线程所占用的资源也并不会随着线程的终止而释放，正如进程之间可以用wait()系统调用来同步终止并释放资源一样，线程就是pthread_join等待并释放

注意pthread_exit只会让主线程自己退出不会让产生的子线程退出；用return则所有的线程退出

使线程退出的方法有：

- 调用`pthread_exit`
- 使调用函数return
- 调用exit会使进程退出，包括已经创建的线程
- 主线程退出

如何让子线程完整执行？

1. 使用pthread_join等待其执行完成
2. 执行时，主线程执行pthread_exit，这样子线程能继续执行
3. 使用pthread_detach使新线程与其他线程脱离同步，要保证主线成不能退出

### detach and join

```c
int pthread_detach(pthread_t thread);
```

- `pthread_t thread` 线程id

线程创建默认是joinable，但如果一个线程结束但没有被join，则他的状态类似于僵尸进程(Zombie Process),还有一部分资源没有被回收，所以创建线程者应该调用pthread_join来等待线程退出，并可得到线程的退出代码，回收其资源，但是调用pthread_join后，线程没有结束，调用者会被阻塞，有些情况我们并不希望如此，比如在web服务器创建一个字线程来处理每一个请求，主线程并不希望因为调用pthread_join而阻塞，这时可以在子线程代码中加入pthread_detach(pthread_self())或是在父线程调用pthread_detach(pthread_t thread_id)非阻塞立即返回，这将使子线程的状态设置为detached,该线程结束后会自动释放所有资源

```c
int pthread_join(pthread_t thread, void **retval);
```

- `pthread_t thread`线程id
- `retval`返回值

调用pthread_join的线程会阻塞，直到指定的线程返回或调用了pthread_exit,如果线程简单的返回，retval会被设置成函数的返回值；如果调用了pthread_exit，那个可以传参给pthread_exit("hello world")当作线程的返回值；如果线程被取消，retval被设置成`PTHREAD_CANCELED`，注意一个线程只允许唯一的一个线程使用pthread_join()等待它的终止，并且被等待线程必须是joinable状态，非Detached状态

## Syncronizing Threads - 线程同步

问题：

```
int bar = 0;
void foo()
{
 if (bar == 0)
			bar = 1;	/* This must only be done once. */
}
这里有一个问题：
 	 Thread 1				 Thread 2
 		if (bar == 0)
 									if (bar == 0)
 						 		bar = 1;
 		bar = 1;
线程1、2会同时设置bar
```

线程库提供了三种线程同步机制：

- mutexes - 互斥锁, 阻止其他线程访问变量，
- join - 等待线程完成
- condition variables - pthread_cond_t

### mutexes - 互斥锁

- 互斥锁用于防止因竞争条件引起的数据不一致。
- 两个或多个线程需要同时在同一块存储区域上执行操作时，通常会发生竞争条件，计算结果取决于执行这些操作的顺序。互斥锁用于序列化共享资源。
- 每当多个线程访问全局资源时，应该有一个与之关联的互斥锁。互斥锁只能用在同一进程的线程，不像信号可以用于多个进程之间的通信。

```c
#include <pthread.h>
#include <stdio.h>

void *foo(void *ptr);
pthread_mutex_t mutex1 = PTHREAD_MUTEX_INITIALIZER;
int bar = 0;

int main()
{
 pthread_t t1, t2;
 int rc1, rc2;
 if ((rc1 = pthread_create(&t1, NULL, foo, NULL))) {
 printf("Thread creation failed: %d\n", rc1);
 }
 if ((rc2 = pthread_create(&t2, NULL, foo, NULL))) {
 printf("Thread creation failed: %d\n", rc2);
 }
 pthread_join(t1, NULL);
 pthread_join(t2, NULL);
 printf("Final counter bar is %d\n", bar);
}
void *foo(void *ptr)
{
 printf("Thread number %llu\n", pthread_self());
 pthread_mutex_lock(&mutex1);
 bar++;
 pthread_mutex_unlock(&mutex1);
}
// cc -g -lpthread main.c -o thread
// -g 允许gdb调试
```

### join

通过pthread_join可以等待多个线程执行完成并获取执行结果

```c
#include <pthread.h>
#include <stdio.h>

#define NUM_OF_THREAD 10
void *foo(void *ptr);
pthread_mutex_t mutex1 = PTHREAD_MUTEX_INITIALIZER;
int bar = 0;

int main()
{
 pthread_t ts[NUM_OF_THREAD];
 int i,j;
 for (i = 0; i < NUM_OF_THREAD; i++) {
 pthread_create(&ts[i], NULL, foo, NULL);
 }
 for (j = 0; j < NUM_OF_THREAD; j++) {
 pthread_join(ts[j], NULL);
 }
 printf("Final counter bar is %d\n", bar);
}
void *foo(void *ptr)
{
 printf("Thread number %llu\n", pthread_self());
 pthread_mutex_lock(&mutex1);
 bar++;
 pthread_mutex_unlock(&mutex1);
}
```

### condition variables - 条件变量

互斥锁，平时接触的比较多，那条件变量是干啥的？为什么条件变量总是和互斥锁搭配来使用

条件变量，线程可以原子方式阻塞，直到满足某个条件为止，比如：线程A和B存在依赖关系，B要在某个条件发生之后才能继续运行，而这个条件只有A才能完成，这个时候就可以用条件变量来完成

create/destory:

```c
int	pthread_condattr_init(pthread_condattr_t *cattr);
pthread_cond_t cond = PTHREAD_COND_INITIALIZER
int	pthread_condattr_destroy(pthread_condattr_t *cattr);
```

- 动态：需要用pthread_condattr_destroy来释放条件变量的内存空间
- 静态：可以把常量`PTHREAD_COND_INITIALIZER`给静态分配的条件变量

waiting on condition：

```CQL
int pthread_cond_wait(pthread_cond_t *cond,pthread_mutex_t *mutex);
int pthread_cond_timewait(pthread_cond_t *cond,pthread_mutex *mutex,const timespec *abstime);
```

这两个函数分别是阻塞等待和超时等待

waking thread based on condition:

```c
int pthread_cond_signal(pthread_cond_t *cond);
int pthread_cond_broadcast(pthread_cond_t *cond);
```

这两个函数通知线程条件已经满足

以下代码就是典型的生产者消费者模型

```c
#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>
#include <string.h>
#include <unistd.h>

#define NUM_OF_THREAD 5
#define QUEUE_CAPACITY 5

struct Queue{
	int ppos;
	int cpos;
	char *data;
	int capacity;
	int len;
}q;
pthread_cond_t cd = PTHREAD_COND_INITIALIZER;
pthread_mutex_t mtx = PTHREAD_MUTEX_INITIALIZER;
void *start(void *args);
void producer();
void consumer();

int count = 0;

int main()
{
	pthread_t threads[NUM_OF_THREAD];
	int i, j;
	memset(&q, 0, sizeof(struct Queue));
	q.capacity = QUEUE_CAPACITY;
	q.data = (char *)malloc(sizeof(char) * QUEUE_CAPACITY);
	for(i=0; i<NUM_OF_THREAD;i++) {
		int *n = (int *)malloc(sizeof(int) * 1);
		*n = i;
		pthread_create(&threads[i], NULL, start, n);
	}
	for(j=0;j<NUM_OF_THREAD;j++){
		pthread_join(threads[j], NULL);
	}
	exit(0);
}
void *start(void *args)
{
	int n = *(int *)args;
	if (n==0) {
		producer();// 1个生产者
	} else {
		consumer();// 4个消费者
	}
}
void producer()
{
	char c;
	while(1)
	{
		if ((c = getchar()) == '\n'){
			continue;
		}
		pthread_mutex_lock(&mtx);
		if (q.len >= QUEUE_CAPACITY) {
			printf("Queue is full\n");
		} else {
			q.len++;
			q.ppos = (q.ppos + 1) % q.capacity;
			q.data[q.ppos] = c;
			printf("get a task\n");
		}
		pthread_cond_broadcast(&cd); // 通知消费线程 来活了
		pthread_mutex_unlock(&mtx);
	}
	return;
}

void consumer()
{
	int len, cpos;
	char c;
	while(1)
	{
		pthread_mutex_lock(&mtx);
		while(q.len <= 0) {
			printf("waitting ...\n");
			pthread_cond_wait(&cd, &mtx);
		}
		q.len--;
		len = q.len;
		q.cpos =(q.cpos + 1) % q.capacity;
		cpos = q.cpos;
		c = q.data[q.cpos];
		pthread_mutex_unlock(&mtx); // 这里生产任务已经接到没必要在占用锁了，否则就没有并发了
		sleep(3);
		printf("completed this task from queue: 【%c】, len 【%d】, cpos 【%d】\n", c, len, cpos);
	}
	return;
}
```

## Thread Pitfalls - 线程陷阱

- 竞争条件： 线程由操作系统调度并执行。不能假定线程按创建顺序执行，他们可以以不同的速度执行。当线程正在执行时（竞赛完成），它们可能会产生意外结果（竞争条件）。必须利用mutexes和join来实现可预测的执行顺序和执行结果
- 线程安全（并发安全）：线程必须调用“线程安全”的函数，这意味着没有静态或全局变量，其他线程可能会假设单线程操作而破坏或读取。如果使用静态或全局变量，则必须使用全局变量或重写程序避免使用这些变量。在c语言中，局部变量在堆栈上分配的，因此任何不使用静态数据或其他共享资源的线程都是线程安全的。线程不安全函数程序中一次只能由一个线程使用，必须确保线程的唯一性；
- 互斥锁死锁：当应用锁互斥锁未解锁时会发生此情况，这导致程序执行无限停止。将两个或多个互斥锁用于代码片段时要小心，当线程第一个pthread_mutex_lock已经锁住，而第二个pthread_mutex_lock被其他线程锁住时，那么第一个互斥锁最终可能会锁定其他所有线程访问数据，包括第二个互斥锁的线程。线程无限期地等待资源变得空闲，从而变成死锁。

```c
void * function1（）
{
	...
	pthread_mutex_lock（＆lock1）; - 执行步骤1
	pthread_mutex_lock（＆lock2）; - 执行步骤3 DEADLOCK !!!
	...
	...
	pthread_mutex_lock（＆lock2）;
	pthread_mutex_lock（＆lock1）;
	...
}
void * function2（）
{
	...
	pthread_mutex_lock（＆lock2）; - 执行步骤2
	pthread_mutex_lock（＆lock1）;
	...
	...
	pthread_mutex_lock（＆lock1）;
	pthread_mutex_lock（＆lock2）;
	...
}
int main（）
{
	...
	pthread_create（＆thread1，NULL，function1，NULL）;
	pthread_create（＆thread2，NULL，function1，NULL）;
	...
}
```



# goroutine

```go
import (
	"fmt"
	"sync"
)
func main() {
	wg := sync.WaitGroup{} // 这里waitgroup类似于pthread_join,等待线程运行完成
	wg.Add(2)
	go worker(&wg)
	go worker(&wg)
	wg.Wait()
}
func worker(wg *sync.WaitGroup) {
	defer wg.Done()
	fmt.Println("Hello world")
}
```

Grouting是go语言特有的并发体，是一种轻量级的线程，由go关键字启动，goroutine和系统线程也不是等价的，两者的区	别实际上只是一个量的区别，正是这个量变引发了质变

- 创建线程容易，退出难，创建一个线程虽然参数不少，但是可以接受，但是一旦涉及到退出就要考虑thread是detached还是joinable
- 线程并发单元间通信困难，易错，多个线程之间虽然有多种机制可选，用起来相当复杂，一个设计到共享内存，就绪各种锁，切容易造成死锁
- `__stacksize`的设定，大小难以确定，系统线程默认是2M
- 一个线程代价相对于进程来说已经很小了，但我们依然不能不能大量创建线程，因为除了每个线程占用的资源除外，操作系统切换线程的代价也不小
- 对于网络程序来说，由于不能创建大量的线程，就要在少量的线程中做网络多路复用，使用epoll这套机制，即便有[libevent](https://github.com/libevent/libevent)/[libev](http://software.schmorp.de/pkg/libev.html)，但是使用起来也相对比较复杂

go采用了用户层轻量级thread，goroutine的stack size非常小（默认2k），goroutine调度的切换不会陷入(trap)操作系统内核层完成，代价很低

一个go程序对于一个操作系统来说知识一个用户层程序，对于操作系统而言只有线程没有goroutine，goroutine的调度全靠go自己完成，一个go程序中，除了用户代码，剩下的就是go runtime了；

线程竞争的是真实物理CPU，go程序是用户层程序，本身整体运行在一个或多个操作系统线程，因此goroutine竞争的 *CPU资源* 实际指的是系统线程

## Atomicity - 原子操作

原子操作，并发编程中“最小的且不可并行化”的操作。从线程角度说，在当前线程修改共享资源期间，其他的线程时不能访问改资源的。go语言是使用sync.Mutex来实现，类似于线程的pthread_mutex_t

```go
var total struct {
 sync.Mutex
 value int
}
func worker(wg *sync.WaitGroup) {
 defer wg.Done()
 for i := 0; i <= 100; i++ {
 total.Lock()
 total.value += i
 total.Unlock()
 }
}
func main() {
 var wg sync.WaitGroup
 wg.Add(2)
 go worker(&wg)
 go worker(&wg)
 wg.Wait()
 fmt.Println(total.value)
}
```

使用互斥锁保护一个数值型的共享资源，效率比较低，有点大才小用的感觉，标准库sync/atomic提供了丰富的支持

```go
var total uint64
func worker(wg *sync.WaitGroup) {
 defer wg.Done()
 var i uint64
 for i = 0; i <= 100; i++ {
 atomic.AddUint64(&total, i)
 }
}
func main() {
 var wg sync.WaitGroup
 wg.Add(2)
 go worker(&wg)
 go worker(&wg)
 wg.Wait()
}
```

## channel

无缓存的发送操作总在对应的接收操作完成之前发生

```go
var message string

var done = make(chan struct{})
func main() {
	go worker()
	<-done// 优先执行接收操作，但会被阻塞直到channel被写入，message被正常赋值
	fmt.Println(message)
}
func worker() {
	message = "hello world"
 done <- struct{}{}
}
```

对于无缓存channel进程的接收，发生在对该channel进行的发送完成之前

```go
var message string

var done = make(chan struct{})
func main() {
	go worker() 
	done <- struct{}{}// 
	fmt.Println(message)
}
func worker() {
	message = "hello world"
	<-done
}
```

对于channle的第K个接收操作发生在第K+C个操作完成之前，其中c是channle的capacity

操作系统只认线程调用，goroutine和线程有哪些区别

goroutine和线程的区别

mysql中常见的日志文件：
- 错误日志(error log)
- 二进制日志(binlog)
- 慢查询日志(slow log)
- 查询日志(log)

# 错误日志
查看错误日志的位置
```shell
mysql> show variables like 'log_error'\G;
```

# 慢查询日志

开启慢查询日志`log_slow_queries`
```shell
mysql> show variables like 'log_slowqueries'\G;
```
慢查询时间`long_query_time`
```shell
mysql> show variables like 'long_query_time'\G
```

sql没有用到索引也会记录到慢查询日志
```shell
mysql> show variables like 'long_throttle_queries_not_using_indexes'\G;
```

mysqldumpslow查看执行时间最长的10条sql
```shell
$ mysqldumpslow -s -al -n 10 mysqlslow.log
```

mysql支持将慢查询日志写入到slow_log表，**log_output**指定慢查询输出格式，默认为file，设置为table会写入到slow_log表

```shell
mysql> show create table mysql.slow_log;
```

# rds执行日志记录sls
阿里云关系数据库RDS（MySQL版本）的SQL执行日志已经与日志服务打通，提供准实时的SQL执行分析功能，并提供内置可深钻的报表、支持自定义审计规则、异常报警、报表订阅与生态对接能力等。
- 据库的登录、退出。
- DDL（Data Definition Language）：对数据库结构定义的SQL，例如CREATE、ALTER DROP、TRUNCATE、COMMENT等。
- DML（Data Manipulation Language）：SQL操作语句，包括SELECT、INSERT、UPDATE、DELETE等。
- 其他SQL执行，包括任何其他通过SQL执行的控制，例如回滚、控制等。
- 失败的SQL执行也会被记录。
- 对SQL执行的延迟、执行结果、影响的行数等信息的提取。

https://help.aliyun.com/document_detail/118266.html

# 二进制日志
- max_binlog_size: 二进制文件最大值，超过该值产生新的文件，后缀加1
- binlog_cache_size: innodb所有未提交的事物都会被记录缓存中去，事物提交时，在写二进制日志中。当一个session开启一个事物时，会自动初始化一个大小为binlog_cache_size大小的缓存，当事物的记录大于binlog_cache_size的时候，会把缓冲的日志写入一个临时文件
    - binlog_cache_use 缓冲写二进制日志次数 
    - binlog_cache_disk_use 临时文件写二进制日志次数

查看binlog文件的内容：
```shell
mysql> mysqlbinlog --start-position=203 douyacun.00007
```

# 套接字文件
本地mysql可以使用套接字文件来连接
```shell
mysql> show variables like 'socket';
```

# pid文件
进程pid，可以用pid文件来重启进程
```shell
mysql> show variables like "";
```



错误日志,慢查询日志,查询日志,二进制日志

mysql日志文件

innodb关键特性包括：
- 插入缓冲 (insert buffer)
- 两次写(double write)
- 自适应hash索引(adaptive hash index)
- 异步I/O (async i/o)
- 刷新临界页 (flush neighbor page)

# 插入缓冲
## insert buffer

每张表都有一个主键索引(没有明确指明，会默认生成一个不可见的主键索引)，主键索引(聚集索引)的插入顺序是非常快的，但是不可能每张表只有一个聚集索引，更多情况下一张表会有很多辅助索引，对于主键索引的插入式顺序存放的，但是对于辅助索引的叶子节点的插入就不是顺序的了。

innodb 对于非聚集索引的插入和更新操作，不是每一次直接插入到索引页，而是先判断索引页是否在缓冲池中,若有直接插入，否则，先放入到insert buffer中。再以一定频率合并insert buffer和索引子节点。通常能将多个插入操作合并到一个操作中，因为在一个索引页中。使用insert buffer需要同时满足两个条件：
- 索引是辅助索引
- 索引不是唯一索引

`show engine innodb status\G;`可以查看insert buffer的使用情况

- seg_size 代表insert buffer大小为 n*16k
- free list len代表空闲列表的长度
- inserts代表插入记录数
- merged recs代表了合并后的插入记录数
- merges 代表合并的次数，实际读取页的次数

> 缓冲池: 是为了通过内存速度来弥补磁盘速度较慢对于性能的影响，包括insert buffer、data pag、index page、lock info、adaptive hash index

**IBUF_POOL_SIZE_PER_MAX_SIZE**可以调整insert_buffer_pool可以占用缓冲池的大小

## change buffer
change buffer可以对DML操作(insert,delete,update)进行缓冲操作,适用对象仍然是非唯一的辅助索引， 对一条记录update的步骤：
- 将记录标记为已删除
- 真正将记录删除

**innodb_change_buffer_max_size**控制change buffer最大使用内存的数量，25表示最多使用1/4缓冲池空间

# double write
插入缓冲给innodb存储引擎带来的是性能上的提升，double write提高了innodb存储引擎的数据页的可靠性

那么double write做了什么？\
数据库宕机时，可能对数据页只写入部分，这种情况称为部分写失效。可以通过redo log来恢复，在写入失效时，先通过页的副本还原该页，在进行重做，这就是double write

double write有一段2m的内存空间，在磁盘上还有2m*的共享表空间，数据先从内存空间写入到共享空间，立即调用fsync同步，此时是顺序写入速度快，在完成写入后，再将共享空间的数据写入到各个表空间文件中。此时写入是离散的。double write写入时会合并写入操作，消耗要小于两次io的消耗

```shell
mysql> show global status like 'innodb_dblwr%\G'
```

- innodb_dblwr_pages_writen: inndob一共写了多少页
- innodb_dblwr_writes: 实际写入次数

`skip_innodb_doublewrite`可以禁止使用doublewrite功能

# 自适应hash索引
hash索引的查找复杂度O(1),B+树的查找取决于B+树的高度，生产环境一般是3～4,需要3～4次

innodb会监控对表上各索引的查询，如果二级索引被频繁访问，成为热点数据，建立hash索引可以带来，速度的提升

hash索引有一个要求，查询模式必须是一样的，必须是等值查询

**`innodb_adaptive_hash_index`**: 是否开启自适应hash索引

# 异步I/O - AIO
AIO优势:
1. 多个I/O异步执行
2. 合并多个I/O为同步操作

mysql read、脏页刷新，磁盘写入都是通过AIO来实现的

# 刷新邻接页
原理是：innodb刷新脏页时，会检测该页所在区的所有页，如果有脏页AIO就会将多个I/O操作合并为一个操作。
**innodb_flush_neighbors** 可以控制是否启用，传统机械键盘建议启用，固态硬盘建议关闭

innodb说这些特性，相信比说支持事务要更有说服力

innodb关键特性

# fsync, fdatasync 同步内核的页缓存到磁盘
```c
#include <unistd.h>

int fsync(int fd);
int fdatasync(int fd);
```

- fsync： 文件描述符(fd)在内核中所有的[脏页](/linux/页缓存.md#dirty_page)同步到的磁盘，调用会被阻塞直到磁盘写入完成，能确保被修改过的块立即写入到磁盘
- fdatasync：类似于fysnc，文件属性(st_atime,st_mtime等)不会同步到磁盘，目的是为了减少磁盘交互

# 与fdatasync相比fsync的性能问题#性能
fysnc 除了同步文件的修改内容(脏页)，还会同步文件的描述信息(metadata、包括size、访问时间st_atime、st_mtime等)，因为文件数据和metadata通常存在磁盘不同的地方，所以fsync至少需要两次I/O操作

多余的一次IO操作，有多么昂贵呢？根据Wikipedia的数据，当前硬盘驱动的平均寻道时间（Average seek time）大约是3~15ms，7200RPM硬盘的平均旋转延迟（Average rotational latency）大约为4ms，因此一次IO操作的耗时大约为10ms左右。

文件的尺寸(st_size)如果发生变化，是需要立即同步的否则OS一旦崩溃，即使文件的数据部分已同步，由于metadata没有同步，依然读不到修改的内容，最后的饿访问时间和修改时间是不需要每次同步的

读redis源码-AOF和磁盘I/O造成的延迟