谷歌浏览器已经是多进程架构，为何在控制台写死循环语句依旧会卡死呢？

之前在分享谷歌浏览器的架构的时候，结合查到的资料来看，给到观众下面的信息：

谷歌浏览器的多进程架构可以解决单进程架构的不稳定的问题。由于进程是相互隔离的，所以当一个页面或者插件崩溃时，影响到的仅仅是当前的页面进程或者插件进程，并不会影响到浏览器和其他页面，这就完美地解决了页面或者插件的崩溃会导致整个浏览器崩溃，也就是不稳定的问题。

被问了那么一个问题，那“为何在控制台写死循环，浏览器依旧会卡死？” 借着这个问题，我们来再进一步研究背后的原因。

#1.开发者工具是单独的进程

打开控制台之前

打开控制台之后，多了一个进程，它有自己的进程ID

#2.每个Tab是对应一个独立的开发者工具进程

我在掘金的首页和具体博客页都打开了开发者工具，发现任务管理器就拥有了两个DevTools的进程。

谷歌浏览器的开发者工具（Developer Tools）与浏览器的渲染进程（Renderer Process）之间的通信是通过一套复杂的机制实现的，用到的协议是Chrome DevTools Protocol协议。

#通信的流程

#1.开发者工具和目标渲染进程建立WebSocket连接

当打开开发者工具的时候，浏览器会为开发者工具创建一个新的进程，并建立一个到目标渲染进程的WebSocket连接。

#2.开发者工具发送请求

用户在开发者工具中执行某个操作(例如，设置断点、检查元素)时，开发者工具会向渲染进程发送一个JSON-RPC请求。

#3.渲染进程处理请求，返回响应

渲染进程接收到请求后，会解析并执行相应操作，并将执行结果封装成一个JSON-RPC响应，发送给开发者工具

#4.开发者工具更新界面

开发者工具接收到响应后，会更新界面，并将结果展示给开发者。

#通信的内容

通过Chrome DevTools Protocol，开发者工具可以与渲染进程进行各种通信，包括但不限于:

• DOM操作: 获取DOM结构，修改DOM元素的属性和样式。
• JavaScript调试: 设置断点、单步执行、查看变量值、调用函数。
• 网络请求: 查看网络请求、修改请求头和响应体。
• 性能分析: 分析页面加载性能、CPU占用率、内存使用情况。
• 日志输出: 查看控制台输出的日志信息

1. 开发者工具 => 设置 => Experiments => 勾选Protocol Monitor

2.更多=> More tools => Protocol monitor

然后，我们就能观察到如下图的内容

经过观察，我决定选择Page.navigatedWithinDocument作为观察点，一会看是否有出现。

#测试过程

测试代码如下：

复制  while (true) {
    console.log(new Date().toISOString());
  }

刚开始的时候，DevTools内存占用空间是230MB，CPU是27.1，开发者工具进程和渲染进程之间通信的内容是五花八门。

随着时间的推移，DevTools内存占用空间升到259MB，CPU是153.6，开发者工具进程和渲染进程之间通信的内容是一致的Runtime.consoleAPICalled。

时间来到一分钟之后，DevTools内存占用空间升到545MB，CPU是141.3，开发者工具进程和渲染进程之间通信的内容是一致的Runtime.consoleAPICalled。

试图切换到前端tab,点击无反应，这个时候可以认为渲染进程已经卡死了，开发者工具也是不正常了（白屏）。

白屏的开发者工具，如下图

在手动杀掉开发者工具进程后，渲染进程也没救回来，可见这两者都受伤了

尝试打开新的tab，访问新的网站，是正常的

利用任务管理器手动杀掉渲染进程之后，显示崩溃界面

#测试结论

1.在控制台写死循环，会卡死当前的渲染进程和开发者工具进程，不会影响其他进程。

2.出现死循环的时候，进程的内存和CPU会不断的攀升。

3.当出现死循环的时候，渲染进程和开发者进程完全被Demo的Runtime.consoleAPICalled通信占据所有带宽， 无法再通信其他内容，可见这两个进程的资源都被死循环语句占用了。

#原因分析

#1.死循环时，渲染进程的主线程被阻塞

尽管浏览器是多进程的，但是每个进程内部依然存在主线程，当在控制台执行死循环时，这个循环会不断占用主线程的执行时间，导致主线程无法及时响应其他任务，比如处理用户交互。

#2.开发者工具无法及时获取更新的数据

在出现死循环的时候，渲染进程的主线程忙着执行循环代码，开发者工具无法从渲染进程那获取更新的数据,渲染进程也无法回应开发者工具的调试接口。

#3.开发者工具自身的资源消耗

在不断的死循环之后，开发者工具从渲染进程那共享到大量的log数据，导致自身的存储数据的资源攀升，导致没有更多资源存储新的数据（谷歌浏览器对开发者工具的内存是有限制的）。

本文以开发者工具是单独的进程展开，介绍渲染进程与开发者进程之间的通信，通过实际的观察，研究在控制台写了死循环之后，渲染进程和开发者进程都有怎样的表现，得出死循环导致页面卡死的原因。从本次研究，可以得到下面的结论。

• 基于浏览器的多进程架构，一个渲染进程的崩溃不会影响到其他渲染进程。
• 在控制台执行死循环时，渲染进程的主线程都在忙着执行JS，无法响应其他交互。
• 渲染进程与开发者工具进程是通过Chrome DevTools Protocol协议进行通信的。
• 渲染进程无法响应开发者工具，以及开发者工具占用的内存攀升，都是开发者工具卡死的原因。

Chrome DevTools Protocol协议