源码 on

Golang之系统排查

Thu, 12 Oct 2023 00:00:00 +0000

系统排查
#

1. 先确定出现问题的进程
#

先排查是否因为程序服务导致的CPU/内存保障，可以使用top命令来排查。

top

确定是服务出问题后，可以使用如下命令持续监测服务进程，$pid即为服务进程的pid。

top -Hp $pid

可以使用top默认根据CPU使用率来排序，可以使用shitft + m 改成使用内存占用率来排序。

2. 使用PProf排查程序内部的问题
#

确定了服务进程的问题后，就可以通过PProf来排查CPU、内存、互斥锁、Goroutines的问题了。下面展示一个demo来简单使用PProf。

import (
	"log"
	"net/http"
	"time"
	_ "net/http/pprof" 
)


func main() {
	go func() {
		for {
			log.Println("do something...")
			time.Sleep(time.Second )
		}
	}()

	_ = http.ListenAndServe("0.0.0.0:6060", nil) //pprof包的init函数里注册了handler 
}

使用web界面查看pprof信息
#

经过上述步骤后，在浏览器打开http://127.0.0.1:6060/debug/pprof/，就能看到pprof界面了。

Golang之内存管理

Mon, 10 Apr 2023 00:00:00 +0000

Golang之内存管理
#

概述
#

Go的内存分配借鉴了Google的TMalloc，其核心思想是内存池+多级对象管理，能加快分配速度，降低资源竞争。

内存分配的方法
#

线性分配法：只需要在内存中维护一个指针，这个指针指向下一片未使用内存的起始位置，如果程序需要新分配一片内存，只要找到这个指针直接分配内存即可。
这种方法实现虽然简单，但有一个致命的缺点，就是无法利用曾经使用过但后面被释放的内存。
空闲链表分配法：会在内部维护一个类似链表的数据结构，当程序需要申请内存时，空闲链表分配器会一次遍历空闲的内存块，找到足够大的内存，然后申请新的资源并修改链表。

Go使用的是空闲链表分配法，再配合隔离适应策略，将内存分割成多个链表，每个链表中内存块大小相等，申请内存时先找到合适的链表，再在链表中找到合适的内存块。

基础结构
#

内存单元相关：mspan、arena
内存池相关：mcache、mcentral、mheap

内存单元
#

首先，在Go程序初始化时，会先将申请到的虚拟内存分为如下几个部分。

Golang之内存逃逸

Mon, 10 Apr 2023 00:00:00 +0000

Golang之内存逃逸
#

内存分配
#

在Golang中，程序申请的一个对象，是在栈上分配，还是在堆上分配，这个是由编译器决定的。

在栈上分配：在程序中，每个函数块都会有自己的内存区域来存储局部变量、返回值等数据，这一块内存区域有特定的数据结构与存储方式，其大小在程序编译的时候就已经分配好了，且这块区域寻址快，开销少，这块内存区域就称为栈区。因为栈的大小在编译的时候就已经确定了，所以当栈存储的数据过大时，会发生“栈溢出”。
在堆上分配：在程序中，全局变量，内存占用大的局部变量，发生了内存逃逸的局部变量就分配在堆上，这一块内存区域没有特定的结构，也没有固定的大小，可以根据需要进行调整。当一个变量分配在堆上的时候，开销会比较大，对Golang这种自带GC的语言来说，会增加GC压力，同时也会带来内存碎片。

内存逃逸
#

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

Golang中的内存逃逸
#

在Golang中可以使用go run -gcflags “-m -l” (-m打印逃逸分析信息，-l禁止内联编译)来分析内存逃逸。使用如下代码来分析内存逃逸：

func foo() *int {
    i := 10
    return  &i
}

func main() {
    a := *foo()
    _ = a
}

执行结果如下：

Golang之内存泄漏

Sat, 18 Mar 2023 00:00:00 +0000

Golang之内存泄漏
#

内存泄漏
#

内存泄漏说白了就是分配的内存(或者变量)不再使用，但是并没有被gc回收，而是继续占用内存。在Golang中内存泄漏大部分都跟channel的不正确使用有关。泄漏的原因是goroutine操作channel后，处于发送阻塞或者接收阻塞状态，而channel处于满或者空的状态，一直得不到改变。同时，垃圾回收器也不会回收此类资源，进而导致goroutine会处于一个一直等待的队列中，不见天日。

