O objeto está agrupando uma técnica obsoleta?

59

Estou muito familiarizado com o conceito de pool de objetos e sempre tento usá-lo o máximo possível.

Além disso, sempre achei que o objeto pool é a norma padrão, já que observei que o próprio Java, bem como os outros frameworks, usam o máximo possível de pooling.

Recentemente, eu li algo que era completamente novo (e contra-intuitivo?) para mim.

Esse pool realmente piora o desempenho do programa, especialmente em aplicativos simultâneos, e é aconselhável instanciar new objects, já que em JVMs mais novas, a instanciação de um objeto é realmente rápida.

Eu li isso no livro: Java Concurrency in Practice

Agora, estou começando a pensar se estou entendendo errado alguma coisa aqui desde a primeira parte do livro, que usei Executors para reutilizar Thread s em vez de criar novas instâncias.

Então o pool de objetos tornou-se obsoleto hoje em dia?

    
por user10326 19.10.2011 / 18:15
fonte

6 respostas

70

Ela é obsoleta como uma técnica geral, porque - como você percebeu - a criação e a destruição de objetos de vida curta por si só (isto é, alocação de memória e GC) é extremamente barata em JVMs modernas. Portanto, usar um conjunto de objetos escritos à mão para seus objetos comuns é provavelmente mais lento, mais complicado e mais propenso a erros do que o simples new . *

Ele ainda tem seus usos, para objetos especiais cuja criação é relativamente cara, como conexões de banco de dados / rede, threads, etc.

* Uma vez tive que melhorar o desempenho de um aplicativo Java de rastreamento. Investigation descobriu uma tentativa de usar um pool de objetos para alocar milhões de objetos ... e o cara inteligente que o escreveu usou um único bloqueio global para torná-lo seguro. A substituição do pool pelo new simples tornou o aplicativo 30 vezes mais rápido.

    
por 19.10.2011 / 18:19
fonte
34

A resposta para a pergunta concreta: 'O agrupamento de objetos é uma técnica obsoleta?' é:

Não. O agrupamento de objetos é amplamente utilizado em locais específicos - pool de threads, pool de conexões de banco de dados, etc.

A criação de objetos gerais nunca foi um processo lento. O pool em si consome recursos - memória e poder de processamento. Qualquer otimização é um trade-off.

A regra é:

Otimização prematura é malvada !!!

Mas quando uma otimização é prematura?

Otimização prematura é feita qualquer otimização , antes que você descubra um gargalo por meio da criação de perfil .

    
por 19.10.2011 / 20:28
fonte
9

Em situações em que você deseja evitar a coleta de lixo por completo, acho que o pool de objetos é a única alternativa viável. Então não, absolutamente não é uma técnica obsoleta.

    
por 19.10.2011 / 20:57
fonte
8

That pooling actually makes program performance worse especially in concurrent applications, and it is advisable to instantiate new objects instead, since in newer JVMs, instantiation of an object is really fast.

Depende do contexto.

    
por 01.01.2016 / 10:11
fonte
7

Medida

Depende completamente do seu caso de uso, tamanho de seus objetos, sua JVM, suas opções de JVM, qual GC você ativou e uma série de outros fatores.

Em resumo: meça antes e meça depois. Supondo que você esteja usando um framework de pooling de objetos (como o Apache), então não deve ser muito doloroso trocar entre implementações.

Dica de teste de desempenho extra - deixe a JVM aquecer um pouco primeiro, execute os testes em uma JVM em execução várias vezes, ela pode se comportar de maneira diferente.

    
por 19.10.2011 / 18:30
fonte
5

Eu não sei se há uma tendência de mudança aqui, mas certamente vai ser o caso que depende . Se a sua classe Java estiver gerenciando um recurso externo, como uma conexão RMI ou carregando um arquivo de recursos, etc - então, certamente, os custos para a instanciação de objetos ainda podem ser altos (embora esses recursos possam ser agrupados para você já!). Como prática geral, eu concordaria com o livro.

    
por 19.10.2011 / 18:21
fonte