Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

runtime: memory leak when assign parameter for map[string]interface{} #38221

Closed
nguyenducthinhdl opened this issue Apr 2, 2020 · 2 comments
Closed

runtime: memory leak when assign parameter for map[string]interface{} #38221

nguyenducthinhdl opened this issue Apr 2, 2020 · 2 comments
Labels
FrozenDueToAge

Comments

@nguyenducthinhdl
Copy link

nguyenducthinhdl commented Apr 2, 2020 •
edited by randall77

Please check this source code. The memory is not deallocated.

package main

import (
	"fmt"
	"runtime"
)

var version = "3456"

func bToMb(b uint64) uint64 {
	return b / 1024 / 1024
}

func PrintMemUsage() {
	var m runtime.MemStats
	runtime.ReadMemStats(&m)
	// For info on each, see: https://golang.org/pkg/runtime/#MemStats
	fmt.Printf("Alloc = %v MiB", bToMb(m.Alloc))
	fmt.Printf("\tTotalAlloc = %v MiB", bToMb(m.TotalAlloc))
	fmt.Printf("\tSys = %v MiB", bToMb(m.Sys))
	fmt.Printf("\tNumGC = %v\n", m.NumGC)
}

func main() {
	var version = "3456"
	//viper.Set("version", version);
	N := 2000000
	PrintMemUsage()
	for i := 1; i <= N; i++ {
		m := make(map[string]interface{})
		m["version"] = version
		delete(m, "version")

		m2 := make(map[string]string)
		m2["version"] = string(version)
	}
	fmt.Println("N: ", N, "version: ", version)
	PrintMemUsage()
}

What version of Go are you using (go version)?

1.14.1

$ go version

Does this issue reproduce with the latest release?

1.14.1

What operating system and processor architecture are you using (go env)?

Tested on Windows and Debian

go env Output
$ go env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\ADMIN\AppData\Local\go-build
set GOENV=C:\Users\ADMIN\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\ADMIN\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\ADMIN\AppData\Local\Temp\go-build969542346=/tmp/go-build -gno-record-gcc-switche

What did you do?

Run the source code on top

What did you expect to see?

Alloc = 0 MiB TotalAlloc = 0 MiB Sys = 5 MiB NumGC = 0
N: 2000000 version: 3456
Alloc = 0 MiB TotalAlloc = 0 MiB Sys = 5 MiB NumGC = 0

What did you see instead?

Alloc = 0 MiB TotalAlloc = 0 MiB Sys = 5 MiB NumGC = 0
N: 2000000 version: 3456
Alloc = 3 MiB TotalAlloc = 30 MiB Sys = 12 MiB NumGC = 7
@seankhliao
Copy link
Member

force a runtime.GC() before reading mem stats

@randall77 randall77 changed the title Memory leak when assign parameter for map[string]interface{} runtime: memory leak when assign parameter for map[string]interface{} Apr 2, 2020
@ianlancetaylor
Copy link
Contributor

Yes. Storing a string value in a variable of interface type requires an allocation.

By the usual definition of memory leak, this is not a leak. The garbage collector is aware of the allocation and will collect it.

If you want more discussion about the exact meaning of the fields set by runtime.ReadMemStats I recommend using a forum. See https://golang.org/wiki/Questions. Thanks.

@golang golang locked and limited conversation to collaborators Apr 2, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@ianlancetaylor @nguyenducthinhdl @gopherbot @seankhliao