场景分析
#

案例1: channel没有接收者
#

下面这段程序展示了并发地向3个站点请求资源，接收者只接收最快返回的那个。

func goroutineLeak1() string {
	responses := make(chan string) //正确姿势：responses := make(chan string, 3)
  //3个发送者
	go func {responses <- request("asia.gopl.io")}()
	go func {responses <- request("europe.gopl.io")}()
	go func {responses <- request("americas.gopl.io")}()
  //1个接收者
	return <- responses
}

goroutineLeak1能正确地接收到最快返回的站点资源，但两个慢的goroutien会因为没有人接收而永远卡住，造成这两个goroutine永远没法被回收。正确的姿势是创建一个带3个buffer的channel，可以回收两个返回比较慢的goroutine。

GPM<4>-场景分析

Wed, 08 Mar 2023 00:00:00 +0000

GPM<4>场景分析
#

场景分析
#

场景一: 创建/执行G
#

当某个G1创建一个新的G2时：

1.运行一个G

2.当本地队列未满，则直接加入本地队列(满足局部性)

3.如果本地队列已满，则将P1本地队列中的前一半(G3/G4)+G7顺序打乱，一同放到全局队列中去。

场景二: 唤醒正在休眠的M
#

当创建一个G时，会尝试唤醒M的休眠队列，假定G2唤醒了M2，M2绑定了P2，此时P2本地队列里没有G，M2此时为自旋线程（没有G可以运行，不断地寻找可运行的G）。自旋线程的存在是为了通过短期的自旋来防止线程被销毁。但过多的自旋线程会白白浪费CPU，所以结合两种情况，系统中最多存在GOMAXPROCS个自旋线程。

场景三: 被唤醒的M从全局队列取G
#

在场景二中被唤醒的M会从全局队列取出n个G来运行，n的计算法则：n = min(len(GQ)/GOMAXPROCS + 1, len(GQ/2))，至少从全局队列取1个G，但每次不要从全局队列移动太多的G到P本地队列，这是从全局队列到P本地队列的负载均衡。

Golang之gin源码分析

Tue, 07 Mar 2023 00:00:00 +0000

gin
#

gin是一个用Go语言编写的web框架。

demo
#

package main

import "github.com/gin-gonic/gin"

func main() {
    r := gin.Default()
    r.GET("/ping", func(c *gin.Context) {
        c.JSON(200, gin.H{
            "message": "pong",
        })
    })
    r.Run()
}

流程分析
#

以下分析基于：

github.com/gin-gonic/gin v1.5.0

1. 创建Engin
#

Engin即引擎，Engin是 Web Server 的基础支持，也是服务的入口和根级的数据结构。下面是Engin的定义。

Golang之slice

Tue, 07 Mar 2023 00:00:00 +0000

slice
#

简介
#

本文旨在讲解slice的数据结构及扩容策略，以下内容基于：

go version go1.16.2 darwin/amd64

slice数据结构
#

type slice struct {
	array unsafe.Pointer  //指向底层数组的指针
  len   int   //slice的长度 len(s)的返回值 for range 遍历slice的话也是以这个为终点
  cap   int   //slice的容量 cap(s)的返回值
}

slice扩容策略
#

可以使用append函数给slice添加元素

Golang之GC

Thu, 23 Feb 2023 00:00:00 +0000

Golang之GC
#

为什么要有GC
#

当程序启动的时候，操作系统会给程序分配堆区与栈区，栈区里的内存是可以自动管理的，当栈区变量的作用域结束，可以被自动收回。堆区属于程序员自己管理的区域，即使堆区变量的作用域结束，后续可能继续使用。所以对于堆区的内存，程序员需要实时关注，如果内存一直增长没有释放，则会溢出，如果内存释放后还继续访问，则会出现非法访问。那有没有一种机制能够让堆区的闲置的内存自动回收？GC可以帮我们做到。GC(Ggrbage Collect)即垃圾回收，它可以通过一定的策略，让程序自动管理内存，让开发者更增加专注业务的开发。

GC常用的策略
#

