java.util.Random真的那么随机吗？我怎么才能生成52！(阶乘)可能的序列？

Question

我一直在用Random (java.util.Random)洗一副52张牌。(8.0658175e+67)有52种可能性。然而，我发现java.util.Random的种子是一个long，它要小得多，只有2^64 (1.8446744e+19)。

从这里，我怀疑java.util.Random是否真的那么随机；它真的能够生成全部52个！可能性？

如果没有，我怎么能可靠地生成一个更好的随机序列，它可以产生所有的52！可能性？

Answer 1

让我提前道歉，因为这有点难以理解……

您完全正确，因为种子只有64位长，所以它只能生成2^64个不同的序列。如果您以某种方式生成64个真实的随机比特并使用它们来选择一个种子，那么您就不能使用该种子在所有52个比特中随机选择！概率相等的可能序列。

但是，只要您实际上不打算生成超过2^64个序列，只要它可以生成的2^64序列没有什么“特殊”或“明显特殊”，那么这一事实就无关紧要。

假设您有两种方法来初始化它--一种方法是使用整个种子来初始化它，另一种方法是在初始化种子之前将种子散列到64位。

如果您不知道哪个初始化器是哪个，您可以编写任何类型的测试来区分它们吗？除非你足够幸运，最终用相同的64位初始化了坏的64位两次，否则答案是否定的。如果不详细了解特定PRNG实现中的一些弱点，您就无法区分这两个初始化器。

或者，假设Random类有一个由2^64个序列组成的数组，这些序列是在遥远的过去的某个时间完全随机选择的，而种子只是这个数组的一个索引。

因此，Random仅使用64位作为其种子的事实实际上在统计上不一定是问题，只要您不会两次使用同一种子的可能性很大。

当然，出于加密的目的，一个64位的种子是不够的，因为让一个系统使用同一种子两次在计算上是可行的。

编辑：

我应该补充的是，尽管上面所有的都是正确的，但java.util.Random的实际实现并不令人敬畏。如果您正在编写纸牌游戏，可以使用MessageDigest应用程序接口来生成"MyGameName"+System.currentTimeMillis()的SHA-256散列，并使用这些位来洗牌。根据上面的论点，只要你的用户不是真的在赌博，你就不必担心currentTimeMillis会返回一个很长的。如果你的用户真的在赌博，那么使用不带种子的SecureRandom。

Answer 2

如果您认为数字仅仅是一个位(或字节)数组，那么也许您可以使用这个Stack Overflow问题中建议的(安全的)Random.nextBytes解决方案，然后将该数组映射到一个new BigInteger(byte[])。

Answer 3

我的实证研究结果是Java.Random并不是完全随机的。如果您尝试使用随机类"nextGaussian()"-method，并为-1和1之间的数字生成足够大的样本总体，则该图是已知为高斯模型的正常分布字段。

芬兰政府拥有的博彩书签全年每天都有一次抽奖游戏，中奖台显示书签以正常分配的方式进行中奖。我对500万次抽奖的Java模拟表明，对于nextInt() -methdod使用的number抽奖，奖金的分配通常与My Bookmarker在每次抽奖中处理奖金的方式相同。

我最好的选择是在每个结尾都避免数字3和7，这是真的，他们很少赢得结果。有几次在1-70 (基诺)之间的整数列中避免了3和7个数字，从而赢得了5个选择中的5个。

芬兰彩票每周抽奖一次周六晚上如果你用39个数字中的12个玩系统，也许你会通过避免3和7的值而在你的优惠券中得到5到6个正确的选择。

芬兰彩票有数字1-40可供选择，需要4张优惠券才能覆盖12个数字系统的所有n个数字。总成本是240欧元，从长远来看，对于帝王赌徒来说，在不破产的情况下玩游戏太贵了。即使你将优惠券分享给其他可供购买的客户，如果你想盈利，你仍然必须相当幸运。