一次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方法是基于线程阻塞。