去内存消费管理

时间:2013-01-29 12:05:04

标签: memory-management go memory-consumption

我是Go的新手,试图找出它如何管理内存消耗。

我的一个测试项目中的内存有问题。我不明白为什么当我的程序运行很长时间时,Go会使用越来越多的内存(从不释放它)。

我正在运行下面提供的测试用例。在第一次分配后,程序使用近350 MB的内存(根据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
}

2 个答案:

答案 0 :(得分:36)

目前,go使用mark-and-sweep garbage collector,它通常不会定义何时丢弃对象。

但是,如果仔细观察,有一个名为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确定何时将跨度返回到操作系统。 Spans are a number of memory pages可以容纳多个对象。它们保留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

内存仍未释放,但GC将内存区域标记为未使用。释放将在何时开始 使用的跨度未使用且早于limit。来自清道夫代码:

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

这种行为当然可能会随着时间的推移而改变,但我希望你现在对物体有点感觉 被强行扔掉,什么时候不被扔掉。

正如zupa所指出的,释放对象可能无法将内存返回给操作系统,依此类推 在某些系统中,您可能看不到内存使用情况的变化。计划9似乎就是这种情况 和Windows this thread on golang-nuts

答案 1 :(得分:15)

要最终(强制)收集未使用的内存,您必须致电runtime.GC()

variable = nil可能会使某些内容无法访问,因此有资格收集,但它本身并不会释放任何内容。