To Pool lub nie Pool dostawców usług kryptograficznych java
Stoję przed zwykłym dylematem podczas kodowania bezpieczeństwaramy : „pula lub nie pula”
Zasadniczo to pytanie jest podzielone na dwie „grupy”:
Grupa 1 :SecureRandom
ponieważ wezwanie donextBytes(...)
jest zsynchronizowany i może stać się wąskim gardłem dla aplikacji WebApp / wielowątkowej
Grupa 2: Dostawcy usług kryptograficznych, tacy jakMessageDigest
, Signature
, Cipher
, KeyFactory
, ... (ze względu na kosztgetInstance()
?)
Jaka jest Twoja opinia ?
Jakie są twoje przyzwyczajenia na takie pytania?
Edytuj 09/07/2013W końcu poświęciłem czas na przetestowanie @QwerkyShare
klasa sama i uważam, że wynik jest całkiem ... zaskakujący.
Klasie brakowało mojego głównego zainteresowania: Baseny jakGenericObjectPool lubStackObjectPool.
Więc przerobiłem klasę, aby przetestować wszystkie 4 alternatywy:
Pojedyncza współużytkowana instancja z synchronizacjąsensnowe instancje wewnątrz każdej pętli (nie interesuje mnie przypadek, w którym można wyciągnąć tworzenie skrótu poza pętlę)sensGenericObjectPool:sensStackObjectPool:sensMusiałem obniżyć liczbę pętli do 100000, ponieważ 1M zajmowało zbyt dużo czasu w pulach.
Dodałem teżThread.yield()
na końcu każdej pętli, aby ładunek miał ładniejszy kształt.
Wyniki (skumulowany czas pracy):
Przegląd wiadomościnowe przypadki: 420 sPojedyncza instancja: 550 sStackObjectPool: 800 sGenericObjectPool: 1900 sKeyFactorynowe instancje: 400sPojedyncza instancja: 350 sStackObjectPool: 2900 sGenericObjectPool: 3500 sSecureRandomStackObjectPool: 1600 snowe instancje: 2300 sGenericObjectPool: 2300sPojedyncza instancja: 2800 sSzyfrStackObjectPool: 2800 sGenericObjectPool: 3500 sPojedyncza instancja: 5100 snowe instancje: 8000 sWniosekW przypadku MessageDigest i KeyFactory pule są zabójcami perf i są nawet gorsze niż pojedyncza instancja z wąskim gardłem synchronizacji, podczas gdy są naprawdę przydatne, jeśli chodzi o SecureRandom i Cipher