async/await و Thread Pool

مشکل: روز کمپین و سرور کند

فروشگاه اینترنتی ما یک صفحه محصول دارد. قیمت هر محصول را از یک سرویس دیگر می‌گیریم. یک نفر این کد را نوشته است:

app.MapGet("/products/{id}/price", (int id, PriceClient prices) =>
{
    var price = prices.GetPriceAsync(id).Result; // waits here
    return Results.Ok(price);
});

در روزهای عادی همه چیز خوب است. ولی در روز کمپین این اتفاق‌ها می‌افتد:

• زمان پاسخ از چند ده میلی‌ثانیه به چند ثانیه می‌رسد.
• مصرف CPU سرور پایین است. سرور «بیکار» به نظر می‌رسد.
• تعداد thread های process آهسته و مدام بالا می‌رود.

برای فهمیدن دلیل، اول باید بدانیم thread چیست و async/await دقیقاً چه کاری می‌کند.

Thread و Thread Pool به زبان ساده

یک Thread کارگری است که کد را اجرا می‌کند. سیستم‌عامل آن را می‌سازد. هر thread حافظه stack جدا دارد و ساختنش هزینه دارد.

برای همین .NET برای هر درخواست thread تازه نمی‌سازد. یک Thread Pool دارد: چند thread آماده که کارها را از یک صف برمی‌دارند. خود ASP.NET Core هر درخواست را روی یک thread از همین pool اجرا می‌کند.

await دقیقاً چه می‌کند؟

بیشتر کار یک API، انتظار است: انتظار برای دیتابیس، برای سرویس دیگر، برای فایل. در این مدت CPU کاری ندارد. سؤال این است: آیا thread هم در این مدت گیر می‌افتد؟

وقتی به یک await می‌رسیم، این قدم‌ها انجام می‌شود:

1. کد تا اولین await اجرا می‌شود. مثلاً درخواست HTTP ساخته و فرستاده می‌شود.
2. کار انتظار به سیستم‌عامل سپرده می‌شود. برای انتظار شبکه هیچ thread ای لازم نیست.
3. متد برمی‌گردد. یک Task ناتمام به صدازننده می‌دهد و thread به pool برمی‌گردد.
4. جواب شبکه می‌رسد. سیستم‌عامل خبر می‌دهد.
5. بقیه متد روی یک thread آزاد اجرا می‌شود. شاید همان thread قبلی نباشد.

چرا Result سرور را کند می‌کند؟

حالا برگردیم به کد روز کمپین. دلیل کندی در چند قدم:

1. هر درخواست یک thread از pool می‌گیرد.
2. خاصیت Result آن thread را تا رسیدن جواب قیمت بلاک می‌کند. thread هیچ کار دیگری نمی‌کند.
3. وقتی درخواست‌ها زیاد شوند، همه thread های pool بلاک می‌شوند. درخواست‌های تازه در صف می‌مانند.
4. سیستم Thread Pool می‌بیند صف بزرگ شده است و thread جدید اضافه می‌کند. ولی این کار را عمداً آهسته انجام می‌دهد. برای همین تعداد thread ها آهسته بالا می‌رود.
5. این thread ها فقط منتظرند و محاسبه نمی‌کنند. پس CPU پایین می‌ماند.

به این وضعیت Thread Pool Starvation (گرسنگی Thread Pool) می‌گوییم. نشانه‌اش همین است: CPU کم، ولی سیستم کند.

مثال زنده

یک بار با Result و یک بار با await اجرا کن. به تعداد thread ها، صف و بیشترین زمان پاسخ دقت کن:

کد درست: async از اول تا آخر

راه حل این است که از endpoint تا پایین‌ترین لایه، همه چیز async باشد. به این قانون async all the way می‌گوییم.

app.MapGet("/products/{id}/price",
    async (int id, PriceClient prices, CancellationToken ct) =>
    {
        var price = await prices.GetPriceAsync(id, ct);
        return Results.Ok(price);
    });

public sealed class PriceClient(HttpClient http)
{
    public async Task<decimal> GetPriceAsync(int productId, CancellationToken ct)
    {
        var text = await http.GetStringAsync($"prices/{productId}", ct);
        return decimal.Parse(text, CultureInfo.InvariantCulture);
    }
}

چند کار با هم

صفحه محصول به قیمت و موجودی نیاز دارد. این دو به هم وابسته نیستند. پس می‌توانیم هر دو را با هم شروع کنیم و بعد منتظر هر دو بمانیم:

var priceTask = prices.GetPriceAsync(id, ct);
var stockTask = stock.GetStockAsync(id, ct);

