.net框架在阻塞调用期间做什么？

问题描述

| 我在代码中观察到一些奇怪的行为，并且试图追踪源代码。我有两个单线程.net应用程序正在运行，并且在同一台计算机上彼此发送WCF消息。它们非常简单，先进行阻塞写，然后进行阻塞读。我注意到在日志中的阻塞呼叫中，我在10毫秒内读写的时间达到了99.99％。但是，在极少数情况下，可能需要500-2000毫秒。我试图确切地了解为什么会这样。我正在跟踪我的应用程序，但可能有一些奇怪的怪癖，可能是罪魁祸首，但我想知道这是否正在进入我不了解的框架方面。 所以我的问题是，当发生诸如阻塞调用之类的事情时，.net应用程序是否会在阻塞执行主线程的同时开始运行后台进程（例如垃圾回收）？ 感谢您的时间。     

解决方法

垃圾收集器拥有自己的专用资源，因此无论您是否使用阻塞调用都没有关系。 阻塞调用基本上意味着在UI线程上运行长时间运行的任务。根据应用程序的类型（WPF，Windows，控制台），UI线程的定义会有所不同，但是在UI线程上运行任务时，UI线程的所有消息都会排队。 您看到的效果可能是由于其他一些问题引起的，例如磁盘或网络瓶颈导致长时间运行的任务延迟。使用perfmon并将延迟时间与perfmon日志进行匹配可能会很有用。     ,您需要考虑到系统上还有许多其他应用程序正在运行的事实。通常情况下，运行可能会很顺利，但是每隔一段时间，您可能会有多个应用程序争夺处理器时间，这会导致您看到延迟。您看到.01％的时间的怪异滞后可能与.NET无关，而与该特定时间点OS上发生的事情更多有关。 我认为问题不在于垃圾收集。您的应用听起来很简单而且紧凑，收集的垃圾可能很少。您正在运行开发机器，并且如果您像大多数开发者一样，将同时打开各种服务器，IDE，文本编辑器和许多Web浏览器选项卡。尝试以下操作：打开较重的应用程序，直到您的物理内存利用率超过75％或更高。 （即使在应用程序之间执行Alt + Tab似乎也很慢。）我猜您会看到更大的延迟和更多的延迟，这是因为将出现更多的页面错误，因此，硬盘的命中率也会增加（主要瓶颈）减慢了整个过程。     ,  所以我的问题是，当   诸如阻塞呼叫之类的   .net应用程序开始运行   后台进程（例如垃圾   集合），而主线程   执行被阻止？ CLR在阻塞调用期间所做的操作完全是不确定的，不是您可以依赖的。您观察到的差异可能是由于无法控制的许多因素（例如网络等待时间）引起的。     ,首先，如果您不使用svctraceutil，请确保使用它，因为它将为您提供大量信息。 WCF的功能取决于您在服务/客户端中设置的数百种配置选项。假设您在长时间的异常调用中使用了建立在tcp之上的绑定，它将重新建立会话或重新传输失败的数据包。使用框架的优点和缺点是，只要它满足您的需求，您就不必担心具体细节。如果您需要细粒度的控制，则始终可以实现自定义绑定或使用原始TCP / IP通信。