HostingEnvironment.QueueBackgroundWorkItem使用ASP.Net线程池还是另一个线程池？

Question

我有一个ASP.Net应用程序，在其中使用HostingEnvironment.QueueBackgroundWorkItem运行后台任务，如下所示的代码。

问题：在下面的代码中计划的后台任务将使用来自ASP.Net线程池线程的线程，还是将使用来自单独线程池的线程？

public ActionResult SendCustMails()
{
      HostingEnvironment.QueueBackgroundWorkItem(ct => SendCustMailsTo(ct, "Customer Notification"));
      return View();
}

private void SendCustMailsTo (CancellationToken ct, string msg)
{
      //some code is omitted
      foreach (var customer in Customers)
      {
            if (ct.IsCancellationRequested)
            {
                  break;
            }

            SendMail(customer, msg);
      }

      return ct;
}

- Sunil

Answer 1

如从托管环境源代码中可以看出，QueueBackgroundWorkItem方法使用了_BackGroundWorkScheduler字段，该字段是BackgroundWorkScheduler类型的，用于调度后台工作项：

public sealed class HostingEnvironment : MarshalByRefObject {
//other field declarations
private static HostingEnvironment _theHostingEnvironment;
private BackgroundWorkScheduler _backgroundWorkScheduler = null; // created on demand
//yet more field declarations


//methods
 [SecurityPermission(SecurityAction.LinkDemand, Unrestricted = true)]
    public static void QueueBackgroundWorkItem(Action<CancellationToken> workItem) {
        if (workItem == null) {
            throw new ArgumentNullException("workItem");
        }

        QueueBackgroundWorkItem(ct => { workItem(ct); return _completedTask; });
    }

    // See documentation on the other overload for a general API overview.
    //
    // This overload of QueueBackgroundWorkItem takes a Task-returning callback; the
    // work item will be considered finished when the returned Task transitions to a
    // terminal state.
    [SecurityPermission(SecurityAction.LinkDemand, Unrestricted = true)]
    public static void QueueBackgroundWorkItem(Func<CancellationToken, Task> workItem) {
        if (workItem == null) {
            throw new ArgumentNullException("workItem");
        }
        if (_theHostingEnvironment == null) {
            throw new InvalidOperationException(); // can only be called within an ASP.NET AppDomain
        }

        _theHostingEnvironment.QueueBackgroundWorkItemInternal(workItem);
    }

    private void QueueBackgroundWorkItemInternal(Func<CancellationToken, Task> workItem) {
        Debug.Assert(workItem != null);

        BackgroundWorkScheduler scheduler = Volatile.Read(ref _backgroundWorkScheduler);

        // If the scheduler doesn't exist, lazily create it, but only allow one instance to ever be published to the backing field
        if (scheduler == null) {
            BackgroundWorkScheduler newlyCreatedScheduler = new BackgroundWorkScheduler(UnregisterObject, Misc.WriteUnhandledExceptionToEventLog);
            scheduler = Interlocked.CompareExchange(ref _backgroundWorkScheduler, newlyCreatedScheduler, null) ?? newlyCreatedScheduler;
            if (scheduler == newlyCreatedScheduler) {
                RegisterObject(scheduler); // Only call RegisterObject if we just created the "winning" one
            }
        }

        scheduler.ScheduleWorkItem(workItem);
    }
//yet more methods

如果我们查看BackgroundWorkScheduler类的源代码：

internal sealed class BackgroundWorkScheduler : IRegisteredObject {
//....
public void ScheduleWorkItem(Func<CancellationToken, Task> workItem) {
        Debug.Assert(workItem != null);

        if (_cancellationTokenHelper.IsCancellationRequested) {
            return; // we're not going to run this work item
        }

        // Unsafe* since we want to get rid of Principal and other constructs specific to the current ExecutionContext
        ThreadPool.UnsafeQueueUserWorkItem(state => {
            lock (this) {
                if (_cancellationTokenHelper.IsCancellationRequested) {
                    return; // we're not going to run this work item
                }
                else {
                    _numExecutingWorkItems++;
                }
            }

            RunWorkItemImpl((Func<CancellationToken, Task>)state);
        }, workItem);
    }
//other methods
}

我们可以注意到它内部使用了Asp.Net线程池来调度工作项。

- Umriyaev

---

感谢您提供详细的答案。我想如果一个人想要使用单独的线程池而不是使用ASP.Net线程池，HangFire是最好的选择。我不喜欢使用来自ASP.Net池的线程来执行后台任务的想法。 - Sunil

@Sunil 没关系，我也很有兴趣知道这个。 - Umriyaev