为什么缓存WCF通道是件坏事？

我在网上读了很多WCF文章，似乎大多数人都在缓存ChannelFactory对象，而不是通道本身。似乎大多数人都害怕使用通道缓存，因为他们不想处理可能导致缓存通道无法使用的网络故障。但是，通过捕获方法上的通信异常，重新创建通道，并使用反射重播方法，可以很容易地解决这个问题

还有一些人认为进行通道缓存是不好的，因为所有通信都将通过单个通道进行。见下文

这一定是件坏事吗？不能跨线程共享通道吗？对这个通道的多个方法调用将被串行处理，性能会受到影响吗

我还没有发现共享频道会降低性能的证据。我确实发现，使用缓存通道比使用非缓存通道快5倍左右，即使这意味着必须使用反射在缓存通道上进行方法调用

另一个优点是不必在所有WCF调用中使用try/catch/finally语句，以便在完成时在通道上调用Close（）、Abort（）或Dispose（）。在我看来，WCF似乎朝着错误的方向迈出了一步，迫使开发人员必须管理WCF频道资源。在.NET远程处理中，您使用Activator类创建了代理，并且不必对其执行任何操作来清理它。.NET Framework为您处理了所有这些问题。

2个主要原因：

ChannelFactory的创建成本很高，而且它是线程安全的=>缓存的完美候选

由通道工厂生成的通道创建成本不高，但它不是线程安全的（实际上它是线程安全的，但并发调用将被阻止并按顺序执行）=>不要在多线程环境中缓存它

---

这里有一个更详细的例子。

@Tom C。这里有一个更详细的例子。根据它，通道确实是线程安全的，但会阻止并发访问并按顺序执行。根据使用的WCF选项，通道可以包含特定于某个会话的状态。所以最好的建议是：缓存工厂，而不是通道。是的，我同意相同通道上的并发调用将按顺序执行，在多线程环境中可能会出现问题。但这可以通过通道池来解决。创建一个频道可能没有创建ChannelFactory那么昂贵，但仍然有成本。这一成本随着时间的推移而增加，对于一些高性能系统来说是不可接受的。也许微软认为大多数软件系统可以在没有缓存通道的性能增益的情况下生存，但这仍然不能解释为什么微软强迫开发人员控制通道清理。为什么让开发人员必须将其代理强制转换为IClientChannel，以便开发人员可以确定是否在该通道上调用Close（）/Abort（）/Dispose（）。当通道超出范围时，为什么不能作为垃圾收集的一部分自动执行此操作。这是一个好问题。