Memory leak due to omitted return value in Golang

This is a creation in Article, where the information may have evolved or changed.

I've been two times because of improper omission of function return values in go, one cause MySQL too many connection error, once caused a serious memory leak. So here you share the problem and the solution, but also remind yourself not to make a similar mistake again.

It is well known that functions in go can return multiple values. But most of the time we don't need all the values, and a variable defined in go must be used, or it will be an error. So for an unwanted return value, the general way to do this is to omit:

For _,value: = Range slice{//....}

A typical is the range above. Range can return two values: if followed by an array or a slice, the first value is the index number. If the range is followed by a map type, the first value is the key of the map. The second value is the specific value in the data or map. Many times we don't need the first value, so just omit it just like it was written in the code above. Such a treatment is generally not a problem, but in some cases serious problems arise. For example, the following code:

For {_, err = http. Post (URL, "", nil) if err! = Nil {fmt. PRINTLN (Err)}time. Sleep (Interval)}

Because there is no need to return the data, as long as the access does not have an error on the line, so I directly omitted the first value point. Then run and see in the task manager that the memory of the program process has been increasing. When you have a bad time, you can increase 2-3mb! It was a bit of a mask at the time, because it was a small part of the loop, and it was used in the official library. The idea was that the official stock was leaking in memory, and thought it would be impossible.

Search on Google for half a day, intended to use PPROF. To tell the truth this tool I really do not use, but there is no way, whether appropriate or inappropriate directly on the. Sure enough, the result is like a heavenly book to me. Look at it, just to find that Goroutine is growing very fast. Click to see, Full screen parameters also can not understand. This time I see bufio this bag, suddenly think of a mistake I encountered before.

Some time ago, when using go to call MySQL, there will be too many connection error. One reason was that I omitted a return value, so the resource was not released and finally ran out of MySQL connections. Will it be the same this time? So I changed the code above:

Var resp *http. responsefor {resp, err = http. Post (URL, "", nil) resp. Body.close () if err! = Nil {fmt. PRINTLN (ERR)} time. Sleep (Interval)}

And then run, the problem is solved!

Comparing the code two times, I found the problem: except for the resources that need to be freed because of the arguments I omitted, and because two omitted arguments are pointers! This is the key! the pointer essence is just an address, not the value itself . So while we omit the return value, we create only a few pointers. In the function we have called, the variable has been created, and the consumed memory has been consumed. With the continuous cycle, there is more and more resources to release, and the memory consumption becomes larger and bigger. This is the key to the problem.

The first time I encountered this problem, I simply thought that although I omitted the return value, go would create an anonymous variable or something that would cause a leak in memory. Knowing this problem again, I just want to understand what the nature of the problem is.

This time the bug, to my lesson is that if go inside a function return value is a pointer, must be careful, do not easily omit. Otherwise, it is possible to create a memory space that has already been applied to the function because it cannot be freed and accumulates continuously. The go document emphasizes the resources to be released manually, such as HTTP. Response.body or Os.file, also do not easily omit (generally not omitted ...) ), and be sure to remember to release, using defer is the most reliable (but there is also a pit ...). ）。