await Task.WhenAll(priceTask, stockTask);

var page = new ProductPage(id, await priceTask, await stockTask);

حالا زمان کل تقریباً برابر کندترین کار است، نه جمع هر دو.

سقف همزمانی

فرض کن باید قیمت ۱۰۰۰ محصول را از سرویس قیمت بگیریم و در کش بگذاریم. اگر همه را با هم بفرستیم، سرویس مقابل زیر بار می‌رود. با متد ForEachAsync در کلاس Parallel یک سقف می‌گذاریم:

await Parallel.ForEachAsync(productIds,
    new ParallelOptions { MaxDegreeOfParallelism = 10, CancellationToken = ct },
    async (id, token) =>
    {
        var price = await prices.GetPriceAsync(id, token);
        latestPrices[id] = price; // a ConcurrentDictionary<int, decimal>
    });

Task با Thread فرق دارد

برای هزاران درخواست همزمان، thread جدا برای هر درخواست راه درستی نیست. ولی یک استثنا داریم: اگر یک کار پس‌زمینه همیشه با یک کتابخانه blocking کار می‌کند، بهتر است thread اختصاصی بگیرد. این‌طوری یک thread از pool را برای همیشه اشغال نمی‌کند. برای این کار گزینه LongRunning را به متد StartNew می‌دهیم. این گزینه فقط برای کد blocking معنی دارد. کد async بعد از اولین await دوباره به pool برمی‌گردد.

لغو کار با CancellationToken

کاربر صفحه گزارش فروش را باز می‌کند. کوئری دو دقیقه طول می‌کشد. کاربر صبر نمی‌کند و صفحه را می‌بندد. چه اتفاقی می‌افتد؟

1. فریم‌ورک ASP.NET Core می‌فهمد اتصال قطع شده است.
2. توکن لغو آن درخواست را فعال می‌کند. این توکن فقط یک سیگنال است.
3. اگر کد ما توکن را به EF Core نداده باشد، کسی به دیتابیس نمی‌گوید «بس کن». کوئری تا آخر اجرا می‌شود و نتیجه‌اش دور ریخته می‌شود.

app.MapGet("/reports/sales", async (ShopDb db, CancellationToken ct) =>
    await db.Orders
        .Where(o => o.CreatedAt >= DateTime.UtcNow.AddDays(-30))
        .GroupBy(o => o.CreatedAt.Date)
        .Select(g => new { Day = g.Key, Total = g.Sum(o => o.Total) })
        .ToListAsync(ct));

کار سنگین CPU

اگر کار واقعاً محاسبه است (مثلاً ساختن یک فایل PDF بزرگ)، async کمکی نمی‌کند. thread واقعاً مشغول است، نه منتظر.

• در ASP.NET Core، متد Run در کلاس Task سودی ندارد. کار را از یک thread pool به همان thread pool منتقل می‌کند. فقط هزینه اضافه می‌سازد.
• در برنامه دسکتاپ مفید است. کار سنگین را از thread صفحه (UI) جدا می‌کند تا صفحه قفل نشود.
• برای کار سنگین در سرور، کار را به صف و یک worker پس‌زمینه بسپار.

قانون‌های مهم

1. هیچ وقت Result یا Wait روی Task نزن. در کد سرور یعنی thread بلاک. در برنامه‌هایی که SynchronizationContext دارند (مثل WinForms)، حتی ممکن است deadlock بدهد.
2. متد async void ننویس. خطای داخل آن را هیچ کس نمی‌گیرد و می‌تواند کل process را از کار بیندازد. تنها استثنا event handler در برنامه‌های دسکتاپ است.
3. توکن لغو را همیشه پاس بده. هر متد async که I/O دارد، یک پارامتر CancellationToken بگیرد.
4. کار را رها نکن (Fire and Forget). اگر یک Task را بدون await رها کنی، خطایش گم می‌شود. وقتی درخواست تمام شود، سرویس‌های Scoped مثل DbContext هم dispose می‌شوند. برای کار پس‌زمینه، از صف و BackgroundService استفاده کن.
5. در کتابخانه‌ها از ConfigureAwait با مقدار false استفاده کن. در ASP.NET Core لازم نیست، چون SynchronizationContext ندارد. ولی کتابخانه نمی‌داند در چه برنامه‌ای اجرا می‌شود.
6. نوع ValueTask را فقط وقتی لازم است انتخاب کن. برای متدی که بیشتر وقت‌ها بدون انتظار جواب می‌دهد (مثلاً از کش) و در کد پرفشار است. فقط یک بار await می‌شود. پیش‌فرض همچنان Task است.

اشتباه‌های رایج

چه وقت async؟