引用计数法。引用计数法为对象维护一个计数器，当对象被引用时，计数器加1，引用被释放，计数器减1，当计数器为0时，表示没有被引用，清除这个对象。引用计数法实现简单，但频繁更新计数器会带来一定开销，且无法解决循环引用的弊端。
标记-清除法。标记-清除法是对对象定时进行标记，标记为“正在使用”与“没有被使用”两种，标记完后对标记为“没有被使用”的进行清除。由于程序是动态在运行的，随时有可能改变对象引用指向，因此，在标记的时候需要STW(Stop The World)，即程序停止一段时间，这段时间专门用来做标记。

Golang中的GC策略
#

Golang在v1.5之前是使用清除-标记法的策略进行GC，但v1.5使用了三色标记法，所谓三色标记法就是通过三个阶段来去定对象的状态（黑色/白色/灰色分别代表三个不同的状态）。

白色：初始对象
灰色：要被清除的对象
黑色：任然在使用的对象

1.创建新对象，全部为白色

Golang之channel源码分析

Mon, 20 Feb 2023 00:00:00 +0000

Golang之channel源码分析
#

1. channel
#

channel是支撑Go语言高性能并发编程模型的重要结构，channel是一个用于同步和通信的有锁环形队列，使用互斥锁解决程序中可能存在的线程竞争问题。以下内容基于：

go version go1.16.2 darwin/amd64

2. channel的数据结构
#

channel其是用runtime.hchan来表示的。

type hchan struct {
	qcount   uint           // 缓冲区buffer里有几个元素
	dataqsiz uint           // 缓冲区buffer最多有几个元素 即缓冲区大小
	buf      unsafe.Pointer // 指向底层循环数组的指针
	elemsize uint16         // 元素大小
	closed   uint32        // 是否关闭
	elemtype *_type        // 元素的类型
	sendx    uint         // 已发送元素在环形数组中的索引
	recvx    uint         // 已接收元素在环形数组中的索引
	recvq    waitq        // 等待接收的goroutine队列
	sendq    waitq        // 待发送的goroutine队列
    
	lock mutex            //锁 保护数据
}

recvq与sendq是waitq类型的数据，分别代表接受的g队列与发送的g队列，waitq是一个双端链表。

Golang之boltdb源码分析

Wed, 15 Feb 2023 00:00:00 +0000

blotdb
#

1. 简介
#

boltdb是一个纯go编写的支持事务的文件型单机kv数据库。 其具有以下特点：

单机部署：不需要考虑CAP
支持事物：仅允许多个只读事务和最多一个读写事务同时运行
索引结构：因为是kv型的数据库，所以天然地只有主键索引（B+树实现），减少了磁盘IO
缓存管理：仅管理写缓存，利用mmap管理读缓存

2. 核心数据结构分析
#

先从介绍一下bolt使用的一些底层的数据结构。

db
page
node
bucket
cursor

1. db
#

在boltdb中，它的数据全部都是存储在文件上，一个db对应一个真实的磁盘文件。

Golang之context源码分析

Wed, 15 Feb 2023 00:00:00 +0000

Golang之context源码分析
#

Context是什么
#

Context是Golang中独特的数据结构，可以用来设置截至日期、同步信号、传递请求相关值，总地来说就是在goroutine构成的树形结构中对信号进行同步以减少计算资源的浪费。以下内容基于：

go version go1.16.2 darwin/amd64

Context的数据结构
#

Context是一个接口，来看下它的接口定义

type Context interface {

	//Deadline方法是获取设置的截至时间，到了这个截至时间，
	//Context会自动发起取消，第二个返回值ok代表是否有设置
	//截至时间
 	Deadline() (deadline time.Time, ok bool) 

 	//Done方法返回一个只读的chan，当这个chan收到消息时代
 	//表Parent Context已经发起了取消请求，当前goroutine
 	//要开始做清理操作了
	Done() <-chan struct{} 

	//Err返回Context被取消的原因
	Err() error

	//Value方法返回Context绑定的对应的key的值，这个是线程安全的
	Value(key interface{}) interface{}
}

context包提供了6种创建Context的方法。每个方法都会返回一种类型的结构体，这些结构体都实现了Context接口。

Golang之map源码分析

Wed, 15 Feb 2023 00:00:00 +0000

Golang之map源码分析
#

哈希表
#

map即哈希表，也称为散列表，是根据关键码值(key value)而直接进行访问的数据结构。也就是说，它通过把关键码值映射（哈希函数）到表中一个位置来访问记录，以加快查找的速度。

