Para Pool ou não para Pool java provedores de serviços de criptografia
Eu enfrento um dilema regular enquanto codifico segurançaframeworks : "piscina ou não piscina"
Basicamente esta questão é dividida em dois "grupos":
Grupo 1 :SecureRandom porque a chamada paranextBytes(...) é sincronizado e pode se tornar um gargalo para um aplicativo WebApp / multi-threaded
Grupo 2: fornecedores de serviços de criptografia comoMessageDigest, Signature, Cipher, KeyFactory... (por causa do custo dogetInstance() ?)
Qual e sua OPINIAO ?
Quais são seus hábitos em tais questões?
Editar 09/07/2013Eu finalmente tirei um tempo para testar @QwerkyShare classifico sozinho e acho o resultado bastante ... surpreendente.
A aula não tinha a minha principal preocupação: piscinas comoGenericObjectPool ouStackObjectPool.
Então eu reformulei a classe para testar todas as 4 alternativas:
Instância compartilhada única com sincronizaçãoessêncianovas instâncias dentro de cada loop (não estou interessado no caso em que você pode extrair a criação de resumo fora do loop)essênciaGenericObjectPool:essênciaStackObjectPool:essênciaEu tive que diminuir o número de loops para 100.000, já que o 1M estava levando muito tempo com pools.
Eu também adicionei umThread.yield() no final de cada loop para dar à carga uma forma mais agradável.
Resultados (tempo de execução cumulativo):
MessageDigestnovas instâncias: 420 sInstância única: 550 sStackObjectPool: 800 sGenericObjectPool: 1900 sKeyFactorynovas instâncias: 400sInstância única: 350 sStackObjectPool: 2900 sGenericObjectPool: 3500 sSecureRandomStackObjectPool: 1600 snovas instâncias: 2300 sGenericObjectPool: 2300sInstância única: 2800 sCifraStackObjectPool: 2800 sGenericObjectPool: 3500 sInstância única: 5100 snovas instâncias: 8000 sConclusãoPara MessageDigest e KeyFactory, os pools são perf killers e são ainda piores do que uma única instância com um gargalo de sincronização, enquanto são realmente úteis quando se trata de SecureRandom e Cipher.