檢測被阻塞的線程

Question

我有一個有關解決異步應用程序問題的理論（我正在使用CCR），我想知道是否有人可以確認我的邏輯。

如果使用線程（即每核一個）比雙指定的線程相同的應用程序慢的默認數目的CCR基於多線程應用程序 - 這是否意味着線程正在在代碼某處阻塞

想什麼？這是一種快速有效的方法來檢測線程是否被無意中阻塞？

Answer 1

「慢」是什麼意思？

如果您想要自動檢測阻塞的線程，那麼這些線程可能會發送心跳，然後由某種顯示器觀察，但是您的選項是有限的。

Answer 2

判斷線程是否被阻塞的廉價方法是在執行任何可能的阻塞操作之前獲取當前系統時間，然後在操作之後查看已經過了多長時間。例如，在等待消息到達的同時，測量線程被阻塞等待消息到達的時間。

除非總是有足夠多的消息要處理，否則線程將阻塞等待消息。如果你有更多的線程，那麼你有更多的潛在消息生成器（取決於你的設計），因此等待接收消息的線程將更有可能準備好一個。

除非可以保證始終有足夠的消息，否則線程不得不等待，而CPU的一個線程太少。

Answer 3

如果是這樣的話，那意味着你的線程池正在被耗盡（也就是說你有2個線程，但你有異步掛載4個IO或其他東西） - 如果你的工作嚴重IO限制，「一個線程每核心「並不適用。

Answer 4

我發現爲了讓系統保持最小的線程流暢性，我儘可能簡化了處理I/O的任務。他們只是將來自I/O的數據發佈到另一個端口，不做進一步處理。因此數據在其他地方排隊等待以受控方式進行處理，而不會干擾儘可能快地抓取數據的任務。這個處理可能發生在Interleave的ExclusiveGroup中，如果有共享狀態需要考慮......並且一個方便的副作用是獨佔任務永遠不會佔用Dispatcher中的所有線程（但是，我懷疑有可能是更糟糕的方式在CCR API中進行管理）