dongzhu7329
2016-04-12 11:26
浏览 311
已采纳

Golang中的内存泄漏

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

图片转代码服务由CSDN问答提供 功能建议

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

  func main(){
 rgc.GetRgcService()
} 
   
 
 

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

 包rgc 
func GetRgcService()(svc * RgcService,错误){} 
   
 
 <  p>函数GetRgcService是一个空函数。 
 
 

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

  == 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字节
   
  
 

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

  • 写回答
  • 好问题 提建议
  • 追加酬金
  • 关注问题
  • 邀请回答

2条回答 默认 最新

  • douwei8096 2016-04-12 11:50
    最佳回答

    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.

    评论
    解决 无用
    打赏 举报
查看更多回答(1条)

相关推荐 更多相似问题