Thanks Ian, It is a memory leak because the memory continues to grow for as long as the loop continues to run. If you change the code example I gave to an infinite loop you'll see that it grows infinitely. I had it stop at 1000 for demonstration purposes because each scan request that my production app gets typically kicks off about 1000 goroutines.
I posted to the issue you linked to as well. Thanks for letting me know about that. I'm measuring memory from the system perspective. Windows and Linux both report gigs of memory used on my production app before it crashes due to out of memory. This is a show-stopper issue for me. If Go can't release memory from a simple goroutine when it exits, I'll have to rewrite using something else. Blessings, Rob Archibald CTO, EndFirst LLC r...@robarchibald.com > On Oct 25, 2017, at 6:50 AM, Ian Lance Taylor <i...@golang.org> wrote: > >> On Wed, Oct 25, 2017 at 12:06 AM, <robmusic.archib...@gmail.com> wrote: >> >> I've got a nasty memory leak. It appears that Go won't reclaim memory when >> goroutines are called in a highly parallel fashion. >> >> To illustrate the issue I've written a simple example below. When I run this >> on my Windows system, I get 800MB to 1 GB of memory consumption. > > How are you measuring memory consumption? > > A memory leak implies that memory continues growing without bound. > That is not what you seem to be reporting. What you are reporting is > high memory usage in a steady state. It's certainly true that if you > create a large number of goroutines in parallel your program will need > a bunch of memory to support those goroutines. And once a program > requires a large amount of memory, it will hold on to that memory for > a while, on the assumption that it is likely to happen again. Over > time unneeded memory will be released back to the system, where "over > time" means several minutes. > > That said, there is a current issue: the G structure that represents a > goroutine is never released. So if your program starts a large number > of goroutines at one time, and then never does that again, you will be > left with some memory that is never released. This is > https://golang.org/issue/9869. > > Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
