在ASP.NET Core极简API中用Task.Run运行长进程是否合理？有哪些隐患？

我有一个长运行进程，希望为其添加REST API，通过该API能够查看长运行进程内部变量的值。我使用极简API制作了一个概念验证示例，代码如下：

public class Program
{
    public static int val = 0;
    public static object locker = new object();


    public static void Main(string[] args)
    {
        Task.Run(() =>
        {
            while (true)
            {
                lock (locker)
                {
                    val++;
                }
                Thread.Sleep(100);
            }
        });

        var builder = WebApplication.CreateBuilder(args);
        var app = builder.Build();

        app.MapGet("/", () => 
        {
            lock (locker)
                return val;
        });

        app.Run();
    }
}

我的想法是将长运行进程的代码放在Task.Run中执行，请问这种方式是否正确？存在哪些潜在的陷阱/问题？

实现方式的正确性 #

从功能层面看，这段代码确实能实现“后台运行计数+API返回结果”的需求，但绝非生产环境的合理方案，存在不少需要警惕的问题。

潜在陷阱与问题 #

• 后台任务生命周期不受控：Task.Run启动的任务没有和ASP.NET Core应用的生命周期绑定。当应用因重启、部署更新、应用池回收等原因关闭时，任务会被强制终止，没有机会执行清理逻辑，可能引发资源泄漏（如未关闭的连接、文件句柄）或数据丢失。
• 任务状态不可监控：如果后台任务抛出未捕获的异常，会静默终止，你无法感知到故障，API仍会返回旧的val值，导致数据不一致。同时你也无法追踪任务是否在正常运行。
• 锁的性能瓶颈：虽然lock保证了线程安全，但对于简单的int操作来说过于笨重。后续如果业务逻辑变复杂或API请求量上升，粗粒度的锁会导致API请求和后台任务互相阻塞，降低系统性能。实际上，针对数值类型的增量和读取，用Interlocked类（如Interlocked.Increment(ref val)）可以实现无锁线程安全，开销更小。
• 静态变量的局限性：静态变量是应用域级别的共享资源，若应用部署在多服务器、多进程（负载均衡场景）或启用进程内并行，不同实例的val值是独立的，API返回的结果会不一致。此外，静态变量若持有大对象或非托管资源，容易引发内存泄漏。
• 无优雅停止机制：后台任务的while(true)循环无法感知应用关闭信号，会被强制中断。正确的做法应该是通过CancellationToken监听应用关闭事件，让任务有机会优雅退出，完成收尾工作。

改进建议 #

• 改用ASP.NET Core官方推荐的后台服务（BackgroundService或IHostedService）实现长运行任务，它会和应用生命周期绑定，支持优雅停止、异常捕获与监控。
• 针对简单数值操作，用Interlocked类替代lock；复杂场景使用ConcurrentDictionary等线程安全集合，减少锁开销。
• 避免用静态变量存储业务状态，改用数据库、Redis等外部存储，保证多实例环境下的数据一致性。
• 添加任务状态监控API，便于排查故障和了解任务运行情况。

内容的提问来源于stack exchange，提问作者David