Golang中的内存泄漏

这里是代码。
在golang主函数中,在main.go中</ p>
\ n

  func main(){
rgc.GetRgcService()
}
</ code> </ pre>

其中 rgc </ code>所在的位置 在另一个名为 mrgc.go </ code>的golang文件中。 里面的代码是</ p>

 包rgc 
func GetRgcService()(svc * RgcService,错误){}
</ code> </ pre>

< p>函数GetRgcService是一个空函数。</ p>

但是,当我使用 valgrind </ code>测试内存时,得到了以下输出</ p>

  == 58156 ==堆摘要:
== 58156 ==退出时使用:4块中1,152字节
== 58156 ==总堆使用量:9个分配,5个释放, 分配的1,304个字节
== 58156 == 1个块中的288个字节可能在丢失记录4 of 4中丢失
== 58156 ==在0x4A27F63:calloc(vg_replace_malloc.c:593)
== 58156 == by 0x4010DE1:allocate_dtv(在/home/opt/gcc-4.8.2.bpkg-r2/gcc-4.8.2.bpkg-r2/lib64/ld-2.18.so)
==58156==通过0x40114ED:_dl_allocate_tls( 在/home/opt/gcc-4.8.2.bpkg-r2/gcc-4.8.2.bpkg-r2/lib64/ld-2.18.so)
==58156==中0x4B36DE2:pthread_create @@ GLIBC_2.2.5 (/home/opt/gcc-4.8.2.bpkg-r2/gcc-4.8.2.bpkg-r2/lib64/libpthread-2.18.so)
==58156==通过0x4B2937:_cgo_sys_thread_start(gcc_linux_amd64 .c:75)
== 58156 ==通过0x45506C:runtime.asmcgocall(/home/map/.jumbo/lib/go/src/runtime/asm_amd64.s:612)
==58156==通过0x50619F :??? (在/home/users/zhanghuaizhi/ttt.38中)
== 58156 ==通过0xC7FFFFFFFF:???
== 58156 ==通过0xC820067FFF:???
== 58156 ==通过0x42D69B:运行时 .allocm(/home/map/.jumbo/lib/go/src/runtime/proc.go:1260)
==58156==通过0x42DD3A:runtime.newm(/home/map/.jumbo/lib/go /src/runtime/proc.go:1510)
==58156==通过0x42E071:runtime.startm(/home/map/.jumbo/lib/go/src/runtime/proc.go:1583)
= = 58156 ==
== 58156 ==泄漏摘要:
== 58156 ==肯定丢失:0字节,位于0块中
== 58156 ==间接丢失:0字节,位于0块中
== 58156 = =可能丢失:4块中的1,152字节
== 58156 ==仍可访问:0块中的0字节
== 58156 ==已抑制:0块中的0字节
</ code> </ pre>

如何释放这些内存? 由于我需要使用此功能来完成很多过程。 它将导致大量内存泄漏,无法释放</ p>
</ div>

展开原文

原文

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

dongtang5057
dongtang5057 我已经在valgrind上工作了十多年:)您只是不能在Go程序中真正使用它(并且不需要使用它)。
4 年多之前 回复
donglu5728
donglu5728 他的观点是,valgrind在Go程序中毫无用处。它不知道Go如何管理内存。Go不使用malloc/free(除非在极少数情况下需要使用标准库,如此处所示),这是valgrind重写以了解内存分配的方法。
4 年多之前 回复
duanpie2834
duanpie2834 valgrind是功能强大的内存测试工具。你可以试试看
4 年多之前 回复
donglin4636
donglin4636 Go是由内存管理和垃圾回收的,因此无法手动释放内存。因此,我不确定使用valgrind检查Go应用是否有用。
4 年多之前 回复

2个回答



没有任何泄漏。 内存仍然可以访问,并且在退出时不释放任何东西是很常见的,它只花不必要的时间,操作系统仍然会处理它。</ p>

这是分配给线程本地存储的内存 一个仍在运行的线程,因此释放它是不正确的。 更好的问题是“如何停止该线程?”,对此的答案是:您没有,Go运行时会处理它。 在退出时不停止线程是很普遍的事情,它只花不必要的时间,操作系统会处理它。</ p>

它与您的代码和函数调用无关,它是 Go运行时会自行分配一些东西。</ p>

Go是一种垃圾收集语言,在上面使用valgrind不会告诉您太多信息。 它既不会检测到实际的内存泄漏,也不会了解仍在使用的内存。</ p>
</ div>

展开原文

原文

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.



您可以手动运行垃圾回收:
https://golang.org/pkg/runtime/#GC </ p>

我认为这样可以释放内存,但正如其他人所说的那样 ,该内存最终将在运行时的计划垃圾收集器运行时释放。</ p>
</ div>

展开原文

原文

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.

Csdn user default icon
上传中...
上传图片
插入图片
抄袭、复制答案,以达到刷声望分或其他目的的行为,在CSDN问答是严格禁止的,一经发现立刻封号。是时候展现真正的技术了!
立即提问
相关内容推荐