一次Task.Run异常问题的排查

最近在测试一个功能代码时发现一个非常奇怪的问题，主要是Task.Run引起一些不符合逻辑的错误，以下针对这一问题排查的总结。

问题代码

可以建个控制台程序来运行以下代码

    class Program{static User user = new User();static void Main(string[] args){for (int i = 0; i < 50; i++){Task.Run(user.Init);}System.Threading.Thread.Sleep(-1);}}public class User{private bool mInit = false;private Task OnInit(){Console.WriteLine("User init");System.Threading.Thread.Sleep(1000);return Task.CompletedTask;}public void Init(){lock (typeof(User)){if (!mInit){var task = Task.Run(this.OnInit);if (!task.Wait(5000)){throw new TimeoutException("user init error!");}mInit = true;}}}}

以上代码执行的结果非常奇怪，当在Debug模式下运行，会抛出超时错误。

运行在release模式下则会引起OnIint方法被执行多次，lock完全起不了作用。。

和朋友讨论过程中说lock不要和Task.Run混用，但Task.Wait的实现是基于线程信号量的和async/await是有着本质的差异。抱着解决问题的思路把Task.Run直接改成了线程池方式运行，但结果还是一样。由于找不到问题原因最终去dotnet上提个issues，看一下能提供什么意见。

问题的发现

对于一个程序员来说问题没解决怎能安心呢，隔一天issues没有响应于是开启的解决问题的碰撞模式。在throw timeout里打个断点看一下情况，结果无意中发现Task的状态是WaitingForActivation

状态描述是等待内部调度激活，意思是说这代码并不是不执行或执行有问题，而因为某些状态导致Task还在等待执行中。然后针对这一问题在网查找了一下才发现这问题的原因，主要问题是for 50已经把线和池中的线程抽光了，然然后在Init方法使用Task.Run的时候就只能等待。。。加上方法后面Task.Wait导致当前线程无法回归到池，所以就只能引起超时间异常！如果这里的Task.Wait不加上个超时，那这测试代码就直接处于假死状态无法继续工作，一个等待一个试图获取线程操作从而形成一个类似于死锁的问题！

总结

当你在使用Task.Run时出现一些非常意想不到的结果时可以通过Task.Status状态可以更好的定位到问题。Task默认也是基于线程池的，所以在使用Task.Run和Task.Wait的就要注意这一点，虽然可以通过加大线程池的最小数量来解决低并发问题，但高并发下还是会存在线程资源不足的情况；为了确保不出现类似于死锁的问题，请在使用Task.Wait必须加上超时时间,并且是越短越好，毕竟Wait方法是基于线程阻塞。