在介绍进程和线程之前，我们需要先了解下什么是并行处理，如果我们理解了并行处理的概念，那么再理解进程与线程之间的的关系会变得轻松很多。
并行处理
计算机中的并行处理就是同一时刻处理多个任务，比如我们要计算下面三个表达式的值并显示出结果。
A = 1+2
B = 20/5
C = 7*8
在编写代码的时候，我们可以把这个过程拆分成四个任务：
- 任务一：计算A = 1+2
- 任务二：计算B = 20/5
- 任务三：计算C = 7*8
- 任务四：显示最后计算的结果
正常情况下程序可以使用单线程来处理，也就是分四步按照顺序分别执行这四个任务。
如果采用多线程，会怎么样呢？我们只需分”两步走“：第一步，使用三个线程同时执行前三个任务；第二步，再执行第四个显示任务。
通过对比分析，你会发现用单线程执行需要四步，而使用多线程只需要两步，因此，使用并行处理能大大提升性能。
线程VS进程
多线程可以并行处理任务，但是线程是不能单独存在的，需要进程来启动和管理，那么什么是进程呢？实际上一个进程就是一个程序的运行实例，具体就是启动一个程序的时候，操作系统会为该程序创建一块内存，用来存放代码、运行中的数据和一个执行任务的主线程，我们把这样的运行环境叫进程。
我们将前文并行处理中提到的计算过程用下图来对比：
从图中可以看出，线程是依附于进程的，而进程中使用多线程并行处理能提升运算效率。
总结来说，进程与线程之间的关系有以下四个特点：
1、进程中的任意一线程执行出错都会导致整个进程的崩溃。
我们可以模拟以下场景：
A = 1+2
B = 20/0
C = 7*8
我们把上面三个表达式稍作修改，在计算B的值的时候线程会出错，这样就会导致整个线程的崩溃，当然另外两个线程的执行结果也没有了。
2、线程之间可以共享进程中的数据。
如下图所示，线程之间可以对进程的公共数据进行读写操作。
从上图我们可以看出，线程1、线程2、线程3分别把执行的结果写入了A、B、C中，然后进程2继续从A、B、C中读取数据，用来显示执行结果。
3、当一个进程关闭之后，操作系统会回收进程所占用的内存。
当一个进程退出时，操作系统会回收该进程所申请的所有资源；即使其中任意进程因为操作不当导致内存泄漏，当进程退出时，这些内存也会被正确回收。
比如之前的IE浏览器，支持很多插件，而这些插件很容易导致内存泄漏，这意味着只要浏览器开着，内存占用就有可能会越来越多，当时当关闭浏览器进程时，这些内存都会被浏览器回收掉。
4、进程之间的内容相互隔离。
进程隔离是为了保护操作系统中的进程互不干扰的技术，每一个进程只能访问自己占有的数据，也就避免了进程A写入数据到进程B的情况。正是因为进程之间的数据是完全隔离的，所以一个进程如果崩溃了，或者挂起了，是不会影响到其他进程的。如果进程之间需要进行数据的通信，这时候，就需要使用用于进程间通信（IPC）的机制了。
单进程浏览器
单进程浏览器是指浏览器的所有功能模块都是运行在同一个进程里，这些模块包括了网络、插件、JavaScript运行环境、渲染引擎和页面等等。单进程浏览器的架构如下图所示：
将如此多的模块运行在一个进程里，导致单进程浏览器有着诸多问题：
1、不稳定：
早期浏览器需要借助插件来实现诸如Web视频、Web游戏等各种强大的功能，但是插件是最容易出问题的模块，并且还运行在浏览器进程之中，所以一个插件的崩溃会引起整个浏览器的崩溃。除了插件以外，渲染引擎模块也是不稳定的，通常一些复杂的JavaScript代码就有可能引起渲染引擎的崩溃。和插件一样，渲染引擎的崩溃也会引起整个浏览器的崩溃。
2、不流畅
从上面的“单进程浏览器架构示意图”可以看出，所有页面的渲染模块、JavaScript执行环境以及插件都是运行在同一个线程中的，这就意味着同一时刻只能有一个模块可以执行。
比如：下面这个无限循环的脚本：
function freeze() {
while(1) {
console.log("freeze");
}
}
freeze();
如果该脚本运行在一个单进程浏览器的页面里，由于它是无限循环的，所以当执行时它会独占整个线程，这样就导致其他运行在该线程中的模块就没机会被运行。因为浏览器中所有页面都运行在该线程中，所以这些页面都没机会去执行任务，这样就导致整个浏览器失去响应，变卡顿。
除了上述脚本或者单进程浏览器变卡顿外，页面的内存泄漏也是单进程变慢的一个重要原因。通常浏览器的内核都是非常复杂的，运行一个复杂点的页面再关闭页面会存在内存不能完全回收的情况，这样导致的问题是使用时间越长，内存占用越高，浏览器会变得越来越慢。
3、不安全
插件可以使用C/C++等代码编写，通过插件可以获取到操作系统的任意资源，这意味着当你在页面运行一个插件的时候这个插件可以完全操作你的电脑，如果是个恶意插件它就可以释放病毒，窃取你的账号密码，引发安全性问题。
至于页面脚本，它可以通过浏览器的漏洞来获取系统权限，这些脚本获取系统权限之后也可以对你的电脑做一些恶意的事情，同样会引发安全问题。
多进程浏览器
上图为Chrome2008年发布时的进程架构图，从图中我们可以看到Chrome页面是运行在单独的渲染流程中的，同时页面里的插件也是运行在单独的插件进程中，而进程之间是通过IPC机制（Inter-Process Communication, 含义为进程间通信或者跨进程通信，指两个进程之间进行数据交换的过程）进行通信。
如何解决不稳定的问题：由于进程之间是相互隔离的，所以当一个页面或者插件崩溃时，影响到的仅仅是当前的页面进程或插件进程，并不会影响浏览器和其他页面，这就完美解决了页面或插件崩溃导致的整个浏览器崩溃，也就是不稳定的问题。
如何解决不流畅的问题：同样，JavaScript 也是运行在渲染进程中的，所以即使 JavaScript 阻塞了渲染进程，影响到的也只是当前的渲染页面，而并不会影响浏览器和其他页面，因为其他页面的脚本是运行在它们自己的渲染进程中的。所以当我们再在 Chrome 中运行上面那个死循环的脚本时，没有响应的仅仅是当前的页面。
如何解决内存泄漏的问题：解决方法那就更简单了，因为当关闭一个页面时，整个渲染进程也会被关闭，之后该进程所占用的内存都会被系统回收，这样就轻松解决了浏览器页面的内存泄漏问题。
采用多进程架构的额外好处是可以使用安全沙箱，你可以把沙箱看成是操作系统给进程上了一把锁，沙箱里面的程序可以运行，但是不能在你的硬盘上写入任何数据，也不能在敏感位置读取任何数据，例如你的文档和桌面。Chrome 把插件进程和渲染进程锁在沙箱里面，这样即使在渲染进程或者插件进程里面执行了恶意程序，恶意程序也无法突破沙箱去获取系统权限。因此多进程架构成为目前所有主流浏览器的共同选择，下面我们来了解一下目前浏览器的多进程架构是怎么样的？
目前多进程架构
上图为最新的Chrome浏览器架构图，从图中可以看出，最新的 Chrome 浏览器包括：1 个浏览器（Browser）主进程、1 个 GPU 进程、1 个网络（NetWork）进程、多个渲染进程和多个插件进程。
- 浏览器进程：主要负责界面显示、用户交互、子进程管理，同时提供存储等功能。
- 渲染进程：核心任务是将 HTML、CSS 和 JavaScript 转换为用户可以与之交互的网页，排版引擎 Blink 和 JavaScript 引擎 V8 都是运行在该进程中，默认情况下，Chrome 会为每个 Tab 标签创建一个渲染进程。出于安全考虑，渲染进程都是运行在沙箱模式下。
- GPU进程：其实，Chrome 刚开始发布的时候是没有 GPU 进程的。而 GPU 的使用初衷是为了实现 3D CSS 的效果，只是随后网页、Chrome 的 UI 界面都选择采用 GPU 来绘制，这使得 GPU 成为浏览器普遍的需求。最后，Chrome 在其多进程架构上也引入了 GPU 进程。
- 网络进程：主要负责页面的网络资源加载，之前是作为一个模块运行在浏览器进程里面的，直至最近才独立出来，成为一个单独的进程。
- 插件进程：主要是负责插件的运行，因插件易崩溃，所以需要通过插件进程来隔离，以保证插件进程崩溃不会对浏览器和页面造成影响。
凡事都有两面性，虽然多进程模型提升了浏览器的稳定性、流畅性和安全性，但同样不可避免地带来了一些问题：
- 更高的资源占用：因为每个进程都会包含公共基础结构的副本（如 JavaScript 运行环境），这就意味着浏览器会消耗更多的内存资源。
- 更复杂的体系结构：浏览器各模块之间耦合性高、扩展性差等问题，会导致现在的架构已经很难适应新的需求了。
未来面向服务的架构
为了解决前面我们说到目前浏览器架构的问题，在 2016 年，Chrome 官方团队使用“面向服务的架构”（Services Oriented Architecture，简称SOA）的思想设计了新的 Chrome 架构。也就是说 Chrome 整体架构会朝向现代操作系统所采用的“面向服务的架构” 方向发展，原来的各种模块会被重构成独立的服务（Service），每个服务（Service）都可以在独立的进程中运行，访问服务（Service）必须使用定义好的接口，通过 IPC 来通信，从而构建一个更内聚、松耦合、易于维护和扩展的系统，更好实现 Chrome 简单、稳定、高速、安全的目标。
Chrome 最终要把 UI、数据库、文件、设备、网络等模块重构为基础服务，类似操作系统底层服务，下面是 Chrome“面向服务的架构”的进程模型图：
目前 Chrome 正处在老的架构向服务化架构过渡阶段，这将是一个漫长的迭代过程。
Chrome 正在逐步构建 Chrome 基础服务（Chrome Foundation Service），如果你认为 Chrome 是“便携式操作系统”，那么 Chrome 基础服务便可以被视为该操作系统的“基础”系统服务层。
同时 Chrome 还提供灵活的弹性架构，在强大性能设备上会以多进程的方式运行基础服务，但是如果在资源受限的设备上（如下图），Chrome 会将很多服务整合到一个进程中，从而节省内存占用。
注：
目前在多进程架构的浏览器中仍然有时会出现单个页面卡死最终崩溃导致所有页面崩溃的情况，这是因为通常情况下是一个页面使用一个进程，但是，有一种情况，叫"同一站点(same-site)"，具体地讲，我们将“同一站点”定义为根域名（例如，geekbang.org）加上协议（例如，https:// 或者http://），还包含了该根域名下的所有子域名和不同的端口，比如下面这三个：
https://time.geekbang.org
https://www.geekbang.org
https://www.geekbang.org:8080
都是属于同一站点，因为它们的协议都是https，而根域名也都是geekbang.org。你也许了解同源策略，但是同一站点和同源策略还是存在一些不同地方，在这里你需要了解它们不是同一件事就行了。
Chrome的默认策略是，每个标签对应一个渲染进程。但是如果从一个页面打开了新页面，而新页面和当前页面属于同一站点时，那么新页面会复用父页面的渲染进程。官方把这个默认策略叫process-per-site-instance。
直白的讲，就是如果几个页面符合同一站点，那么他们将被分配到一个渲染进程里面去。
所以，这种情况下，一个页面崩溃了，会导致同一站点的页面同时崩溃，因为他们使用了同一个渲染进程。
为什么要让他们跑在一个进程里面呢？
因为在一个渲染进程里面，他们就会共享JS的执行环境，也就是说A页面可以直接在B页面中执行脚本。因为是同一家的站点，所以是有这个需求的。
参考资料：极客时间《浏览器工作原理与实现》专栏
标签：插件,浏览器,Chrome,线程,进程,页面 来源： https://blog.csdn.net/weixin_44196299/article/details/102651547
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。