Process-per-site-instance和Process-per-site应该理解吗？我看了这里的解释，感觉这两种说法没有什么区别吗？希望老天爷能给予一些更简单的解释，举例更好吗？Process-per-site-instance：Chromium为用户访问的每个站点示例创建一个渲染器进程。这确保了来自不同站点的页面被独立渲染，并且对同一站点的单独访问也被彼此隔离。因此，故障（例如，呈现器崩溃）或站点的一个示例中的大量资源使用将不会影响浏览器的其余部分。此模型基于内容的来源和选项卡之间的关系（选项卡之间可能相互编写脚本）。因此，两个选项卡可能显示在同一进程中呈现的页面，而导航到给定选项卡中的跨站点页面可能会切换选项卡的呈现进程。Process-per-site：Chromium还支持一个流程模型，该模型将不同的站点彼此隔离，但将同一站点的所有示例分组到同一个流程中，该模型基于内容的来源，而不是标签之间的关系。
link:
1条答案
按热度按时间8nuwlpux1#
最明显的区别之一是，在
Process-per-site模式下，它确保每个站点使用的进程不超过一个，而在Process-per-site-instance（默认模式）下，一个站点可以有多个进程。下面是一个简单的实验来说明这种差异：
每个站点的进程示例
首先在正常/默认模式下打开Chromium（我在Chromium Build 778138上做过，我认为在任何最近的Chrome Build上结果都会相同）。
然后打开两个
github.com选项卡。打开任务管理器（在Chromium中的更多工具下）。
如您所见，这两个选项卡具有两个不同的进程ID
86892和86894每个站点的流程
退出Chromium，并通过在终端中运行此命令以进入每个站点模式的进程（我使用的是MacOS，对于Windows，您可以遵循this）来使用附加参数重新打开它：
open -a "Chromium" --args --process-per-site然后打开两个
github.com选项卡。与上一步相同，打开任务管理器。
正如您所看到的，这两个github选项卡具有相同的进程ID
86831另一个有趣的观察结果是，第一个（
Process-per-site-instance）的总内存占用量约为125 MB，而第二个（Process-per-site）的总内存占用量约为88 MB，少了30%！但缺点是，如Chromuim website所述：(Process-per-site) Can result in large renderer processes. Sites like google.com host a wide variety of applications that may be open concurrently in the browser, all of which would be rendered in the same process. Thus, resource contention and failures in these applications could affect many tabs, making the browser seem less responsive. It is unfortunately hard to identify site boundaries at a finer granularity than the registered domain name without breaking backwards compatibility.进一步阅读：
在this article中，作者在
Process-per-site-instance模式下做了一些有趣的体验，我认为这可以进一步提高您对Chrome进程模型的理解。