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

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

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

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

打开控制台之前

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

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

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

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

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

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

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

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

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

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

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

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

测试代码如下：

 1  while (true) {
 2    console.log(new Date().toISOString());
 3  }

刚开始的时候，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通信占据所有带宽，无法再通信其他内容，可见这两个进程的资源都被死循环语句占用了。

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

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

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

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