以流資源的並行操作的進度限制工作

Question

，我發現自己最近使用SemaphoreSlim類，限制在（大）的可並行操作的進度工作流資源：

// The below code is an example of the structure of the code, there are some 
// omissions around handling of tasks that do not run to completion that should be in production code 

SemaphoreSlim semaphore = new SemaphoreSlim(Environment.ProcessorCount * someMagicNumber); 
foreach (var result in StreamResults()) 
{ 
    semaphore.Wait(); 
    var task = DoWorkAsync(result).ContinueWith(t => semaphore.Release()); 
    ... 
} 

這是爲了避免將太多的結果帶入內存，並且程序無法應付（通常通過OutOfMemoryException證明）。儘管代碼工作正常並且性能合理，但仍然感覺不太好。特別是someMagicNumber乘數，它雖然通過分析進行調整，但可能並不盡如人意，並且也不適應DoWorkAsync的實施變化。

以同樣的方式，線程池可以克服安排許多事情執行的障礙，我希望能夠克服根據可用資源將許多事情加載到內存中的障礙。

由於確定性地不可能確定OutOfMemoryException是否會發生，我明白我所尋找的可能只能通過統計方式實現，或者根本不可能實現，但是我希望我錯過了一些東西。

Answer 1

在這裏，我想說，你可能會推翻這個問題。過沖的後果相當高（程序崩潰）。太低的後果是，程序可能會減慢。只要你仍然有一些超出最小值的緩衝區，進一步增加到緩衝區通常幾乎沒有效果，除非管道中任務的處理時間非常不穩定。

如果你的緩衝區不斷填滿，通常意味着管道中的任務執行得比其後的任務快得多，所以即使沒有相當小的緩衝區，它也可能始終確保任務跟隨它有一些工作。獲得緩衝區90％好處所需的緩衝區大小通常會非常小（可能有幾十個項目），而獲得OOM錯誤所需的一側就像6+ 大於的訂單。只要你處在這兩個數字之間的某個位置（這是一個非常大的範圍），你就會很好。

只要運行你的靜態測試，選擇一個靜態數字，或許爲「以防萬一」增加幾個百分點的額外數值，你應該很好。至多，我會將一些幻數移到配置文件中，以便在輸入數據或機器規格發生根本性變化的情況下，可以在不重新編譯的情況下更改它們。