¿Qué podría pasar si no cierro la respuesta. Cuerpo?

En Go, tengo algunas respuestas http y a veces me olvido de llamar:

resp.Body.Close()

¿Qué pasa en este caso? habrá una fuga de memoria? ¿También es seguro colocarlo defer resp.Body.Close()inmediatamente después de obtener el objeto de respuesta?

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

¿Qué pasa si hay un error, podía respo resp.Bodysea nula?

¿Qué pasa en este caso? ¿Habrá una fuga de memoria?

Es una fuga de recursos. La conexión no se volverá a utilizar y puede permanecer abierta, en cuyo caso el descriptor de archivo no se liberará.

Además, ¿es seguro poner en aplazamiento resp. Body.Close () inmediatamente después de obtener el objeto de respuesta?

No, siga el ejemplo proporcionado en la documentación y ciérrelo inmediatamente después de verificar el error.

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

De la http.Clientdocumentación:

Si el error devuelto es nulo, la Respuesta contendrá un Cuerpo no nulo que se espera que el usuario cierre. Si el cuerpo no se lee en EOF y no se cierra, es posible que el RoundTripper subyacente del cliente (normalmente Transporte) no pueda reutilizar una conexión TCP persistente con el servidor para una solicitud subsiguiente de "mantener vivo".

Si Response.Bodyno se cerrará con el Close()método, los recursos asociados con un fd no se liberarán. Esta es una fuga de recursos.

Clausura Response.Body

De la fuente de respuesta :

Es responsabilidad de la persona que llama cerrar Body.

Por lo tanto, no hay finalizadores vinculados al objeto y debe cerrarse explícitamente.

Manejo de errores y limpiezas diferidas

En caso de error, se puede ignorar cualquier respuesta. Una respuesta no nula con un error no nulo solo ocurre cuando CheckRedirect falla, e incluso entonces el Response.Body devuelto ya está cerrado.

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

Al principio, el descriptor nunca se cierra, como se mencionó anteriormente.

Y lo que es más, golang almacenará en caché la conexión (usando persistConnstruct para envolver) para reutilizarla, si DisableKeepAliveses falso.

En golang después del client.Dométodo de uso , go ejecutará el readLoopmétodo goroutine como uno de los pasos.

Entonces, en golang http transport.go, pconn(persistConn struct)no se colocará en el idleConncanal hasta que se cancele la solicitud en el readLoopmétodo, y también esta goroutine ( readLoopmétodo) se bloqueará hasta que se cancele la solicitud.

Aquí está el código que lo muestra.

Si quieres saber más, necesitas ver el readLoopmétodo.

Consulte https://golang.org/src/net/http/client.go
"Cuando err es nil, resp siempre contiene un resp. No nil".

pero no dicen cuando err! = nil, resp siempre es nil.
Continúan diciendo: "Si resp.Body no está cerrado, es posible que el RoundTripper subyacente del Cliente (normalmente Transporte) no pueda reutilizar una conexión TCP persistente con el servidor para una solicitud subsiguiente de" mantener vivo ".

Entonces, normalmente he resuelto el problema de esta manera:

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