今天下午，突然线上出现大量高级掉落重复出现。
正常的概率是1%，结果部分玩家出现了很多。导致了群里炸了锅。于是开始分析掉落部分代码：
这里做过一次优化，以前是不停的new 一个Random对象。后面测试时候发现效率不高，于是采用了复用的方式。现在似乎这里除了问题，分析下来应该是Random在某种条件下输出了相同值。
问题分析
既然Random出了问题，那么有下面几个问题：
1. 触发Random出问题的条件是什么？
2. Random出问题后会输出什么值呢？
3. 假如是固定值，是有条件固定还是无条件呢？
触发条件
有一种说法是：由于不指定seed情况下，random会默认用时间的tick来当作种子。如果在一个tick内重复过多的调用，则会产生固定值。
不过根据线上情况分析：这个问题持续了半小时。所以这个马上被否决了。
接下来搜索后得到了一个线索：
并且有人提到当random停止工作后，他固定返回0。
多线程环境下，的确使用static的random会产生这样的问题。这样来看应该是这里对于random的优化不当了。不过随之而来的是，固定值真的是0么？
固定值
停摆后的random的固定输出值是什么？真的是0。
同理，线上的表现否定了这个结果。因为如果是0，玩家的掉落数目也使用了这个随机数，所以他们应该获取不到这个异常的结果。。。
那么究竟是什么值呢？只能通过模拟多线程来压测了
具体代码如上，在多线程环境下模拟随机过程，推论是：如果正常他应该输出比较均匀的分布，如果异常应该可以发现某个值特别大。
当次数低于100000次，我并没有看到太多异常。当超过这个值后有趣的事情发生了：
这三次异常的结果我差不多测试了30多遍才出来。也就是说差不多只有10%的概率出现Random罢工。这样的确证实了前面的说的多线程情况下， random输出固定值。可以看到一开始应该是均匀分布的，一旦出现多线程问题，马上罢工。
固定条件
Ranom 罢工后会输出固定值这点确认了。但不是网上大家说的是0，而是取决于我输入的min值。这样就解释了线上的大部分疑惑了。并且继续做测试可以发现，这个固定值一旦产生并不是固定不变，而是每次都等于min值。
测试条件为5-10，11-15两个取间同时开始随机取值，检查分布。结果如下图：
看到当第一个红框出现罢工后，下一个Random值不是5，而是直接都输出成11了。
如何改进呢？
原来是通过new 一个Random达到隔离的目的，但现在看来有两个问题：
1. 效率不高
2. 并没有根本解决多线程下罢工的问题。
网上给的方案是采用锁，这样感觉效率也不高。并不能给这个底层方法带来本质的变化。
现在想到的一个方案类似于concurrentDictionary那样，多粒度控制锁的一个Random池子。利用这个数据结构的并发性，来创造多个可以复用的Random实例。每次需要时候采用RondRobin算法获得一个对象即可。
当然更激进的做法就是不用并发对象，直接做1000个实例，感觉出错的概率会下降不少。
以下就是核心代码部分，每次通过到队列中获取random实例，而非反复构造它。当然在竞争十分激烈的情况下有可能拿不到random，这个时候就做了个保底。使用全局的globalRandom.
static Random DequeueRand(Random random)
{
if (random == null)
{
if (GlobalRandomQueue.TryDequeue(out Random rand))
{
random = rand;
GlobalRandomQueue.Enqueue(rand);
}
else
{
// 保底
random = globalRandom;
}
}
return random;
}
测试效果：测试10批，每批10次， 每次1百万条，random函数再也不出现“罢工“情况了