是不是意味着它为每个线程抓取了一个new线程池线程
完成 IO 操作 ?或者它是一个专用的线程数
这个?
为每个 I/O 请求创建一个新线程会非常低效,以至于无法达到目的。相反,运行时从少量线程开始(具体数量取决于您的环境),并根据需要添加和删除工作线程(具体算法同样因您的环境而异)。 .NET 的主要版本在此实现中都发生了变化,但基本思想保持不变:运行时尽最大努力创建和维护尽可能多的线程,以有效地为所有 I/O 提供服务。在我的系统(Windows 8.1、.NET 4.5.2)上,一个全新的控制台应用程序在输入 Main 时只有 3 个线程,并且在请求实际工作之前,这个数字不会增加。
这是否意味着我将同时拥有 1000 个 IOCP 线程池线程
(有点)跑这里,什么时候都完成了?
没有。当您发出 I/O 请求时,线程将在完成端口上等待以获取结果并调用注册的任何回调来处理结果(无论是通过 BeginXXX 方法还是作为任务的继续)。如果你使用了一个任务并且不等待它,那么该任务就简单地结束,线程返回到线程池中。
如果你真的等待它呢? 1000 个 I/O 请求的结果不会真正同时到达,因为中断不会同时到达,但是假设间隔比我们需要处理它们的时间短得多。在这种情况下,线程池将继续旋转线程来处理结果,直到达到最大值,并且任何进一步的请求最终都将在完成端口上排队。根据您的配置方式,这些线程可能需要一些时间才能启动。
考虑以下(故意很糟糕的)玩具程序:
static void Main(string[] args) {
printThreadCounts();
var buffer = new byte[1024];
const int requestCount = 30;
int pendingRequestCount = requestCount;
for (int i = 0; i != requestCount; ++i) {
var stream = new FileStream(
@"C:\Windows\win.ini",
FileMode.Open, FileAccess.Read, FileShare.ReadWrite,
buffer.Length, FileOptions.Asynchronous
);
stream.BeginRead(
buffer, 0, buffer.Length,
delegate {
Interlocked.Decrement(ref pendingRequestCount);
Thread.Sleep(Timeout.Infinite);
}, null
);
}
do {
printThreadCounts();
Thread.Sleep(1000);
} while (Thread.VolatileRead(ref pendingRequestCount) != 0);
Console.WriteLine(new String('=', 40));
printThreadCounts();
}
private static void printThreadCounts() {
int completionPortThreads, maxCompletionPortThreads;
int workerThreads, maxWorkerThreads;
ThreadPool.GetMaxThreads(out maxWorkerThreads, out maxCompletionPortThreads);
ThreadPool.GetAvailableThreads(out workerThreads, out completionPortThreads);
Console.WriteLine(
"Worker threads: {0}, Completion port threads: {1}, Total threads: {2}",
maxWorkerThreads - workerThreads,
maxCompletionPortThreads - completionPortThreads,
Process.GetCurrentProcess().Threads.Count
);
}
在我的系统(有 8 个逻辑处理器)上,输出如下(结果可能因您的系统而异):
Worker threads: 0, Completion port threads: 0, Total threads: 3
Worker threads: 0, Completion port threads: 8, Total threads: 12
Worker threads: 0, Completion port threads: 9, Total threads: 13
Worker threads: 0, Completion port threads: 11, Total threads: 15
Worker threads: 0, Completion port threads: 13, Total threads: 17
Worker threads: 0, Completion port threads: 15, Total threads: 19
Worker threads: 0, Completion port threads: 17, Total threads: 21
Worker threads: 0, Completion port threads: 19, Total threads: 23
Worker threads: 0, Completion port threads: 21, Total threads: 25
Worker threads: 0, Completion port threads: 23, Total threads: 27
Worker threads: 0, Completion port threads: 25, Total threads: 29
Worker threads: 0, Completion port threads: 27, Total threads: 31
Worker threads: 0, Completion port threads: 29, Total threads: 33
========================================
Worker threads: 0, Completion port threads: 30, Total threads: 34
当我们发出 30 个异步请求时,线程池很快就会使 8 个线程可用于处理结果,但之后它只会以每秒 2 个左右的悠闲速度启动新线程。这表明,如果您想正确利用系统资源,最好确保您的 I/O 处理快速完成。实际上,让我们将委托更改为以下内容,这表示对请求的“正确”处理:
stream.BeginRead(
buffer, 0, buffer.Length,
ar => {
stream.EndRead(ar);
Interlocked.Decrement(ref pendingRequestCount);
}, null
);
结果:
Worker threads: 0, Completion port threads: 0, Total threads: 3
Worker threads: 0, Completion port threads: 1, Total threads: 11
========================================
Worker threads: 0, Completion port threads: 0, Total threads: 11
同样,结果可能会因您的系统和不同的运行而有所不同。在这里,我们几乎看不到完成端口线程的运行,而我们发出的 30 个请求在没有启动新线程的情况下完成。您应该会发现您可以将“30”更改为“100”甚至“100000”:我们的循环启动请求的速度不能超过完成请求的速度。但是请注意,结果严重偏向于我们,因为“I/O”一遍又一遍地读取相同的字节,并且将从操作系统缓存而不是从磁盘读取来提供服务。这并不是为了展示实际的吞吐量,当然,只是为了展示开销的差异。
要使用工作线程而不是完成端口线程重复这些结果,只需将FileOptions.Asynchronous 更改为FileOptions.None。这使得文件访问同步,异步操作将在工作线程上完成,而不是使用完成端口:
Worker threads: 0, Completion port threads: 0, Total threads: 3
Worker threads: 8, Completion port threads: 0, Total threads: 15
Worker threads: 9, Completion port threads: 0, Total threads: 16
Worker threads: 10, Completion port threads: 0, Total threads: 17
Worker threads: 11, Completion port threads: 0, Total threads: 18
Worker threads: 12, Completion port threads: 0, Total threads: 19
Worker threads: 13, Completion port threads: 0, Total threads: 20
Worker threads: 14, Completion port threads: 0, Total threads: 21
Worker threads: 15, Completion port threads: 0, Total threads: 22
Worker threads: 16, Completion port threads: 0, Total threads: 23
Worker threads: 17, Completion port threads: 0, Total threads: 24
Worker threads: 18, Completion port threads: 0, Total threads: 25
Worker threads: 19, Completion port threads: 0, Total threads: 26
Worker threads: 20, Completion port threads: 0, Total threads: 27
Worker threads: 21, Completion port threads: 0, Total threads: 28
Worker threads: 22, Completion port threads: 0, Total threads: 29
Worker threads: 23, Completion port threads: 0, Total threads: 30
Worker threads: 24, Completion port threads: 0, Total threads: 31
Worker threads: 25, Completion port threads: 0, Total threads: 32
Worker threads: 26, Completion port threads: 0, Total threads: 33
Worker threads: 27, Completion port threads: 0, Total threads: 34
Worker threads: 28, Completion port threads: 0, Total threads: 35
Worker threads: 29, Completion port threads: 0, Total threads: 36
========================================
Worker threads: 30, Completion port threads: 0, Total threads: 37
线程池每秒启动一个工作线程,而不是为完成端口线程启动的两个。显然,这些数字取决于实现,并且可能会在新版本中发生变化。
最后,让我们演示一下ThreadPool.SetMinThreads 的用法,以确保可用于完成请求的最少线程数。如果我们回到FileOptions.Asynchronous 并将ThreadPool.SetMinThreads(50, 50) 添加到我们玩具程序的Main 中,结果是:
Worker threads: 0, Completion port threads: 0, Total threads: 3
Worker threads: 0, Completion port threads: 31, Total threads: 35
========================================
Worker threads: 0, Completion port threads: 30, Total threads: 35
现在,线程池不再耐心地每两秒添加一个线程,而是继续旋转线程直到达到最大值(在这种情况下不会发生,因此最终计数保持在 30)。当然,所有这 30 个线程都陷入了无限等待——但如果这是一个真实的系统,那么这 30 个线程现在可能会做有用的工作,即使不是非常有效的工作。不过,我不会尝试 this 处理 100000 个请求。