为什么您的代码不应使用100％CPU？[关闭]

我专门讲的是在Windows XP或更高版本上运行的C＃.NET 4程序，但是一般的答案也是可以接受的。

假设一个已经优化和高效的程序。这里的问题完全归结于CPU使用率高对硬件的影响，以及是否应该限制高使用率的程序以减少磨损，而不是取决于我的实现是否有效。

今天的一位同事建议我不要在数据加载过程中实现100％CPU利用率的目标，因为“现代CPU价格便宜，并且在100％CPU时会迅速降级”。

这是真的？如果是这样，为什么？以前，我给人的印象是100％CPU使用率对于密集或长时间的操作来说是更可取的，而且我在这两种方法上都找不到任何可敬的资源。

如果散热不足，则CPU可能会过热。但是它们全部（至少所有现代PC CPU都具有）各种热保护机制，这些机制将限制时钟速度，或者最后关闭。

因此，是的，在尘土飞扬的笔记本电脑上，100％的CPU负载可能会导致暂时性问题，但没有任何损坏或“降级”（无论如何）。

对于受CPU约束的问题，100％CPU负载是正确的选择。

至于应用程序（UI）响应能力，这是与CPU利用率不同的概念。完全可能有一个使用1％CPU的无响应应用程序，或者使用100％CPU的响应式应用程序。UI响应能力可以归结为在UI线程中完成的工作量，以及UI线程相对于其他线程的优先级。

Windows程序（winforms / WPF）应始终保持响应状态。通过使用100％cpu资源的流程的简单实施，就很容易使您的程序甚至系统看上去呆滞不前。

通过良好的实现（例如：使用较低优先级的单独线程），这应该不是问题。

您不必担心CPU会很快中断。

通常，使用100％CPU的程序没有任何问题，而实际上它在做有用的工作，并且不会浪费时间去处理更重要的事情。如果某个特定的硬件平台例如仅能够连续使用100％CPU一秒钟，然后必须将其调回到50％以避免过热，那么通常对于执行有用工作的应用程序来说更好尽可能快地运行，并让CPU或OS处理任何必要的节流，而不是让应用程序猜测其“应该”运行的速度。如果应用程序或线程有低优先级的工作要做，这是有用的，但并非始终很关键，那么将操作系统将低优先级任务的CPU使用率限制为50％可能会有所帮助，以便在CPU需要执行此操作时它很快就会准备好“冲刺”一秒钟，但是除了请求低线程优先级之外，应用程序不必担心这些事情。

不能使用100％CPU的最大情况是：

• 应用程序正忙于等待某个事件，而该事件不会被持久性轮询加速（如果浪费精力检查任务是否完成，则可能会被延迟，否则它可能会被花费在执行任务上）。

