What is goroutine leak?

<p>Hi all<br/> Can someone explain to me, what is goroutine leak?<br/> Thanks</p> <hr/>**评论：**<br/><br/>jwcrux: <pre><p>A quick Google search points out <a href="http://openmymind.net/Leaking-Goroutines/">this post</a>. Assuming what this author talks about and what you&#39;re asking about are the same thing, &#34;goroutine leaks&#34; occur when you create a goroutine but it falls out of scope.</p> <p>Here&#39;s the code given by the author:</p> <pre><code>type Writer struct { queue chan []byte } func NewWriter() *Writer { w := &amp;Writer{ queue: make(chan []byte, 10), } go w.process() return w } func (w *Writer) Write(message []byte) { w.queue &lt;- message } func (w *Writer) process() { for { message := &lt;- w.queue // do something with message } } func main() { fmt.Println(runtime.NumGoroutine()) // 4 test() fmt.Println(runtime.NumGoroutine()) // 5 } func test() { NewWriter() } </code></pre> <p>You can see in the code that the <code>Writer</code> returned by <code>test()</code> is not stored anywhere, causing it to fall out of scope. However, the goroutine is still running in the background but there&#39;s nothing we can do about it. This &#34;leaks&#34; goroutines.</p></pre>zero_coding: <pre><blockquote> <p>&#34;goroutine leak</p> </blockquote> <p>thanks so much.</p></pre>binaryblade: <pre><p>Shouldnt the gc clean that up?</p></pre>irylia: <pre><p>In theory it might be possible for the GC to prove that some goroutines will never have an observable effect on the rest of the program and collect them, but in practice you probably don&#39;t want it to.</p> <p>The halting problem unfortunately ensures that you can&#39;t make this determination with 100% accuracy, and if you can&#39;t rely on your goroutines always being cleaned up you&#39;d have to write them so that they eventually exit anyway.</p></pre>jwcrux: <pre><p>Why would the gc think the goroutine was halted? It has a channel that&#39;s still actively waiting for a message. The problem is that we can&#39;t send a message to it.</p> <p>I guess the gc could see that there is no way to reference it, but I could imagine some instability if it chose to stop a goroutine that was still in progress.</p></pre>binaryblade: <pre><p>In this instance the GC can prove that there are no references between it and the rest of the application and it makes no calls to any &#34;impure&#34; functions such as a file write or syscall or runtime. You are right to say that the goroutines are cooperative in the way they multitask, however, things like channel reads are one of the locations the goroutines will yield. I don&#39;t have to show that the go routine has halted, but I can show that whatever it is doing has no affect on the rest of the world. If i can show that it is equivalently a NOP then I can collect it.</p></pre>icholy: <pre><p><a href="http://play.golang.org/p/upL9wTcojb" rel="nofollow">http://play.golang.org/p/upL9wTcojb</a></p></pre>plafoucr: <pre><p>I just ran into this issue this week-end :) Check out: <a href="https://github.com/golang/go/issues/10574" rel="nofollow">https://github.com/golang/go/issues/10574</a> In short words, go routines are background running functions left behind. They never finish, or after a very long time, and will accumulate, eating resources (very slowly).</p></pre>djherbis: <pre><p>You&#39;re describing a leaked go routine, not a regular one. A proper go routine will finish when it returns from its function and will be freed. A leaked routine never returns because its stuck at a blocking op or an infinite loop. </p></pre>rjw57: <pre><p>Serious question: what parts don&#39;t you understand in the top 5 Google results for &#34;goroutine leak&#34;? Or do you want someone to add a sixth explanation?</p></pre>echophant: <pre><p>I think this is a little harsh, linking him to one of the results would have been sufficient.</p></pre>chipaca: <pre><p>Par for the course on this sub, though. And a significant part of the community too.</p> <p>Only thing I miss about Python, really.</p></pre>rjw57: <pre><p>I assume that the OP already Googled and didn&#39;t understand the existing answers. Since they all seemed pretty good I thought there must be some sticking point which was unlikely to be overcome with a re-wording or a linking. Hence asking what that sticking point was. Other replies in this thread lead me to believe that my faith that OP may have just googled the problem first was probably misguided.</p></pre>ihsw: <pre><p>Spawning a goroutine without waiting for it to finish, exemplified by the error <code>All goroutines are asleep - deadlock!</code>.</p> <p>Normally a goroutine would finish on its own automatically, however if there are looping structures within it (eg: waiting on disk IO/network IO) then additional work is required to synchronize/schedule for its departure without triggering a deadlock.</p> <p>It is a necessary part of asynchronous programming -- momentarily having to resynchronize where appropriate.</p></pre>