哈希碰撞
#

哈希函数是整个哈希表的关键。所以为了更好的性能，我们希望在尽可能短的时间内，相同的key经过哈希函数的计算，可以得到相同的索引，不同的key经过哈希函数的计算，可以得到不同的索引，但在实际中往往事与愿违，不同的key小概率会计算出相同的索引，这就是哈希冲突（collision），几乎所有的哈希函数都存在这个问题。常见的解决哈希冲突的方法有：

开放寻址法：开放寻址法是如果通过哈希函数计算出的key所对应的空间已经被占用了，就从数组尾部再找一个还没被占用的空间将数据存进去。
拉链法：实现拉链法一般会使用数组加上链表，数组的每个索引位置装的是一个链表，当发生hash冲突时，将新的kv挂在这个链表的尾部。

版本
#

以下内容基于：

go version go1.16.2 darwin/amd64

map的数据结构
#

Golang里map由runtime.hmap实现。

Golang之sync.Once源码分析

Wed, 15 Feb 2023 00:00:00 +0000

Golang之sync.Once源码分析
#

sync.Once简介
#

sync.Once 是 Go 语言实现的一种对象，用来**保证某种行为只会被执行一次。**sync.Once通常用来实现单例模式的初始化。

源码分析
#

以下内容基于：

go version go1.16.2 darwin/amd64

sync.Once结构

type Once struct {
	done uint32  //用来表示是否已经执行 0-未执行 1-以执行
	m    Mutex   //互斥锁
}

Sync.Once只提供了一个Do的方法。

func (o *Once) Do(f func()) {
  // 一种错误的方式是使用cas锁 atomic.CompareAndSwapUint32
	//	if atomic.CompareAndSwapUint32(&o.done, 0, 1) {
	//		f()
	//	}
  // cas锁虽然保证了原子操作，但可能会出现Do里的流程还没执行完就返回的情况
  // 比如：A号groutine先执行了cas操作，将o.done改为1，然后执行Do流程，B号goroutine
  // 也执行cas操作，发现o.done已经为1了，直接返回，但这时Do流程可能还未执行完！sync.Once
  // 是要保证函数返回后Do流程一定是执行完的，所以这违反了它设计的原则。

	if atomic.LoadUint32(&o.done) == 0 { //如果 o.done==1 则说明方法已执行 直接返回 
		// 如果是0 说明还未执行 进入执行doSlow流程（注意！！！这里可能有好几个goroutine进入这里去执行）
		o.doSlow(f)
	}
}

once.doSlow是正真执行Do流程的函数。

Golang之sync.Map源码分析

Mon, 13 Feb 2023 00:00:00 +0000

Golang之sync.Map源码分析
#

map的并发操作
#

从前面文章的分析可以看到，原生的map如果并发读写的话，会抛出异常。

	if h.flags&hashWriting != 0 {
		throw("concurrent map read and map write")
	}

也就是说原生的map不是并发安全的。如果要实现并发安全，可以在操作map的时候加一把mutex锁。但官方提供了更高效的sync.Map，使其能在并发安全的前提下更加高效地读写。sync.Map使用了写时复制（即Copy On Write）技术来实现安全的高并发的map。sync.Map适用于读多写少的场景。

sync.Map数据结构
#

type Map struct {

	mu Mutex //互斥锁 保护dirty字段

	read atomic.Value //只读数据 实际类型为sync.readOnly

	dirty map[interface{}]*entry //写入数据 操作前需先加锁
 
	misses int //每次从read读取失败（read穿透） misses+1
}

其中sync.readOnly的数据结构

GPM<1>-进程-线程-协程

Thu, 09 Feb 2023 00:00:00 +0000

GPM<1> 进程/线程/协程
#

进程/线程/协程
#

进程
#

进程是一个具有一定独立功能的程序在一个数据集上的一次动态执行的过程，是操作系统进行资源分配和调度的一个独立单位，是应用程序运行的载体。每一个进程都有自己独立的地址空间。

线程
#

线程是进程的一个实体，是CPU调度和分派的基本单位，线程自己基本上不拥有系统资源，但是它可与同属一个进程的其他的线程共享进程所拥有的全部资源。线程的上下文切换比进程的上下文切换快得多，所以对他的调度的开销会小很多，从而提高系统资源的利用率和吞吐量。