• 应用程序过多地重绘了显示内容。“过多地”的定义将在某种程度上取决于显示设备的性质和所显示的内容。如果显示硬件能够以120fps的速度显示，则可能会出现动画以120fps的速度显示而不添加运动模糊，但如果不添加动画则无法以较低的帧速率清晰显示。如果使用运动模糊渲染帧要比不使用运动模糊渲染帧花费更多的时间，那么在支持帧的硬件上以120fps进行渲染实际上并不比使用运动模糊以较慢的帧速率渲染更昂贵。[简单情况：一个带有29个辐条的轮子，每秒旋转一圈。在120fps下，砂轮似乎会以适当的速度和方向旋转。在60fps下

显然，前者是坏的。第二个更微妙。如果以某个移动平台为目标，则在某些情况下可能希望允许用户选择所需的动画帧频，因为某些用户可能不担心电池寿命，但希望获得最佳质量的动画，而另一些用户则接受较低质量的动画。动画以换取更长的电池寿命。与其让应用程序尝试猜测应该在哪里进行权衡，不如让用户自定义它可能会有所帮助。

“现代CPU价格便宜，并且在100％CPU时会迅速降级”。

我认为没有人真正解决过此问题的“降级”部分。当芯片温度超过制造商的限制时，IC将会退化。IC通常设计为可在高达125C的温度下运行，尽管每升高10C会使寿命缩短50％

处理器并不总是具有温度调节功能。然后，某些AMD Durons遇到了问题（如果不使用散热器，则有可能毁坏一个）。现在，所有PC处理器都将内置温度传感器，这些温度传感器会反馈到CPU时钟，并会降低时钟速度以防止损坏。因此，您可能会发现您的程序正在使用100％的可用CPU，但是由于散热不足，CPU仅以其额定速度的75％运行。

在用户程序中，不是尝试管理CPU消耗的正确位置。通常，您的程序应该在尽可能快的执行操作与等待，暂停，等待输入或磁盘访问之间进行切换。如果可能的话，应该避免繁忙等待和自旋锁，但是要礼貌地对待系统的其余部分。

Windows和Linux都具有将执行性能和热量管理的CPU“调节器”系统。由于此操作是在操作系统级别完成的，因此可以解决系统CPU的总消耗。操作系统的责任是管理硬件并防止用户程序滥用它。硬件所有者有责任保持风扇清洁和工作，制造商首先要安装足够的散热器和风扇。

在某些情况下，设备的散热不足，但是大量的返修告诉制造商不要这样做。

扮演魔鬼的拥护者：在某种程度上，无法达到100％利用率的程序可能会导致更严重的磨损：除非它被挂起以等待击键，否则很有可能在大多数情况下被挂起以等待磁盘I / O。磁盘是（仍然通常是）大型机械设备，它们在移动时会遭受机械磨损或遭受电击/陀螺效应的风险，更不用说功耗了。

“ ..现代CPU很便宜，并且在100％CPU下会迅速降级”。

您完全不必担心“ CPU降级”。现代CPU的质量并不比以前低。

这是非常昂贵的（并且越来越每隔几年更贵），使CPU的，一些数十亿美元建立一个新的晶圆厂也并不少见（见链接）。

http://en.wikipedia.org/wiki/Semiconductor_fabrication_plant

CPU的生产成本最多取决于否。生产的单位。这是经济上众所周知的事实。毕竟，这就是它们可以相对便宜地出售的原因。（我认为，这里不需要链接）

我可以列举许多原因，说明为什么我认为现代CPU的质量要比“以前的时代”更高。

但只有最重要的一点：测试方面的优势。现代电子产品是“为测试而设计”的。无论是软件还是硬件，对几乎所有其他事物进行测试评估的广泛见解都不是那么古老。对于CPU，甚至进行测试以形成不同的价格和频率类型，例如，最好的CPU以最高的频率出售。尽管如此，较便宜的处理器通常能够以比售出的频率更高的频率运行-它们之所以受到损害，仅是因为制造商想以更高的价格出售某些“高级”处理器。

（另一方面，与七十年代处理器的几千个晶体管相比，如今正常使用超过15亿个晶体管的处理器当然有更多的错误。但这与我对IMO的回答并不矛盾。往往有许多已知的错误，至少在微代码中如此，但这不在此限。）

还有更多原因不用担心程序的CPU降级：

• 第一个原因是，现代CPU如果温度过高，则会降低其频率或节流阀。

  应当清楚的是，如果您全年使用100％24/7的CPU，通常它会比每隔一周（每隔一小时）使用一次的CPU更早失效。但是顺便说一句，对于汽车也是如此。只有在这种情况下，我才会考虑CPU利用率和潜在的睡眠问题。

• 第二个原因是编写一个使用OS中100％CPU的程序确实非常困难（例如，在Windows中）。此外，现代CPU（通常）至少具有2-4个内核。因此，传统算法倾向于使用100％的单核CPU，而现在在双核CPU上只有50％（简化但在实际场景中可以看到）。

• 此外，操作系统可以控制CPU，而不能控制您的程序，因此，如果有其他具有相同或更高优先级的应用程序（默认设置），则您的程序只会获得尽可能多的CPU，而其他应用程序则不会饿死。（当然，这只是简化的理论，Windows，Linux和其他操作系统的多任务处理也不是完美的，但是总的来说，我认为这是正确的）。

“我以前给人的印象是，对于密集型或长时间运行，CPU使用率最好为100％。”

是的，留下来。但是例如，如果您等待并循环执行另一个进程，换句话说什么也不做，那么如果在该循环中将Thread.Sleep（）毫秒化，从而为其他进程留出了额外的时间，那就还不错。尽管对于一个好的多任务操作系统来说并不必要，但是我已经解决了一些问题，例如Windows2000。（例如，这并不意味着在计算中使用Sleep（）。

这种降解在理论上是可能的，被称为“ 电迁移 ”。电迁移与温度有关，随着温度的升高而加速。对于现代CPU，这是否是一个实际问题尚待争论。现代VLSI设计实践可以补偿电迁移，并且芯片更有可能因其他原因而失败。

话虽如此，电迁移甚至在正常的负载和温度下也会发生，但它的速度足够慢，以至于精心设计的芯片要么在失效之前就已经过时，要么先通过其他机制失效。

电迁移的速率取决于芯片的温度，寿命每增加10°C就会增加一倍。实际上，这是称为“ HTOL”（高温工作寿命）的测试的基础，该测试测量芯片在例如125°C下死亡所需的时间。在125°C下运行的芯片将比在55°C下运行的芯片快大约100倍的故障，因此，如果设计为在55°C下至少可持续10年，则芯片在125°C下可能会在1个月内失效。如果在更合理的温度（例如85°C）下运行，则此类芯片的失效时间至少比设计的时间早5-10倍。

当然，CPU通常在设计时考虑到较高的温度，因此它们在85°C 24/7 100％负载运行时通常可以持续数年。因此，我建议您不要担心“耗尽” CPU，而只担心从软件工程的角度来看100％的负载是否合适。

如果在客户端上运行代码，则CPU利用率为100％，这意味着那时客户端计算机只能用于具有更高优先级的任务，而不能用于其他任何事情。由于大多数应用程序通常以默认优先级运行，因此使用这些计算机的用户将注意到计算机死机，并且无法在其计算机上执行其他操作。即使我们谈论的是短暂的突发事件，从事某些工作的用户仍然会注意到它。

就像其他人说的那样，您对设置非常保密，所以我不能肯定地说。但是，如果您的客户端是台式计算机，则不要使用100％的CPU。不是因为CPU降级，而是因为它不是在用户工作期间中断用户的好方法。

因此情况是这样的：您有一些代码使用100％的所有CPU运行了五个小时，并且已对其进行了尽可能多的优化，该计算机的所有者很好，因为该计算机五个小时都无法使用，并且您的同事声称最好使用所有CPU的83.33％在6小时内运行代码，因为这样可以减少计算机的磨损。

这取决于您使用的计算机。我知道一家计算机制造商拒绝在保修期内对廉价的家用计算机进行保修维修，这些廉价家用计算机在科学环境中以24/7运行。他们显然希望客户购买价格更高的服务器或“商用”计算机。他们是否成功，我不知道。

我拥有的每台Mac在其生命周期中的某个时候，每天都有100％CPU使用率的代码。在一种情况下，我必须关闭显示器，因为我没有笔记本电脑的原装充电器，并且具有4核和超线程功能，它消耗的电量比所提供的充电器多-因此电池电量耗尽，并且当电池到达时5％的计算机会降低时钟速度，直到电池电量达到10％为止！（关闭显示屏后，它会全速运行几天）。在任何情况下都不会造成任何不良影响。

因此，使用精心设计的计算机，您是对的。使用设计不良的廉价计算机，您的同事可能是正确的。另一方面，您可能要考虑等待时间的成本与购买更换计算机的成本。

如果可以，请使代码的优先级较低，并确保将占用大量CPU的线程与GUI分开。这样您可能具有100％的利用率，但是用户始终可以始终运行其他任务并保持响应状态。就其本身而言，CPU被设计为以100％的使用率保持运行一段时间，否则它不会被释放。除非最终用户对其硬件进行了严重而危险的修改，否则您将不会损坏任何东西。