C# 随机函数Random 半翻

当你在 Stack Overflow 看到有关Random标题的问题时，肯定知道这又是无数类似基本问题中的一个，下面这篇文章将讲解为随机性为何产生如此多的问题，以及如何解

问题

 Stack Overflow (or newsgroup, or mailing list etc) 中的相关问题内容基本上就是:

         "我在使用random.next方法去产生随机数字，但总是产生相同的数字。它不停的变换运行，但每次总是产生很多相同的数字“

这些问题产生的代码大致如下:

可是，问题出现在哪里？

解释

Random对象并非是真随机数产生器，而是伪随机数产生器。每个Random实例都有一些特定的状态，当你调用Next（或者NextDouble或者NextBytes）的时候，它会根据当时特定状态产生数字，这些数字表面上看起来是随机的，伴随着内部状态的变化，当你再次调用Next方法是又会产生貌似随机的数字。

可以确认的是，如果创建的实例拥有相同的初始状态（可以通过seed提供）并且按照相同的顺序调用其方法，你将会得到相同的结果。

那这段代码的问题在哪里？每个循环里我们使用了新的random对象实例。Random类的无参构造函数使用当前日期和时间作为seed--所以在内部定时器计算出当前日期和时间已经变化之前，代码已经执行多次了。因此我们重复使用了相同的seed--其结果也是重复的。

怎么办？

使用基于密码安全的随机数产生器

     大多数情况下，随机数产生效率不是大问题 --问题是有没有合适的随机函数API。 RandomNumberGenerator 只是用来产生随机的bytes-仅此而已。Compare this with the API of Random, which lets you ask for a random integer, or a random double, or a random set of bytes. I usually find that I need an integer in a range - and getting that reliably and uniformly from a random array of bytes is non-trivial. It's far from impossible, but at the very least you'd probably want an adapter class on top of RandomNumberGenerator. In many cases, the pseudo-randomness of Random is acceptable - if you can avoid the pitfalls described earlier. Let's look at how we can do that.

重复使用同一个Random实例对象

如下代码：

现在每个循环会打印出不同的数字....但还没完。想想当你多次快速成功调用这个函数时会发生什么？我们仍然可能创建了两个使用相同seed的Random实例，那么相同的结果我们就会重现两次。

        有两种方法可以解决这个问题，一个选择就是使用静态变量维持一个Random的实例供每个用户调用。另外一个选择是（不知咋翻）There are two ways of avoiding this problem. One option is to use a static field to maintain a single instance of Random which everything uses. Alternatively, we could push the instantiation higher, of course - eventually reaching the top of the program, which only ever instantiates  a single element of Random, and passes it down everywhere. That's a nice idea (and it expresses the dependency nicely), but it won't quite work... at least, it could cause problems if your code uses multiple threads.

线程安全

Random isn't thread-safe. It's a real pain, given how we'd ideally like to use a single instance everywhere in our program. But no, if you use the same instance at the same time from multiple threads, it's quite possible to end up with a state of all zeroes internally, at which point the instance becomes useless.

Again, there are two approaches here. One is to still use one instance, but also use a lock which every caller has to remember to acquire while they're using the random number generator. That can be simplified by using a wrapper which does the locking for you, but in a heavily multithreaded system you'll still potentially waste a lot of time waiting for locks.

The other approach - and the one we'll pick up here - is to have one instance per thread. We need to make sure that when we create instances we don't reuse the same seed (so we can't just call the parameterless constructor, for example), but other than that it's relatively straightforward.

A safe provider

Fortunately, the new ThreadLocal<T> class in .NET 4 makes it very easy to write providers which need to have a single instance per thread. You simply give theThreadLocal<T> constructor a delegate to call to obtain the initial value, and you're away. In my case I've chosen to use a single seed variable, initialized usingEnvironment.TickCount (just like the parameterless Random constructor) which is then incremented every time we need a new random number generator - which is once per thread.

The whole class is static, with just a single public method: GetThreadRandom. It's a method rather than a property mostly for the sake of convenience: rather than make any classes which need random numbers depend on Random itself, they'll depend on Func<Random>. If the type is only designed to operate in a single thread, it can call the delegate to obtain a single instance of Random and reuse it; if it could be used from multiple threads it can call the delegate each time it needs a random number generator. This will only create as many instances as there are threads, and each will start with a different seed. When passing in the dependency, we can then use a method conversion: new TypeThatNeedsRandom(RandomProvider.GetThreadRandom). Here's the code:

Simple, isn't it? That's because all it's concerned with is providing the right instance of Random. It doesn't care what methods you call on the instance after it's been fetched. Code can still abuse this class of course, by stashing one Random reference and reusing it from multiple threads, but it's also easy to do the right thing.

Problems with interface design

One problem remains: this still isn't very secure. As I mentioned earlier, there's a more secure version in RandomNumberGenerator, with the most commonly used derived class being RNGCryptoServiceProvider. However, the API to that really is hard to use in common cases.

It would be very pleasant indeed if the framework providers had separated the "source of randomness" concept from the "I want to get a random value in a simple way" concept. Then we could have used a simple API backed by either a secure or insecure source of randomness, depending on our requirements. Unfortunately, 'twas not to be. Maybe in a future iteration... or maybe a third party will come up with an adapter instead. (It's beyond me, unfortunately... doing this kind of thing properly is remarkably difficult.) You can nearly get away with deriving from Random and overriding Sample and NextBytes... but it's not clear exactly how they need to work, and even Sample can be tricky. Maybe next time...

最后

以上就是可耐小白菜为你收集整理的C# 随机函数Random 半翻的全部内容，希望文章能够帮你解决C# 随机函数Random 半翻所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。