进程/线程联系与区别
#

其实Linux下并没有线程，只是为了迎合开发口味，搞了个轻量级进程出来就叫做了线程。轻量级进程和进程一样，都有自己独立的task_struct进程描述符，也都有自己独立的pid。从操作系统视角看，调度上和进程没有什么区别，都是在等待队列的双向链表里选择一个task_struct切到运行态而已。只不过轻量级进程和普通进程的区别是可以共享同一内存地址空间、代码段、全局变量、同一打开文件集合而已。线程切换和进程切换之间的主要区别在于，在线程切换期间，虚拟内存空间保持不变，而在进程切换期间则不然。那么CPU从一个task_struct切换到另一个task_struct时，是如何断定它进程间切换还是线程间切换呢？我我们可以通过task_struct里的tgid （thread group id）这个字段来判断。tgid这个字段在task_struct里代表线程的组id，即同一组（同一进程下）的线程拥有相同的tgid，当CPU切换task_struct时发现两个task_struct的tgid不同，则认为是进程切换，需要重新加载虚拟内存空间。

GPM<2>-协程的实现

Thu, 09 Feb 2023 00:00:00 +0000

GPM<2> 协程的实现
#

协程的实现
#

协程
#

前面我们说过利用协程具有轻量/上下文切换成本低等特点，那么他是如何在计算机中体现的? 到底协程是在那里被承载的?

线程分为用户态线程与内核态线程，一个用户态线程必须绑定一个内核态线程，但CPU并不知道用户态线程的存在，也就是说CPU没法管到用户空间的事。既然CPU管不到用户空间的事，那用户空间就成了“三不管”地带了，那就决定在用户空间搞点事情。

这样内核线程依然叫“线程”，用户线程就叫“协程”。

既然一个协程能绑定到一个线程上，那为什么不能将多个协程绑定到一个或多个线程上呢？下面分析三种协程与线程的绑定关系。

N:1模式
#

N个协程绑定在一个线程上，优点是协程的切换都在用户态，不用陷入内核态，切换迅速且切换的成本低。但其也有很明显的缺点。

因为N个协程都绑定到一个线程上了，即使是多核的计算也没有办法实现并行，浪费了计算机的性能。一旦某个协程阻塞，本线程下的其他协程都无法执行，没有了并发能力。

1:1模式
#

解决了N:1模式没有并发能力的不足，但每次切换协程都要切换线程，成本太高，失去了协程存在的意义。

GPM<3>-调度设计

Thu, 09 Feb 2023 00:00:00 +0000

GPM<3> 调度设计
#

GPM
#

G: Goroutine，Goroutine这个概念来自协程，一个Goroutine必须必须绑定到P上才能被CPU执行。Goroutine非常轻量，创建一个Goroutine只需要几kb的内存资源(实际上这个内存资源是动态的，如果有需要runtime会为goroutine自动分配资源)。

P: Processer, 即为G和M的调度对象，用来调度G和M之间的关联关系，其数量可通过GOMAXPROCS()来设置，默认为CPU核心数。

M: Machine, OS 内核线程抽象，代表着真正执行计算的资源，在绑定有效的 P 后，执行P调度出来的G。M的数量由runtime决定(默认最大1000)。M 并不保留 G 状态，这是 G 可以跨 M 调度的基础。

Go调度器的是由GPM构成的。

调度器初期设计
#

调度器初期的设计是并没有P，仅有G与M，造成了如下弊端。

1.如每次M调度G都需要获G全局队列的锁，造成了激烈的锁竞争。

2.无法实现G的局部性（即从当M1执行G1时，G1创建出来的G1’无法保证任然被M1执行）

3.M需要经常互相传递可运行的 G，引入了大量的延迟；

调度器进阶设计
#

基于旧的调度器的弊端，Go设计了一个全新的调度器。再新的调度器中，加入了P。M是G运行的实体，P负责把G分配到M上进行执行，M才是真真正正的“干活者”。

Golang之内存管理2

Wed, 08 Feb 2023 00:00:00 +0000

Golang之内存管理
#

概述
#

Golang的内存分配借鉴了Google的TMalloc，其核心思想是内存池+多级对象管理，能加快分配速度，降低资源竞争。

