25

私は Go が初めてで、メモリ消費をどのように管理するかを理解しようとしています。

テスト プロジェクトの 1 つでメモリに問題があります。私のプログラムが長時間実行されると、なぜ Go がますます多くのメモリを使用するのか (メモリを解放しないのか) がわかりません。

以下に示すテストケースを実行しています。最初の割り当ての後、プログラムは約 350 MB のメモリを使用します (ActivityMonitor によると)。次に、それを解放しようとすると、ActivityMonitor はメモリ消費量が 2 倍になることを示しています。なんで？

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
}
4

2 に答える 2

36

現在、go はマーク アンド スイープ ガベージ コレクタを使用していますが、これは通常、オブジェクトがいつ破棄されるかを定義していません。

ただし、よく見ると、sysmon基本的にプログラムが実行されている限り実行され、定期的に GC を呼び出すgo ルーチンが呼び出されます。

// 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)

forcegcperiodGC が強制的に呼び出されるまでの期間を決定します。scavengelimitスパンがいつオペレーティング システムに返されるかを決定します。スパンは、複数のオブジェクトを保持できるメモリ ページの数です。それらは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

ご覧のとおり、get と return の間に gc 呼び出しは行われません。ただし、遅延を 5 秒から 3 分 ( の 2 分以上forcegcperiod) に変更すると、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 が指摘したように、オブジェクトを解放してもオペレーティング システムにメモリが返されない可能性があるため、特定のシステムではメモリ使用量の変化が見られない場合があります。golang-nuts のこのスレッドによると、これは Plan 9 と Windows の場合のようです。

于 2013-01-29T15:27:16.777 に答える
15

最終的に（強制的に）未使用のメモリを収集するには、を呼び出す必要がありますruntime.GC()。

variable = nil物事が到達不能になり、収集の対象となる可能性がありますが、それ自体は何も解放しません。

于 2013-01-29T12:14:23.690 に答える