probablePrime 上的 Javadoc：
返回一个可能是素数的正 BigInteger，其中 指定的位长度。 BigInteger 返回的概率 此方法复合不超过2-100。
我的问题是，通过不保证质数，但几乎可以肯定，这可以获得多少性能？此外，这种性能差异真的值得在未来某个时间发生错误的微小机会吗？特别是如果加密的有效性取决于这个数字是素数。
【问题讨论】：
标签： java performance biginteger
probablePrime() 的核心是一系列Miller-Rabin 测试（执行的轮数取决于数字的位大小）以及Lucas-Lehmer primality test。这些的时间复杂度在很大程度上取决于BigInteger 实现的其余部分。从维基百科获取“慢”估计值分别为 O(k log(n)^3) 和 O(log(n)^3)。
另一方面，AKS-primality test，没有未经证实的猜想，可以在 Õ(log(n)^6) 中运行。
因此，假设您的数字足够大，概率测试可能比确定性测试快很多。对于任何足够大的密码学来说，渐近行为很可能是可观察到的。当然，唯一确定的方法是实施修改后的 AKS 并对结果进行计时。
（k 是 Mille-Rabin 中的循环数）。
【讨论】：
如果你有这个：
特别是如果加密的有效性取决于这个数字 素数
那种约束，那么我认为你不应该使用probablePrime。因为你无法保证算法的正确性。
但是如果获得非素数的概率非常低，例如可以与SHA-1 collision probability 相媲美，那么您可以接受。 （如果 git 对它没问题，那么你就是）
如果您在给定范围内使用质数池，那么您可以预先生成质数列表并将它们放入查找表中。这会给你O(1) 时间复杂度。
【讨论】：
almost 专用于加密
O(n log n) 复杂性。否则你在O(n^2) 周围有一些东西。我不知道probablePrime 的渐近时间复杂度，但我基于api 的猜测介于O(n log n) 和O(n) 之间。不要认为这是理所当然的。你有很多方法来计算素数。查看this 和维基百科页面了解素数。