function - 值接收器与指针接收器

Question

我很不清楚在哪种情况下我想使用值接收器而不是总是使用指针接收器。

从文档中回顾一下:

type T struct {
    a int
}
func (tv  T) Mv(a int) int         { return 0 }  // value receiver
func (tp *T) Mp(f float32) float32 { return 1 }  // pointer receiver

文档还说“对于基本类型、 slice 和小型结构等类型，值接收器非常便宜，因此除非方法的语义需要指针，否则值接收器是高效的清晰。”

第一点 他们的文档说值接收器“非常便宜”，但问题是它是否比指针接收器便宜。所以我做了一个小基准(code on gist)这告诉我，即使对于只有一个字符串字段的结构，指针接收器也更快。这些是结果:

// Struct one empty string property
BenchmarkChangePointerReceiver  2000000000               0.36 ns/op
BenchmarkChangeItValueReceiver  500000000                3.62 ns/op


// Struct one zero int property
BenchmarkChangePointerReceiver  2000000000               0.36 ns/op
BenchmarkChangeItValueReceiver  2000000000               0.36 ns/op

(编辑:请注意第二点在较新的 go 版本中无效，请参阅评论。)

第二点 文档说它是一个“高效且清晰”的值(value)接受者，这更像是一个品味问题，不是吗？就我个人而言，我更喜欢通过在所有地方使用相同的东西来保持一致性。什么意义上的效率？在性能方面，似乎指针几乎总是更有效率。很少有具有一个 int 属性的测试运行显示出值接收器的最小优势(范围为 0.01-0.1 ns/op)

有人能告诉我一个值接收器显然比指针接收器更有意义的情况吗？或者我在基准测试中做错了什么？我是否忽略了其他因素？

Answer 1

请注意 the FAQ does mention consistency

Next is consistency. If some of the methods of the type must have pointer receivers, the rest should too, so the method set is consistent regardless of how the type is used. See the section on method sets for details.

如前所述in this thread :

The rule about pointers vs. values for receivers is that value methods canbe invoked on pointers and values, but pointer methods can only be invokedon pointers

这不是真的，因为 commented通过 Sart Simha

Both value receiver and pointer receiver methods can be invoked on a correctly-typed pointer or non-pointer.

Regardless of what the method is called on, within the method body the identifier of the receiver refers to a by-copy value when a value receiver is used, and a pointer when a pointer receiver is used: example.

现在:

Can someone tell me a case where a value receiver clearly makes more sense then a pointer receiver?

Code Review comment可以帮助:

• If the receiver is a map, func or chan, don't use a pointer to it.
• If the receiver is a slice and the method doesn't reslice or reallocate the slice, don't use a pointer to it.
• If the method needs to mutate the receiver, the receiver must be a pointer.
• If the receiver is a struct that contains a sync.Mutex or similar synchronizing field, the receiver must be a pointer to avoid copying.
• If the receiver is a large struct or array, a pointer receiver is more efficient. How large is large? Assume it's equivalent to passing all its elements as arguments to the method. If that feels too large, it's also too large for the receiver.
• Can function or methods, either concurrently or when called from this method, be mutating the receiver? A value type creates a copy of the receiver when the method is invoked, so outside updates will not be applied to this receiver. If changes must be visible in the original receiver, the receiver must be a pointer.
• If the receiver is a struct, array or slice and any of its elements is a pointer to something that might be mutating, prefer a pointer receiver, as it will make the intention more clear to the reader.
• If the receiver is a small array or struct that is naturally a value type (for instance, something like the time.Time type), with no mutable fields and no pointers, or is just a simple basic type such as int or string, a value receiver makes sense.
  A value receiver can reduce the amount of garbage that can be generated; if a value is passed to a value method, an on-stack copy can be used instead of allocating on the heap. (The compiler tries to be smart about avoiding this allocation, but it can't always succeed.) Don't choose a value receiver type for this reason without profiling first.
• Finally, when in doubt, use a pointer receiver.

粗体部分可以在net/http/server.go#Write()中找到:

// Write writes the headers described in h to w.
//
// This method has a value receiver, despite the somewhat large size
// of h, because it prevents an allocation. The escape analysis isn't
// smart enough to realize this function doesn't mutate h.
func (h extraHeader) Write(w *bufio.Writer) {
...
}

---

备注:irbull在 the comments 中指出关于接口(interface)方法的警告:

Following the advice that the receiver type should be consistent, if you have a pointer receiver, then your (p *type) String() string method should also use a pointer receiver.

But this does not implement the Stringer interface, unless the caller of your API also uses pointer to your type, which might be a usability problem of your API.

I don't know if consistency beats usability here.

---

指出:

• "Method Sets (Pointer vs Value Receiver) "

you can mix and match methods with value receivers and methods with pointer receivers, and use them with variables containing values and pointers, without worrying about which is which.
Both will work, and the syntax is the same.

However, if methods with pointer receivers are needed to satisfy an interface, then only a pointer will be assignable to the interface — a value won't be valid.

• "Go interfaces and automatically generated functions "来自 Chris Siebenmann (2017 年 6 月)

Calling value receiver methods through interfaces always creates extra copies of your values.

接口(interface)值基本上是指针，而您的值接收方方法需要值；因此，每次调用都需要 Go 创建该值的新副本，用它调用您的方法，然后丢弃该值。
只要您使用值接收方方法并通过接口(interface)值调用它们，就没有办法避免这种情况；这是 Go 的基本要求。

• “Learning about Go's unaddressable values and slicing ”(来自 Chris(2018 年 9 月)的剧照)

Concept of unaddressable values, which are the opposite of addressable values. The careful technical version is in the Go specification in Address operators, but the hand waving summary version is that most anonymous values are not addressable (one big exception is composite literals)