工人服务神秘地停止工作

Question

尊敬的女士们，先生们，我最近在 .Net Core 3.1 中第一次使用 Worker 服务，而在一般的 Windows 服务中只进行了第二次（第一次是在 .Net Framework 中制作的，直到今天都可以正常工作） .如果有人可以阐明我将提供的示例中缺少的内容，那就太好了。

所以，为了简单起见，我的问题是： 我假设长时间（永远）运行的 Worker 服务在一天中的任意时间意外停止工作，但在服务管理器中仍显示为“正在运行”（这可能是 Windows 处理服务的方式）。不一定要每天都这样，但它会时不时停止工作，直到我手动停止它然后在服务管理器中重新启动它。

我也有stumbled upon this question，它似乎可以解决我的问题，但即使在将我的所有服务代码块完全包装在 try-catch 中之后，即使在顶层，我仍然没有在我的 Log 表中注册任何内容，或者如果我的数据库连接失败，即使在我设置写入的文件中。服务似乎只是停止调用 ExecuteAsync() 方法。

好的，这是我的代码的逻辑结构，我已经排除了实现，我只是展示在调用 DoWork 之前会发生什么：

public class Worker : BackgroundService
{
    private readonly IConfiguration _configuration;
    public Worker(IConfiguration configuration)
    {
        _configuration = configuration;
    }

    public override Task StartAsync(CancellationToken cancellationToken)
    {                      
        return base.StartAsync(cancellationToken);
    }

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        try
        {
            while (true)
            {
                try //paranoid try-catch
                {
                    await DoWork();
                    await Task.Delay(TimeSpan.FromSeconds(45), stoppingToken);
                }
                catch (Exception e)
                {
                    await Log(e, customMessage: "Proccess failed at top level.");
                }
            }
        }
        catch (Exception e)
        {
            await Log(e, customMessage: "Proccess failed at topmost level.");
        }

    }

    private async Task DoWork()
    {
        try
        {
            
        }
        catch (Exception e)
        {
            await Log(e);
        }
    }

    public async Task Log(Exception e, string user = null, string emailID = null, string customMessage = null)
    {
        
    }
}

如您所见，我没有处理取消，就像我上面链接的问题一样。现在我考虑一下，也许我应该这样做，而某些事情是无意中发送了取消？我没有这样做的原因是因为我不确定哪些事件确切地表明了取消。只有手动停止服务，或者其他什么可能？如果是发送的取消导致我的服务停止工作，它不应该也停止我的服务运行吗？

顺便说一句，我刚刚在虚拟服务上测试了取消，它使用while(true) 实现了我的逻辑，它捕获了停止异常，即使它有点尴尬，因为它捕获它并在停止之前多次记录它，所以我认为它可能不是导致我的 DoWork 不触发的取消令牌。

Answer 1

好的，伙计们，我已经修好了。见下面的评论。

我猜想导致死锁的原因可能是通过相同连接从不同线程到数据库的并发调用过多。
并不是说我知道那会是原因（我仍然不知道并且只能猜测为什么会发生这种情况，所以如果有人能澄清为什么会发生这种情况以及为什么不打电话请排队），但是当我尝试修复它时，这似乎是一个很好的起点。

我所做的只是将可能的并发调用限制为 1：

1. 在类级别上实例化 SemaphoreSlim：
   private static SemaphoreSlim Semaphore = new SemaphoreSlim(1);
2. 在我的每个数据库调用之前插入SemaphoreSlim.WaitAsync，并在调用后的 finally 块中插入其各自的SemaphoreSlim.Release：
   

try
{
    await Semaphore.WaitAsync();
    var id = await sqlCommand.ExecuteScalarAsync().ToString();
}
finally
{
    Semaphore.Release();
}

我认为这会降低性能，但令我惊喜的是，我并没有感觉到明显的差异。

此外，我很想将 Semaphore 的初始计数设置为超过 1 个线程，但我认为如果死锁发生在许多线程上，那么它可能发生在 2-10 个线程上。有人可能对这个数字有更多了解吗？是处理器相关、SQL 相关还是 C# 相关？

Answer 2

你是否实现了一个 dispose 方法在完成 DoWork 方法后关闭数据库连接？我在使用工作服务时遇到了死锁问题，并意识到数据库连接没有被释放。实现 dispose 方法后，它对我来说可以解决问题。