值部

此篇文章后续的若干文章将介绍Go中更多的类型。为了更容易和更深刻地理解那些类型,最好先阅读一下本文。

Go类型分为两大类别(category)

Go可以被看作是一门C语言血统的语言,这可以通过此前的指针结构体两篇文章得以验证。 Go中的指针和结构体类型和C语言很类似。

另一方面,Go也可以被看作是C语言的一个扩展框架。这可以从C中的值的内存结构都是很透明的,但Go中一些种类的类型的值的内存结构不是很透明这一事实体现出来。 在C中,每个值在内存中只占据一段连续内存。但是,一些Go类型的值可能占据多段连续内存。

每段连续内存均存储着一个值部(value part)。下面这张图描绘了一个含有两个值部的值。

值部

上面的段落描述了两个类别的Go类型。下面将列出这两个类别(category)中的类型(type)种类(kind)。

第一个类别中的类型种类包括:布尔类型、各种数值类型、结构体类型、指针类型、以及后面将要详细解释的数组类型和非类型安全指针类型。 数组类型将在下一片文章中详述。非类型安全指针类型将在此篇文章中详述。 此类别中的类型的值和C值类似,在内存中都只含有一个透明的直接部分。

其它种类的类型均属于第二个类别。此类别中的值在内存中可以包含若干间接部分,并且它们的直接部分是不透明的。 具体说来,这些类型的种类包括:

通过封装了很多具体的实现细节,第二个类别中的类型给Go编程带来了很大的便利。 不同的编译器实现会采用不同的内部结构来实现这些类型,但是这些类型的值的外在表现必须满足Go白皮书中的要求。

第二个类别中的类型将在后续文章中得到详细的解释。

注意:

上面所列出的第二个分类中的类型对于编程来说并非是很基础的类型。 我们可以使用第一个分类中的类型来实现第二个分类中的类型。 但是,通过将一些常用或者很独特的功能封装到第二个分类中的类型里,使用Go编程的效率将得到大大提升,体验将得到大大增强。

另一方面,这些封装同时也隐藏了这些类型的值的内部结构,使得Go程序员不能对这些类型有一个更全局更深刻的认识。有时候这会对更好地理解Go带来了一些障碍。

为了帮助Go程序员更好的理解第二个分类中的类型和它们的值,本文余下的内容将对这些类型的内在实现做一个简单介绍。 这些实现的细节将不会在本文中谈及。本文的介绍主要基于(但并不完全符合)官方标准编译器的实现。

Go中的两种指针类型

在继续下面的内容之前,我们先了解一下Go中的两种指针类型并明确一下“引用”这个词的含义。

我们已经在上上篇文章中了解了Go中的指针。 那篇文章中所介绍的指针属于类型安全的指针。事实上,Go还支持另一种称为非类型安全的指针类型。 非类型安全的指针类型提供在unsafe标准库包中。 非类型安全指针类型通常使用unsafe.Pointer来表示。 unsafe.Pointer类似于C语言中的void*。 底层类型为unsafe.Pointer类型都是非类型安全指针类型。

在《Go语言101》中的大多数文章中,如果没有特别说明,当一个指针类型被谈及,它表示一个类型安全指针。 但是在本文的余下内容中,当一个指针被谈及,它表示一个任意指针类型,包括类型安全的和非类型安全的。

一个指针值存储着另一个值的地址,除非此指针值是一个nil空指针。 我们可以说此指针引用着另外一个值,或者另外一个值被此指针所引用。 一个值可能被间接引用,比如

以后,我们将一个含有(直接或者间接)指针字段的结构体类型称为一个指针包裹类型,将一个含有(直接或者间接)指针的类型称为指针持有者类型。 指针类型和指针包裹类型都属于指针持有者类型。元素类型为指针持有者类型的数组类型也是指针持有者类型(数组将在下一篇文章中介绍)。

第二个分类中的类型的(可能的)内部实现结构定义

下面是第二个分类中的类型的可能的内部定义。

映射、通道和函数类型的内部定义

映射、通道和函数类型的内部定义很相似:
// 映射类型
type _map *hashtableImpl // 目前,官方标准编译器是使用
                         // 哈希表来实现映射的。

// 通道类型
type _channel *channelImpl

// 函数类型
type _function *functionImpl

从这些定义,我们可以看出来,这三个种类的类型的内部结构其实是一个指针类型。 或者说,这些类型的值的直接部分在内部是一个指针。 这些类型的每个值的直接部分引用着它的具体实现的底层间接部分。

切片类型的内部定义

