在 C#（.NET）中，Semaphore 和 SemaphoreSlim 都用于控制同時訪問某一資源或池的線程數(shù)量（即“信號量”機制），但它們在實現(xiàn)方式、性能、功能和適用場景上有顯著區(qū)別。

下面從多個維度詳細對比兩者，并附使用示例。

一、核心區(qū)別概覽

二、詳細對比說明

1.跨進程支持

Semaphore：

// 進程 A
var sem = new Semaphore(2, 2, "MyGlobalSemaphore");

// 進程 B
var sem = Semaphore.OpenExisting("MyGlobalSemaphore");

適用于多個進程共享有限資源（如硬件設備、全局連接池）。

• 可創(chuàng)建命名信號量，供多個進程共享。

SemaphoreSlim：

• 僅限當前進程內(nèi)使用，無法跨進程。
• 內(nèi)部使用 ManualResetEventSlim 或自旋，無內(nèi)核對象名稱。

2.異步支持（關(guān)鍵區(qū)別?。?/h3>

SemaphoreSlim 提供 WaitAsync() 方法，完美支持 async/await：

private static SemaphoreSlim _sem = new SemaphoreSlim(3);

public async Task ProcessAsync()
{
    await _sem.WaitAsync(); // 異步等待，不阻塞線程
    try
    {
        await CallExternalApiAsync(); // 模擬 I/O 操作
    }
    finally
    {
        _sem.Release();
    }
}

? 非常適合 Web API、高并發(fā) I/O 場景（如限流）。

Semaphore 只有同步方法 WaitOne()，在異步上下文中會阻塞線程，導致線程池饑餓：

// ? 不推薦在 async 方法中使用
sem.WaitOne(); // 阻塞當前線程！

3.性能差異

• SemaphoreSlim：

  • 在無競爭或輕度競爭時，完全在用戶態(tài)運行，無系統(tǒng)調(diào)用。
  • 即使有競爭，也先自旋（SpinWait），失敗后才使用輕量內(nèi)核事件。
  • 延遲低、吞吐高。

• Semaphore：

  • 每次 WaitOne() / Release() 都觸發(fā)內(nèi)核模式切換（約 1000~3000 納秒開銷）。
  • 適合低頻、長時間持有的場景。

?? 性能測試表明：在高頻短臨界區(qū)場景，SemaphoreSlim 比 Semaphore 快 5~10 倍以上。

4.API 差異

三、使用示例對比

? 場景：限制并發(fā) HTTP 請求（推薦用SemaphoreSlim）

// 使用 SemaphoreSlim（支持異步）
private static readonly SemaphoreSlim _throttle = new SemaphoreSlim(5, 5);

public async Task<string> FetchDataAsync(string url)
{
    await _throttle.WaitAsync(); // 異步等待，不占線程
    try
    {
        using var client = new HttpClient();
        return await client.GetStringAsync(url);
    }
    finally
    {
        _throttle.Release();
    }
}

? 高效、不阻塞線程池線程，適合 ASP.NET Core 等高并發(fā)環(huán)境。

? 場景：兩個進程共享最多 2 個數(shù)據(jù)庫連接（必須用Semaphore）

進程 A：

var sem = new Semaphore(2, 2, "Global\\DBConnectionPool");
sem.WaitOne();
// 使用數(shù)據(jù)庫連接...
sem.Release();

進程 B：

var sem = Semaphore.OpenExisting("Global\\DBConnectionPool");
sem.WaitOne();
// 使用數(shù)據(jù)庫連接...
sem.Release();

? 只有 Semaphore 能跨進程協(xié)調(diào)資源。

四、如何選擇？

五、注意事項

1.SemaphoreSlim不是線程安全的“計數(shù)器”

• 它只控制進入數(shù)量，不保證操作原子性。
• 臨界區(qū)內(nèi)仍需其他同步機制（如 lock）保護共享數(shù)據(jù)。

2.避免在SemaphoreSlim中阻塞線程

// ? 錯誤：在 WaitAsync 后又同步阻塞
await _sem.WaitAsync();
Thread.Sleep(1000); // 浪費線程！應使用 await Task.Delay(1000)

3.Release()調(diào)用次數(shù)不能超過Wait()

• 否則會拋出 SemaphoreFullException。
• 建議始終用 try/finally 包裹。

? 總結(jié)

?? 默認選擇 SemaphoreSlim；只有需要跨進程時才用 Semaphore。

到此這篇關(guān)于C# Semaphore與SemaphoreSlim區(qū)別小結(jié)的文章就介紹到這了,更多相關(guān)C# Semaphore SemaphoreSlim內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論