内存没有被释放

Alb*_*lbi 1 memory-leaks go pprof lz4

这是一个解压缩字符串的简单程序,我只是运行一个循环来显示内存使用量增加并且所使用的内存永远不会被释放。

即使8小时后内存也没有被释放

解压字符串包:https://github.com/Albinzr/lzGo - (简单的lz字符串算法)

我添加了一个要点链接,因为用于解压缩的字符串很大

源代码: 代码

在此输入图像描述

活动监视器 在此输入图像描述

我是新手,谁能告诉我如何解决内存问题?

20 月 15 日更新当达到内存限制时,应用程序仍然崩溃,因为它只使用 12mb - 15mb 这不应该发生!

Old*_*Pro 6

这里发生了很多事情。

首先,使用 Go 版本 1.14.2你的程序对我来说工作得很好。它似乎没有泄漏内存。

其次,即使我通过将循环大小增加到 100 并将结果保存在数组中故意造成内存泄漏,我也只使用了大约 100 MB 的内存。

第三,您不应该使用活动监视器或任何其他操作系统级工具来检查 Go 程序中的内存泄漏。操作系统内存管理是一个极其复杂的主题,操作系统工具旨在帮助您确定程序如何影响整个系统,而不是程序内部发生的情况。

具体来说,macOS“实际内存”(类似于 RSS,常驻集大小)包括程序不再使用但操作系统尚未收回的内存。当垃圾收集器释放内存并告诉操作系统它不再需要该内存时,操作系统不会立即收回它。(为什么它以这种方式工作超出了本答案的范围。)此外,如果操作系统处于内存压力下,它不仅可以收回程序已释放的内存,而且还可以收回(暂时)程序的内存仍在使用但“最近”没有访问,以便另一个急需内存的程序可以使用它。在这种情况下,即使进程实际上没有使用更少的内存,“实际内存”也会减少。操作系统报告的统计数据无法为您提供帮助。

您需要使用原生 Go 设置(例如expvar 和 expvarmon GODEBUG=gctrace=1)或工具(例如expvarexpvarmon)来查看垃圾收集器正在做什么。

至于为什么你的程序在限制它时会耗尽内存,请记住,默认情况下,Go 会构建一个动态链接的可执行文件,仅仅读取所有共享库就会占用大量内存。尝试使用静态链接构建您的应用程序CGO_ENABLED=0,看看是否有帮助。查看当您仅运行 1 次循环迭代时它使用了多少内存。