背景/简介：
非常奇怪的问题，在抛出特定异常时，似乎所有其他线程都停止执行，直到处理异常为止。该应用程序是一个代理服务器，通过一个tcp套接字池连接多个请求（在任何一个时间范围内数百个），它通过socks连接连接到N个其他代理客户端。这也是通过传递委托而不是使用异常来尝试，但性能结果相同。
正常操作下的日志片段：
14:40:17.700 [PrxSvc:9058] --> [200] 1217ms http://redact.example.com
14:40:17.700 [PrxSvc:9058] C-DEBUG:C
14:40:17.716 [PrxSvc:9058] --> [200] 1098ms http://redact.example.com
14:40:17.716 [PrxSvc:9058] C-DEBUG:C
14:40:17.727 [PrxSvc:9054] --> [200] 905ms http://redact.example.com
14:40:17.727 [PrxSvc:9054] C-DEBUG:C
14:40:17.778 [PrxSvc:9050] --> [200] 453ms http://redact.example.com
14:40:17.778 [PrxSvc:9050] C-DEBUG:C
14:40:17.781 [Unnamed Thread] C-DEBUG:A
14:40:17.781 [Unnamed Thread] C-DEBUG:B
14:40:17.796 [PrxSvc:9058] --> [200] 652ms http://redact.example.com
14:40:17.796 [PrxSvc:9058] C-DEBUG:C
14:40:17.807 [PrxSvc:9056] --> [200] 1555ms http://redact.example.com
14:40:17.807 [PrxSvc:9056] C-DEBUG:C
14:40:17.816 [PrxSvc:9064] --> [200] 396ms http://redact.example.com
套接字池重用与域的连接，但是当外部服务器关闭连接时，我们显然没有收到任何通知。当我们尝试通过TcpSocksHandler.TaskHandler方法重用此连接时：
socks.Send(buffer, 0, rcv, SocketFlags.None);
socks.Receive(new byte[1], 0, 1, SocketFlags.Peek);
此异常包含以下内容：
catch
{
//The socket is bad, we should get a new socket.
Log("This socket has expired! - Server has closed the connection.");
Log(String.Format("This socket was {0} seconds old: {1}", seconds, socks.Guid));
socks.Dispose();
Log("C-DEBUG:1");
throw new SocksSocketFailureException(); //throw exception. to bubble back up.
}
然后它被调用代码捕获，在堆栈中多次，如下所示：
DoHandleRequest{...
try
{
_actualEndPoint = TcpSocksHandler.TaskHandler(socket, context.SocksSocket, 30000000, method);
}
catch (SocksSocketFailureException ssfe)
{
context.SocksSocket = null;
Logger.Log("C-DEBUG:2");
throw;
}
}
ProxyBase.HandleRequest{...
try
{
...
success = DoHandleRequest(context, out bytes);
}
catch (SocksSocketFailureException ssfex)
{
Logger.Log("C-DEBUG:3");
throw;
}
}
ProxyManager.HandleRequest{
while (true)
{
// Pick the best available proxy to handle the request
Logger.Log("C-DEBUG:A");
IProxy proxy = GetNextProxy(context) ?? NullProxy.Instance;
Logger.Log("C-DEBUG:B");
try
{
// Process the request
proxy.HandleRequest(context);
Logger.Log("C-DEBUG:C");
break;
}
catch(SocksSocketFailureException ssfex)
{
Logger.Log("C-DEBUG:4");
}
catch (Exception)
{
break;
}
}
}
从下面的日志片段中，您可以看到此（或缺少）
的表现14:40:34.090 [PrxSvc:9068] C-DEBUG:A
14:40:34.090 [PrxSvc:9068] C-DEBUG:B
14:40:34.231 [PrxSvc:9068] This socket has expired! - Server has closed the connection.
14:40:34.231 [PrxSvc:9068] This socket was 6.281049 seconds old: 61cc51b9-f121-4529-9649-7defcc1f5586
14:40:34.231 [PrxSvc:9068] C-DEBUG:1
14:40:34.528 [PrxSvc:9068] C-DEBUG:2
14:40:34.715 [PrxSvc:9068] C-DEBUG:3
14:40:34.918 [PrxSvc:9068] C-DEBUG:4
14:40:34.918 [PrxSvc:9068] C-DEBUG:A
上面没有编辑任何日志行 - 几乎整个秒都没有处理任何其他行！ （我们通常可以处理一百个请求）。 另外，仅仅在堆栈中冒泡异常的行为似乎需要一秒钟（有时更多！）。 - 请注意上述日志行的时间。例如DEBUG：3和DEBUG：4 !!之间的差距为2秒。
我不知道是什么原因引起的。任何建议/想法将不胜感激！
更新
基于Eamon的问题，我将相同的x64版本推送到非生产本地计算机，运行Windows8 64位。安装为服务，发布版本，如上例所示。唯一的另一个区别是它现在定位4个代理节点（PrxSvc 9050,9052,9054,9056），而不是之前的80个。 我现在不能再说这些异常步骤是否阻止了线程执行，因为它们是及时执行的：
16:53:59.787 [PrxSvc:9056] This socket has expired! - Server has closed the connection.
16:53:59.787 [PrxSvc:9056] This socket was 0.1280009 seconds old: 69d12cc9-9456-47db-86b2-a2ebf87b41bf
16:53:59.787 [PrxSvc:9056] C-DEBUG:1
16:53:59.787 [PrxSvc:9056] C-DEBUG:2
16:53:59.787 [PrxSvc:9056] C-DEBUG:3
16:53:59.787 [PrxSvc:9056] C-DEBUG:4
16:53:59.787 [PrxSvc:9056] C-DEBUG:A
在这台机器上，代码目前正以每秒约80个请求的速度处理800个并发请求，并且可以轻松处理更多... 究竟是什么造成了这种差异？！
为了完整性，我重新进行了第一次测试（在win2008服务器上），有4个节点，而不是80个，并得到了相同的垃圾结果：
17:22:44.891 [PrxSvc:9054] C-DEBUG:B
17:22:45.063 [PrxSvc:9054] This socket has expired! - Server has closed the connection.
17:22:45.063 [PrxSvc:9054] This socket was 25.84375 seconds old: cfdee74d-9941-4c8c-80cd-f32aa14b7877
17:22:45.063 [PrxSvc:9054] C-DEBUG:1
17:22:45.485 [PrxSvc:9054] C-DEBUG:2
17:22:45.751 [PrxSvc:9054] C-DEBUG:3
17:22:46.016 [PrxSvc:9054] C-DEBUG:4
答案 0 :(得分：1)
这不是你的问题的答案，你的程序中的错误是什么，但是如果没有看到全局或我自己测试你的代码，我几乎无法分辨。通常我会为此写评论，但我的文字太长了。
您的第一个示例日志（“正常操作”）对我来说有点混乱。只有一个C-DEBUG:A和C-DEBUG:B，而至少每个C-DEBUG:C都必须有一个，不是吗？
其他示例看起来很好，一切都按照我的预期发生（ A =＆gt; B =＆gt; exception =＆gt; 1 =＆gt; 2 =＆gt; 3 =＆gt; 4 =＆gt; A < / em>的）。好吧，似乎只有一个线程，但这些例子并不能说明这是错误的;我看到另一个帖子没有第二个C-DEBUG:A。你期待什么呢？
关于你的更新：这里我想知道更多关于你的测试机器的性能，因为每次抛出异常都需要一些执行时间。这就是为什么在循环中抛出异常是一个很大的性能损失的原因。服务器的时间似乎有点慢，但从我的角度来看还不错。
虽然不能给你提示你的问题，但至少我可以给你一个声明，即抛出异常不是其他线程的阻塞因素。证明我写的一个小程序（如果你想知道我是怎么做的，请参阅下面的源代码）。该计划的输出是
19:31:09.2788 [Thread-0] 0
19:31:09.2788 [Thread-1] 1
19:31:09.3908 [Thread-0] 0
19:31:09.3908 [Thread-1] 1
19:31:09.4908 [Thread-1] 1
19:31:09.4908 [Thread-0] 0
19:31:09.5908 [Thread-0] 0
19:31:09.5998 [Thread-1] Caught exception callstack frame 29
19:31:09.6078 [Thread-1] Caught exception callstack frame 28
19:31:09.6148 [Thread-1] Caught exception callstack frame 27
19:31:09.6218 [Thread-1] Caught exception callstack frame 26
19:31:09.6288 [Thread-1] Caught exception callstack frame 25
19:31:09.6358 [Thread-1] Caught exception callstack frame 24
19:31:09.6418 [Thread-1] Caught exception callstack frame 23
19:31:09.6488 [Thread-1] Caught exception callstack frame 22
19:31:09.6548 [Thread-1] Caught exception callstack frame 21
19:31:09.6608 [Thread-1] Caught exception callstack frame 20
19:31:09.6668 [Thread-1] Caught exception callstack frame 19
19:31:09.6728 [Thread-1] Caught exception callstack frame 18
19:31:09.6778 [Thread-1] Caught exception callstack frame 17
19:31:09.6828 [Thread-1] Caught exception callstack frame 16
19:31:09.6888 [Thread-1] Caught exception callstack frame 15
19:31:09.6908 [Thread-0] 0
19:31:09.6938 [Thread-1] Caught exception callstack frame 14
19:31:09.6978 [Thread-1] Caught exception callstack frame 13
19:31:09.7028 [Thread-1] Caught exception callstack frame 12
19:31:09.7078 [Thread-1] Caught exception callstack frame 11
19:31:09.7128 [Thread-1] Caught exception callstack frame 10
19:31:09.7168 [Thread-1] Caught exception callstack frame 9
19:31:09.7218 [Thread-1] Caught exception callstack frame 8
19:31:09.7258 [Thread-1] Caught exception callstack frame 7
19:31:09.7299 [Thread-1] Caught exception callstack frame 6
19:31:09.7339 [Thread-1] Caught exception callstack frame 5
19:31:09.7369 [Thread-1] Caught exception callstack frame 4
19:31:09.7409 [Thread-1] Caught exception callstack frame 3
19:31:09.7439 [Thread-1] Caught exception callstack frame 2
19:31:09.7469 [Thread-1] Caught exception callstack frame 1
19:31:09.7499 [Thread-1] Caught exception callstack frame 0
19:31:09.7509 [Thread-1] 1
19:31:09.7919 [Thread-0] 0
19:31:09.8509 [Thread-1] 1
19:31:09.8919 [Thread-0] 0
19:31:09.9509 [Thread-1] 1
19:31:10.0509 [Thread-1] 1
19:31:10.1509 [Thread-1] 1
19:31:10.2509 [Thread-1] 1
19:31:10.3509 [Thread-1] 1
正如您所看到的，线程 Thread-0 打印0，而 Thread-1 的例外工作在callstack上。这里没有阻止！
在此参考我的计划：
class Program {
class MyException : Exception {}
// A class for give the starting thread operation some parameters
class ThreadStartParameter {
// For identifying each thread
public int Id { get; set; }
// For building up a deeper callstack frame
public int CallStackDepth { get; set; }
// Indicates that this thread should throw an exception
public bool ThrowException { get; set; }
}
static void Main(string[] args) {
// Create two threads and let them run concurrently
Thread t0 = new Thread(BuildUpCallStack) { Name = "Thread-0" };
Thread t1 = new Thread(BuildUpCallStack) { Name = "Thread-1" };
t0.Start(new ThreadStartParameter {
Id = 0,
CallStackDepth = 0,
ThrowException = false
});
t1.Start(new ThreadStartParameter {
Id = 1,
CallStackDepth = 0,
ThrowException = true
});
Console.Read();
}
// Recursive helper method to build a callstack of 30 frames, which
// is used to rethrow an exception at each level
static void BuildUpCallStack(object data) {
ThreadStartParameter parameter = (ThreadStartParameter)data;
if (parameter.CallStackDepth < 30) {
try {
BuildUpCallStack(new ThreadStartParameter {
Id = parameter.Id,
CallStackDepth = parameter.CallStackDepth + 1,
ThrowException = parameter.ThrowException
});
} catch (MyException e) {
Log(string.Format("Caught exception callstack frame {0}",
parameter.CallStackDepth));
// If an exception occured, rethrow it unless this
// callstack frame was the first
if (parameter.CallStackDepth != 0) throw;
// If this frame was the first in callstack, restart the
// thread but this time without throwing an exception (for
// demonstrate such a restart character like your Proxies do)
BuildUpCallStack(new ThreadStartParameter {
Id = parameter.Id,
CallStackDepth = 0,
ThrowException = false
});
}
return;
}
DoSomething(parameter);
}
static void DoSomething(object data) {
ThreadStartParameter parameter = (ThreadStartParameter)data;
for (int counter = 0; counter < 7; counter++) {
if (counter == 3 && parameter.ThrowException)
throw new MyException();
Log(parameter.Id);
Thread.Sleep(100);
}
}
static void Log(object message) {
Console.WriteLine(
" {0:HH:mm:ss.ffff} [{1}] {2}",
DateTime.Now,
Thread.CurrentThread.Name,
message.ToString());
}
}
如果你在你的测试机器上尝试这个程序，我猜你应该开始更多“好”的线程（不会抛出异常）和/或增加所需的callstack深度，以便像我一样看到效果。
答案 1 :(得分：0)
例外是便宜的投掷和昂贵的捕获。除非代码知道如何处理它们，否则不要捕获异常。这似乎是C-Debug的情况：2和C-Debug：3。你也有一个已知的条件，即对方关闭了它的连接。您不应该使用异常来处理这个问题。您需要公开类似于IsConnected的方法或属性，并在循环中检查它而不是依赖于抛出的异常：
while(true) {
IProxy proxy = GetNextProxy(context) ?? NullProxy.Instance;
if (!proxy.IsConnected)
continue;
try {
proxy.HandleRequest(context);
break;
} catch {
// handle actual exceptional cases here
}
}
您可以在上面的代码中添加一个计数器或计时器，如果需要，则在x次重试或特定时间段到期的情况下抛出异常，但无论如何IsConnected属性检查将提高性能你的代码很大。