十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
数组是一个由 固定长度 的 特定类型元素 组成的序列,一个数组可以由零个或多个元素组成。 数组是值类型
成都创新互联是一家专业提供乾安企业网站建设,专注与成都网站制作、网站设计、H5网站设计、小程序制作等业务。10年已为乾安众多企业、政府机构等服务。创新互联专业网络公司优惠进行中。
数组的每个元素都可以通过索引下标来访问,索引下标的范围是从0开始到数组长度减1的位置,内置函数 len() 可以返回数组中元素的个数。
2.类型的打印,结果的第二种打印方式
3.对元素的修改或者赋值
4.判断数组是否相等:长度、类型
4.数组的地址:连续存储的空间
5.数组的赋值、地址、取值
6.数组的默认值
7.数组的初始化
8.数组的逆置
9.求数组的最大值、最小值、平均值
10.对数组字符串进行连接
11.冒泡排序法的实现
12.数组做函数的参数
13.二维数组:赋值和地址
14.二维数组:打印和输出
15. 指针数组,每一个元素都是地址
17.数组的内存分配
1、首先使用自定义RoundTripper。
2、其次在请求前取出Header里的token,修改body。
3、最后实现动态修改payload,即可修改最大值。
在开始之前,希望你计算一下 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 的内存布局印象和大对象的优化非常有帮