上下文切换的成本

我一直认为我擅长多任务处理 。 这就是为什么我认为我不必付出与上下文切换（或任务切换 ）相关联的代价的原因。

这周我意识到这是错误的。 我不是很擅长多任务处理，上下文切换比我想象的要昂贵得多。

我犯错的原因很简单：

我并没有像我想的那样被打扰 。

为什么上下文切换是如此昂贵？

上下文切换的效果令我非常痛苦：

• 如果我正在做某事，并且必须开始做其他事情，那么在我实际从事这项新工作之前，可能要花一些时间。
• 因为我一天必须多次切换上下文，所以我觉得自己做不到任何事情（通常这不只是一种感觉）。

Joel Spolsky解释了此原因 ：

这里的窍门是，当您管理程序员时，特别是任务切换将花费非常，非常，非常长的时间。 这是因为编程是一种任务，您必须立即将很多事情记在脑子里。 一次记住的东西越多，编程的效率就越高。 一个程序员全力以赴地编写代码，使他们无所不用其极：变量名称，数据结构，重要的API，他们编写和调用的许多实用函数的名称，甚至它们所在的子目录的名称存储他们的源代码。 如果您将该程序员送去克里特岛度过三个星期的假期，他们会忘记这一切。 人类的大脑似乎将其移出了短期RAM，并将其交换到了备份磁带上，从那里永远需要检索。

有趣的是，上下文切换的价格不是恒定的。 这取决于新任务的复杂性。

如果新任务非常简单，甚至连猴子都可以做到，那么代价就很小。 通常，我可以完成新任务并继续执行旧任务而不会浪费任何时间。 这样做的原因是因为新任务非常简单，所以我不必清除短期记忆。

另一方面，如果新任务不简单，则代价很高。 我必须清理我的短期记忆并加载完成新任务所需的信息。 完成新任务后，我必须清理我的短期记忆并加载与原始任务相关的信息。 换句话说，我必须付出两次代价！

上下文切换的价格是多少？ 我认为这取决于个人，但是我注意到每个上下文切换可能需要5到30分钟。 这是疯狂的，因为如果您每天必须多次切换上下文， 则会浪费很多时间并消耗大量的精力 。

寻找中间立场

因为上下文切换的代价很高，而且很耗费人力，所以我们应该不惜一切代价避免这样做。 但是，这说起来容易做起来难，因为“真正的”团队合作（敏捷方法）是现代软件开发中必不可少的部分，我认为它具有明显的好处，不容忽视。

换句话说， 我们必须在协作和繁重的工作之间找到中间立场 。

我们必须尊重自己的时间和团队成员的时间，最简单的方法是遵循以下规则：

• 当时做一件事 。 如果必须完成两项任务，请先完成最重要的一项，然后再开始执行第二项。 这样，您至少可以完成最重要的任务。 如果尝试完成这两项任务，则可能无法完成这两项。
• 使用异步通信 。 下次您有问题时，请不要打扰可以回答您问题的人。 相反，您应该使用异步通信工具，例如IM，电子邮件或其他一些协作工具。 这样，此人可以在有时间的时候回答您的问题。 另外，请明确您的团队成员必须以相同的方式对待您。 如果除非您的问题没有立即得到回答，否则粪便会打败粉丝，您可以打断可以帮助您的人，但是请记住，这个人为回答您的问题付出了沉重的代价 。
• 如果需要完成某件事，请确保您不被打扰 。 如果您正在执行一项重要任务，则必须能够不间断地完成它。 创建一种方式向您的同事发出您不想打扰的信号。 如果您的同事不尊重这一点，您可以在家庭办公室工作，直到完成此任务。 另外，请记住，这是一条双向路。
• 接受您不能做所有事情，并确保您的雇主也接受此事 。 如果您的角色是定期帮助其他开发人员，请不要感到难过，因为您觉得自己无法完成任何事情。 确保您不承担任何高优先级的任务，因为您无法给予他们应有的关注。

这些建议中的一些似乎是反敏捷的 。 问题在于，敏捷软件开发方法的兴起创造了一种精神形象，鼓励我们一直进行协作。 这种精神形象将破坏我们的生产力，我们不应该接受它 。

相反，我们应该接受有足够的协作时间和时间来完成繁重的工作 ，并且我们不能同时做这两项工作 （除非我们正在进行结对编程或mob编程 ）。

翻译自: https://www.javacodegeeks.com/2014/04/the-cost-of-context-switching.html