【问题标题】:Pointers vs. values in parameters and return values指针与参数和返回值中的值
【发布时间】:2014-06-25 22:00:52
【问题描述】:

在 Go 中有多种方法可以返回 struct 值或其切片。对于我见过的个人:

type MyStruct struct {
    Val int
}

func myfunc() MyStruct {
    return MyStruct{Val: 1}
}

func myfunc() *MyStruct {
    return &MyStruct{}
}

func myfunc(s *MyStruct) {
    s.Val = 1
}

我了解这些之间的区别。第一个返回结构的副本,第二个是指向函数内创建的结构值的指针,第三个期望传入现有的结构并覆盖该值。

我已经看到所有这些模式都在各种情况下使用,我想知道关于这些的最佳实践是什么。你什么时候用哪个?例如,第一个可能适用于小型结构(因为开销很小),第二个适用于较大的结构。第三个,如果你想非常节省内存,因为你可以很容易地在调用之间重用单个结构实例。有什么最佳实践来说明何时使用哪个?

同样,关于切片的同样问题:

func myfunc() []MyStruct {
    return []MyStruct{ MyStruct{Val: 1} }
}

func myfunc() []*MyStruct {
    return []MyStruct{ &MyStruct{Val: 1} }
}

func myfunc(s *[]MyStruct) {
    *s = []MyStruct{ MyStruct{Val: 1} }
}

func myfunc(s *[]*MyStruct) {
    *s = []MyStruct{ &MyStruct{Val: 1} }
}

再次重申:这里的最佳做法是什么。我知道切片始终是指针,因此返回指向切片的指针没有用。但是,我是否应该返回一个结构值切片、一个指向结构的指针切片,我应该将一个指向切片的指针作为参数传递(Go App Engine API 中使用的模式)?

【问题讨论】:

  • 正如你所说,这真的取决于用例。根据情况所有都有效 - 这是一个可变对象吗?我们想要一个副本还是指针?等等。顺便说一句,您没有提到使用new(MyStruct) :) 但是分配指针和返回指针的不同方法之间并没有真正的区别。
  • 这简直就是过度工程。结构必须非常大,才能返回指针使您的程序更快。只是不要打扰,编码,配置文件,如果有用就修复。
  • 返回值或指针的方式只有一种,即返回值或指针。如何分配它们是一个单独的问题。使用适合您情况的方法,并在担心之前编写一些代码。
  • 顺便说一句,出于好奇,我对此进行了基准测试。返回结构与指针的速度似乎大致相同,但是将指针传递给函数的速度要快得多。虽然不在一个水平上,但这很重要
  • @Not_a_Golfer:我认为这只是 bc 分配是在函数之外完成的。基准值与指针的基准测试还取决于结构的大小和事后的内存访问模式。复制缓存行大小的东西是尽可能快的,并且从 CPU 缓存中解引用指针的速度与从主内存中解引用它们的速度大不相同。

标签: pointers go


【解决方案1】:

tl;dr

  • 使用接收器指针的方法很常见; the rule of thumb for receivers is, "如有疑问,请使用指针。"
  • 切片、映射、通道、字符串、函数值和接口值在内部使用指针实现,指向它们的指针通常是多余的。
  • 在其他地方,对大结构或必须更改的结构使用指针,否则 pass values,因为通过指针意外更改内容会令人困惑。

你应该经常使用指针的一种情况:

  • 接收者比其他参数更常见。方法修改它们被调用的东西,或者命名类型是大型结构并不罕见,因此the guidance is 默认为指针,除非在极少数情况下。
    • Jeff Hodges 的copyfighter 工具自动搜索按值传递的非微小接收器。

