go语言读内存 golang var 内存

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 的内存布局印象和大对象的优化非常有帮
Go 如何查看一个变量的内存地址 理解指针问题 熟悉C语言的同学都知道,查看一个变量的地址在处理指针的相关问题的时候直观重要,在C中直接取地址符 即可 。那么在Go语言中如何查看一个变量的地址 , 我们使用unsafe.Pointer() 函数来查看一个变量的内存地址 。
举例:
type Vertex struct {
X, Y float64
}
func (v Vertex) sqrt() float64 {
return math.Sqrt(v.X * v.Xv.Y * v.Y)
}
func (vVertex) scale(f float64) { //带 号 和不带*号的区别 可以从内存地址来看出
fmt.printf("=======", unsafe.Pointer(v))//v 本身就是指针 存储的就是地址 不用取地址
v.X = x.X * f
v.Y = v.Y * f
}
func main() {
v := Vertex{3, 4}
fmt.printf("=======", unsafe.Pointer(v))
v.scale(10)
fmt.Println(v.sqrt())
}
//带 号 打印的结果 ====== -%!(EXTRA unsafe.Pointer=0xc00006e070)======%!(EXTRA unsafe.Pointer=0xc00006e070) 相同
//不带 号 打印的结果======%!(EXTRA unsafe.Pointer=0xc000094060)======%!(EXTRA unsafe.Pointer=0xc000094090) 不同
去掉*号 在scale()方法中要对 v 进行取地址操作
(十一)golang 内存分析编写过C语言程序的肯定知道通过malloc()方法动态申请内存,其中内存分配器使用的是glibc提供的ptmalloc2 。除了glibc,业界比较出名的内存分配器有Google的tcmalloc和Facebook的jemalloc 。二者在避免内存碎片和性能上均比glic有比较大的优势,在多线程环境中效果更明显 。
Golang中也实现了内存分配器,原理与tcmalloc类似,简单的说就是维护一块大的全局内存,每个线程(Golang中为P)维护一块小的私有内存,私有内存不足再从全局申请 。另外,内存分配与GC(垃圾回收)关系密切,所以了解GC前有必要了解内存分配的原理 。
为了方便自主管理内存,做法便是先向系统申请一块内存,然后将内存切割成小块,通过一定的内存分配算法管理内存 。以64位系统为例,Golang程序启动时会向系统申请的内存如下图所示:
预申请的内存划分为spans、bitmap、arena三部分 。其中arena即为所谓的堆区,应用中需要的内存从这里分配 。其中spans和bitmap是为了管理arena区而存在的 。
arena的大小为512G , 为了方便管理把arena区域划分成一个个的page,每个page为8KB,一共有512GB/8KB个页;
spans区域存放span的指针,每个指针对应一个page,所以span区域的大小为(512GB/8KB)乘以指针大小8byte = 512M
bitmap区域大小也是通过arena计算出来 , 不过主要用于GC 。
span是用于管理arena页的关键数据结构,每个span中包含1个或多个连续页,为了满足小对象分配,span中的一页会划分更小的粒度,而对于大对象比如超过页大小,则通过多页实现 。
根据对象大小,划分了一系列class,每个class都代表一个固定大小的对象 , 以及每个span的大小 。如下表所示:
上表中每列含义如下:
class: class ID,每个span结构中都有一个class ID, 表示该span可处理的对象类型
bytes/obj:该class代表对象的字节数
bytes/span:每个span占用堆的字节数,也即页数乘以页大小
objects: 每个span可分配的对象个数,也即(bytes/spans)/(bytes/obj)waste
bytes: 每个span产生的内存碎片,也即(bytes/spans)%(bytes/obj)上表可见最大的对象是32K大小,超过32K大小的由特殊的class表示 , 该class ID为0,每个class只包含一个对象 。
span是内存管理的基本单位,每个span用于管理特定的class对象, 跟据对象大小 , span将一个或多个页拆分成多个块进行管理 。src/runtime/mheap.go:mspan定义了其数据结构:
以class 10为例,span和管理的内存如下图所示:
spanclass为10,参照class表可得出npages=1,nelems=56,elemsize为144 。其中startAddr是在span初始化时就指定了某个页的地址 。allocBits指向一个位图,每位代表一个块是否被分配,本例中有两个块已经被分配,其allocCount也为2 。next和prev用于将多个span链接起来,这有利于管理多个span,接下来会进行说明 。
有了管理内存的基本单位span,还要有个数据结构来管理span,这个数据结构叫mcentral , 各线程需要内存时从mcentral管理的span中申请内存,为了避免多线程申请内存时不断的加锁,Golang为每个线程分配了span的缓存,这个缓存即是cache 。src/runtime/mcache.go:mcache定义了cache的数据结构
alloc为mspan的指针数组,数组大小为class总数的2倍 。数组中每个元素代表了一种class类型的span列表,每种class类型都有两组span列表,第一组列表中所表示的对象中包含了指针,第二组列表中所表示的对象不含有指针,这么做是为了提高GC扫描性能,对于不包含指针的span列表,没必要去扫描 。根据对象是否包含指针,将对象分为noscan和scan两类,其中noscan代表没有指针,而scan则代表有指针,需要GC进行扫描 。mcache和span的对应关系如下图所示:
mchache在初始化时是没有任何span的 , 在使用过程中会动态的从central中获取并缓存下来,跟据使用情况,每种class的span个数也不相同 。上图所示,class 0的span数比class1的要多,说明本线程中分配的小对象要多一些 。
cache作为线程的私有资源为单个线程服务,而central则是全局资源,为多个线程服务,当某个线程内存不足时会向central申请 , 当某个线程释放内存时又会回收进central 。src/runtime/mcentral.go:mcentral定义了central数据结构:
lock: 线程间互斥锁,防止多线程读写冲突
spanclass : 每个mcentral管理着一组有相同class的span列表
nonempty: 指还有内存可用的span列表
empty: 指没有内存可用的span列表
nmalloc: 指累计分配的对象个数线程从central获取span步骤如下:
将span归还步骤如下:
从mcentral数据结构可见 , 每个mcentral对象只管理特定的class规格的span 。事实上每种class都会对应一个mcentral,这个mcentral的集合存放于mheap数据结构中 。src/runtime/mheap.go:mheap定义了heap的数据结构:
lock: 互斥锁
spans: 指向spans区域,用于映射span和page的关系
bitmap:bitmap的起始地址
arena_start: arena区域首地址
arena_used: 当前arena已使用区域的最大地址
central: 每种class对应的两个mcentral
从数据结构可见,mheap管理着全部的内存 , 事实上Golang就是通过一个mheap类型的全局变量进行内存管理的 。mheap内存管理示意图如下:
系统预分配的内存分为spans、bitmap、arean三个区域,通过mheap管理起来 。接下来看内存分配过程 。
针对待分配对象的大小不同有不同的分配逻辑:
(0, 16B) 且不包含指针的对象: Tiny分配
(0, 16B) 包含指针的对象:正常分配
[16B, 32KB] : 正常分配
(32KB, -) : 大对象分配其中Tiny分配和大对象分配都属于内存管理的优化范畴 , 这里暂时仅关注一般的分配方法 。
以申请size为n的内存为例,分配步骤如下:
Golang内存分配是个相当复杂的过程,其中还掺杂了GC的处理 , 这里仅仅对其关键数据结构进行了说明,了解其原理而又不至于深陷实现细节 。1、Golang程序启动时申请一大块内存并划分成spans、bitmap、arena区域
2、arena区域按页划分成一个个小块 。
3、span管理一个或多个页 。
4、mcentral管理多个span供线程申请使用
5、mcache作为线程私有资源,资源来源于mcentral 。
Go语言文件操作本文主要介绍了Go语言中文件读写的相关操作 。
文件是什么?
计算机中的文件是存储在外部介质(通常是磁盘)上的数据集合,文件分为文本文件和二进制文件 。
os.Open() 函数能够打开一个文件,返回一个 *File 和一个 err。对得到的文件实例调用 close() 方法能够关闭文件 。
为了防止文件忘记关闭 , 我们通常使用defer注册文件关闭语句 。
Read方法定义如下:
它接收一个字节切片,返回读取的字节数和可能的具体错误,读到文件末尾时会返回 0 和 io.EOF。举个例子:
使用for循环读取文件中的所有数据 。
bufio是在file的基础上封装了一层API,支持更多的功能 。
io/ioutil 包的 ReadFile 方法能够读取完整的文件 , 只需要将文件名作为参数传入 。
os.OpenFile() 函数能够以指定模式打开文件,从而实现文件写入相关功能 。
其中:
name :要打开的文件名flag :打开文件的模式 。模式有以下几种:
perm :文件权限,一个八进制数 。r(读)04,w(写)02,x(执行)01 。
为什么要使用 Go 语言?Go 语言的优势在哪里1. 保留但大幅度简化指针
Go语言保留着C中值和指针的区别go语言读内存,但是对于指针繁琐用法进行了大量的简化,引入引用的概念 。所以在Go语言中,go语言读内存你几乎不用担心会因为直接操作内寸而引起各式各样的错误 。
2. 多参数返回
还记得在C里面为了回馈多个参数 , 不得不开辟几段指针传到目标函数中让其操作么go语言读内存?在Go里面这是完全不必要的 。而且多参数的支持让Go无需使用繁琐的exceptions体系,一个函数可以返回期待的返回值加上error,调用函数后立刻处理错误信息,清晰明了 。
3. Array , slice,map等内置基本数据结构
如果你习惯了Python中简洁的list和dict操作,在Go语言中 , 你不会感到孤单 。一切都是那么熟悉 , 而且更加高效 。如果你是C程序员,你会发现你又找到了STL的vector 和 map这对朋友 。
4. Interface
Go语言最让人赞叹不易的特性,就是interface的设计 。任何数据结构,只要实现了interface所定义的函数,自动就implement了这个interface,没有像Java那样冗长的class申明,提供了灵活太多的设计度和OO抽象度,让你的代码也非常干净 。千万不要以为你习惯了Java那种一条一条加implements的方式,感觉还行,等接口的设计越来越复杂的时候,无数Bug正在后面等着你 。
同时,正因为如此,Go语言的interface可以用来表示任何generic的东西 , 比如一个空的interface , 可以是string可以是int,可以是任何数据类型,因为这些数据类型都不需要实现任何函数,自然就满足空interface的定义了 。加上Go语言的type assertion , 可以提供一般动态语言才有的duck typing特性 , 而仍然能在compile中捕捉明显的错误 。
5. OO
Go语言本质上不是面向对象语言,它还是过程化的 。但是,在Go语言中,你可以很轻易的做大部分你在别的OO语言中能做的事,用更简单清晰的逻辑 。是的,在这里,不需要class , 仍然可以继承,仍然可以多态,但是速度却快得多 。因为本质上,OO在Go语言中,就是普通的struct操作 。
6. Goroutine
这个几乎算是Go语言的招牌特性之一了 , 我也不想多提 。如果你完全不了解Goroutine , 那么你只需要知道 , 这玩意是超级轻量级的类似线程的东西,但通过它,你不需要复杂的线程操作锁操作,不需要care调度,就能玩转基本的并行程序 。在Go语言里,触发一个routine和erlang spawn一样简单 。基本上要掌握Go语言,以Goroutine和channel为核心的内存模型是必须要懂的 。不过请放心 , 真的非常简单 。
7. 更多现代的特性
和C比较 , Go语言完全就是一门现代化语言,原生支持的Unicode, garbage collection, Closures(是的,和functional programming language类似), function是first class object,等等等等 。
看到这里,你可能会发现 , 我用了很多轻易 , 简单,快速之类的形容词来形容Go语言的特点 。我想说的是 , 一点都不夸张,连Go语言的入门学习到提高,都比别的语言门槛低太多太多 。在大部分人都有C的背景的时代,对于Go语言,从入门到能够上手做项目,最多不过半个月 。Go语言给人的感觉就是太直接了,什么都直接 , 读源代码直接 , 写自己的代码也直接 。
【go语言读内存 golang var 内存】go语言读内存的介绍就聊到这里吧,感谢你花时间阅读本站内容,更多关于golang var 内存、go语言读内存的信息别忘了在本站进行查找喔 。

    推荐阅读