锐客网

  1. 首页 > 生活百科 > it技术 > >

go语言unsafe性能 go语言nil

数组IT技术

Go语言中恰到好处的内存对齐 在开始之前go语言unsafe性能，希望go语言unsafe性能你计算一下Part1共占用的大小是多少呢？
输出结果：
这么一算go语言unsafe性能，Part1这一个结构体的占用内存大小为 1 4 1 8 1 = 15 个字节 。相信有的小伙伴是这么算的，看上去也没什么毛病
真实情况是怎么样的呢？go语言unsafe性能我们实际调用看看，如下：
输出结果：
最终输出为占用 32 个字节 。这与前面所预期的结果完全不一样 。这充分地说明了先前的计算方式是错误的 。为什么呢？
在这里要提到 “内存对齐” 这一概念 ， 才能够用正确的姿势去计算，接下来go语言unsafe性能我们详细的讲讲它是什么
有的小伙伴可能会认为内存读?。?就是一个简单的字节数组摆放
上图表示一个坑一个萝卜的内存读取方式 。但实际上 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
【go语言unsafe性能 go语言nil】 通过本节的分析 ， 可得知先前的 “推算” 为什么错误？
是因为实际内存管理并非 “一个萝卜一个坑” 的思想 。而是一块一块 。通过空间换时间（效率）的思想来完成这块读取、写入 。另外也需要兼顾不同平台的内存操作情况
在上一小节，可得知根据成员变量的类型不同，其结构体的内存会产生对齐等动作 。那假设字段顺序不同，会不会有什么变化呢？我们一起来试试吧 :-)
输出结果：
通过结果可以惊喜的发现，只是 “简单” 对成员变量的字段顺序进行改变，就改变了结构体占用大小
接下来我们一起剖析一下Part2 ，看看它的内部到底和上一位之间有什么区别，才导致了这样的结果？
符合规则 2，不需要额外对齐
Part2 内存布局：ecax|bbbb|dddd|dddd
通过对比Part1和Part2的内存布局，你会发现两者有很大的不同 。如下：
仔细一看 ， Part1存在许多 Padding 。显然它占据了不少空间，那么 Padding 是怎么出现的呢？
通过本文的介绍，可得知是由于不同类型导致需要进行字节对齐，以此保证内存的访问边界
那么也不难理解，为什么 调整结构体内成员变量的字段顺序 就能达到缩小结构体占用大小的疑问了，是因为巧妙地减少了 Padding 的存在 。让它们更 “紧凑” 了 。这一点对于加深 Go 的内存布局印象和大对象的优化非常有帮
Go切片数组深度解析Go 中的分片数组，实际上有点类似于Java中的ArrayList,是一个可以扩展的数组，但是Go中的切片由比较灵活，它和数组很像，也是基于数组 ， 所以在了解Go切片前我们先了解下数组 。
数组简单描述就由相同类型元素组成的数据结构, 在创建初期就确定了长度，是不可变的 。
但是Go的数组类型又和C与Java的数组类型不一样，NewArray 用于创建一个数组 ， 从源码中可以看出最后返回的是 Array{}的指针，并不是第一个元素的指针，在Go中数组属于值类型 ， 在进行传递时，采取的是值传递，通过拷贝整个数组 。Go语言的数组是一种有序的struct 。
Go 语言的数组有两种不同的创建方式 ， 一种是显示的初始化，一种是隐式的初始化 。
注意一定是使用 [...]T 进行创建，使用三个点的隐式创建，编译器会对数组的大小进行推导，只是Go提供的一种语法糖 。
其次，Go中数组的类型 ， 是由数值类型和长度两个一起确定的 。[2]int 和 [3]int 不是同一个类型，不能进行传参和比较，把数组理解为类型和长度两个属性的结构体 ， 其实就一目了然了 。
Go中的数组属于值类型，通常应该存储于栈中，局部变量依然会根据逃逸分析确定存储栈还是堆中 。
编译器对数组函数中做两种不同的优化：
在静态区完成赋值后复制到栈中 。
总结起来，在不考虑逃逸分析的情况下 ， 如果数组中元素的个数小于或者等于 4 个，那么所有的变量会直接在栈上初始化，如果数组元素大于 4 个，变量就会在静态存储区初始化然后拷贝到栈上 。
由于数组是值类型，那么赋值和函数传参操作都会复制整个数组数据 。
不管是赋值或函数传参 ， 地址都不一致，发生了拷贝 。如果数组的数据较大，则会消耗掉大量内存 。那么为了减少拷贝我们可以主动的传递指针呀 。
地址是一样的 ， 不过传指针会有一个弊端，从打印结果可以看到，指针地址都是同一个，万一原数组的指针指向更改了，那么函数里面的指针指向都会跟着更改 。
同样的我们将数组转换为切片，通过传递切片 ， 地址是不一样的，数组值相同 。
切片是引用传递，所以它们不需要使用额外的内存并且比使用数组更有效率 。
所以，切片属于引用类型 。
通过这种方式可以将数组转换为切片 。
中间不加三个点就是切片,使用这种方式创建切片，实际上是先创建数组 ， 然后再通过第一种方式创建 。
使用make创建切片，就不光编译期了，make创建切片会涉及到运行期 。1. 切片的大小和容量是否足够?。?
切片是否发生了逃逸，最终在堆上初始化 。如果切片小的话会先在栈或静态区进行创建 。
切片有一个数组的指针，len是指切片的长度, cap指的是切片的容量 。
cap是在初始化切片是生成的容量 。
发现切片的结构体是数组的地址指针array unsafe.Pointer，而Go中数组的地址代表数组结构体的地址 。
slice 中得到一块内存地址 ， array[0]或者unsafe.Pointer(array[0]) 。
也可以通过地址构造切片
nil切片：指的unsafe.Pointer 为nil
空切片：
创建的指针不为空，len和cap为空
当一个切片的容量满了，就需要扩容了 。怎么扩，策略是什么？
如果原来数组切片的容量已经达到了最大值，再想扩容，Go 默认会先开一片内存区域，把原来的值拷贝过来，然后再执行 append() 操作 。这种情况对现数组的地址和原数组地址不相同 。
从上面结果我们可以看到，如果用 range 的方式去遍历一个切片，拿到的 Value 其实是切片里面的值拷贝,即浅拷贝 。所以每次打印 Value 的地址都不变 。
由于 Value 是值拷贝的，并非引用传递，所以直接改 Value 是达不到更改原切片值的目的的，需要通过 slice[index] 获取真实的地址 。
Rust 和 Go,哪个性能更好？要说性能，那是Rust更好 。更多的编译期优化、无 GC 等特点加持，开发高性能应用自然是 Rust 性能高 。据统计利用 Rust 开发的 RipGrep 性能甚至赛过使用 C 开发的 Grep 。
但是性能不是唯一考量，当你纠结 Borrow Check，纠结 unsafe，纠结 copy clone ， 纠结各种奇怪的类型限制的时候；当你 cargo build 怒草电脑风扇三分钟的时候；人家 GoLang 可能早就发两个版了 。
同时 Rust 的语法花活众多，遍历数组可以写循环也可以 for_each() 一行流 。不像 GoLang 那么白开水谁写都差不多一个味道，经常第一天想到神来之笔快乐 Coding 到半夜第二天爬起来发现昨晚写的都甚么东西看不懂不如蜘蛛爬，这是坠痛苦的！
Go 的编译器为了个编译速度快连循环不变式提升、循环展开、对齐等等优化一个都不做，函数内敛一堆限制大多数情况都不做（比如函数里有个 for 或者 defer 或者 select 等，或者函数多于 40 个表达式），拥有的优化一只手都能数的过来：
基础优化欠缺 ， 高级优化更是一个没有，和在 Debug 配置编译下的 -O0 优化的 C差不多一个概念（而且跑得更慢），哪来的资本和 rust 比性能 。
其他方面：
而且 Go 的 GC 吞吐量也很低，大多数情况下各方面 Go 跑的甚至都比 Java 更慢 。只不过得益于 AOT 编译的设计，相比 Java 而言除了内存占用小和启动速度快之外就没有任何优势了，比较适合拿来做性能不关键的命令行工具 。
个人还是更喜欢 Rust 。
关于go语言unsafe性能和go语言nil的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站 。

    推荐阅读


    上一篇：mysql日期类型比较大小 mysql日期字符串怎么比较大小

    下一篇：阿里云云服务器退款 阿里云服务器怎么退回