Golang内存模型层次结构
#

MCache
#

访问mcache依然不需要加锁而是直接访问，且MCache中依然保存各种大小的Span。MCache是与Golang协程调度模型GPM中的P所绑定，而不是和线程绑定。因为Golang调度的GPM模型，真正可运行的线程M的数量与P的数量一致，即GOMAXPROCS个，所以MCache与P进行绑定更能节省内存空间使用，可以保证每个G使用MCache时不需要加锁就可以获取到内存。

MCentral
#

当MCache中某个Size Class对应的Span被一次次Object被上层取走后，如果出现当前Size Class的Span空缺情况，MCache则会向MCentral申请对应的Span。Goroutine、MCache、MCentral、MHeap互相交换的内存单位是不同，向Mcentral申请内存是需要加锁的。

Golang之内存对齐

Tue, 07 Feb 2023 00:00:00 +0000

Golang之内存对齐
#

现象
#

type foo struct {
	a bool   //1字节
	b int32  //4字节
	c int8   //1字节
	d int64  //8字节
	e byte   //1字节
}

func main() {
    f := foo{}
    fmt.Println("size of foo: ", unsafe.Sizeof(f))
}

这个输出结果是各个字段占用内存的和15字节吗？答案并不是，输出的结果是32字节，要大于所有字段占用内存大小的总和15字节。

内存对齐
#

可能很多人认为在结构体中各个字段的内存是连续的，cpu按各个字段的大小按需读取相应的值。

但实际上，cpu读取内存是以块为单位的，块的大小可以为 2、4、6、8、16 字节等大小（也称为内存粒度），cpu每次都读去内存里的“若干块”数据。在内存分布上，内存也是“一块一块”分布的，数据不是按照其本身的大小排布，而是按照内存粒度的来排布，以方便cpu快速读取数据，这就是内存对齐。

为什么需要内存对齐？
#

1.平台原因：不是所有硬件平台都能访问任意地址上的任意数据。例如：特定的硬件平台只允许在特定地址获取特定类型的数据，否则会导致异常情况。

Golang之mutex源码分析

Fri, 03 Feb 2023 00:00:00 +0000

Golang之mutex
#

互斥锁Mutex
#

在Golang中用于表示互斥锁的是sync.Lock，其作用是保护临界区，确保任意时间只有一个goroutine能拿到锁。

正常模式&饥饿模式
#

为了保证公平性，Golang在v1.9的互斥锁版本中引入了饥饿模式与正常模式。

如果当前锁正在被持有，抢不到锁就会进入一个等待的队列，当锁被释放后，从这个队列的队头里唤醒一个goroutine（等待者），但是锁不会直接给这个等待者，而是必须与正在获取锁但还未进入等待队列的goroutine竞争这把锁，与刚唤醒的等待者相比，这个goroutine正持有CPU，所以获取到锁的概率较大。如果等待者抢锁失败，那么它就会被放回队列头部，如果它超过1ms都还没获取到锁，就从正常模式切换为饥饿模式。
在饥饿模式下，当锁释放后，锁会直接交给等待队列的第一个等待者，不必再与新来的goroutine竞争，新来的goroutine会直接加到等待队列的队尾。当满足以下两个条件时，饥饿模式将切换回正常模式。（1）当前被唤醒的等待者获得锁后，发现队列只剩它自己一个了，那么切换回正常模式。（2）当前被唤醒的等待者获得锁后，发现自己的等待时间不超过1ms，那么切换回正常模式。

在正常模式下，当前拥有CPU的goroutine比起等待队列里的goroutine有很大几率获得锁，这样可以避免协程上下文的频繁切换。但这样又会导致等待队列里的goroutine活活“饿死”，所以又必须有饥饿模式，保证等待已久的goroutine能够获取到锁，以保证公平性。

sync.Lock
#

type Mutex struct {
	state int32 //表示锁的状态，有锁定、饥饿、唤醒等状态
	sema  uint32 //表示信号量 用于实现mutex阻塞队列的定位
}

const (
	mutexLocked = 1 << iota //1 state & 1 == 1 表示上锁状态
	mutexWoken	            //2 state & 2 == 1 表示唤醒状态 
	mutexStarving           //4 state & 4 == 1 表示饥饿状态
	mutexWaiterShift = iota //3 state >> 3 获取等待者的数量	

	starvationThresholdNs = 1e6 //进入饥饿状态的阈值
)

