解决方案
- MessageDigest => 根据需要经常创建新实例
- KeyFactory => 使用单个共享实例
- SecureRandom => 使用StackObjectPool
- 密码 => 使用StackObjectPool
问题
在编写安全框架时,我经常面临两难境地:“汇集或不汇集”
基本上这个问题分为两个“组”:
第 1 组:
SecureRandom
因为调用nextBytes(...)
是同步的,它可能成为 WebApp / 多线程应用程序的瓶颈第 2 组:加密服务提供商,如
MessageDigest
,Signature
,Cipher
,KeyFactory
, ... (因为getInstance()
? 的成本)
你有什么意见 ?
你对这些问题有什么习惯?
编辑 09/07/2013
我终于花时间自己测试了@QwerkyShare
课程,我发现结果相当……令人惊讶。
这门课缺少我主要关心的问题:像GenericObjectPool或StackObjectPool这样的池。
因此,我对课程进行了重新设计以测试所有 4 种替代方案:
我不得不将循环数降低到 100000,因为 1M 占用池的时间太多。
我还在Thread.yield()
每个循环的末尾添加了一个,以使负载具有更好的形状。
结果(累积运行时间):
- 信息摘要
- 新实例:420 秒
- 单实例:550 秒
- StackObjectPool : 800 秒
- 通用对象池:1900 秒
- 密钥工厂
- 新实例:400s
- 单实例:350 秒
- StackObjectPool : 2900 秒
- 通用对象池:3500 秒
- 安全随机
- StackObjectPool : 1600 秒
- 新实例:2300 秒
- 通用对象池:2300s
- 单实例:2800 秒
- 密码
- StackObjectPool : 2800 秒
- 通用对象池:3500 秒
- 单实例:5100 秒
- 新实例:8000 秒
结论
对于 MessageDigest 和 KeyFactory,池是性能杀手,甚至比具有同步瓶颈的单个实例还要糟糕,而对于 SecureRandom 和 Cipher,它们确实很有用