通过 Parallel.ForEach 使用对多线程的依赖

Question

我使用 Simple Injector 作为我的 IoC 容器。 SimpleInjector 使用这种简单的技术来处理 Per Thread 和 Per Web Request 的混合生活方式

container.RegisterPerWebRequest<IWebRepository, Repository>();
container.RegisterLifetimeScope<IThreadRepository, Repository>();
container.Register<IRepository>(container.GetInstance<Repository>());

// Register as hybrid PerWebRequest / PerLifetimeScope.
container.Register<Repository>(() =>
{
    Repository repository;
    if (HttpContext.Current != null)
        repository = (Repository)container.GetInstance<IWebRepository>();
    else
        repository = (Repository)container.GetInstance<IThreadRepository>();

    return repository;
});

不幸的是（显然！），当我使用 Parallel.ForEach 并尝试并行调用 Repository 类的多个实例时，在我的 UnitOfWork 类的其他地方，这给了我一个问题，因为只有第一个线程在 HttpContext 中找到值。当前的

using (TransactionScope scope = new TransactionScope())
{
    Parallel.ForEach(new List<IRepository>() { _repository1, _repository2 ... }, 
        (repository) =>
        {
            repository.Commit();
        });
    scope.Complete();
}

现在我已经写完了问题，我可以看到我可能在问不可能的事情或一些愚蠢的事情……但是到底是什么……这能做到吗？ 单个请求/线程注册是否可用于多个内部线程？

Answer 1

通过依赖注入，您可以尝试集中有关对象生命周期的知识。 这个集中的地方叫做Composition Root 。 当您开始将依赖项从一个线程传递到另一个线程时，代码的这些部分必须知道传递这些依赖项是否安全。 例如，这些依赖项是线程安全的吗？ 这些依赖项能否在新上下文中运行（例如在 HTTP 或 WCF 请求之外）？ 在许多情况下，这可能很容易分析，但会阻止您使用其他实现更改这些依赖项，因为现在您必须记住代码中有发生这种情况的地方，您需要知道传递了哪些依赖项。 您再次分散了这些知识，使推理 DI 配置的正确性变得更加困难，并且更容易以一种使您的代码直接失败（最好）或导致难以调试竞争条件（最坏）的方式错误配置容器）。

因此，最安全的做法是让每个新启动的线程通过向容器询问来构建新的对象图。 不要将依赖项（即：由容器管理和注入的实例）从一个线程传递到另一个线程。

在您的情况下，您甚至似乎遇到了问题，因为您的存储库似乎与 http 上下文有关系，因为它们似乎无法传输到其他线程。 在那种情况下，这很容易：不要这样做;-)

这并不意味着您不能以任何方式使用多线程来提高性能。 但是，您必须确保此操作不会将依赖项从一个线程移动到另一个线程，或者它们何时移动； 确保此代码（在您的情况下为Parallel.ForEach ）位于应用程序的组合根内，因为这是唯一可以/应该知道此操作是否可以安全执行的地方。

但是，在您的特定情况下，我发现您在多个线程上提交非常可怕。 该工作单元的提交不应该是原子的吗？ 当您在不同线程上执行存储库提交时，您确定此提交仍然是原子的吗？ 当其中一个提交失败但其他提交成功时会发生什么？ 如何回滚已经成功的操作？ 我认为您可以（并且您可能已经）解决了这些问题，但是这样的解决方案给系统增加了很多额外的复杂性。 您必须认真地问自己，性能改进是否真正补偿了您添加到系统中的额外复杂性。

您可以在此处找到有关在多线程应用程序中使用依赖项注入的更多信息。