英文:
memory leaks in golang
问题
这是代码。
在main.go
中的main
函数中:
func main() {
rgc.GetRgcService()
}
其中rgc
是另一个名为mrgc.go
的Golang文件中的变量。文件中的代码如下:
package rgc
func GetRgcService() (svc *RgcService, err error) {}
GetRgcService
函数是一个空函数。
然而,当我使用valgrind
测试内存时,我得到了以下输出:
==58156== HEAP SUMMARY:
==58156== in use at exit: 1,152 bytes in 4 blocks
==58156== total heap usage: 9 allocs, 5 frees, 1,304 bytes allocated
==58156== 288 bytes in 1 blocks are possibly lost in loss record 4 of 4
==58156== at 0x4A27F63: calloc (vg_replace_malloc.c:593)
==58156== by 0x4010DE1: allocate_dtv (in /home/opt/gcc-4.8.2.bpkg-r2/gcc-4.8.2.bpkg-r2/lib64/ld-2.18.so)
==58156== by 0x40114ED: _dl_allocate_tls (in /home/opt/gcc-4.8.2.bpkg-r2/gcc-4.8.2.bpkg-r2/lib64/ld-2.18.so)
==58156== by 0x4B36DE2: pthread_create@@GLIBC_2.2.5 (in /home/opt/gcc-4.8.2.bpkg-r2/gcc-4.8.2.bpkg-r2/lib64/libpthread-2.18.so)
==58156== by 0x4B2937: _cgo_sys_thread_start (gcc_linux_amd64.c:75)
==58156== by 0x45506C: runtime.asmcgocall (/home/map/.jumbo/lib/go/src/runtime/asm_amd64.s:612)
==58156== by 0x50619F: ??? (in /home/users/zhanghuaizhi/ttt.38)
==58156== by 0xC7FFFFFFFF: ???
==58156== by 0xC820067FFF: ???
==58156== by 0x42D69B: runtime.allocm (/home/map/.jumbo/lib/go/src/runtime/proc.go:1260)
==58156== by 0x42DD3A: runtime.newm (/home/map/.jumbo/lib/go/src/runtime/proc.go:1510)
==58156== by 0x42E071: runtime.startm (/home/map/.jumbo/lib/go/src/runtime/proc.go:1583)
==58156==
==58156== LEAK SUMMARY:
==58156== definitely lost: 0 bytes in 0 blocks
==58156== indirectly lost: 0 bytes in 0 blocks
==58156== possibly lost: 1,152 bytes in 4 blocks
==58156== still reachable: 0 bytes in 0 blocks
==58156== suppressed: 0 bytes in 0 blocks
我该如何释放这些内存?因为我需要使用这个函数进行大量的处理,它导致了大量无法释放的内存泄漏。
英文:
Here is the code.
In the golang main function, which in main.go
func main() {
rgc.GetRgcService()
}
where the rgc
is in another golang file, named mrgc.go
. The code inside is
package rgc
func GetRgcService() (svc *RgcService, err error) {}
The function GetRgcService is a empty function.
However, when I used valgrind
to test the memory, I got the following output
==58156== HEAP SUMMARY:
==58156== in use at exit: 1,152 bytes in 4 blocks
==58156== total heap usage: 9 allocs, 5 frees, 1,304 bytes allocated
==58156== 288 bytes in 1 blocks are possibly lost in loss record 4 of 4
==58156== at 0x4A27F63: calloc (vg_replace_malloc.c:593)
==58156== by 0x4010DE1: allocate_dtv (in /home/opt/gcc-4.8.2.bpkg-r2/gcc-4.8.2.bpkg-r2/lib64/ld-2.18.so)
==58156== by 0x40114ED: _dl_allocate_tls (in /home/opt/gcc-4.8.2.bpkg-r2/gcc-4.8.2.bpkg-r2/lib64/ld-2.18.so)
==58156== by 0x4B36DE2: pthread_create@@GLIBC_2.2.5 (in /home/opt/gcc-4.8.2.bpkg-r2/gcc-4.8.2.bpkg-r2/lib64/libpthread-2.18.so)
==58156== by 0x4B2937: _cgo_sys_thread_start (gcc_linux_amd64.c:75)
==58156== by 0x45506C: runtime.asmcgocall (/home/map/.jumbo/lib/go/src/runtime/asm_amd64.s:612)
==58156== by 0x50619F: ??? (in /home/users/zhanghuaizhi/ttt.38)
==58156== by 0xC7FFFFFFFF: ???
==58156== by 0xC820067FFF: ???
==58156== by 0x42D69B: runtime.allocm (/home/map/.jumbo/lib/go/src/runtime/proc.go:1260)
==58156== by 0x42DD3A: runtime.newm (/home/map/.jumbo/lib/go/src/runtime/proc.go:1510)
==58156== by 0x42E071: runtime.startm (/home/map/.jumbo/lib/go/src/runtime/proc.go:1583)
==58156==
==58156== LEAK SUMMARY:
==58156== definitely lost: 0 bytes in 0 blocks
==58156== indirectly lost: 0 bytes in 0 blocks
==58156== possibly lost: 1,152 bytes in 4 blocks
==58156== still reachable: 0 bytes in 0 blocks
==58156== suppressed: 0 bytes in 0 blocks
How can I free these memory? Since I need to used this function to do a lot of process. It causes lots of memory leaks, which can not be freed
答案1
得分: 20
没有泄漏任何内容。内存仍然可访问,不释放退出时的内容是很常见的,只是会浪费时间,而且操作系统会处理它。
这是分配给仍在运行的线程的线程本地存储的内存,因此释放它是不正确的。一个更好的问题是“如何停止这个线程?”,答案是:你不需要停止,Go运行时会处理它。在退出时不停止线程是很常见的,只是会浪费时间,而且操作系统会处理它。
这与你的代码和函数调用无关,这是Go运行时为自身分配的内容。
Go是一种垃圾回收语言,使用valgrind对其进行检测不会告诉你太多信息。它既无法检测真正的内存泄漏,也无法理解哪些内存仍在使用中。
英文:
Nothing was leaked. The memory is still reachable and it's quite common to not free things on exit, it just takes unnecessary time and the OS will deal with it anyway.
This is memory allocated to thread local storage to a thread that's still running, so it would be incorrect to free it. A better question would be "how do I stop this thread?", to which an answer is: you don't, the Go runtime deals with it. It is quite common to not stop threads at exit, it just takes unnecessary time and the OS will deal with it anyway.
It has nothing to do with your code and your function call, it's something that Go runtime allocates for itself.
Go is a garbage collected language and using valgrind on it will not tell you much. It will neither detect real memory leaks nor will it understand which memory is still in use.
答案2
得分: 1
你可以手动运行垃圾回收:
https://golang.org/pkg/runtime/#GC
我认为这将释放内存,但正如其他人所说,当运行时的计划垃圾收集器运行时,该内存最终会被释放。
英文:
You can manually run garbage collection:
https://golang.org/pkg/runtime/#GC
I think that would free up the memory, but as others have said, that memory will get freed eventually when the runtime's scheduled garbage collector runs.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论