今天我尝试对在XDocument上运行的foreach语句进行一些优化。
优化之前：
foreach (XElement elem in xDoc.Descendants("APSEvent").ToList())
{
//some operations
}
优化后：
Parallel.ForEach(xDoc.Descendants("APSEvent").ToList(), elem =>
{
//same operations
});
我发现在Parallel.ForEach(...)中，.NET只开启了一个线程！因此，Parallel的时间跨度比标准的foreach要大。
你认为为什么.NET只开启了一个线程？是由于文件锁定吗？ 谢谢
并不是错误，Parallel.ForEach可能会使用比请求的线程更少的线程以实现更好的性能。根据MSDN [链接]:
默认情况下，Parallel.ForEach和Parallel.For方法可以使用变量数量的任务。这就是为什么例如ParallelOptions类具有MaxDegreeOfParallelism属性而不是“MinDegreeOfParallelism”属性。 这个想法是系统可以使用比请求的线程更少的线程来处理循环。
.NET线程池通过允许并行任务的工作线程数量随时间动态变化，适应于不断变化的工作负载。在运行时，系统观察是否增加线程数量可以改善整体吞吐量或降低整体吞吐量，并相应地调整工作线程数量。
从问题描述中，没有任何说明TPL为什么没有生成更多的线程。
在问题中没有任何证据表明这是问题所在。这很容易解决：您可以在进入循环之前记录线程ID，并将其作为您的循环内的第一件事。
如果始终是相同的数字，则是TPL无法生成线程。然后，您应该尝试不同版本的代码以及何种更改触发TPL序列化所有内容。一个原因可能是列表中的元素数量较少。TPL会对您的集合进行分区，如果只有几个项目，您可能最终只会得到一个批次。顺便说一下，这种行为是可配置的。
可能是您在循环中无意中锁定了某个锁，那么您将看到许多不同的数字，但不会加速。然后，简化代码直到问题消失。
使用方法如下：
int ParallelThreads = 10;
Parallel.ForEach(xDoc.Descendants("APSEvent").ToList(), new ParallelOptions() { MaxDegreeOfParallelism = ParallelThreads }, (myXDOC, i, j) =>
{
//do whatever you want here
});
是的，没错，Document.Load(...) 锁定了文件，由于线程之间的资源争用，TPL无法充分利用多个线程的优势。尝试将XML加载到一个Stream中，然后使用Parallel.For(...)。
Parallel.ForEach无法（合理地）了解正在迭代的集合（它只"看到"传递进来的List<XElement>，并且假设它没有任何特殊的实现是不合理的）。此外，ToList基本上会急切地获取所有元素，因此在这里锁定（以及从文件中读取）不应该有任何影响。 - Christian.K