锐客网

  1. 首页 > 睿知 > it技术 > >

图解go语言内存分配 go语言实现简单kv存储

队列IT技术

内存对齐问题1.平台原因(移植原因)： 不是所有的硬件平台都能访问任意地址上的任意数据的；某些硬件平台只能
在某些地址处取某些特定类型的数据 ， 否则抛出硬件异常 。
2.性能原因： 数据结构应该尽可能地在自然边界上对齐 。原因在于，为了访问未对齐的内存，处理器需要作两次内存访问；而对齐的内存访问仅需要一次访问 。(如果是对齐的，那么CPU不需要跨越两个操作字，不是对齐的则需要访问两个操作字才能拼接出需要的内存地址)
指针的大小一般是一个机器字的大小
通过Go语言的structlayout工具，可以得出下图
这些类型在之前的 slice 、 map 、 interface 已经介绍过了，也特意强调过，makehmap函数返回的是一个指针，因此map的对齐为一个机器字.
回头看看 sync.pool的防止copy的空结构体字段,也是放在第一位，破案了 。
计算机结构可能会要求内存地址 进行对齐;也就是说，一个变量的地址是一个因子的倍数，也就是该变量的类型是对齐值 。
函数Alignof接受一个表示任何类型变量的表达式作为参数，并以字节为单位返回变量(类型)的对齐值 。对于变量x：
这是因为int64在bool之后未对齐 。
【图解go语言内存分配 go语言实现简单kv存储】它是32位对齐的，但不是64位对齐的，因为我们使用的是32位系统，因此实际上只是两个32位值并排在一起 。
● 内存对齐是为了cpu更高效访问内存中数据
● 结构体对齐依赖类型的大小保证和对齐保证
● 地址对齐保证是：如果类型 t 的对齐保证是 n，那么类型 t 的每个值的地址在运行时必须是 n 的倍数 。
● struct内字段如果填充过多，可以尝试重排，使字段排列更紧密 ， 减少内存浪费
● 零大小字段要避免作为struct最后一个字段，会有内存浪费
● 32位系统上对64位字的原子访问要保证其是8bytes对齐的；当然如果不必要的 话 ， 还是用加锁（mutex）的方式更清晰简单
图解go-内存对齐
doc-pdf
Golang的调度模型Go有四大核心模块，基本全部体现在runtime，有调度系统、GC、goroutine、channel，那么深入理解其中的精髓可以帮助我们理解Go这一门语言！
参考: 调度系统设计精要
下面是我用Go语言简单写的一个调度器 ， 大家可以看看设计思路，以及存在的问题！
1、测试条件，调度器只启动两个线程，然后一个线程主要是负责循环的添加任务，一个线程循环的去执行任务
2、测试条件，调度器启动三个线程，然后两个线程去执行任务 ， 一个添加任务
3、继续测试，启动十个线程 ， 一个添加任务，九个执行任务
4、我们添加一些阻塞的任务
执行可以看到完全不可用
1、 可以看到随着M的不断的增加，可以发现执行任务的数量也不断的减少，原因是什么呢？有兴趣的同学可以加一个pprof可以看看，其实大量的在等待锁的过程！
2、如果我的M运行了类似于Sleep操作的方法如何解决了 ， 我的调度器还能支撑这个量级的调度吗？
关于pprof如何使用：在代码头部加一个这个代码：
我们查看一下go tool pprof main/prof.pporf
可以看到真正执行代码的时间只有 0.17s0.02s 其他时间都被阻塞掉了！
1、GM模型中的所有G都是放入到一个queue，那么导致所有的M取执行任务时都会去竞争锁，我们插入G也会去竞争锁，所以解决这种问题一般就是减少对单一资源的竞争，那就是桶化，其实就是每个线程都分配一个队列
2、GM模型中没有任务状态，只有runnable，假如任务遇到阻塞，完全可以把任务挂起再唤醒
这里其实会遇到一个问题，假如要分配很多个线程，那么此时随着线程的增加，也会造成队列的增加 ， 其实也会造成调度器的压力，因为它需要遍历全部线程的队列去分配任务以及后续会讲到的窃取任务！
因为我们知道CPU的最大并行度其实取决于CPU的核数，也就是我们没必要为每个线程都去分配一个队列，因为就算是给他们分配了，他们自己去那执行调度，其实也会出现大量阻塞，原因就是CPU调度不过来这些线程！
Go里面是只分配了CPU个数的队列 ， 这里就是P这个概念，你可以理解为P其实是真正的资源分配器 ， M很轻只是执行程序，所有的资源内存都维护在P上！M只有绑定P才能执行任务（强制的）！
这样做的好处：
1、首先调度程序其实就是调度不同状态的任务，go里面为Go标记了不同的状态 ， 其实大概就是分为：runnable，running，block等，所以如何充分调度不同状态的G成了问题 ， 那么关于阻塞的G如何解决，其实可以很好的解决G调度的问题！
上面这些情况其实就分为：
2、用户态阻塞，一般Go里面依靠gopark函数去实现，大体的代码逻辑基本上和go的调度绑定死了
源码在：
3、其实对于netpool 这种nio模型，其实内核调用是非阻塞的，所以go开辟了一个网络轮训器队列，来存放这些被阻塞的g，等待内核被唤醒！那么什么时候会被唤醒了，其实就是需要等待调度器去调度了！
4、如果是内核态阻塞了（内核态阻塞一般都会将线程挂起，线程需要等待被唤醒），我们此时P只能放弃此线程的权利，然后再找一个新的线程去运行P！
关于着新线程：找有没有idle的线程，没有就会创建一个新的线程！
关于当内核被唤醒后的操作：因为GPM模型所以需要找到个P绑定 ， 所以G会去尝试找一个可用的P，如果没有可用的P，G会标记为runnable放到全局队列中！
5、其实了解上面大致其实就了解了Go的基本调度模型
答案文章里慢慢品味！
如果某个 G 执行时间过长，其他的 G 如何才能被正常的调度？ 这便涉及到有关调度的两个理念：协作式调度与抢占式调度 。协作式和抢占式这两个理念解释起来很简单： 协作式调度依靠被调度方主动弃权；抢占式调度则依靠调度器强制将被调度方被动中断 。
例如下面的代码，我本地的版本是go1.13.5
执行:GOMAXPROCS=1配置全局只能有一个P
可以看到main函数无法执行!也就是那个go 空转抢占了整个程序
备注：
但是假如我换为用 1.14 版本执行 ， 有兴趣的话可以使用我的docker镜像，直接可以拉?。?fanhaodong/golang:1.15.11和fanhaodong/golang:1.13.5
首先我们知道G/M/P，G可能和M也可能和P解除绑定，那么关于数据变量放在哪哇！其实这个就是逃逸分析！
输出可以看到其实没有发生逃逸，那是因为 demo被拷贝它自己的栈空间内
备注：
-gcflags"-N -l -m"其中-N禁用优化-l禁止内联优化 ， -m打印逃逸信息
那么继续改成这个
可以看到发现 demo对象其实被逃逸到了堆上！这就是不会出现类似于G如果被别的M执行 ， 其实不会出现内存分配位置的问题！
所以可以看到demo其实是copy到了堆上！这就是g逃逸的问题，和for循环一样的
执行可以发现 ， 其实x已经逃逸到了堆上，所以你所有的g都引用的一个对象 ， 如何解决了
如何解决了 ， 其实很简单
也谈goroutine调度器
图解Go运行时调度器
Go语言回顾：从Go 1.0到Go 1.13
Go语言原本
调度系统设计精要
Scalable Go Scheduler Design Doc
Go语言中恰到好处的内存对齐 在开始之前，希望你计算一下Part1共占用的大小是多少呢？
输出结果：
这么一算，Part1这一个结构体的占用内存大小为 1 4 1 8 1 = 15 个字节 。相信有的小伙伴是这么算的，看上去也没什么毛病
真实情况是怎么样的呢？我们实际调用看看，如下：
输出结果：
最终输出为占用 32 个字节 。这与前面所预期的结果完全不一样 。这充分地说明了先前的计算方式是错误的 。为什么呢？
在这里要提到 “内存对齐” 这一概念 ， 才能够用正确的姿势去计算，接下来我们详细的讲讲它是什么
有的小伙伴可能会认为内存读?。褪且桓黾虻サ淖纸谑榘诜?
上图表示一个坑一个萝卜的内存读取方式 。但实际上 CPU 并不会以一个一个字节去读取和写入内存 。相反 CPU 读取内存是 一块一块读取 的，块的大小可以为 2、4、6、8、16 字节等大小 。块大小我们称其为 内存访问粒度。如下图：
在样例中，假设访问粒度为 4 。CPU 是以每 4 个字节大小的访问粒度去读取和写入内存的 。这才是正确的姿势
另外作为一个工程师，你也很有必要学习这块知识点哦 :)
在上图中，假设从 Index 1 开始读取，将会出现很崩溃的问题 。因为它的内存访问边界是不对齐的 。因此 CPU 会做一些额外的处理工作 。如下：
从上述流程可得出，不做 “内存对齐” 是一件有点 "麻烦" 的事 。因为它会增加许多耗费时间的动作
而假设做了内存对齐，从 Index 0 开始读取 4 个字节，只需要读取一次，也不需要额外的运算 。这显然高效很多，是标准的 空间换时间 做法
在不同平台上的编译器都有自己默认的 “对齐系数”，可通过预编译命令#pragma pack(n)进行变更，n 就是代指 “对齐系数” 。一般来讲，我们常用的平台的系数如下：
另外要注意，不同硬件平台占用的大小和对齐值都可能是不一样的 。因此本文的值不是唯一的，调试的时候需按本机的实际情况考虑
输出结果：
在 Go 中可以调用unsafe.Alignof来返回相应类型的对齐系数 。通过观察输出结果，可得知基本都是2^n ， 最大也不会超过 8 。这是因为我手提（64 位）编译器默认对齐系数是 8 ， 因此最大值不会超过这个数
在上小节中，提到了结构体中的成员变量要做字节对齐 。那么想当然身为最终结果的结构体，也是需要做字节对齐的
接下来我们一起分析一下，“它” 到底经历了些什么，影响了 “预期” 结果
在每个成员变量进行对齐后，根据规则 2，整个结构体本身也要进行字节对齐，因为可发现它可能并不是2^n ， 不是偶数倍 。显然不符合对齐的规则
根据规则 2，可得出对齐值为 8 。现在的偏移量为 25，不是 8 的整倍数 。因此确定偏移量为 32 。对结构体进行对齐
Part1 内存布局：axxx|bbbb|cxxx|xxxx|dddd|dddd|exxx|xxxx
通过本节的分析，可得知先前的 “推算” 为什么错误？
是因为实际内存管理并非 “一个萝卜一个坑” 的思想 。而是一块一块 。通过空间换时间（效率）的思想来完成这块读取、写入 。另外也需要兼顾不同平台的内存操作情况
在上一小节，可得知根据成员变量的类型不同，其结构体的内存会产生对齐等动作 。那假设字段顺序不同 ， 会不会有什么变化呢？我们一起来试试吧 :-)
输出结果：
通过结果可以惊喜的发现，只是 “简单” 对成员变量的字段顺序进行改变，就改变了结构体占用大小
接下来我们一起剖析一下Part2，看看它的内部到底和上一位之间有什么区别，才导致了这样的结果？
符合规则 2，不需要额外对齐
Part2 内存布局：ecax|bbbb|dddd|dddd
通过对比Part1和Part2的内存布局，你会发现两者有很大的不同 。如下：
仔细一看 ， Part1存在许多 Padding 。显然它占据了不少空间，那么 Padding 是怎么出现的呢？
通过本文的介绍，可得知是由于不同类型导致需要进行字节对齐，以此保证内存的访问边界
那么也不难理解 ， 为什么 调整结构体内成员变量的字段顺序 就能达到缩小结构体占用大小的疑问了，是因为巧妙地减少了 Padding 的存在 。让它们更 “紧凑” 了 。这一点对于加深 Go 的内存布局印象和大对象的优化非常有帮
【golang详解】go语言GMP(GPM)原理和调度Goroutine调度是一个很复杂的机制，下面尝试用简单的语言描述一下Goroutine调度机制 ， 想要对其有更深入的了解可以去研读一下源码 。
首先介绍一下GMP什么意思：
G ----------- goroutine: 即Go协程，每个go关键字都会创建一个协程 。
M ---------- thread内核级线程，所有的G都要放在M上才能运行 。
P ----------- processor处理器 ， 调度G到M上 ， 其维护了一个队列，存储了所有需要它来调度的G 。
Goroutine 调度器P和 OS 调度器是通过 M 结合起来的，每个 M 都代表了 1 个内核线程，OS 调度器负责把内核线程分配到 CPU 的核上执行
模型图：
避免频繁的创建、销毁线程，而是对线程的复用 。
1）work stealing机制
当本线程无可运行的G时，尝试从其他线程绑定的P偷取G，而不是销毁线程 。
2）hand off机制
当本线程M0因为G0进行系统调用阻塞时，线程释放绑定的P，把P转移给其他空闲的线程执行 。进而某个空闲的M1获取P ， 继续执行P队列中剩下的G 。而M0由于陷入系统调用而进被阻塞，M1接替M0的工作，只要P不空闲 ， 就可以保证充分利用CPU 。M1的来源有可能是M的缓存池，也可能是新建的 。当G0系统调用结束后，根据M0是否能获取到P ， 将会将G0做不同的处理：
如果有空闲的P，则获取一个P，继续执行G0 。
如果没有空闲的P ， 则将G0放入全局队列，等待被其他的P调度 。然后M0将进入缓存池睡眠 。
如下图
GOMAXPROCS设置P的数量，最多有GOMAXPROCS个线程分布在多个CPU上同时运行
在Go中一个goroutine最多占用CPU 10ms，防止其他goroutine被饿死 。
具体可以去看另一篇文章
【Golang详解】go语言调度机制 抢占式调度
当创建一个新的G之后优先加入本地队列，如果本地队列满了，会将本地队列的G移动到全局队列里面，当M执行work stealing从其他P偷不到G时，它可以从全局G队列获取G 。
协程经历过程
我们创建一个协程 go func()经历过程如下图：
说明：
这里有两个存储G的队列 ， 一个是局部调度器P的本地队列、一个是全局G队列 。新创建的G会先保存在P的本地队列中，如果P的本地队列已经满了就会保存在全局的队列中；处理器本地队列是一个使用数组构成的环形链表，它最多可以存储 256 个待执行任务 。
G只能运行在M中，一个M必须持有一个P，M与P是1：1的关系 。M会从P的本地队列弹出一个可执行状态的G来执行 ， 如果P的本地队列为空，就会想其他的MP组合偷取一个可执行的G来执行；
一个M调度G执行的过程是一个循环机制；会一直从本地队列或全局队列中获取G
上面说到P的个数默认等于CPU核数，每个M必须持有一个P才可以执行G，一般情况下M的个数会略大于P的个数 ， 这多出来的M将会在G产生系统调用时发挥作用 。类似线程池，Go也提供一个M的池子，需要时从池子中获取 ， 用完放回池子，不够用时就再创建一个 。
work-stealing调度算法：当M执行完了当前P的本地队列队列里的所有G后，P也不会就这么在那躺尸啥都不干，它会先尝试从全局队列队列寻找G来执行，如果全局队列为空，它会随机挑选另外一个P，从它的队列里中拿走一半的G到自己的队列中执行 。
如果一切正常 ， 调度器会以上述的那种方式顺畅地运行，但这个世界没这么美好，总有意外发生，以下分析goroutine在两种例外情况下的行为 。
Go runtime会在下面的goroutine被阻塞的情况下运行另外一个goroutine：
用户态阻塞/唤醒
当goroutine因为channel操作或者network I/O而阻塞时（实际上golang已经用netpoller实现了goroutine网络I/O阻塞不会导致M被阻塞，仅阻塞G ， 这里仅仅是举个栗子），对应的G会被放置到某个wait队列(如channel的waitq)，该G的状态由_Gruning变为_Gwaitting，而M会跳过该G尝试获取并执行下一个G，如果此时没有可运行的G供M运行，那么M将解绑P，并进入sleep状态；当阻塞的G被另一端的G2唤醒时（比如channel的可读/写通知），G被标记为，尝试加入G2所在P的runnext（runnext是线程下一个需要执行的 Goroutine 。）， 然后再是P的本地队列和全局队列 。
系统调用阻塞
当M执行某一个G时候如果发生了阻塞操作，M会阻塞，如果当前有一些G在执行，调度器会把这个线程M从P中摘除，然后再创建一个新的操作系统的线程(如果有空闲的线程可用就复用空闲线程)来服务于这个P 。当M系统调用结束时候，这个G会尝试获取一个空闲的P执行，并放入到这个P的本地队列 。如果获取不到P，那么这个线程M变成休眠状态，加入到空闲线程中，然后这个G会被放入全局队列中 。
队列轮转
可见每个P维护着一个包含G的队列，不考虑G进入系统调用或IO操作的情况下，P周期性的将G调度到M中执行 ， 执行一小段时间，将上下文保存下来 ， 然后将G放到队列尾部，然后从队列中重新取出一个G进行调度 。
除了每个P维护的G队列以外，还有一个全局的队列，每个P会周期性地查看全局队列中是否有G待运行并将其调度到M中执行，全局队列中G的来源，主要有从系统调用中恢复的G 。之所以P会周期性地查看全局队列，也是为了防止全局队列中的G被饿死 。
除了每个P维护的G队列以外，还有一个全局的队列，每个P会周期性地查看全局队列中是否有G待运行并将其调度到M中执行，全局队列中G的来源 ， 主要有从系统调用中恢复的G 。之所以P会周期性地查看全局队列，也是为了防止全局队列中的G被饿死 。
M0
M0是启动程序后的编号为0的主线程 ， 这个M对应的实例会在全局变量rutime.m0中，不需要在heap上分配，M0负责执行初始化操作和启动第一个G，在之后M0就和其他的M一样了
G0
G0是每次启动一个M都会第一个创建的goroutine ， G0仅用于负责调度G，G0不指向任何可执行的函数 ， 每个M都会有一个自己的G0 ， 在调度或系统调用时会使用G0的栈空间，全局变量的G0是M0的G0
一个G由于调度被中断 ， 此后如何恢复？
中断的时候将寄存器里的栈信息，保存到自己的G对象里面 。当再次轮到自己执行时 ， 将自己保存的栈信息复制到寄存器里面，这样就接着上次之后运行了 。
我这里只是根据自己的理解进行了简单的介绍 ， 想要详细了解有关GMP的底层原理可以去看Go调度器 G-P-M 模型的设计者的文档或直接看源码
参考：()
()
图解go语言内存分配的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于go语言实现简单kv存储、图解go语言内存分配的信息别忘了在本站进行查找喔 。

    推荐阅读


    上一篇：如何设置服务器地址？ 怎么添加服务器地址

    下一篇：如何在服务器上使用kiftd？ kiftd怎么在服务器