C# 为什么.Net中的Random（）是这样实现的？

我最近在这里回答了一个问题，该问题由@dtb成员编辑

这个问题涉及使用Random（）-并说该成员编辑了我的答案以避免出现这种情况（正如他所说的）

我的原始代码不会单独受到此问题的攻击，如下所示：

public void DoStuff()
{
    var rand = new Random();
    while() {} //Inner loop that uses 'rand'
}

答案被编辑，因为它的意图似乎是在循环中调用函数-这会使代码易受攻击-它被更改为基本上：

public void DoStuff(Random R)
{
    while() {} //Inner loop that uses 'rand'
}

我当时的想法是——这将维护随机实例的负担推到了更高的层次上——如果有问题的程序员不理解它是如何实现的，他们仍然会落入这个陷阱

我想我的问题是-为什么.Net中的Random（）不以与Javascript中相同的方式实现-使用一个静态的全局Random（）（例如，每个AppDomain？）？ 当然，对于极少数需要控制种子的情况，您仍然可以提供更显式的重载/方法，将当前时间用作种子

当然，这将避免这种常见的陷阱。有人能告诉我.Net方法的好处吗

编辑：我理解控制种子是很重要的——然而，默认情况下强制执行这一点似乎是一个奇怪的选择。如果有人想控制种子，他们很可能知道自己在做什么

---

干杯。

因为这样可以控制多个随机生成源。如果需要，通过为每个实例设置相同的种子，可以生成相同的序列。有时候你不希望其他的动作影响你的数字流

想象一个游戏：每个随机数都是由一个种子数生成的，所以如果你保存了玩家的输入和随机种子，你就可以从头到尾复制整个游戏。但是，如果你在游戏中生成随机的粒子或其他不相关但随机的东西，你也不想保存它们。最简单的方法是声明两个随机项，一个用于重要内容，另一个用于所有其他内容。但这只是一个例子

---

因此，您可以根据自己的需要自由声明随机序列，并且如果您希望以这种方式使用它，则无需使用技巧

.NET解决方案比涉及单个全局生成器的解决方案更灵活。它允许应用程序的每个部分创建和使用可重复的伪随机数的独立序列，这对于调试非常重要。调试依赖伪随机数的代码一开始就不好玩；当从代码的不同部分访问同一个生成器时，就不可能了

同时，如果您想拥有一个共享的

Random

，只需几行代码就可以轻松地将其提供给您的应用程序：

// !!! This is not thread safe!!!
static class RandomHelper {
    private static readonly Random rnd = new Random();
    public static Random Instance {get { return rnd; } }
}

---

Random

是一个类。您如何拥有一个跨机器、应用程序域等的全局生成器？可能存在重复的问题，您可以在每个应用程序域中静态管理一个。一般来说，我认为编程框架有权假设用户-程序员知道他们在干什么。NET在许多方面都比Winapi更容易“默认情况下”处理问题，但这一基本假设仍然存在。@AakashM显然你是对的-但编程框架也应该做出设计决策，以帮助程序员避免常见的陷阱，如DSure-这很好。我想我的问题可以细化为：为什么默认行为是更为深奥的选择。@DaveBish我的猜测和其他人的一样好，但我怀疑这样做是为了迫使程序员有意识地选择一个共享实例：一旦做出这种选择，就很难返回到多个实例，所以.NET的架构师不想让程序员做出这样的选择。这是对任何试图逐字复制您的示例代码的人的警告。。。

Random

类不是线程安全的，因此在多线程环境（例如ASP.NET）中使用

RandomHelper

的任何人都可能会得到糟糕的结果。（我猜你已经知道这一点，但我也很确定其他人不知道。）@LukeH：同样值得注意的是，一个典型的伪随机生成器在没有显式锁定或其他类似机制的情况下不会是线程安全的，这意味着让两个线程各自创建并使用自己的伪随机生成器要比让一个静态生成器在线程之间共享更快。