Dinâmica do uso da Memória do Java vs C++

Question

Eu sou um programador de C++ atualmente tentando trabalhar em Java.Trabalhando em C++ eu tenho um hábito de manter o controle da dinâmica de alocações de memória, e o emprego de várias técnicas como RAII para evitar vazamento de memória.Java como sabemos fornece um Coletor de Lixo(GC) para cuidar de vazamentos de memória.Assim, enquanto a programação em Java deve apenas deixar ir todas as salutares preocupações de memória heap e deixá-lo para GC para cuidar dos vazamentos de memória ou se deve ter uma abordagem semelhante à que, enquanto as linguagens de programação sem GC, tente cuidar da memória alocada e só deixar o GC cuidar do que você pode perder.Qual deve ser a abordagem?Quais são as desvantagens de ambos?

Answer 1

Eu não tenho certeza do que você quer tentar cuidar da memória alocada na presença de um GC, mas eu vou tentar algum leitura da mente.

Basicamente, você não deve "preocupar-se" sobre a sua memória sendo coletados.Se você não objetos de referência mais, eles serão apanhados.Lógico vazamentos de memória são ainda possíveis de se criar uma situação onde os objetos são referenciados para o resto do programa (exemplo:registrar ouvintes e nunca onu, registrá-los, exemplo:a implementação de um vetor, tais como a recolha de que não definir itens para null ao remover itens fora da final).

No entanto, se você tiver uma forte RAII plano de fundo, você vai ficar desapontado ao saber que não há equivalente direto em Java.A GC é uma primeira classe de ferramenta para lidar com a memória, mas não há nenhuma garantia sobre quando (ou mesmo se) finalizadores são chamados.Isso significa que, em primeira classe, o tratamento aplicado a memória é não aplicado a qualquer outro recurso, tal como:windows, conexões de banco de dados, sockets, arquivos, primitivos de sincronização, etc.

Answer 2

Com Java e .net (e imagino que a maioria das outras GC ed línguas), você não precisa se preocupar muito com a memória de heap em tudo.O que você fazer necessidade de se preocupar, é nativa recursos como identificadores de arquivos, sockets, GUI primitivos como os tipos de letra e tal.Aqueles que geralmente precisam ser "eliminados", que libera os recursos nativos.(Eles, muitas vezes, deite-se na finalização de qualquer maneira, mas é meio duvidoso para voltar a cair sobre isso.Elimine coisas a si mesmo.)

Answer 3

Com um GC, você tem que:

• ainda cuidar corretamente versão não-memória, recursos como identificadores de arquivo e conexões a banco de dados.
• certifique-se de que você não manter as referências a objetos que você não precisa mais (como mantê-los em coleções).Porque se você fizer isso, você tem um vazamento de memória.

Além do que, você não pode realmente "cuidar da memória alocada", e tentar fazer isso seria um desperdício de tempo.

Answer 4

Tecnicamente, você não precisa se preocupar com a limpeza após as alocações de memória desde que todos os objetos estejam devidamente contabilizada de referência e o GC vai cuidar de tudo.Na prática, hiperativa GC irá afetar negativamente o desempenho.Assim, enquanto o Java não tem um delete operador, você vai fazer bem para reutilização de objetos, tanto quanto possível.

Também o Java não tem destruidores desde objetos vai existir até que o GC começa a eles,.Java tem, portanto, o finally construir o que você deve usar para garantir que todos os não-relacionados à memória os recursos (arquivos sockets, etc) são fechados quando tiver terminado com eles.Não confie em finalise o método para fazer isso para você.

Answer 5

Em Java o GC cuida de alocação de memória e de liberação de memória não utilizada.Isso não significa que você pode ignorar o problema juntos.

O Java GC liberta objetos que não são referenciados a partir da raiz.Isso significa que o Java ainda pode ter vazamentos de memória se você não for cuidadoso para remover as referências a partir de contextos globais, como caches global HashMaps, etc.

Se qualquer conjunto de objetos que fazem referência um ao outro, não são referenciados a partir da raiz, o Java GC irá libertá-los.I. e.ele não funciona com contagens de referência, de modo que você não precisa null todas as referências de objeto (embora alguns estilos de codificação, você prefere limpeza de referências como sonn como eles não são mais necessários.)