Что может случиться, если я не закрою ответ. Body?

В Go у меня есть несколько HTTP-ответов, и я иногда забываю позвонить:

resp.Body.Close()

Что происходит в этом случае? будет утечка памяти? Также безопасно ли вставлять defer resp.Body.Close()сразу после получения объекта ответа?

client := http.DefaultClient
resp, err := client.Do(req)
defer resp.Body.Close()
if err != nil {
    return nil, err
}

Что делать , если есть ошибка, может respили resp.Bodyбыть нулевым?

Что происходит в этом случае? будет утечка памяти?

Это утечка ресурсов. Соединение не будет использоваться повторно и может оставаться открытым, и в этом случае дескриптор файла не будет освобожден.

Также безопасно ли вставлять defer resp.Body.Close () сразу после получения объекта ответа?

Нет, следуйте примеру, приведенному в документации, и закройте его сразу после проверки ошибки.

client := http.DefaultClient
resp, err := client.Do(req)
if err != nil {
    return nil, err
}
defer resp.Body.Close()

Из http.Clientдокументации:

Если возвращенная ошибка равна нулю, ответ будет содержать тело, отличное от нуля, которое пользователь должен закрыть. Если Body не одновременно считывается в EOF и не закрывается, базовый RoundTripper клиента (обычно Transport) может не иметь возможности повторно использовать постоянное TCP-соединение с сервером для последующего запроса «keep-alive».

Если Response.Bodyне будет закрыт Close()методом, то ресурсы, связанные с fd, не будут освобождены. Это утечка ресурсов.

Закрытие Response.Body

Из источника ответа :

Ответственность за закрытие Body - ответственность вызывающего абонента.

Таким образом, к объекту не привязаны финализаторы, и он должен быть явно закрыт.

Обработка ошибок и отложенная очистка

В случае ошибки любой ответ можно игнорировать. Отклик, отличный от nil, с ошибкой, отличной от nil, возникает только в случае сбоя CheckRedirect, и даже тогда возвращенный Response.Body уже закрыт.

resp, err := http.Get("http://example.com/")
if err != nil {
    // Handle error if error is non-nil
}
defer resp.Body.Close() // Close body only if response non-nil

Сначала дескриптор никогда не закрывается, как упоминалось выше.

Более того, golang будет кэшировать соединение (используя persistConnstruct to wrap) для его повторного использования, если оно DisableKeepAlivesравно false.

В golang после использования client.Doметода go будет запускать readLoopметод goroutine как один из шагов.

Таким образом, в golang http transport.goa pconn(persistConn struct)не будет помещен в idleConnканал до тех пор, пока req не будет отменен в readLoopметоде, а также этот goroutine ( readLoopметод) будет заблокирован до тех пор, пока req не будет отменен.

Вот код, показывающий это.

Если вы хотите узнать больше, вам нужно увидеть readLoopметод.

См. Https://golang.org/src/net/http/client.go
"Когда err равно nil, resp всегда содержит ненулевое значение resp.Body."

но они не говорят, что когда err! = nil, resp всегда равно nil.
Далее они говорят: «Если resp.Body не закрыт, базовый RoundTripper клиента (обычно Transport) может не иметь возможности повторно использовать постоянное TCP-соединение с сервером для последующего запроса« keep-alive »».

Поэтому я обычно решал проблему следующим образом:

client := http.DefaultClient
resp, err := client.Do(req)
if resp != nil {
   defer resp.Body.Close()
}
if err != nil {
    return nil, err 
}