我在有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吗,这就是为什么我开始使用它的原因,在第一个答案中有最后一个建议。
debug.FreeOsMemory()
Go运行时不会将可用内存立即“释放”回OS,这会造成效率低下。
您应该让Go运行时处理此问题。如果您的应用程序不稳定而没有调用debug.FreeOsMemory(),则存在更大的问题,即使它“看似”有帮助,您也不应对此加以掩盖。甚至可能使情况变得更糟,好像为一个请求提供服务确实需要大量内存(在完成请求后,GC会适当释放该内存),调用FreeOsMemory()只会将其返回到运行时必须要求的OS。 /在处理另一个请求时再次分配。如果您还没有将其交还给操作系统,它将可用于下一个请求…
FreeOsMemory()
尝试减少请求处理程序的内存需求。如果不可能(可疑),请限制可能需要同时处理的大内存请求的数量。