Ciclo de vida do Construtor X memória

5 respostas
K

Saudações!

Já entendi o ciclo de vida de objetos e variáveis, porém não achei nada relacionado ao ciclo de vida de métodos e Construtores.
O Construtor de uma classe permanece em “memória” durante toda a vida do objeto ou é “liberado” após o término ou retorno?

Cenário hipotético:

public class formPai { private AlgumaCoisa objAc; ... demais atributos public formPai(){ ... objAc = new AlgumaCoisa(); ... } } public class AlgumaCoisa { //atributos diversos public AlgumaCoisa(){ ... 400 linhas de código ... criações, IFs, loops, coisas, coisas ... ... atribuições diversas ... } ... métodos diversos }
As 400 linhas de código do construtor de AlgumaCoisa irão permanecer em memória enquanto o objeto AlgumaCoisa existir em frmPai?

Ou seria melhor fazer o seguinte?

public class AlgumaCoisa { ... atributos diversos public AlgumaCoisa(){ AlgumaCoisaAux aux = new AlgumaCoisaAux(); ... 20 linha de código ... atribuições diversas aux = null; } ... métodos diversos } public class AlgumaCoisaAux { public AlgumaCoisaAux(){ ... 380 linhas de código ... criações, IFs, loops, coisas, coisas ... } ... }
Não estou questionando legibilidade de código ou programação elegante, apenas procurando entender como é feita a alocação e liberação de memória pelo Java. O cenário é em relação aos Construtores, porém comentários relacionados a métodos serão bem-vindos.

5 Respostas

FernandoFranzini

Eu realmente não entendi sua pergunta, mas vai alguma resposta.
Não é construtor ou método que fica na memória, mas as referencias para variaveis ou objetos que foram alocados dentro da execução deles.
Esse assunto é bem extenso e por isso eu te indicaria a leitura de qualquer livro de SCJP que traz todo o conteúdo relevante sobre o assunto.

fantomas

Oi kako,

Pergunta interessante porem complexa, normalmente as respostas para isso estão (na net) em tópicos sobre compiladores / construção de linguagens.

Ao processar um códig as estruturas costumam ir para locais específicos de memória dependendo do que está sendo processado / executado, umas com maior  ou menor duração. Por exemplo: As estruturas de dados que passamos nos parametros de um método deve ficar na stack segment (pilha), os códigos dos métodos na code segment (inclusive o construtor que é um método), as estruturas de dados da classe (atributos) na data segment. Os dados ficam na stack segment enquando durar o processamento do método ao terminar a pilha é liberada.

Como vc esta se referindo ao Java que tem uma JVM que cria um tipo de ambiente controlado tudo o que falei pode ser que seja feito de forma diferente.

A arquitetura do microprocessador e os requisitos do projeto (linguagem) tem forte impacto no que vc perguntou. Minha intenção maior foi dar um ponta  inicial na discução e se possivel apontar a direção onde possivelmente vc irá encontrar as respostas.

flws

K

Esclarecendo… eu venho de uma linguagem/ambiente em que um objeto é alocado na memória e desalocado após não ser mais referenciado… todo o objeto… Se um objeto é “grande” - muito " código", não necessariamente variáveis/dados - ocupa mais espaço na memória do que um objeto “pequeno” enquanto for referenciado, em todo o tempo de vida. Por “todo o objeto” entender inclusive métodos não utilizados naquela execução específica, bastando existir na codificação do objeto.

Sabendo disso e buscando otimização de recursos, era boa prática “segmentar” o código em objeto “temporários” cuja existência seria apenas de suprir um objeto principal. Mais processamento, mas menos alocação de recursos a médio/longo prazo.

Em relação ao Java já encontrei, li e reli muitos documentos que tratam do ciclo de vida de uma variável e de um objeto enquanto variável. Não encontrei nada sobre o ciclo de vida de um método. Com a dica do fantomas (obrigado fantomas) irei procurar sobre code segment.

Mas reformulando e esclarecendo minha questão:
Em Java, do ponto de vista de ocupação de memória pelo código (não variáveis/dados), é melhor segmentar o código em objetos que possam ser rapidamente descartados e coletados pelo garbage? ou os métodos - especialmente os construtores - também são coletados pelo garbage mesmo que a classe do método continue existindo/sendo referenciada?
OBS:Sei que o garbage trabalha sozinho mas não custa dar uma “ajudinha”.
OBS2 e o mais importante:

Busco a experiência de cada um, a forma comum de trabalhar, o dia-a-dia …

Andre_Brito

kako:
Mas reformulando e esclarecendo minha questão:
Em Java, do ponto de vista de ocupação de memória pelo código (não variáveis/dados), é melhor segmentar o código em objetos que possam ser rapidamente descartados e coletados pelo garbage? ou os métodos - especialmente os construtores - também são coletados pelo garbage mesmo que a classe do método continue existindo/sendo referenciada?

Pelo código você diz a quantidade de linhas?! Se for isso, acredito que a resposta pra sua pergunta é não, não influencia no uso de memória.

Agora, se dados são alocados em memória, preenchidos, atualizados ou alguma outra operação que mexa no estado da memória, aí sim pode-se dizer que a memória vai ser mais exigida. Mas não pela quantidade de linhas do método e do construtor, e sim pelas alocações.

Minha resposta é só com base no ‘creio’ mesmo. Sua pergunta é complexa e acredito que a resposta também vai ser complexa de provar. De qualquer forma, dê uma lida no draft no livro da Caelum sobre o gerenciamento de memória do Java. O link é este.

gomesrod

Olá,

Não sou um grande especialista em compiladores, JVM, etc, mas vou dar uma pequena contribuição:

A quantidade de memória ocupada por um objeto não depende do tamanho de seu código, de seus métodos, etc, mas sim das suas variáveis de instância.

Evidentemente nenhum programa em nenhuma linguagem* pode ser executado sem que esteja carregado na memória, mas acontece que para a VM existe uma distinção entre o que é Classe e o que é Objeto.

As classes (que são o “código” em si, métodos, construtores, blocos estaticos, entre outras coisas íntimas demais para falar nesse horário) são carregadas pelo Classloader uma única vez em cada execução do programa.

São carregados na primeira vez que a classe é utilizada e ficam em memória PARA SEMPRE, até a JVM ser finalizada.

Quando você instancia um objeto, é alocada uma área na memória (heap) apenas para o ESTADO desse objeto, ou seja, suas variáveis de instância.
Essa “área de memória da instância” é associada a uma Classe, que já está carregada em outro espaço de memória (do classloader), formando seu objeto, o que é muito mais inteligente do que replicar todo o código da classe em cada objeto.

Essa parte do Heap é que está sujeita à ação do garbage collector, e é com ela que devemos nos preocupar.
A parte da memória referente ao classloader não será limpa nunca.

Então voltando ao seu caso: a CLASSE AlgumaCoisa fica na memória exatamente pelo mesmo tempo, ou seja, para sempre. O OBJETO, no entanto, teoricamente ficará menos tempo em memória no segundo cenário, pois suas referências tem um escopo menor.

Não sei se fui claro o suficiente, qualquer coisa é só perguntar.

  • “Nenhuma linguagem” foi uma maneira de dizer, estou falando das mais comuns mas não conheço todas as linguagens/plataformas do universo para saber se é uma verdade absoluta hehe
Criado 17 de maio de 2011
Ultima resposta 17 de mai. de 2011
Respostas 5
Participantes 5