小编use*_*181的帖子

尝试从安装到CIFS文件系统的目录中获取文件名列表.如果序列中有一定数量的文件(> 55),即00000.xxx到00299.xxx,则列表中缺少某些文件(例如文件00055.xxx可能不存在).无关文件的大小.它们可以是零大小.使用本地文件系统中的相同代码可以正常工作.丢失的文件似乎与目录中的文件数量一致(例如,目录中的56个文件可能总是丢失文件21,而300个文件可能会丢失55,81,137).以下程序中不返回任何错误.

这是在CentOS 7.4上运行的.

将golang程序减少为两种不同的方法(均失败):

方法1:

package main
import "os"
import "fmt"
import "io/ioutil"

func main() {
    directory := os.Args[1]

    files, readDirError := ioutil.ReadDir(directory)

    if readDirError != nil {
        fmt.Printf("Error in readDir\n")
        fmt.Println(readDirError)
        fmt.Println("\n")
    }

    for x, f := range files {
        fmt.Printf("%d => %s\n", x, f.Name())
    }
}

方法#2

package main
import "os"
import "fmt"

func main() {
    dir, readDirError := os.Open(os.Args[1])

    defer dir.Close()

    if readDirError != nil {
        fmt.Printf("Error in readDir\n")
        fmt.Println(readDirError)
        fmt.Println("\n")
    }

    fi, err := dir.Stat() …

我在 Suse Linux Enterprise 上运行我的 C 程序，它压缩了几千个大文件（大小在 10MB 到 100MB 之间），随着程序的运行，程序变得越来越慢（它在英特尔 Sandy Bridge 板上运行 32 个线程的多线程）。当程序完成并再次运行时，它仍然很慢。

当我观察程序运行时，我看到程序运行时内存正在耗尽，你会认为这只是一个典型的内存泄漏问题。但是，由于正常的 malloc()/free() 不匹配，我希望所有内存在程序终止时返回。但是，当程序完成时，大部分内存不会被回收。free 或 top 命令显示 Mem：总共 63996M，已使用 63724M，当程序减速停止时有 272M 空闲，但在终止后，空闲内存仅增长回约 3660M。当程序重新运行时，空闲内存很快就用完了。

顶部程序仅显示该程序在运行时最多使用了 4% 左右的内存。

我认为这可能是内存碎片问题，但是，我构建了一个小型测试程序来模拟程序中的所有内存分配活动（内置了许多随机方面 - 大小/数量），并且它始终返回所有内存完成。所以，我不认为是这样。

问题：

1. 是否可能存在会永久丢失内存的 malloc()/free() 不匹配，即即使在进程完成之后？

2. C 程序（不是 C++）中还有哪些其他东西会导致永久性内存丢失，即在程序完成后，甚至终端窗口关闭？只有重新启动才能恢复内存。我已经阅读了其他关于文件未关闭导致问题的帖子，但是，我认为我没有这个问题。

3. 查看 top 和 free 的内存统计数据是否有效，即它们是否准确地描述了内存情况？它们似乎确实与程序的缓慢相对应。

4. 如果程序只显示4%的内存使用率，valgrind之类的会发现这个问题吗？