Seu colega não faz ideia do que está falando.
Sua operação mais cara seria ouvi-los . Eles perderam seu tempo direcionando você para informações com mais de uma década desatualizadas (a partir da data original em que essa resposta foi postada) e você terá que gastar tempo postando aqui e pesquisando na Internet pela verdade.
Espero que eles estejam apenas ignorando algo que ouviram ou leram há mais de uma década e não sabem nada melhor. Eu tomaria qualquer outra coisa que eles dissessem como suspeita também, isso deveria ser uma falácia bem conhecida por qualquer um que se mantenha atualizado de qualquer forma.
Tudo é um objeto (exceto primitives
)
Tudo diferente de primitivos ( int, long, double
, etc) são Objetos em Java. Não há como evitar a criação de objetos em Java.
No início, no início dos anos 90, as implementações de JVM no início dos anos 2000 tiveram alguma sobrecarga de desempenho na alocação real de Objetos. Este não tem sido o caso desde pelo menos 2005.
Se você ajustar -Xms
para suportar toda a memória necessária para que seu aplicativo seja executado corretamente, o GC talvez nunca precise executar e varrer a maior parte do lixo nas implementações modernas de GC, programas de curta duração nunca .
Ele não tenta maximizar o espaço livre, que é um arenque vermelho, maximiza o desempenho do tempo de execução. Se isso significa que o heap da JVM é quase 100% alocado o tempo todo, que assim seja. A memória de heap livre da JVM não oferece nada apenas sentado lá de qualquer maneira.
Existe um equívoco de que o GC irá liberar memória de volta para o resto do sistema de uma maneira útil, isso é completamente falso!
O heap da JVM não aumenta e diminui, de forma que o resto do sistema é afetado positivamente pela memória livre na Pilha da JVM . -Xms
aloca TODO o que é especificado na inicialização e sua heurística é nunca realmente liberar qualquer parte dessa memória de volta ao sistema operacional para ser compartilhada com qualquer outro processo do sistema operacional até que essa instância da JVM seja encerrada completamente. -Xms=1GB -Xmx=1GB
aloca 1 GB de RAM, independentemente de quantos objetos são realmente criados a qualquer momento. Existem algumas configurações que permitem que porcentagens da memória heap sejam liberadas, mas para todos os propósitos práticos a JVM nunca é capaz de liberar memória suficiente para que isso aconteça , portanto, nenhum outro processo pode recuperar essa memória, então o resto do sistema não se beneficiará do heap da JVM estar livre . Um RFE para isso foi "aceito" 29-NOV-2006, mas nada foi feito sobre isso. Este comportamento não é considerado uma preocupação por alguém de autoridade.
Existe um conceito errôneo de que a criação de muitos objetos curtos e curtos faz com que a JVM pause por longos períodos de tempo. Isso também é falso
Algoritmos de GC atuais são realmente otimizados para criar muitos objetos pequenos que são de curta duração, que são basicamente a heurística de 99% para objetos Java em cada programa. Tentativas no Object Pooling farão a JVM piorar na maioria dos casos.
Os únicos Objetos que precisam de pool atualmente são Objetos que se referem a recursos finitos que são externos para a JVM; Sockets, arquivos, conexões de banco de dados, etc e podem ser reutilizados. Objetos regulares não podem ser agrupados no mesmo sentido que em idiomas que permitem acesso direto a locais da memória. Object caching é um conceito diferente e pode ou não ser o que algumas pessoas chamam ingenuamente pooling , os dois conceitos não são a mesma coisa e não devem ser confundidos.
Os algoritmos modernos de GC não têm este problema porque eles não são desalocados em um horário, eles desalocam quando a memória livre é necessária em uma determinada geração. Se o heap for grande o suficiente, nenhuma desalocação ocorrerá o tempo suficiente para causar pausas.