ti-enxame.com

Você lida com condições de falta de memória?

O que você faz quando malloc retorna 0 ou uma nova exceção lança? Apenas interromper ou tentar sobreviver à condição OOM/salvar o trabalho do usuário?

9
mbq

Eu evitaria o OOM como evitar um acidente.

Evite fazer uma grande quantidade de trabalho (e alocar uma grande quantidade de memória) de uma vez. Mantenha os dados no disco, confie no cache de disco do SO e use o IO mapeado em memória) tanto quanto possível e opere apenas em uma pequena parte dos dados por vez. Se grandes quantidades de dados precisam estar on-line (servidos com baixa latência) e, em seguida, mantê-los na memória em várias máquinas, como fazem todas as grandes empresas de mecanismo de pesquisa ou comprar um SSD.

4
rwong

A maioria das pessoas que responde a esta pergunta provavelmente nunca trabalhou em sistemas embarcados, onde malloc retornar 0 é uma possibilidade muito real. Em um sistema no qual estou trabalhando atualmente, há um total de 4,25K bytes de RAM (isso é 4352 bytes). Estou alocando 64 bytes para a pilha e atualmente tenho um 1600 heap de bytes. Ontem eu estava depurando uma rotina de caminhada de heap para poder seguir a alocação e liberação de memória. A caminhada de heap usa um pequeno buffer (30 bytes) alocado estaticamente para a saída para uma porta serial. Ele será desativado para o versão de lançamento.

Como este é um produto de consumo, é melhor não ficar sem memória depois que o produto for lançado. Tenho certeza que sim durante o desenvolvimento. Em qualquer caso, tudo que posso fazer é buzinar o alto-falante algumas vezes e forçar a reinicialização.

13
tcrosley

Para ser bem honesto, em todos os projetos que fiz (lembre-se de que ainda não estou trabalhando em lugar nenhum), nunca considerei que isso pudesse acontecer e, portanto, suponho que meus programas morreriam rapidamente.

Além disso, o manuseio de um OOM requer que você tenha pré-alocado os recursos para exibir a mensagem de erro ou para salvar tudo, o que pode ser meio inconveniente.

Sinto que hoje em dia, memória custando menos do que amendoim, não é algo que deveria acontecer com frequência. Na aurora da memória protegida e antes, talvez isso fosse uma preocupação, mas agora? Os únicos erros OOM que já vi foram de código bugado.

4
zneak

Verificar códigos de retorno malloc é geralmente inútil de qualquer maneira.

Os sistemas operacionais modernos sobrecarregam a memória: eles fornecem aos processos mais memória do que realmente está disponível. A memória concedida ao seu processo é virtual, toda mapeada para uma única página zerada.

Só depois de gravar na memória uma página física exclusiva é alocada para seus processos. Se esta alocação falhar, o kernel encerrará um processo (talvez o seu!) Na tentativa de encontrar memória. Nesse ponto, não há mais nada que você possa fazer.

2
Kristof Provost

A menos que você esteja desenvolvendo para sistemas embarcados, sistemas em tempo real ou sistemas que são tão críticos que as falhas podem custar vidas ou bilhões de dólares ... Então provavelmente não vale a pena se preocupar financeiramente com as condições de falta de memória.

Na maioria dos casos, há pouco que pode ser feito quando você está sem memória de qualquer maneira, uma vez que não há memória para criar novos objetos ou executar quaisquer tarefas que possam fazer algo. Você tem que pesar o custo do aplicativo que gerencia OOM e o benefício que você obtém ao fazê-lo.

2
Erik Funkenbusch

Eu sempre verificaria se há erros. Se algo retornar uma condição de erro, isso deve ser tratado pelo seu programa. Mesmo que seja uma mensagem que diga "Sem memória, tenho que ir!", É melhor do que "Violação de acesso", "core despejado" ou qualquer outra coisa. Uma é uma condição de erro que você lida, a outra é um bug. E o usuário também perceberá isso.

Para o seu caso específico, você pode tentar reverter a operação, liberando recursos que alocou até chegar ao ponto de falha, relatando o erro e continuando a execução (talvez quando você estiver tentando encerrar o aplicativo, você pode dar o opção de sair imediatamente). Desta forma, o usuário pode decidir o que fazer, ou tentar liberar memória mexendo, fechando arquivos, etc. Claro, como você pode lidar com a situação depende muito do seu programa - um programa que não deveria ser interativo provavelmente só precisa registrar o erro e sair ou continuar.

1
Dysaster