一些不需要指针的情况:

  • 代码审查指南建议传递像type Point struct { latitude, longitude float64 } 这样的小型结构,甚至可能更大一些的东西作为值,除非您调用的函数需要能够就地修改它们。

    • 值语义可避免出现别名情况,即此处的赋值意外地更改了此处的值。
    • 为了一点点速度而牺牲干净的语义并不容易,有时按值传递小结构实际上更有效,因为它避免了cache misses 或堆分配。
    • 因此,Go Wiki 的 code review comments 页面建议在结构较小且可能保持这种方式时按值传递。
    • 如果“大”截止值看起来很模糊,那就是;可以说,许多结构都在一个指针或值都可以的范围内。作为下限,代码审查 cmets 建议将切片(三个机器字)用作值接收器是合理的。作为更接近上限的东西,bytes.Replace 需要 10 个单词的 args(三个切片和一个 int)。您可以找到situations,即使复制大型结构也能获得性能优势,但经验法则并非如此。
  • 对于切片,您不需要传递指针来更改数组的元素。例如,io.Reader.Read(p []byte) 更改了 p 的字节。这可以说是“将小结构视为值”的一种特殊情况,因为在内部,您正在传递一个称为 slice header 的小结构(请参阅Russ Cox (rsc)'s explanation)。同样,您不需要指针来修改地图或在频道上通信

  • 对于您将重新切片的切片(更改开始/长度/容量),append 等内置函数接受切片值并返回一个新值。我会模仿那个;它避免了别名,返回一个新切片有助于提醒人们注意可能分配一个新数组的事实,并且调用者很熟悉。

    • 遵循这种模式并不总是可行的。像database interfacesserializers 这样的一些工具需要附加到在编译时类型未知的切片。它们有时会在 interface{} 参数中接受指向切片的指针。
  • 映射、通道、字符串以及函数和接口值,就像切片一样,是内部引用或已经包含引用的结构,所以如果您只是想避免复制底层数据,您不需要将指针传递给它们。 (rsc wrote a separate post on how interface values are stored)。

    • 在极少数情况下,您可能仍需要传递指针以修改调用者的结构:例如,flag.StringVar 采用 *string

你在哪里使用指针:

  • 考虑你的函数是否应该是你需要指针指向的任何结构的方法。人们期望x 上有很多方法可以修改x,因此将修改后的结构设置为接收器可能有助于减少意外。当接收者应该是指针时,有guidelines

  • 对其非接收者参数有影响的函数应该在 godoc 中明确说明,或者更好的是,在 godoc 和名称中明确说明(如 reader.WriteTo(writer))。

  • 您提到通过允许重用来接受指针以避免分配;为了内存重用而更改 API 是一种优化,我会延迟直到明确分配具有不平凡的成本,然后我会寻找一种不会将更棘手的 API 强加给所有用户的方法:

    1. 为了避免分配,Go 的escape analysis 是你的朋友。您有时可以通过创建可以使用普通构造函数、普通文字或有用的零值(如bytes.Buffer)初始化的类型来帮助它避免堆分配。
    2. 考虑使用Reset() 方法将对象重新置于空白状态,就像某些stdlib 类型提供的那样。不关心或无法保存分配的用户不必调用它。
    3. 考虑将 modify-in-place 方法和 create-from-scratch 函数编写为匹配对,为方便起见:existingUser.LoadFromJSON(json []byte) error 可以被 NewUserFromJSON(json []byte) (*User, error) 包装。同样,它将懒惰和挤压分配之间的选择推给了单个调用者。
    4. 寻求回收内存的调用者可以让sync.Pool处理一些细节。如果一个特定的分配造成了很大的内存压力,你确信你知道什么时候不再使用分配,并且你没有更好的优化可用,sync.Pool 可以提供帮助。 (CloudFlare 发布了 a useful (pre-sync.Pool) blog post 关于回收的信息。)

最后,关于你的切片是否应该是指针:值切片可能很有用,并且可以节省分配和缓存未命中。可能有拦截器:

  • 创建项目的 API 可能会强制指向您,例如您必须调用 NewFoo() *Foo 而不是让 Go 使用 zero value 进行初始化。
  • 项目所需的生命周期可能并不完全相同。整个切片立即释放;如果 99% 的项不再有用,但您有指向其他 1% 的指针,则所有数组都保持分配状态。
  • 移动值可能会导致性能或正确性问题,从而使指针更具吸引力。值得注意的是,appendgrows the underlying array 时复制项目。在 append 之前获得的指针指向错误的位置,对于巨大的结构,复制可能会更慢,例如sync.Mutex 不允许复制。在中间插入/删除和排序类似地移动项目。

一般来说,如果您将所有项目都放在前面并且不移动它们(例如,在初始设置后不再有appends),或者如果您确实继续移动它们,那么值切片是有意义的但你确定没关系(不/小心使用指向项目的指针,项目足够小以有效复制等)。有时您必须考虑或衡量您的具体情况,但这是一个粗略的指导。

【讨论】:

  • 什么是大结构?有大结构和小结构的例子吗?
  • 你怎么知道 bytes.Replace 在 amd64 上需要 80 个字节的参数?
  • 签名为Replace(s, old, new []byte, n int) []byte; s、old 和 new 各为三个字(slice headers are (ptr, len, cap)),n int 为一个字,所以 10 个字,即 8 个字节/字为 80 个字节。
  • 如何定义大结构?有多大?
  • @AndyAldo 我的所有来源(代码审查 cmets 等)都没有定义阈值,所以我决定说这是一个判断调用,而不是设置阈值。三个单词(如切片)一直被视为有资格成为标准库中的值。我刚刚找到了一个五字值接收器的实例(text/scanner.Position),但我不会读太多(它也是作为指针传递的!)。没有基准等,我只会做任何看起来最便于阅读的事情。
【解决方案2】:

您希望将方法接收器用作指针的三个主要原因:

  1. “首先,也是最重要的,该方法是否需要修改接收器?如果需要,接收器必须是一个指针。”

  2. “其次是效率的考虑。如果receiver很大,比如一个大的struct,使用指针receiver会便宜很多。”

  3. “接下来是一致性。如果该类型的某些方法必须有指针接收器,其余的也应该有,因此无论类型如何使用,方法集都是一致的”

参考:https://golang.org/doc/faq#methods_on_values_or_pointers

编辑:另一件重要的事情是了解您发送到函数的实际“类型”。类型可以是“值类型”或“引用类型”。

即使切片和映射充当引用,我们也可能希望在更改函数中切片长度等场景中将它们作为指针传递。

【讨论】:

  • 对于 2,截止点是多少?我怎么知道我的结构是大还是小?另外,是否有一个足够小的结构,使得使用值而不是指针更有效地(这样就不必从堆中引用它)?
  • 我想说的字段和/或嵌套结构的数量越多,结构就越大。我不确定是否有特定的截止或标准方法可以知道何时可以将结构称为“大”或“大”。如果我正在使用或创建一个结构,我会根据我上面所说的知道它的大小。但这只是我!。
【解决方案3】:

如果可以(例如,不需要作为引用传递的非共享资源),请使用值。原因如下:

  1. 您的代码将更美观、更易读,避免使用指针运算符和空值检查。
  2. 您的代码将更安全地防止空指针恐慌。
  3. 您的代码通常会更快:是的,更快!为什么?

原因 1:您将在堆中分配更少的项目。从堆栈分配/解除分配是立即的,但在堆上分配/解除分配可能非常昂贵(分配时间+垃圾收集)。你可以在这里看到一些基本的数字:http://www.macias.info/entry/201802102230_go_values_vs_references.md

原因 2:特别是如果您将返回值存储在切片中,您的内存对象将在内存中更加紧凑:循环一个所有项目都是连续的切片比迭代一个所有项目都连续的切片要快得多这些项目是指向内存其他部分的指针。不是为了间接步骤,而是为了增加缓存未命中。

神话打破:典型的 x86 缓存行是 64 字节。大多数结构都比这小。在内存中复制一条缓存线的时间和复制一个指针的时间差不多。

仅当代码的关键部分运行缓慢时,我才会尝试进行一些微优化并检查使用指针是否会在一定程度上提高速度,但代价是可读性和可维护性降低。

【讨论】:

  • >原因 1:您将在堆栈中分配更少的项目。您的意思是您将在 heap 中分配更少的项目?
  • 是的,谢谢指正!
  • 谢谢。这是第一个提到堆/堆栈的答案,这是一个很大的区别。
【解决方案4】:

您通常需要返回指针的情况是在构造一些有状态或可共享资源的实例。这通常由前缀为 New 的函数完成。

因为它们代表某物的特定实例并且它们可能需要协调某些活动,所以生成代表相同资源的重复/复制结构没有多大意义——因此返回的指针充当句柄资源本身。

一些例子:

在其他情况下,返回指针只是因为默认情况下结构可能太大而无法复制:


另外,可以通过返回内部包含指针的结构的副本来避免直接返回指针,但这可能不被认为是惯用的:

【讨论】:

  • 此分析中隐含的是,默认情况下,结构是按按值复制的(但不一定是它们的间接成员)。
【解决方案5】:

关于struct vs.pointer return value,我在github上阅读了许多备受瞩目的开源项目后感到困惑,因为这两种情况都有很多例子,我发现了这篇惊人的文章: https://www.ardanlabs.com/blog/2014/12/using-pointers-in-go.html

“一般来说,除非结构类型已被实现为表现得像原始数据值一样,否则与指针共享结构类型值。

如果您仍然不确定,这是另一种思考方式。将每个结构都视为具有性质。如果结构的性质是不应更改的,例如时间、颜色或坐标,则将该结构实现为原始数据值。如果结构的性质是可以更改的,即使它从未出现在您的程序中,它也不是原始数据值,应该实现为与指针共享。不要创建具有二元性的结构。”

完全相信。

【讨论】:

    猜你喜欢
    • 2018-05-30
    • 2015-11-19
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2017-09-05
    • 1970-01-01
    • 2014-08-16
    相关资源
    最近更新 更多