前言

本篇译文对应的原文

标题：Pointers and Allocation - Go Frequently Asked Questions(FAQ)

yoko备注

目录

  • 函数参数什么时候按值传递？
  • 方法定义在值类型上还是指针类型上？
  • new和make有什么区别？
  • int类型在64位系统上大小是多少？
  • 我如何知道一个变量是分配在堆上还是栈上？
  • 为什么我的golang进程占用了很多虚拟内存？
  • TODO
    • 什么时候需要使用指向interface的指针？

函数参数什么时候按值传递？

和所有的 c语言 家族的语言一样，golang中的所有东西都是按值传递。也就是说，函数总是获取到所传递实参的拷贝，就像有赋值语句把值传递给参数。比如说，传递一个int值给一个函数会拷贝这个int值，传递一个指针值也给拷贝这个指针，但不是拷贝指针所指向的数据。

map和slice类型的行为和指针类似：它们是包含了指向底层map和slice数据的描述符。拷贝map或slice时并不会拷贝它指向的数据。拷贝一个interface会拷贝interface存储的数据。如果interface存储的是一个结构体，拷贝这个interface会拷贝这个结构体。如果interface存储的是一个指针。拷贝这个interface会拷贝这个指针，但是同样的，不会拷贝它指向的数据。

方法定义在值类型上还是指针类型上？

func (s *MyStruct) pointerMethod() { } // method on pointer
func (s MyStruct)  valueMethod()   { } // method on value

对于不熟悉指针的开发者，对这两个例子的区别可能有些困惑，但是实际情况其实十分简单。当在一个类型上定义一个方法时，接收者（上面例子中的s）的行为完全和将这个接收者作为这个方法的参数是一样的。考虑把接收者定义为值类型或指针类型，和把函数的参数定义为值类型或指针类型是一样的。有以下几点需要考虑。

pointerMethodvalueMethod

随便说一句，java中方法的接收者总是使用指针类型，虽然它们的指针本质上有些伪装（有一个提案是往 java 中添加值类型接收者）。golang中的值类型接收者是少见的。

第二点是考虑效率。如果接收者比较大，比如说一个大结构体，使用指针类型接收者代价会更小些。

接下来考虑一致性。如果有的方法的接收者类型必须为指针类型，那么其余方法也应该使用指针类型，使得方法集合是一致的，无论实际使用的调用类型是值类型还是指针类型。

对于基础类型，slice，小结构体这些类型，值类型接收者的代价是很低的，所以除非方法从语义上需要指针类型接收者，那么使用值类型接收者是高效且清晰的。

yoko备注
英文原文在说明一致性，方法集合时，引用FAQ中另外一个章节的内容：
https://golang.org/doc/faq#different_method_sets
我个人的理解是，
当方法定义为值类型接收者时，那么只能使用值类型调用
当方法定义为指针类型接收者时，那么不但能使用指针类型调用，还能使用值类型调用

如果已经有方法定义为指针类型接收者了，那么为了保持一致，其余的方法应该都定义为指针类型接收者
不然会造成指针类型的对象有的方法能调，有的不行

并且指针类型可以在方法内解引用得到实体对象
但是值类型由于要保持方法内修改对象对外不可见，那么在方法内获取对象的地址是不安全的

new和make有什么区别？

简单来说：new分配内存，而make用来初始化slice，map，channel这三个类型。

int类型在64位系统上大小是多少？

int和uint的大小是具体实现相关的，但是在一个指定的平台上它们是相等。为了可移植性，依赖特定大小的值的代码应该使用显式大小的类型，比如int64。在32位系统编译器默认使用32位整型，在64位系统整型使用64位（从历史来看，也不总是这样）。

foo := 3.0
var foo float32 = 3.0
foo := float32(3.0)

我如何知道一个变量是分配在堆上还是栈上？

从正确性角度来说，你不需要知道一个变量是分配在堆上还是栈上。golang中的每个变量，只要还有引用，生命周期就会一直持续。golang选择变量存储在何位置的具体实现是不影响golang的语言语义的。

变量存储位置对编写高效程序是有影响的。如果可能的话，golang编译器会将函数的局部变量分配在函数的栈空间上。然后，如果编译器不能证明这个变量在函数返回后不会被引用，那么编译器必须将这个变量分配在带垃圾回收机制的堆上以避免出现野指针错误。并且，如果一个局部变量特别大，把它分配在堆上可能会比分配在栈上更好些。

在当前的编译器中，如果一个变量的地址被获取，那么这个变量可能会分配在堆上。然而，一个基础的逃逸分析可以识别出一些变量在函数返回后不再存活的场景，那么这种变量会继续保存在栈上。

为什么我的golang进程占用了很多虚拟内存？

golang的内存分配器预申请了一大块虚拟内存区域用于后续内存申请。这个虚拟内存是和具体的golang进程关联的；这个预分配行为不会剥夺其它进程的内存。

如果想知道一个golang进程的实际内存申请大小，使用Unix的top命令并观察RES（linux平台）或者RSIZE（macos平台）。

TODO

什么时候需要使用指向interface的指针？

yoko备注
什么时候需要使用指向interface的指针？

这一小节翻译的不好，建议阅读英文原文。
对本小节的临时翻译我也贴在本文末尾处了。

针对这个问题的答案是，不要使用指向interface的指针。

个人感觉它所表达的内容有两点：
第一点是，一个实际类型只要实现了一个interface的接口，
那么这个实际类型的值或者这个实际类型的指针都能够被这个interface接收。

第二点是，不要使用指向interface的指针（注意，并不是第一点中说的指向实际类型的指针，要区分开），
interface并不能接收指向该interface的指针，编译会报错。

几乎永远不要使用。指向interface的指针只出现在罕见的情况，它掩盖了interface值的类型用于延时取值。

一个常见的错误是传递一个指向interface值的指针给一个需要interface参数的函数。编译器会对此报错，但是这种情况仍然让人困惑，因为有时候指针需要满足interface。尽管一个指向具体类型的指针可以满足interface，但是有一种例外是一个指向interface的指针无法满足一个interface。

考虑以下变量声明

var w io.Writer
fmt.Fprintf
fmt.Fprintf(w, "hello, world\n")

然而如果我们传递w的地址，程序将编译失败。

fmt.Fprintf(&w, "hello, world\n") // Compile-time error.
interface{}