Как работает несколько параллельных запросов при Scoped контексте?

Обзор параллельных запросов в Scoped контексте

В ASP.NET Core Scoped — это один из основных времен жизни зависимостей, где один экземпляр службы создается на каждый HTTP-запрос. При работе с параллельными запросами важно понимать, как контейнер внедрения зависимостей управляет этими экземплярами.

Основной принцип работы

Scoped-службы создаются один раз на каждый HTTP-запрос. Это означает, что для параллельных запросов создаются разные экземпляры служб, даже если они выполняются одновременно в одном приложении.

// Пример Scoped-службы
public interface IDataService
{
    Guid GetInstanceId();
}

public class DataService : IDataService
{
    private readonly Guid _id = Guid.NewGuid();
    
    public Guid GetInstanceId() => _id;
}

// Регистрация в Startup.cs или Program.cs
builder.Services.AddScoped<IDataService, DataService>();

Параллельная обработка запросов

Когда несколько клиентов отправляют запросы одновременно:

1. Каждый запрос получает собственный контекст выполнения (Scope)
2. Для каждого Scope создается отдельный экземпляр Scoped-службы
3. Параллельные запросы не разделяют экземпляры Scoped-служб

[ApiController]
[Route("api/test")]
public class TestController : ControllerBase
{
    private readonly IDataService _dataService;
    
    public TestController(IDataService dataService)
    {
        _dataService = dataService;
    }
    
    [HttpGet("parallel")]
    public async Task<IActionResult> GetParallel()
    {
        // Симуляция параллельных операций внутри одного запроса
        var tasks = new List<Task<Guid>>();
        
        for (int i = 0; i < 3; i++)
        {
            tasks.Add(Task.Run(() => _dataService.GetInstanceId()));
        }
        
        var results = await Task.WhenAll(tasks);
        
        // Все результаты будут одинаковыми, так как это один Scope
        return Ok(new {
            InstanceId = _dataService.GetInstanceId(),
            ParallelResults = results
        });
    }
}

Ключевые аспекты параллелизма

1. Изоляция данных между запросами

Каждый HTTP-запрос работает с изолированным экземпляром Scoped-службы. Это предотвращает:

• Состояние гонки (race conditions) между запросами
• Нежелательное разделение данных между пользователями
• Проблемы потокобезопасности на уровне запросов

2. Внутризапросный параллелизм

В рамках одного запроса могут выполняться параллельные операции (через Task.Run, Parallel.ForEach, etc.). В этом случае:

• Все параллельные задачи используют один экземпляр Scoped-службы
• Требуется обеспечение потокобезопасности самой службой
• Entity Framework DbContext требует особого внимания (не поддерживает параллельные операции)

public class UnsafeScopedService
{
    private int _counter = 0;
    
    // ОПАСНО: не потокобезопасно при параллельном выполнении внутри одного запроса
    public int Increment() => ++_counter;
}

public class ThreadSafeScopedService
{
    private int _counter = 0;
    private readonly object _lock = new object();
    
    // Безопасно: используется синхронизация
    public int Increment()
    {
        lock (_lock)
        {
            return ++_counter;
        }
    }
}

3. Создание дочерних Scope

В некоторых сценариях может потребоваться создать дочерний Scope внутри запроса:

public class ServiceWithChildScope
{
    private readonly IServiceProvider _serviceProvider;
    
    public ServiceWithChildScope(IServiceProvider serviceProvider)
    {
        _serviceProvider = serviceProvider;
    }
    
    public async Task ProcessInIsolation()
    {
        // Создание нового Scope для изолированной операции
        using (var scope = _serviceProvider.CreateScope())
        {
            var isolatedService = scope.ServiceProvider
                .GetRequiredService<IDataService>();
            
            // isolatedService - новый экземпляр, отличный от родительского Scope
            await Task.Run(() => isolatedService.DoWork());
        }
    }
}

Практические рекомендации

Для работы с параллельными запросами:

1. Проектируйте Scoped-службы как потокобезопасные, если они могут использоваться в параллельных операциях внутри одного запроса
2. Избегайте хранения изменяемого состояния в Scoped-службах
3. Для Entity Framework DbContext:
   • Не выполняйте параллельные асинхронные операции с одним экземпляром
   • Создавайте новый экземпляр DbContext для параллельных задач при необходимости

// Правильная работа с DbContext в параллельном контексте
public async Task ProcessDataInParallel(List<int> ids)
{
    var tasks = ids.Select(async id =>
    {
        // Создаем новый Scope для каждой параллельной задачи
        using var scope = _serviceProvider.CreateScope();
        var context = scope.ServiceProvider
            .GetRequiredService<ApplicationDbContext>();
        
        return await context.Users.FindAsync(id);
    });
    
    var results = await Task.WhenAll(tasks);
    // Обработка результатов
}

Производительность и масштабирование

1. Scoped-службы создаются для каждого запроса, что увеличивает нагрузку на сборщик мусора
2. Параллельные запросы увеличивают потребление памяти (много одновременных экземпляров)
3. Оптимизация: используйте пул объектов для тяжелых ресурсов или переходите на Transient для легковесных служб

Заключение

Scoped-контекст обеспечивает идеальную изоляцию данных между параллельными HTTP-запросами, что критически важно для веб-приложений. Каждый запрос получает собственный набор экземпляров служб, предотвращая конфликты данных между пользователями. Однако внутри одного запроса разработчик должен самостоятельно обеспечивать потокобезопасность при параллельном выполнении операций. Понимание этих механизмов позволяет создавать масштабируемые и надежные приложения, корректно работающие в многопользовательской среде.