3 回答
TA贡献1898条经验 获得超8个赞
我遇到了同样的问题(可能是不同的情况或设置)并以不同的方式修复它:
func some_func(file_name []string) {
for _, file_name := range file_names {
f, _ := os.Create(file_name)
// defer f.Close() // bad idea
_, _ = f.Write([]byte("some text"))
f.Close() // better idea
}
}
问题是defer它将在函数返回时执行,这可能需要一段时间 - 取决于循环大小(坏主意)。所以只要做明确(更好的主意)
TA贡献1815条经验 获得超13个赞
基本上在 UNIX 平台中,操作系统对进程在任何给定时间可能拥有的打开文件描述符的数量进行了限制。由于您已达到当前打开的文件(和/或管道或套接字)的限制,并且您正在尝试打开一个新文件(和/或管道或套接字),因此引发了
错误。 为避免此问题,您必须在完成使用打开的文件后关闭文件too many open files
Close()
TA贡献1796条经验 获得超4个赞
OP 没有提供最小的、可重现的示例。有问题的错误是由未发布的代码引起的。演示这一点的一种简单方法是简单地在一个最小示例中运行提供的代码(没有其他活动),并查看它没有失败。
函数ioutil.ReadFile当然会关闭文件。在这种情况下,它被牵连,只是因为它试图在已经达到资源限制时打开一个新文件。
Go 中的一个常见问题是无法关闭隐式打开的流。这种情况的一个特定情况是在使用http库的客户端函数时打开了一个流。
示例:(1), (2)
客户端完成后必须关闭响应正文:
resp, err := http.Get("http://example.com/")
if err != nil {
// handle error
}
defer resp.Body.Close()
body, err := ioutil.ReadAll(resp.Body)
此类请求应始终包括对 的调用Close,使用如上所示的形式。
可能还有其他类似的隐式流被打开的情况......
这是一个特别棘手的问题,因为对于琐碎的程序,您永远不会知道其中的区别。直到您通过数百或数千次迭代运行此程序时,您才会知道存在问题。然后,错误通常可能表现为某些不相关的函数调用失败——正如 OP 所展示的那样。
- 3 回答
- 0 关注
- 245 浏览
添加回答
举报