切片类型的内部定义:
type _slice struct {
	elements unsafe.Pointer // 引用着底层的元素
	len      int            // 当前的元素个数
	cap      int            // 切片的容量
}

从这个定义可以看出来,一个切片类型在内部可以看作是一个指针包裹类型。 每个非零切片值包含着一个底层间接部分用来存储此切片的元素。 一个切片值的底层元素序列(间接部分)被此切片值的elements字段所引用。

字符串类型的内部结构

type _string struct {
	elements *byte // 引用着底层的byte元素
	len      int   // 字符串的长度
}

从此定义可以看出,每个字符串类型在内部也可以看作是一个指针包裹类型。 每个非零字符串值含有一个指针字段 elements。 这个指针字段引用着此字符串值的底层字节元素序列。

接口类型的内部定义

我们可以认为接口类型在内部是如下定义的:
type _interface struct {
	dynamicType  *_type         // 引用着接口值的动态类型
	dynamicValue unsafe.Pointer // 引用着接口值的动态值
}

从这个定义来看,接口类型也可以看作是一个指针包裹类型。一个接口类型含有两个指针字段。 每个非零接口值的(两个)间接部分分别存储着此接口值的动态类型和动态值。 这两个间接部分被此接口值的直接字段dynamicTypedynamicValue所引用。

事实上,上面这个内部定义只用于表示空接口类型的值。空接口类型没有指定任何方法。 后面的接口一文详细解释了接口类型和值。 非空接口类型的内部定义如下:
type _interface struct {
	dynamicTypeInfo *struct {
		dynamicType *_type       // 引用着接口值的动态类型
		methods     []*_function // 引用着动态类型的对应方法列表
	}
	dynamicValue unsafe.Pointer // 引用着动态值
}

一个非空接口类型的值的dynamicTypeInfo字段的methods字段引用着一个方法列表。 此列表中的每一项为此接口值的动态类型上定义的一个方法,此方法对应着此接口类型所指定的一个的同原型的方法。

在赋值中,底层间接值部将不会被复制

现在我们了解了第二个分类中的类型的内部结构是一个指针或者指针包裹类型。 当然,Go编译器不会把用户代码中的这些类型的值视为指针或者结构体值。 这些定义只用于Go运行时(runtime)的实现。

在Go中,每个赋值操作(包括函数调用传参等)都是一个值的浅复制过程(假设源值和目标值的类型相同)。 换句话说,在一个赋值操作中,只有源值的直接部分被复制给了目标值。 如果源值含有间接部分,则在此赋值操作完成之后,目标值和源值的直接部分将引用着相同的间接部分。 换句话说,两个值将共享底层的间接值部,如下图所示:

值复制

事实上,对于字符串值和接口值的赋值,上述描述在理论上并非百分百正确。 官方FAQ明确说明了在一个接口值的赋值中,接口的底层动态值将被复制到目标值。 但是,因为一个接口值的动态值是只读的,所以在接口值的赋值中,官方标准编译器并没有复制底层的动态值。这可以被视为是一个编译器优化。 对于字符串值的赋值,道理是一样的。所以对于官方标准编译器来说,上一段的描述是100%正确的。

因为一个间接值部可能并不专属于任何一个值,所以在使用unsafe.Sizeof函数计算一个值的尺寸的时候,此值的间接部分所占内存空间未被计算在内。

关于术语“引用类型”和“引用值”

“引用”这个术语在Go社区中使用得有些混乱。很多Go程序员在Go编程中可能由此产生了一些困惑。 一些文档或者网络文章,包括一些官方文档,把“引用”(reference)看作是“值”(value)的一个对立面。 《Go语言101》强烈不推荐这种定义。在这一点上,本人不想争论什么。这里仅仅列出一些肯定错误地使用了“引用”这个术语的例子:

我并不是想说引用类型这个术语在Go中是完全没有价值的, 我只是想表达这个术语是完全没有必要的,并且它常常在Go的使用中导致一些困惑。我推荐使用指针持有者类型来代替这个术语。 另外,我个人的观点是最好将引用这个词限定到只表示值之间的关系,把它当作一个动词或者名词来使用,永远不要把它当作一个形容词来使用。 这样将在使用Go的过程中避免很多困惑。

Go语言101项目目前同时托管在GithubGitlab上。 欢迎各位在这两个项目中通过提交bug和PR的方式来改进完善Go语言101中的各篇文章。

本书微信公众号名称为"Go 101"。每个工作日此公众号将尽量发表一篇和Go语言相关的原创短文。各位如果感兴趣,可以搜索关注一下。

赞赏