AsyncEx项目中Task.Factory.StartNew与异步委托的陷阱分析

在异步编程中，我们经常会遇到需要创建并管理多个并发任务的情况。最近在AsyncEx项目中发现了一个有趣的现象：一个理论上应该永远运行的任务却意外地完成了。这个现象揭示了.NET异步编程中一个容易被忽视的重要问题。

问题现象

开发者编写了一个压力测试方法，创建了100个长期运行的任务，每个任务都在无限循环中尝试获取AsyncLock锁。理论上，这个方法应该永远不会返回，因为所有任务都在无限循环中。然而实际上，Task.WhenAll却意外完成了。

问题根源

问题的核心在于错误地使用了Task.Factory.StartNew方法来启动异步委托。Task.Factory.StartNew是.NET早期引入的API，它在处理异步lambda表达式时会产生不符合预期的行为。

当我们将async lambda传递给Task.Factory.StartNew时，实际上创建了两个任务：

1. 外层任务：由StartNew直接创建，代表同步部分的执行
2. 内层任务：由async方法返回，代表异步操作的完成

Task.WhenAll等待的是外层任务的完成，而外层任务在遇到第一个await时就完成了（因为它只是启动了异步操作）。这解释了为什么所有任务"看似"都完成了。

正确解决方案

在大多数现代.NET异步编程场景中，应该使用Task.Run而不是Task.Factory.StartNew。Task.Run是专门为异步编程设计的，它能正确处理async lambda表达式。

修正后的代码应该如下：

public async Task StressTest()
{
    var testLock = new AsyncLock();

    var tasks = Enumerable.Range(0, 100)
        .Select(taskIndex => Task.Run(async () =>
        {
            while (true)
            {
                using var _ = await testLock.LockAsync();
            }
        }))
        .ToArray();

    await Task.WhenAll(tasks);
}

关于LongRunning标志的说明

原代码中使用了TaskCreationOptions.LongRunning标志，这个标志的实际作用经常被误解：

1. 它只是给任务调度器的一个提示，并不保证任何特定的行为
2. 对于CPU密集型任务，它可能会创建一个专用线程
3. 对于I/O密集型任务（如异步操作），它通常没有实际效果
4. 在现代.NET中，默认的任务调度器已经足够智能，通常不需要这个提示

最佳实践建议

1. 优先使用Task.Run而不是Task.Factory.StartNew
2. 只有在非常明确需要控制任务调度细节时，才考虑使用Task.Factory.StartNew
3. 使用async/await时，确保理解任务链的完整生命周期
4. 对于纯粹的异步操作，通常不需要指定LongRunning标志

理解这些底层机制对于编写健壮、高效的异步代码至关重要。在异步编程中，选择正确的任务创建方式可以避免许多微妙的错误和性能问题。