‫کانال‌ها (Channels) در مقابل صف‌ها (Queues) در دات‌نت؛ چرا در سال ۲۰۲۶ باید ساختارهای سنتی را کنار بگذاریم؟

public class BackgroundTaskQueue : IBackgroundTaskQueue
{
    private ConcurrentQueue<Func<CancellationToken, Task>> _workItems = new();
    private SemaphoreSlim _signal = new SemaphoreSlim(0);

    public void QueueBackgroundWorkItem(Func<CancellationToken, Task> workItem)
    {
        if (workItem == null) throw new ArgumentNullException(nameof(workItem));

        _workItems.Enqueue(workItem);
        _signal.Release(); // سیگنال‌دهی به نخ مصرف‌کننده
    }

    public async Task<Func<CancellationToken, Task>> DequeueAsync(CancellationToken cancellationToken)
    {
        await _signal.WaitAsync(cancellationToken);
        _workItems.TryDequeue(out var workItem);

        return workItem;
    }
}

• فقدان مکانیزم کنترل بار یا فشار معکوس (Backpressure): صف ConcurrentQueue در این بخش ظرفیت نامحدودی دارد. اگر نرخ تولید کارها در سیستم (مثلاً از طریق کلاینت‌های API) بسیار بیشتر از سرعت پردازش آنها توسط BackgroundService باشد، صف به شکل نامحدود در حافظه (Heap) رشد کرده و در نهایت منجر به کرش سرور با خطای OutOfMemoryException می‌شود.
• پیچیدگی و هزینه هماهنگیPrimitives: در این الگو شما مجبورید دو ساختار داده مستقل (ConcurrentQueue برای ذخیره و SemaphoreSlim برای سیگنال‌دهی) را به طور دستی هماهنگ کنید. این هماهنگی دستی هزینه‌بر است و احتمال بروز باگ‌های هم‌روندی را افزایش می‌دهد.
• تله‌ی نشتی حافظه به دلیل کلوژرها (Closure Memory Leak): در این طراحی، صف اقدام به پذیرش Func (یک لامبدا یا دلیگیت) می‌کند. اگر توسعه‌دهنده‌ای هنگام ثبت کار، یک سرویس دارای طول عمر Scoped (مانند کانتکست دیتابیس یا IUserContext) را درون این لامبدا کپچر (Capture) کند، این شیء به یک کلوژر تبدیل شده و به دلیل ذخیره در یک صف Singleton، طول عمر آن همیشگی می‌شود! این موضوع یکی از ریشه‌های پنهان و کابوس‌وار نشتی حافظه در دات‌نت است.

// ساختار داده‌محور کوچک بدون کپچر کردن کانتکست‌های طول عمر کوتاه
public record BackgroundJobMessage(Guid JobId, string JobType, string Payload);

public interface IBackgroundTaskQueue
{
    ValueTask QueueBackgroundWorkItemAsync(BackgroundJobMessage workItem, CancellationToken cancellationToken = default);
    ValueTask<BackgroundJobMessage> DequeueAsync(CancellationToken cancellationToken);
}

using System.Threading.Channels;

public class ChannelBackgroundTaskQueue : IBackgroundTaskQueue
{
    private readonly Channel<BackgroundJobMessage> _channel;

    public ChannelBackgroundTaskQueue(int capacity = 1000)
    {
        // ساخت یک کانال ناهمگام و محدود برای مدیریت پایداری حافظه
        var options = new BoundedChannelOptions(capacity)
        {
            FullMode = BoundedChannelFullMode.Wait, // در صورت پر شدن، تولیدکننده به صورت آسنکرون منتظر می‌ماند
            SingleReader = true,                  // بهینه‌سازی: فقط یک BackgroundService کارها را می‌خواند
            SingleWriter = false                  // کنترلرها یا سرویس‌های متعدد می‌توانند کار تزریق کنند
        };

        _channel = Channel.CreateBounded<BackgroundJobMessage>(options);
    }

