在某些情况下，Go 会自动关闭文件描述吗？

Question

我正在尝试检测Go打开的文件描述，但没有故意关闭。换句话说，我试图使我的代码“错误”，资源泄漏。我的代码是func hh(w http.ResponseWriter, r *http.Request) {    f0, err := os.OpenFile("notes.txt", os.O_RDWR|os.O_CREATE, 0755)    if err != nil {        log.Fatal(err)    }        // I don't close file    fmt.Println(io.ReadAll(f0))}func main() {    http.HandleFunc("/req", hh)    log.Fatal(http.ListenAndServe(":8080", nil))}我使用shell脚本文件打印出有多少文件描述属于这个Go程序。FCOUNT=`lsof -p $1 | grep -v " txt " | wc -l`;echo "PID: $1 $FCOUNT" | sort -nk3无论我向此服务器发送多少请求（），MacBook上的数字仍然是10。当然，我检查并得到相同的答案。curl http://localhost:8080/reqActivity MonitorPS：我的第一个版本的代码实际上正在使用，并且没有关闭响应。也有同样的情况。http.GetBody我的环境： ，macOS Big Sur 11.2.3go version go1.16.2 darwin/amd64有谁知道为什么文件描述号在我认为应该泄漏时保持静止？我的 shell 脚本有问题吗？还是Golang在里面做了一些技巧？谢谢！更新问题是我正在检查命名的进程而不是我的文件夹名称。Go真的给了我一个额外的程序，看起来像一个守护进程，它不能显示fd细节。真正的程序清楚地显示了fd泄漏。尽管如此，我从关于golang的GC的答案和评论中得到了一些知识。gogo我将结束这个问题。

Answer 1

正如Burak Serdar所指出的那样，在gc期间关闭打开的文件是可能的。这意味着主题行中提出的问题的答案 - “在某些情况下，Go 会自动关闭文件描述吗？—是“是”。但在某些情况下，这里正在做很多繁重的工作。

垃圾回收实际发生的时间点通常很难预测（尽管您可以自己故意调用GC代码）。终结器的运行点甚至更难预测，因为有些工作可能在单独的goroutine中完成。有关详细信息，请参阅如何停止 golang gc 并手动触发它？，并注意 Go 的每个版本可能会更改有关 GC 内部的一些规则（尽管 的操作非常稳定）。GOGC

Answer 2

在Unix中，打开的文件由垃圾回收器关闭：

https://golang.org/src/os/file_unix.go 186号线