state字段总共占用32个bit，其中用前三位表示三个状态，后29个bit表示等待的goroutine个数。

Golang之ants源码分析

Tue, 24 Jan 2023 00:00:00 +0000

ants
#

1. 简介
#

ants 是一个高性能的协程池，实现了对大规模 goroutine 的调度管理、goroutine 复用，允许使用者在开发并发程序的时候限制协程数量，复用资源，达到更高效执行任务的效果。其具体特点如下：

自动调度海量的 goroutines，复用 goroutines
定期清理过期的 goroutines，进一步节省资源
提供了大量有用的接口：任务提交、获取运行中的 goroutine 数量、动态调整 Pool 大小、释放 Pool、重启 Pool
优雅处理 panic，防止程序崩溃
资源复用，极大节省内存使用量；在大规模批量并发任务场景下比原生 goroutine 并发具有更高的性能
非阻塞机制

本文从pool顶层方法开始，到底层workArray的实现，由上至下分析整个ants的工作流程。以下代码分析基于：

github.com/panjf2000/ants/v2 v2.6.0

2. 项目结构
#

ants                		       root directory
├── interal                    
    ├── spinlock                  自实现的自旋锁
├── ants.go                 		  定义常量、errors显示、默认goroutine池、封装一些方便用户操作查看goroutine池的函数
├── options.go                    goroutine池的相关配置
├── pool.go 											普通pool(不绑定特定函数)的创建以及对pool相关的操作
├── pool_func.go                  创建绑定某个特定函数的pool以及对pool相关的操作
├── worker.go                     goWorker的定义及方法
├── worker_array.go               workerArray的接口和一个能返回实现该接口的函数
├── worker_loop_queue.go 					loopQueue的定义及方法 loopQueue实现了workerArray
├── worker_stack.go               workerStack的定义及方法 workerStack实现了workerArray

3. 数据结构及实现原理
#

3.1 概念
#

首先需要明白ants代码两个概念，worker及task（任务）

Golang之defer

Sun, 18 Sep 2022 00:00:00 +0000

Golang之defer
#

defer
#

Golang的defer会在函数返回前去执行传入的函数，它会经常被用于关闭文件描述符、关闭数据库连接以及解锁资源。

常见使用场景
#

1.关闭文件

func foo1()  {
	file, err :=  os.OpenFile("your file path", os.O_RDONLY, 0755)
	if err != nil {
		return
	}
	defer file.Close()
	//use file do something
	//...

	return
}

2.解锁

func foo2(mu *sync.Mutex)  {
	mu.Lock()
	defer mu.Unlock()
	//do something
	//...

	return
}

defer数据结构
#

type _defer struct {
	siz       int32  //参数和结果的内存大小
	sp        uintptr //栈指针
	pc        uintptr //调用方的程序计数器
	fn        *funcval //defer中传入的函数
	_panic    *_panic //触发延迟调用的结构体，可能为空
	link      *_defer //指向下一个defer
}

defer调用链
#

当goroutine获取到一个defer，就会创建一个runtime._defer结构体，然后将runtime._defer追加到当前goroutine的defer链表的最前面。

Golnag之interface

Tue, 23 Aug 2022 00:00:00 +0000

Golang之interface
#

接口
#

接口（interface）是一组仅包含方法名、参数、返回值的未具体实现的方法的集合。接口只定义规范而不去实现，细节由具体的对象来实现。Golang中接口是一种抽象的类型。

实现
#

Golang中interface通常分为两大类，一种是空接口，这种接口不带任何方法。

type a interface{}

另一种是非空接口，这种接口带有方法

type duck interface {
	quack()
}

这两种类型的接口底层分别对应两个不同的结构，空接口对应runtime.eface，非空接口对应runtime.iface

eface的定义如下

type eface struct {
	_type *_type  //记录类型信息（_type是GO语言中所有类型的公共描述，Go语言几乎所有的数据结构都可以抽象成 _type，是所有类型的公共描述，type负责决定data应该如何解释和操作）
	data  unsafe.Pointer //指向数据的指针
}

iface的定义如下