    public async ValueTask QueueBackgroundWorkItemAsync(BackgroundJobMessage workItem, CancellationToken cancellationToken = default)
    {
        if (workItem == null) throw new ArgumentNullException(nameof(workItem));

        // نوشتن کاملاً آسنکرون و غیرمسدودکننده نخ در کانال
        await _channel.Writer.WriteAsync(workItem, cancellationToken); 
    }

    public async ValueTask<BackgroundJobMessage> DequeueAsync(CancellationToken cancellationToken)
    {
        // خواندن بومی و آسنکرون
        return await _channel.Reader.ReadAsync(cancellationToken);
    }
}

using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;

public class QueuedHostedService : BackgroundService
{
    private readonly Channel<BackgroundJobMessage> _channel; // یا تزریق مستقیم کانتکست Reader
    private readonly IBackgroundTaskQueue _taskQueue;
    private readonly IServiceProvider _serviceProvider;
    private readonly ILogger<QueuedHostedService> _logger;

    public QueuedHostedService(
        IBackgroundTaskQueue taskQueue, 
        IServiceProvider serviceProvider,
        ILogger<QueuedHostedService> logger)
    {
        _taskQueue = taskQueue;
        _serviceProvider = serviceProvider;
        _logger = logger;
    }

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        _logger.LogInformation("سرویس پردازش پس‌زمینه کانال آغاز به کار کرد.");

        // با استفاده از الگوی پیشنهادی ReadAllAsync، از استثناهای ناخواسته جلوگیری می‌کنیم
        while (!stoppingToken.IsCancellationRequested)
        {
            try
            {
                // دریافت کار بعدی به صورت بومی و کاملاً آسنکرون
                var workItem = await _taskQueue.DequeueAsync(stoppingToken);

                // ایجاد یک Scope جدید برای حل وابستگی سرویس‌های طول عمر کوتاه (Scoped)
                using var scope = _serviceProvider.CreateScope();
                
                // فرض کنید یک مفسر یا هاندر برای پردازش کارهای پس‌زمینه دارید
                var processor = scope.ServiceProvider.GetRequiredService<IJobProcessor>();
                
                await processor.ProcessAsync(workItem, stoppingToken);
            }
            catch (OperationCanceledException)
            {
                // خروج امن سرویس در زمان درخواست لغو یا خاموشی سرور
                _logger.LogWarning("عملیات خواندن از صف لغو شد.");
            }
            catch (Exception ex)
            {
                _logger.LogError(ex, "خطایی در طول پردازش آیتم صف پس‌زمینه رخ داد.");
            }
        }
    }
}

• مدیریت هوشمند لود (Backpressure): با تعیین ظرفیت ۱۰۰۰ عددی برای کانال، اگر سیستم تحت هجوم ناگهانی درخواست‌ها قرار گیرد، متد WriteAsync به طور آسنکرون اجرای متد کنترلر وب را متوقف می‌کند (پاز غیرمسدودکننده). این dam یا سد مانع از خراب شدن Heap حافظه سرور می‌شود.
• خروج کاملاً امن (Graceful Shutdown): دات‌نت هنگام پایان یافتن کار نرم‌افزار، توکن لغو (stoppingToken) را فعال می‌کند. ساختار کانال به دلیل بومی بودن در بستر Async/Await این توکن را به زیبایی در متد خواندن اعمال کرده و کارگران به سرعت و بدون نقص کارهای جاری را به اتمام رسانده و متوقف می‌شوند.
• امنیت مطلق در برابر نشتی حافظه: با عبور از متد دلیگیت (Func) و حرکت به سمت ساختار داده‌محور (BackgroundJobMessage)، عملاً امکان انتقال کلوژرها و زنده نگه‌داشتن اشیاء سنگین لایه وب به صف‌های سنگین Singleton صفر شده است.
• کارایی فوق‌العاده بالا (Lock-Free Algorithms): کانال‌ها در دات‌نت به جای تکیه بر قفل‌های سنگین سیستم‌عاملی یا هماهنگی‌های دستیِ ساختارهایی مثل SemaphoreSlim، از الگوریتم‌های درونی بدون قفل (Lock-free) استفاده می‌کنند کهContention کامپیوتر را به حداقل ممکن رسانده و امکان انتقال ده‌ها هزار پیام در ثانیه را به سادگی فراهم می‌آورد.