Я использую goroutines в пакете, где есть tcp-сервер. Ответ большую часть времени очень тяжелый, но когда процедуры заканчиваются, он не очищается от памяти.FreeOSMemory() in production
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
}
Так что в этом случае реакция является большим, и goroutine с использованием 10% памяти, это нормально, потому что я получаю 170.000 пользователей из базы данных и анализировать результат JSON. Но когда handleRequest и все еще находится в памяти, если я не использую debug.FreeOsMemory()
. У меня есть сомнения, что это хороший способ сделать это, потому что он находится в debug pacakge, поэтому мой вопрос - это хороший способ освободить память, что используют goroutines? Я тестировал его, чтобы он не влиял на систему и не работал очень хорошо. Если нет, что хорошего? Я не могу дождаться GC, чтобы понять это ?! Я читал this, и именно поэтому я начал его использовать, в первом ответе есть последнее предложение.
«это хороший способ, чтобы освободить память, какие goroutines используют». Ответ: Нет. Держитесь подальше от таких хаков, тем более что они не помогают. – Volker
@ Волькер Во-первых, почему я получил голос? Во-вторых, что хорошего тогда? – PumpkinSeed