Go内存消耗管理

Question

Go内存消耗管理

memory-managementgomemory-consumption

25

我刚接触Go语言，正在尝试弄清楚它如何管理内存消耗。

我在一个测试项目中遇到了内存问题。当我的程序运行了很长时间后，我不明白为什么Go会越来越多地使用内存（从未释放它）。

我正在运行下面提供的测试用例。第一次分配后，程序使用了近350MB的内存（根据ActivityMonitor）。然后我尝试释放它，ActivityMonitor显示内存消耗翻倍。为什么？

我正在使用Go 1.0.3在OS X上运行此代码。

这段代码有什么问题？在Go程序中管理大型变量的正确方式是什么？

我在实现一个使用大量时间和内存的算法时遇到了另一个与内存管理相关的问题；在运行一段时间后，它会抛出一个“内存不足”的异常。

package main

import ("fmt" 
"time"
)

func main() {
  fmt.Println("getting memory")
  tmp := make([]uint32, 100000000)
  for kk, _ := range tmp {
    tmp[kk] = 0
  }
  time.Sleep(5 * time.Second)
  fmt.Println("returning memory")
  tmp = make([]uint32, 1)
  tmp = nil
  time.Sleep(5 * time.Second)
  fmt.Println("getting memory")
  tmp = make([]uint32, 100000000)
  for kk, _ := range tmp {
    tmp[kk] = 0
  }
  time.Sleep(5 * time.Second)
  fmt.Println("returning memory")
  tmp = make([]uint32, 1)
  tmp = nil
  time.Sleep(5 * time.Second)  
  return
}

- duganets

1

这是一篇关于Go语言内存管理的好文章链接：http://lwn.net/Articles/428100/。 - OlliP

1

我正在OSx上运行这段代码，使用的是go1.0.3。如果您需要使用Go tip（即将成为1.1）进行一些占用内存较大的操作，强烈建议使用它。起初我有些犹豫，但在几位Go开发者推荐后，它对于我来说比1.0.3更稳定，特别是在内存使用方面。 - voidlogic

2个回答

15

要最终（强制）收集未使用的内存，您必须调用runtime.GC()。

variable = nil 可能会使某些内容不可访问从而有资格进行收集，但它本身并不能释放任何东西。

- zzzz

4

这已经不正确了，你需要使用FreeOSMemory来将内存返回给操作系统。 - OneOfOne

@OneOfOne，你有没有想过为什么runtime.GC()不再起作用了？FreeOSMemory调用了freeOSMemory，它是在runtime包中实现的，这是什么意思？ - paradite

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- nemo · Accepted Answer

目前，Go使用一种标记-清除垃圾收集器，一般情况下不定义何时丢弃对象。

然而，如果你仔细观察，有一个名为sysmon的Go协程基本上会在程序运行时一直运行并定期调用GC：

// forcegcperiod is the maximum time in nanoseconds between garbage
// collections. If we go this long without a garbage collection, one
// is forced to run.
//
// This is a variable for testing purposes. It normally doesn't change.
var forcegcperiod int64 = 2 * 60 * 1e9

(...)

// If a heap span goes unused for 5 minutes after a garbage collection,
// we hand it back to the operating system.
scavengelimit := int64(5 * 60 * 1e9)

forcegcperiod 确定强制调用 GC 的时间间隔。 scavengelimit 确定何时将 span 返回给操作系统。Spans 是一些内存页面的集合，可以容纳多个对象。它们被保留了 scavengelimit 时间，如果没有对象在其上且超过了 scavengelimit，则会被释放。

在代码的后面，你可以看到有一个跟踪选项。你可以使用它来查看，每当清理工认为他需要清理时:

$ GOGCTRACE=1 go run gc.go
gc1(1): 0+0+0 ms 0 -> 0 MB 423 -> 350 (424-74) objects 0 handoff
gc2(1): 0+0+0 ms 1 -> 0 MB 2664 -> 1437 (2880-1443) objects 0 handoff
gc3(1): 0+0+0 ms 1 -> 0 MB 4117 -> 2213 (5712-3499) objects 0 handoff
gc4(1): 0+0+0 ms 2 -> 1 MB 3128 -> 2257 (6761-4504) objects 0 handoff
gc5(1): 0+0+0 ms 2 -> 0 MB 8892 -> 2531 (13734-11203) objects 0 handoff
gc6(1): 0+0+0 ms 1 -> 1 MB 8715 -> 2689 (20173-17484) objects 0 handoff
gc7(1): 0+0+0 ms 2 -> 1 MB 5231 -> 2406 (22878-20472) objects 0 handoff
gc1(1): 0+0+0 ms 0 -> 0 MB 172 -> 137 (173-36) objects 0 handoff
getting memory
gc2(1): 0+0+0 ms 381 -> 381 MB 203 -> 202 (248-46) objects 0 handoff
returning memory
getting memory
returning memory

正如你所看到的，在获取并返回之间没有进行任何gc调用。然而，如果你将延迟从5秒改为3分钟（超过forcegcperiod的2分钟），gc将移除这些对象：

returning memory
scvg0: inuse: 1, idle: 1, sys: 3, released: 0, consumed: 3 (MB)
scvg0: inuse: 381, idle: 0, sys: 382, released: 0, consumed: 382 (MB)
scvg1: inuse: 1, idle: 1, sys: 3, released: 0, consumed: 3 (MB)
scvg1: inuse: 381, idle: 0, sys: 382, released: 0, consumed: 382 (MB)
gc9(1): 1+0+0 ms 1 -> 1 MB 4485 -> 2562 (26531-23969) objects 0 handoff
gc10(1): 1+0+0 ms 1 -> 1 MB 2563 -> 2561 (26532-23971) objects 0 handoff
scvg2: GC forced // forcegc (2 minutes) exceeded
scvg2: inuse: 1, idle: 1, sys: 3, released: 0, consumed: 3 (MB)
gc3(1): 0+0+0 ms 381 -> 381 MB 206 -> 206 (252-46) objects 0 handoff
scvg2: GC forced
scvg2: inuse: 381, idle: 0, sys: 382, released: 0, consumed: 382 (MB)
getting memory

记忆体仍未被释放，但垃圾回收已将该记忆体区域标记为未使用。当使用的跨度未被使用且年龄超过limit时，释放将开始。来自清道夫代码：

if(s->unusedsince != 0 && (now - s->unusedsince) > limit) {
    // ...
    runtime·SysUnused((void*)(s->start << PageShift), s->npages << PageShift);
}

这种行为可能会随着时间的推移而改变，但我希望您现在能够感受到对象何时被强制丢弃以及何时不会被强制丢弃。正如zupa所指出的那样，释放对象可能不会将内存返回给操作系统，因此在某些系统上，您可能看不到内存使用情况的变化。根据golang-nuts上的这个线程，这似乎是Plan 9和Windows的情况。