生成连续重复随机数代码异常：是运行过慢还是程序故障？

我完全理解你的困惑——从概率数值上看，连续9个相同数字的概率是1/10⁹，连续8个是1/10⁸，看起来只是10倍的差距，但实际运行时的耗时却天差地别。这里有两个核心原因：

1. 期望等待次数的计算并非简单的10倍，且方差会彻底打破预期 #

你可能误以为“期望等待次数是概率的倒数”，但这个结论只适用于独立重复事件（比如每次尝试都完全重置进度）。但在生成连续相同数字的场景中，每次失败并不会彻底清零你的进度：

比如，当你已经积累了8个连续的1，下一次如果生成了2，你并不是回到“0连续”的状态，而是拥有了1个连续的2——这种进度的部分保留，让期望等待次数的计算变得复杂。

对于生成1-10的随机数，等待出现任意连续k个相同数字的期望次数公式是：

E(k) = (10ᵏ - 1) / 9

代入数值：

• k=8时，E(8)≈11,111,111（约1100万次）
• k=9时，E(9)≈111,111,111（约1.1亿次）

从期望上看确实是约10倍的差距，但问题在于这个场景的方差极大——实际运行的次数可能远高于期望。比如你可能在500万次就达成k=8（运气较好），但也可能在数亿次还没达成k=9（运气极差），而你刚好遇到了后者。

2. 极端情况的概率比你想象的更高 #

当k越大，出现“长时间无法达成目标”的概率就越高。比如对于k=9，虽然期望是1.1亿次，但有相当大的概率需要运行数亿甚至数十亿次才能命中连续9个相同的数字。这就像抛硬币，期望抛2次出正面，但你也有可能抛10次都不出——而k越大，这种“倒霉”情况的概率和持续时间都会急剧上升。

验证建议 #

如果你想验证这个逻辑，可以：

• 多次运行k=9的测试，看看平均耗时是否接近期望的10倍（单次波动会极大，但多次平均后会趋近于理论值）
• 优化随机数生成效率，比如使用更轻量的随机数生成器，避免不必要的系统调用
• 加入进度打印，实时查看当前积累的最长连续相同数字长度，判断是否在逐步接近目标

内容的提问来源于stack exchange，提问作者R.Sailer