golang中的内存泄漏

Question

这是代码.在golang主函数中,在main.go中

func main() {
    rgc.GetRgcService()
}

其中,rgc在另一golang文件,命名mrgc.go.里面的代码是

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

我怎样才能释放这些记忆？因为我需要使用这个功能来做很多过程.它会导致大量内存泄漏,无法释放

Answer 1

什么都没有泄露.内存仍然可以访问,并且退出时不会释放任何东西是很常见的,它只需要不必要的时间,操作系统无论如何都会处理它.

这是分配给线程本地存储到仍在运行的线程的内存,因此释放它是不正确的.一个更好的问题是"如何阻止这个线程？",答案是:你没有,Go运行时处理它.在退出时不停止线程是很常见的,它只需要不必要的时间,操作系统无论如何都会处理它.

它与您的代码和函数调用无关,它是Go运行时为自己分配的东西.

Go是一种垃圾收集语言,使用valgrind不会告诉你太多.它既不会检测到真正的内存泄漏,也不会了解哪些内存仍在使用中.