一尘不染

生产中的FreeOSMemory()

go

我在有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()。我怀疑这是否是一种好方法,因为它位于调试包中,所以我的问题
是清空goroutines正在使用的内存的好方法
吗?我对其进行了测试,因此它不会对系统造成影响,并且无法很好地工作。如果没有,什么是好的方法?我等不及要清理GC吗,这就是为什么我开始使用它的原因,在第一个答案中有最后一个建议。


阅读 591

收藏
2020-07-02

共1个答案

一尘不染

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

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

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

2020-07-02