我在几个不同的Windows服务中遇到此问题，这些服务广泛使用async / await范例来运行许多不同的i / o密集型任务。经过一段时间（可能是8小时到几天），我的一些任务停止服务（也就是说，在i / o完成后它们不会继续）。这不是因为线程池没有线程，因为如果我查看perfmon中的线程，那么进程中会有10-20个线程运行;相反，它看起来好像线程池拒绝创建新线程，即使有任务等待服务。
特别是，看看perfmon，当服务启动并且行为正常时，线程数随着任务在系统中运行而变化，在高活动时从大约20到70或更多，然后慢慢下降。当任务开始挂起时，线程数似乎停留在18-22范围内。
受影响最大的任务似乎是需要一段时间才能完成的任务，特别是等待来自Amazon SQS队列的消息。
我已经尝试将ThreadPool最小线程设置为更高的值;这似乎可以延缓症状的发作（虽然很难说，因为起病是如此多变）但不能消除它。
我希望有人能够充分了解.net 4.5 ThreadPool的内部工作原理，他们可以解释这种行为，或者指出我可能做错的其他事情。