Cosa potrebbe accadere se non chiudo la risposta.

In Go, ho alcune risposte http e talvolta mi dimentico di chiamare:

resp.Body.Close()

Cosa succede in questo caso? ci sarà una perdita di memoria? Inoltre è sicuro da inserire defer resp.Body.Close()subito dopo aver ottenuto l'oggetto risposta?

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

E se c'è un errore, potrebbe respo resp.Bodyessere nullo?

Cosa succede in questo caso? ci sarà una perdita di memoria?

È una perdita di risorse. La connessione non verrà riutilizzata e può rimanere aperta, nel qual caso il descrittore di file non verrà liberato.

Inoltre è sicuro mettere defer resp.Body.Close () immediatamente dopo aver ottenuto l'oggetto risposta?

No, segui l'esempio fornito nella documentazione e chiudilo subito dopo aver verificato l'errore.

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

Dalla http.Clientdocumentazione:

Se l'errore restituito è nullo, la risposta conterrà un corpo non nullo che l'utente dovrebbe chiudere. Se il corpo non viene letto su EOF e chiuso, il RoundTripper sottostante del client (in genere Transport) potrebbe non essere in grado di riutilizzare una connessione TCP persistente al server per una successiva richiesta "keep-alive".

Se Response.Bodynon verrà chiuso con Close()metodo, una risorsa associata a un fd non verrà liberata. Questa è una perdita di risorse.

Chiusura Response.Body

Dalla fonte della risposta :

È responsabilità del chiamante chiudere Body.

Quindi non ci sono finalizzatori associati all'oggetto e deve essere chiuso esplicitamente.

Gestione degli errori e pulizie differite

In caso di errore, qualsiasi risposta può essere ignorata. Una risposta non nullo con un errore non nullo si verifica solo quando CheckRedirect non riesce e anche in questo caso il Response.Body restituito è già chiuso.

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

All'inizio il descrittore non si chiude mai, come le cose menzionate sopra.

E per di più, golang memorizzerà nella cache la connessione (usando la persistConnstruttura per avvolgere) per riutilizzarla, se DisableKeepAlivesè falso.

Nel client.Dometodo golang dopo l'uso , go eseguirà il readLoopmetodo goroutine come uno dei passaggi.

Quindi in golang http transport.go, a pconn(persistConn struct)non verrà inserito nel idleConncanale fino a quando il req non sarà cancellato nel readLoopmetodo, e anche questo goroutine ( readLoopmetodo) sarà bloccato fino a quando il req non sarà cancellato.

Ecco il codice che lo mostra.

Se vuoi saperne di più, devi vedere il readLoopmetodo.

Vedere https://golang.org/src/net/http/client.go
"Quando err è nil, resp contiene sempre un resp.Body non nullo."

ma non dicono quando err! = nil, resp è sempre nullo. Continuano a dire:
"Se resp.Body non è chiuso, il RoundTripper sottostante del client (tipicamente Transport) potrebbe non essere in grado di riutilizzare una connessione TCP persistente al server per una successiva richiesta" keep-alive "."

Quindi in genere ho risolto il problema in questo modo:

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