问题描述
确定，据我了解，在.NET线程池保留了一些后台线程准备用于某种类型的任务。
OK, as I understand it, the .NET Threadpool maintains a number of background threads ready to be used for tasks of some kind.
获取/ SetMinThreads和获取/ SetMaxThreads方法包含可退还或调整的两个参数。
The Get/SetMinThreads and Get/SetMaxThreads methods contain two parameters that can be returned or adjusted.
据MSDN这两个参数指示工作线程的数量和用于异步IO操作线程的数目。
According to MSDN the two parameters indicate the number of worker threads and the number of threads used for async IO operations.
什么类型的操作使用线程，这些特殊类型的？
What type of operations use these specific type of thread?
工作线程：
- QueueUserWorkItem我presume。
- 还有别的吗？
异步IO线程：
- 在例如文件流调用的BeginXXX，Endxxx时使用？ （或者网络，串行端口等）
- 还有别的吗？
感谢您的任何澄清，或关于这个问题一个很好的链接。
Thanks for any clarification, or a good link on the subject.
推荐答案
是的，QUWI也是一个委托类型的的BeginInvoke（）方法。并且通过少数几类就业，BackgroundWorker的是最有名的例子。其中引擎盖下仅使用委托的BeginInvoke的（）。
Yes, QUWI but also a delegate type's BeginInvoke() method. And employed by a few classes, BackgroundWorker is the best known example. Which under the hood merely uses delegate's BeginInvoke().
I / O完成线程是一个非常低级的Windows功能得到code的I / O请求完成时可以快速运行。从ReadFileEx（）函数的最后一个参数最明显的，还有其他的。托管相当于通过ThreadPool.BindHandle（）暴露出来。
I/O completion threads are a very low-level Windows feature to get code to run quickly when an I/O request completes. Most visible from the ReadFileEx() function's last argument, there are others. The managed equivalent is exposed through ThreadPool.BindHandle().
这是.NET类的工作得到这一权利。短短几年的使用它：的FileStream，PipeStream，FileSystemWatcher的，插座，的SerialPort的内部工作线程和一些WCF通道支持类
It is the job of .NET classes to get that right. Just a few use it: FileStream, PipeStream, FileSystemWatcher, Socket, SerialPort's internal worker thread and some WCF channel support classes.
我个人没有得到API中暴露了这些配置的详细信息，特别是I / O完成线程的人的忠实粉丝。这是一个有点虎头蛇尾的BCL团队，他们结束了一些FUD。这些设置会影响整个程序，默认已经相当慷慨的。他们修改一下，大约相当于调用GC.Collect的（）。如果你能找到一个很好的理由去改变的，那最好是与仅一小时停留在一个地狱般的地方的时候留下来赶上飞机回了家。在那里：）
I'm personally not a big fan of getting these config details exposed in the API, especially the I/O completion thread ones. It's a bit of a cop-out by the BCL team, some FUD on their end. These settings affect the entire program, the defaults are already quite generous. Tinkering with them is roughly equivalent to calling GC.Collect(). If you ever manage to find a good reason to change them, that better be when stuck in a hellhole with only one hour left to catch the plane back home. Been there :)
这篇关于.NET线程池工作线程和异步IO线程的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！