生产中的FreeOSMemory（）

  • Z时代
  • 2024-01-10
  • 分类：问答

我在有TCP服务器的软件包中使用goroutines。大多数时候，响应非常沉重，但是当例程结束时，不会从内存中清除它。

func Handle() {
    service := ":7777"
    tcpAddr, err := net.ResolveTCPAddr("tcp4", service)
    checkError(err)
    listener, err := net.ListenTCP("tcp", tcpAddr)
    checkError(err)
    defer listener.Close()
    for {
        conn, err := listener.Accept()
        checkError(err)
        go handleRequest(conn, db)
    }
}
func handleRequest(conn net.Conn, db *sql.DB) {
    message := make([]byte, 0, 4096)
    tmp := make([]byte, 256)
    n, err := conn.Read(tmp)
    if err != nil {
        if err != io.EOF {
            fmt.Println("read error:", err)
        }
    }
    message = append(message, tmp[:n]...)
    fmt.Println("Message Received:", string(message))
    // do something to get resp
    conn.Write(append(resp, []byte("\n")...))
    conn.Close()
    debug.FreeOSMemory()
    return
}

因此，在这种情况下，响应很大，并且可以使用10％的内存作为goroutine，因为我从数据库中获得了170.000个用户并将结果解析为JSON。但是当handleRequest仍然在内存中时，如果我没有使用debug.FreeOsMemory()。我怀疑这是否是一种好方法，因为它位于调试包中，所以我的问题

吗？我对其进行了测试，因此它不会对系统造成影响，并且无法很好地工作。如果没有，什么是好的方法？我等不及要清理GC吗，这就是为什么我开始使用它的原因，在第一个答案中有最后一个建议。

回答：

Go运行时不会将可用内存立即“释放”回OS，这会造成效率低下。

您应该让Go运行时处理此问题。如果您的应用程序不稳定而没有调用debug.FreeOsMemory()，则存在更大的问题，即使它“看似”有帮助，您也不应对此加以掩盖。甚至可能使情况变得更糟，好像为一个请求提供服务确实需要大量内存（在完成请求后，GC会适当释放该内存），调用FreeOsMemory()只会将其返回到运行时必须要求的OS。

/在处理另一个请求时再次分配。如果您还没有将其交还给操作系统，它将可用于下一个请求…

尝试减少请求处理程序的内存需求。如果不可能（可疑），请限制可能需要同时处理的大内存请求的数量。

以上是 生产中的FreeOSMemory（） 的全部内容， 来源链接： utcz.com/qa/421318.html

回到顶部