type iface struct {
	tab  *itab //
	data unsafe.Pointer //指向数据的指针
}

itab是最重要的结构，每一个 itab 都占 32 字节的空间。itab里面包含了interface的一些关键信息，比如method的具体实现。

源码 on

Golang之系统排查

系统排查 #

1. 先确定出现问题的进程 #

2. 使用PProf排查程序内部的问题 #

使用web界面查看pprof信息 #

Golang之内存管理

Golang之内存管理 #

概述 #

内存分配的方法 #

基础结构 #

内存单元 #

Golang之内存逃逸

Golang之内存逃逸 #

内存分配 #

内存逃逸 #

Golang中的内存逃逸 #

Golang之内存泄漏

Golang之内存泄漏 #

内存泄漏 #

场景分析 #

案例1: channel没有接收者 #

GPM<4>-场景分析

GPM<4>场景分析 #

场景分析 #

场景一: 创建/执行G #

场景二: 唤醒正在休眠的M #

场景三: 被唤醒的M从全局队列取G #

Golang之gin源码分析

gin #

demo #

流程分析 #

1. 创建Engin #

Golang之slice

slice #

简介 #

slice数据结构 #

slice扩容策略 #

Golang之GC

Golang之GC #

为什么要有GC #

GC常用的策略 #

Golang中的GC策略 #

Golang之channel源码分析

Golang之channel源码分析 #

1. channel #

2. channel的数据结构 #

Golang之boltdb源码分析

blotdb #

1. 简介 #

2. 核心数据结构分析 #

1. db #

Golang之context源码分析

Golang之context源码分析 #

Context是什么 #

Context的数据结构 #

Golang之map源码分析

Golang之map源码分析 #

哈希表 #

哈希碰撞 #

版本 #

map的数据结构 #

Golang之sync.Once源码分析

Golang之sync.Once源码分析 #

sync.Once简介 #

源码分析 #

Golang之sync.Map源码分析

Golang之sync.Map源码分析 #

map的并发操作 #

sync.Map数据结构 #

GPM<1>-进程-线程-协程

GPM<1> 进程/线程/协程 #

进程/线程/协程 #

进程 #

线程 #

进程/线程联系与区别 #

GPM<2>-协程的实现

GPM<2> 协程的实现 #

协程的实现 #

协程 #

系统排查
#

1. 先确定出现问题的进程
#

2. 使用PProf排查程序内部的问题
#

使用web界面查看pprof信息
#

Golang之内存管理
#

概述
#

内存分配的方法
#

基础结构
#

内存单元
#

Golang之内存逃逸
#

内存分配
#

内存逃逸
#

Golang中的内存逃逸
#

Golang之内存泄漏
#

内存泄漏
#

场景分析
#

案例1: channel没有接收者
#

GPM<4>场景分析
#

场景分析
#

场景一: 创建/执行G
#

场景二: 唤醒正在休眠的M
#

场景三: 被唤醒的M从全局队列取G
#

gin
#

demo
#

流程分析
#

1. 创建Engin
#

slice
#

简介
#

slice数据结构
#

slice扩容策略
#

Golang之GC
#

为什么要有GC
#

GC常用的策略
#

Golang中的GC策略
#

Golang之channel源码分析
#

1. channel
#

2. channel的数据结构
#

blotdb
#

1. 简介
#

2. 核心数据结构分析
#

1. db
#

Golang之context源码分析
#

Context是什么
#

Context的数据结构
#

Golang之map源码分析
#

哈希表
#

哈希碰撞
#

版本
#

map的数据结构
#

Golang之sync.Once源码分析
#

sync.Once简介
#

源码分析
#

Golang之sync.Map源码分析
#

map的并发操作
#

sync.Map数据结构
#

GPM<1> 进程/线程/协程
#

进程/线程/协程
#

进程
#

线程
#

进程/线程联系与区别
#

GPM<2> 协程的实现
#

协程的实现
#

协程
#

N:1模式
#

1:1模式
#

GPM<3> 调度设计
#

GPM
#

调度器初期设计
#

调度器进阶设计
#

Golang之内存管理
#

概述
#

Golang内存模型层次结构
#

MCache
#

MCentral
#

Golang之内存对齐
#

现象
#

内存对齐
#

为什么需要内存对齐？
#

Golang之mutex
#

互斥锁Mutex
#