バグまたは機能？

Question

package main 

import (
    "sync" 
    "runtime" 
) 

type S struct { 
    chs chan int 
} 

var wg sync.WaitGroup 

func worker(s *S) { 
    for i := range s.chs { 
     println("In worker, ch = ", i) 
    } 

    wg.Done() 
} 

func main() { 
    s := S{make(chan int)} 

    runtime.SetFinalizer(&s, func(ss *S) { 
     println("Finalizer") 
     close(ss.chs) 
    }) 


    wg.Add(1) 

    go worker(&s) 
    for i := 0; i < 1; i++ { 
     s.chs <- 1 
    } 

    runtime.GC() 

    wg.Wait() 
} 

出力は（1.8.3を行く） 'の範囲' とGolangの 'チャンネル' に関連したガベージコレクション：

労働者で

、CH = 1人の

ファイナ

---

私はこのプログラムがデッドロックすることを期待しています。 runtime.GC()は、worker()がs.chsへの参照を保持しているので、sを収集しません。

ただし、1.8.3で終了します。 sのファイナライザでは、close(s.chs)でも正常に呼び出されます。

rangeとGCで特別なことがあるのだろうかと思います。

ありがとうございました。

Answer 1

私は、これは何が起こっているかである場合には100％わからないんだけど、runtime godocから、二SetFinalizerのための最後の段落に：

例えば、Aが含ま構造体への場合は、Pポイントファイルディスクリプタ d、pにはファイルディスクリプタをクローズするファイナライザがあり、関数内で最後にpを使用した場合は、syscall.Write（pd、buf、 サイズ）を呼び出すと、すぐにpに到達できない可能性がありますプログラムが syscall.Writeと入力すると、クローズファイル 記述子（または、悪いことに、別のゴルーチンによって をオープンしたまったく異なるファイル記述子）に書き込みを行っているため、syscall.Writeが失敗する原因となります。この問題を回避するには、syscall.Writeを呼び出した後に runtime.KeepAlive（p）を呼び出します。 Finalizerはおそらくのように、すぐに問題のvarの最後の使用後には早く実行できることを私に示唆

。

私はこの可能性については考えていませんでしたが、技術的には、GCは変数のスコープがなくなる前に変数を収集できるかどうかを知ることができます。この単純な例を考えてみましょう。

strをGCで収集できなかった理由はありません。それは決して再び使われることはなく、それはこれを知っている可能性が非常に高いです。