我有一个关于解决异步应用程序故障的理论（我正在使用CCR），我想知道是否有人可以证实我的逻辑。
如果使用默认线程数（即每个核心一个）的基于CCR的多线程应用程序比指定线程的两倍的同一应用程序慢 - 这是否意味着线程在代码中的某处被阻塞
有什么想法？这是一种检测线程是否被无意阻塞的快速有效方法吗？
答案 0 :(得分：0)
“慢”是什么意思？
如果你想自动检测被阻止的线程，那么这些线程可能会发送一个心跳，然后由某种监视器观察，但你的选择是有限的。
答案 1 :(得分：0)
判断线程是否被阻塞的一种便宜方法是在执行任何可能的阻塞操作之前获取当前系统时间，然后在操作之后，查看已经过了多长时间。例如，在等待消息到达时，请测量以查看线程被阻塞等待消息到达的时间。
除非总是有足够的消息要处理，否则线程将阻止等待消息。如果你有更多的线程，那么你有更多潜在的消息生成器（取决于你的设计），因此等待接收消息的线程更有可能准备一个。
除非你能保证总是有足够的消息所以没有线程必须等待，否则一个到CPU的线程就太少了。
答案 2 :(得分：0)
如果是这种情况，那就意味着您的线程池已经耗尽（即您有2个线程，但是您已经异步挂了4个IO或者其他东西） - 如果您的工作受到大量IO限制，则规则为“每个线程一个核心“并不真正适用。
答案 3 :(得分：0)
我发现为了使系统保持最小的线程流量，我尽可能简洁地处理I / O的任务。他们只是将数据从I / O发布到另一个端口，不再进行进一步处理。因此，数据在其他地方排队以便以受控方式进行处理，而不会干扰尽可能快地抓取数据的任务。这个处理可能发生在Interleave的ExclusiveGroup中，如果有共享状态要考虑......并且一个方便的副作用是独占任务永远不会占用Dispatcher中的所有线程（但是，我怀疑可能有更自然的方式）在CCR API中管理这个）