No Go, tenho algumas respostas http e às vezes me esqueço de ligar para:
resp.Body.Close()
O que acontece nesse caso? haverá um vazamento de memória? Também é seguro colocar defer resp.Body.Close()imediatamente após obter o objeto de resposta?
client := http.DefaultClient
resp, err := client.Do(req)
defer resp.Body.Close()
if err != nil {
return nil, err
}
E se houver um erro, pode respou resp.Bodyser nulo?
Respostas:
O que acontece nesse caso? haverá um vazamento de memória?
É um vazamento de recursos. A conexão não será reutilizada e pode permanecer aberta, caso em que o descritor de arquivo não será liberado.
Também é seguro colocar em adiar resp.Body.Close () imediatamente após obter o objeto de resposta?
Não, siga o exemplo fornecido na documentação e feche-o imediatamente após verificar o erro.
client := http.DefaultClient
resp, err := client.Do(req)
if err != nil {
return nil, err
}
defer resp.Body.Close()
Da http.Clientdocumentação:
Se o erro retornado for nulo, a resposta conterá um corpo diferente de nulo que o usuário deve fechar. Se o corpo não for lido para EOF e fechado, o RoundTripper subjacente do cliente (normalmente transporte) pode não ser capaz de reutilizar uma conexão TCP persistente com o servidor para uma solicitação "keep-alive" subsequente.
io.LimitReader. Eu normalmente uso um limite bem pequeno, já que é mais rápido fazer uma nova conexão se a solicitação for muito grande.
_, err := client.Do(req)também faz com que o descritor de arquivo permaneça aberto. Assim, mesmo que não se importe qual é a resposta, ainda é necessário atribuí-la a uma variável e fechar o corpo.
Se Response.Bodynão for fechado comClose() método, os recursos associados a um fd não serão liberados. Este é um vazamento de recursos.
Response.BodyDa fonte de resposta :
É responsabilidade do chamador fechar o Body.
Portanto, não há finalizadores vinculados ao objeto e ele deve ser fechado explicitamente.
Em caso de erro, qualquer resposta pode ser ignorada. Uma Resposta não nula com um erro não nula ocorre apenas quando CheckRedirect falha e, mesmo então, o Response.Body retornado já está fechado.
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
A princípio o descritor nunca fecha, como as coisas mencionadas acima.
E o que é mais, golang irá armazenar em cache a conexão (usando persistConnstruct para embrulhar) para reutilizá-la, se DisableKeepAlivesfor false.
No golang após o client.Dométodo de uso , go irá executar o goroutinereadLoop método como uma das etapas.
Portanto, em golang http transport.go, a pconn(persistConn struct)não será colocado no idleConncanal até que o req seja cancelado no readLoopmétodo, e também esta goroutine ( readLoopmétodo) será bloqueada até que o req seja cancelado.
Aqui está o código que o mostra.
Se você quiser saber mais, você precisa ver o readLoopmétodo.
Veja https://golang.org/src/net/http/client.go
"Quando err é nulo, resp sempre contém um resp.Body não nulo."
mas eles não dizem quando err! = nulo, resp sempre é nulo. Eles continuam a dizer:
"Se resp.Body não estiver fechado, o RoundTripper subjacente do Cliente (normalmente Transporte) pode não ser capaz de reutilizar uma conexão TCP persistente com o servidor para uma solicitação" keep-alive "subsequente."
Então, normalmente resolvo o problema assim:
client := http.DefaultClient
resp, err := client.Do(req)
if resp != nil {
defer resp.Body.Close()
}
if err != nil {
return nil, err
}