解決
- MessageDigest=>必要に応じて新しいインスタンスを作成する
- KeyFactory=>単一の共有インスタンスを使用
- SecureRandom=> StackObjectPoolを使用する
- 暗号=> StackObjectPoolを使用する
質問
セキュリティフレームワークをコーディングしているときに、「プールするかしないか」という通常のジレンマに直面します。
基本的に、この質問は2つの「グループ」に分かれています。
グループ1:
SecureRandom
の呼び出しnextBytes(...)
が同期され、WebApp/マルチスレッドアプリのボトルネックになる可能性があるためグループ2:、、、、、 ...など
MessageDigest
の暗号サービスプロバイダー( ?のコストのため)Signature
Cipher
KeyFactory
getInstance()
あなたの意見は何ですか ?
そのような質問に対するあなたの習慣は何ですか?
2013年9月7日編集
私はついに自分で@QwerkyShare
クラスをテストするのに時間をかけました、そして私は結果がかなり...驚くべきことに気づきました。
クラスには私の主な関心事が欠けていました:GenericObjectPoolやStackObjectPoolのようなプール。
だから私は4つの選択肢すべてをテストするためにクラスを作り直しました:
- 同期の要点を持つ単一の共有インスタンス
- 各ループ内の新しいインスタンス(ダイジェストの作成をループの外にプルできる場合は興味がありません)要点
- GenericObjectPool:要点
- StackObjectPool:要点
1Mがプールで時間がかかりすぎたため、ループの数を100000に減らす必要がありました。
また、各ループの最後にを追加Thread.yield()
して、負荷の形状を改善しました。
結果(累積実行時間):
- メッセージダイジェスト
- 新しいインスタンス:420秒
- シングルインスタンス:550秒
- StackObjectPool:800秒
- GenericObjectPool:1900秒
- KeyFactory
- 新しいインスタンス:400秒
- シングルインスタンス:350秒
- StackObjectPool:2900秒
- GenericObjectPool:3500秒
- SecureRandom
- StackObjectPool:1600秒
- 新しいインスタンス:2300秒
- GenericObjectPool:2300秒
- シングルインスタンス:2800秒
- 暗号
- StackObjectPool:2800秒
- GenericObjectPool:3500秒
- シングルインスタンス:5100秒
- 新しいインスタンス:8000秒
結論
MessageDigestとKeyFactoryの場合、プールはパフォーマンスキラーであり、同期のボトルネックがある単一のインスタンスよりもさらに悪いですが、SecureRandomとCipherに関しては非常に便利です。