前言

这段时间面试官都挺忙的，频频出现在博客文章标题，虽然我不是特别想蹭热度，但是实在想不到好的标题了-。-，蹭蹭就蹭蹭 :)

事实上我在面试的时候确实被问到了这个问题，而且是一道在线 coding 的编程题，当时虽然思路正确，可惜最终也并不算完全答对

结束后花了一段时间整理了下思路，那么究竟该如何实现一个大文件上传，以及在上传中如何实现断点续传的功能呢？

本文将从零搭建前端和服务端，实现一个大文件上传和断点续传的 demo

前端：vue element-ui

服务端：nodejs

文章有误解的地方，欢迎指出，将在第一时间改正，有更好的实现方式希望留下你的评论

大文件上传

整体思路

前端

前端大文件上传网上的大部分文章已经给出了解决方案，核心是利用 Blob.prototype.slice 方法，和数组的 slice 方法相似，调用的 slice 方法可以返回原文件的某个切片

这样我们就可以根据预先设置好的切片最大数量将文件切分为一个个切片，然后借助 http 的可并发性，同时上传多个切片，这样从原本传一个大文件，变成了同时传多个小的文件切片，可以大大减少上传时间

另外由于是并发，传输到服务端的顺序可能会发生变化，所以我们还需要给每个切片记录顺序

服务端

服务端需要负责接受这些切片，并在接收到所有切片后合并切片

这里又引伸出两个问题

1. 何时合并切片，即切片什么时候传输完成

2. 如何合并切片

第一个问题需要前端进行配合，前端在每个切片中都携带切片最大数量的信息，当服务端接受到这个数量的切片时自动合并，也可以额外发一个请求主动通知服务端进行切片的合并

第二个问题，具体如何合并切片呢？这里可以使用 nodejs 的 读写流（readStream/writeStream），将所有切片的流传输到最终文件的流里

talk is cheap,show me the code，接着我们用代码实现上面的思路

前端部分

前端使用 Vue 作为开发框架，对界面没有太大要求，原生也可以，考虑到美观使用 element-ui 作为 UI 框架

上传控件

首先创建选择文件的控件，监听 change 事件以及上传按钮

复制代码

请求逻辑

考虑到通用性，这里没有用第三方的请求库，而是用原生 XMLHttpRequest 做一层简单的封装来发请求

request({
      url,
      method = "post",
      data,
      headers = {},
      requestList
    }) {
      return new Promise(resolve => {
        const xhr = new XMLHttpRequest();
        xhr.open(method, url);
        Object.keys(headers).forEach(key =>
          xhr.setRequestHeader(key, headers[key])
        );
        xhr.send(data);
        xhr.onload = e => {
          resolve({
            data: e.target.response
          });
        };
      });
    }
复制代码

上传切片

接着实现比较重要的上传功能，上传需要做两件事

• 对文件进行切片

• 将切片传输给服务端

复制代码

当点击上传按钮时，调用 createFileChunk 将文件切片，切片数量通过文件大小控制，这里设置 10MB，也就是说 100 MB 的文件会被分成 10 个切片

createFileChunk 内使用 while 循环和 slice 方法将切片放入 fileChunkList 数组中返回

在生成文件切片时，需要给每个切片一个标识作为 hash，这里暂时使用文件名 + 下标，这样后端可以知道当前切片是第几个切片，用于之后的合并切片

随后调用 uploadChunks 上传所有的文件切片，将文件切片，切片 hash，以及文件名放入 FormData 中，再调用上一步的 request 函数返回一个 proimise，最后调用 Promise.all 并发上传所有的切片

发送合并请求

这里使用整体思路中提到的第二种合并切片的方式，即前端主动通知服务端进行合并，所以前端还需要额外发请求，服务端接受到这个请求时主动合并切片

复制代码

服务端部分

简单使用 http 模块搭建服务端

const http = require("http");
const server = http.createServer();

server.on("request", async (req, res) => {
  res.setHeader("Access-Control-Allow-Origin", "*");
  res.setHeader("Access-Control-Allow-Headers", "*");
  if (req.method === "OPTIONS") {
    res.status = 200;
    res.end();
    return;
  }
});

server.listen(3000, () => console.log("正在监听 3000 端口"));
复制代码

接受切片

使用 multiparty 包处理前端传来的 FormData

在 multiparty.parse 的回调中，files 参数保存了 FormData 中文件，fields 参数保存了 FormData 中非文件的字段

const http = require("http");
const path = require("path");
const fse = require("fs-extra");
const multiparty = require("multiparty");

const server = http.createServer();
+ const UPLOAD_DIR = path.resolve(__dirname, "..", "target"); // 大文件存储目录

server.on("request", async (req, res) => {
  res.setHeader("Access-Control-Allow-Origin", "*");
  res.setHeader("Access-Control-Allow-Headers", "*");
  if (req.method === "OPTIONS") {
    res.status = 200;
    res.end();
    return;
  }

+  const multipart = new multiparty.Form();

+  multipart.parse(req, async (err, fields, files) => {
+    if (err) {
+      return;
+    }
+    const [chunk] = files.chunk;
+    const [hash] = fields.hash;
+    const [filename] = fields.filename;
+    const chunkDir = path.resolve(UPLOAD_DIR, filename);

+   // 切片目录不存在，创建切片目录
+    if (!fse.existsSync(chunkDir)) {
+      await fse.mkdirs(chunkDir);
+    }

+      // fs-extra 专用方法，类似 fs.rename 并且跨平台
+      // fs-extra 的 rename 方法 windows 平台会有权限问题
+      // https://github.com/meteor/meteor/issues/7852#issuecomment-255767835
+      await fse.move(chunk.path, `${chunkDir}/${hash}`);
+    res.end("received file chunk");
+  });
});

server.listen(3000, () => console.log("正在监听 3000 端口"));
复制代码

查看 multiparty 处理后的 chunk 对象，path 是存储临时文件的路径，size 是临时文件大小，在 multiparty 文档中提到可以使用 fs.rename(由于我用的是 fs-extra，它的 rename 方法 windows 平台权限问题，所以换成了 fse.move) 移动临时文件，即移动文件切片

在接受文件切片时，需要先创建存储切片的文件夹，由于前端在发送每个切片时额外携带了唯一值 hash，所以以 hash 作为文件名，将切片从临时路径移动切片文件夹中，最后的结果如下

合并切片

在接收到前端发送的合并请求后，服务端将文件夹下的所有切片进行合并

const http = require("http");
const path = require("path");
const fse = require("fs-extra");

const server = http.createServer();
const UPLOAD_DIR = path.resolve(__dirname, "..", "target"); // 大文件存储目录

+ const resolvePost = req =>
+   new Promise(resolve => {
+     let chunk = "";
+     req.on("data", data => {
+       chunk += data;
+     });
+     req.on("end", () => {
+       resolve(JSON.parse(chunk));
+     });
+   });

+ const pipeStream = (path, writeStream) =>
+  new Promise(resolve => {
+    const readStream = fse.createReadStream(path);
+    readStream.on("end", () => {
+      fse.unlinkSync(path);
+      resolve();
+    });
+    readStream.pipe(writeStream);
+  });

// 合并切片
+ const mergeFileChunk = async (filePath, filename, size) => {
+  const chunkDir = path.resolve(UPLOAD_DIR, filename);
+  const chunkPaths = await fse.readdir(chunkDir);
+  // 根据切片下标进行排序
+  // 否则直接读取目录的获得的顺序可能会错乱
+  chunkPaths.sort((a, b) => a.split("-")[1] - b.split("-")[1]);
+  await Promise.all(
+    chunkPaths.map((chunkPath, index) =>
+      pipeStream(
+        path.resolve(chunkDir, chunkPath),
+        // 指定位置创建可写流
+        fse.createWriteStream(filePath, {
+          start: index * size,
+          end: (index + 1) * size
+        })
+      )
+    )
+  );
+  fse.rmdirSync(chunkDir); // 合并后删除保存切片的目录
+};

server.on("request", async (req, res) => {
  res.setHeader("Access-Control-Allow-Origin", "*");
  res.setHeader("Access-Control-Allow-Headers", "*");
  if (req.method === "OPTIONS") {
    res.status = 200;
    res.end();
    return;
  }

+   if (req.url === "/merge") {
+     const data = await resolvePost(req);
+     const { filename,size } = data;
+     const filePath = path.resolve(UPLOAD_DIR, `${filename}`);
+     await mergeFileChunk(filePath, filename);
+     res.end(
+       JSON.stringify({
+         code: 0,
+         message: "file merged success"
+       })
+     );
+   }

});

server.listen(3000, () => console.log("正在监听 3000 端口"));
复制代码

由于前端在发送合并请求时会携带文件名，服务端根据文件名可以找到上一步创建的切片文件夹

接着使用 fs.createWriteStream 创建一个可写流，可写流文件名就是切片文件夹名 + 后缀名组合而成

随后遍历整个切片文件夹，将切片通过 fs.createReadStream 创建可读流，传输合并到目标文件中

值得注意的是每次可读流都会传输到可写流的指定位置，这是通过 createWriteStream 的第二个参数 start/end 控制的，目的是能够并发合并多个可读流到可写流中，这样即使流的顺序不同也能传输到正确的位置，所以这里还需要让前端在请求的时候多提供一个 size 参数

   async mergeRequest() {
      await this.request({
        url: "http://localhost:3000/merge",
        headers: {
          "content-type": "application/json"
        },
        data: JSON.stringify({
+         size: SIZE,
          filename: this.container.file.name
        })
      });
    },
复制代码

其实也可以等上一个切片合并完后再合并下个切片，这样就不需要指定位置，但传输速度会降低，所以使用了并发合并的手段，接着只要保证每次合并完成后删除这个切片，等所有切片都合并完毕后最后删除切片文件夹即可

至此一个简单的大文件上传就完成了，接下来我们再此基础上扩展一些额外的功能

显示上传进度条

上传进度分两种，一个是每个切片的上传进度，另一个是整个文件的上传进度，而整个文件的上传进度是基于每个切片上传进度计算而来，所以我们先实现切片的上传进度

切片进度条

XMLHttpRequest 原生支持上传进度的监听，只需要监听 upload.onprogress 即可，我们在原来的 request 基础上传入 onProgress 参数，给 XMLHttpRequest 注册监听事件

 // xhr
    request({
      url,
      method = "post",
      data,
      headers = {},
+      onProgress = e => e,
      requestList
    }) {
      return new Promise(resolve => {
        const xhr = new XMLHttpRequest();
+       xhr.upload.onprogress = onProgress;
        xhr.open(method, url);
        Object.keys(headers).forEach(key =>
          xhr.setRequestHeader(key, headers[key])
        );
        xhr.send(data);
        xhr.onload = e => {
          resolve({
            data: e.target.response
          });
        };
      });
    }
复制代码

由于每个切片都需要触发独立的监听事件，所以还需要一个工厂函数，根据传入的切片返回不同的监听函数

在原先的前端上传逻辑中新增监听函数部分

    // 上传切片，同时过滤已上传的切片
    async uploadChunks(uploadedList = []) {
      const requestList = this.data
+       .map(({ chunk,hash,index }) => {
          const formData = new FormData();
          formData.append("chunk", chunk);
          formData.append("hash", hash);
          formData.append("filename", this.container.file.name);
+         return { formData,index };
        })
+       .map(async ({ formData,index }) =>
          this.request({
            url: "http://localhost:3000",
            data: formData，
+           onProgress: this.createProgressHandler(this.data[index]),
          })
        );
      await Promise.all(requestList);
       // 合并切片
      await this.mergeRequest();
    },
    async handleUpload() {
      if (!this.container.file) return;
      const fileChunkList = this.createFileChunk(this.container.file);
      this.data = fileChunkList.map(({ file }，index) => ({
        chunk: file,
+       index,
        hash: this.container.file.name + "-" + index
+       percentage:0
      }));
      await this.uploadChunks();
    }    
+   createProgressHandler(item) {
+      return e => {
+        item.percentage = parseInt(String((e.loaded / e.total) * 100));
+      };
+    }
复制代码

每个切片在上传时都会通过监听函数更新 data 数组对应元素的 percentage 属性，之后把将 data 数组放到视图中展示即可

文件进度条

将每个切片已上传的部分累加，除以整个文件的大小，就能得出当前文件的上传进度，所以这里使用 Vue 计算属性

  computed: {
       uploadPercentage() {
          if (!this.container.file || !this.data.length) return 0;
          const loaded = this.data
            .map(item => item.size * item.percentage)
            .reduce((acc, cur) => acc + cur);
          return parseInt((loaded / this.container.file.size).toFixed(2));
        }
 }
复制代码

最终视图如下

作者：yeyan1996
来源：https://juejin.cn/post/6844904046436843527

大家好，我是道哥。

今天，我们来聊一道常见的考题，也出现在腾讯面试的三面环节，非常有意思。具体的题目如下：

文件中有40亿个QQ号码，请设计算法对QQ号码去重，相同的QQ号码仅保留一个，内存限制1G.

这个题目的意思应该很清楚了，比较直白。为了便于大家理解，我来画个动图玩玩，希望大家喜欢。

能否做对这道题目，很大程度上就决定了能否拿下腾讯的offer，有一定的技巧性，一起来看下吧。

在原题中，实际有40亿个QQ号码，为了方便起见，在图解和叙述时，仅以4个QQ为例来说明。

方法一：排序

很自然地，最简单的方式是对所有的QQ号码进行排序，重复的QQ号码必然相邻，保留第一个，去掉后面重复的就行。

原始的QQ号为：

排序后的QQ号为：

去重就简单了：

可是，面试官要问你，去重一定要排序吗？显然，排序的时间复杂度太高了，无法通过腾讯面试。

方法二：hashmap

既然直接排序的时间复杂度太高，那就用hashmap吧，具体思路是把QQ号码记录到hashmap中：

mapFlag[123] = true
mapFlag[567] = true
mapFlag[123] = true
mapFlag[890] = true

由于hashmap的去重性质，可知实际自动变成了：

mapFlag[123] = true
mapFlag[567] = true
mapFlag[890] = true

很显然，只有123，567，890存在，所以这也就是去重后的结果。

可是，面试官又要问你了：实际要存40亿QQ号码，1G的内存够分配这么多空间吗？显然不行，无法通过腾讯面试。

方法三：文件切割

显然，这是海量数据问题。看过很多面经的求职者，自然想到文件切割的方式，避免内存过大。

可是，绞尽脑汁思考，要么使用文件间的归并排序，要么使用桶排序，反正最终是能排序的。

既然排序好了，那就能实现去重了，貌似就万事大吉了。我只能坦白地说，高兴得有点早哦。

接着，面试官又要问你：这么多的文件操作，效率自然不高啊。显然，无法通过腾讯面试。

方法四：bitmap

来看绝招！我们可以对hashmap进行优化，采用bitmap这种数据结构，可以顺利地同时解决时间问题和空间问题。

在很多实际项目中，bitmap经常用到。我看了不少组件的源码，发现很多地方都有bitmap实现，bitmap图解如下：

这是一个unsigned char类型，可以看到，共有8位，取值范围是[0, 255]，如上这个unsigned char的值是255，它能标识0~7这些数字都存在。

同理，如下这个unsigned char类型的值是254，它对应的含义是：1~7这些数字存在，而数字0不存在：

由此可见，一个unsigned char类型的数据，可以标识0~7这8个整数的存在与否。以此类推：

• 一个unsigned int类型数据可以标识0~31这32个整数的存在与否。

• 两个unsigned int类型数据可以标识0~63这64个整数的存在与否。

显然，可以推导出来：512MB大小足够标识所有QQ号码的存在与否，请注意：QQ号码的理论最大值为2^32 - 1，大概是43亿左右。

接下来的问题就很简单了：用512MB的unsigned int数组来记录文件中QQ号码的存在与否，形成一个bitmap，比如：

bitmapFlag[123] = 1
bitmapFlag[567] = 1
bitmapFlag[123] = 1
bitmapFlag[890] = 1

实际上就是：

bitmapFlag[123] = 1
bitmapFlag[567] = 1
bitmapFlag[890] = 1

然后从小到大遍历所有正整数(4字节)，当bitmapFlag值为1时，就表明该数是存在的。 而且，从上面的过程可以看到，自动实现了去重。显然，这种方式 可以通过腾讯的面试 。

扩展练习一

文件中有40亿个互不相同的QQ号码，请设计算法对QQ号码进行排序，内存限制1G.

很显然，直接用bitmap, 标记这40亿个QQ号码的存在性，然后从小到大遍历正整数，当bitmapFlag的值为1时，就输出该值，输出后的正整数序列就是排序后的结果。

请注意，这里必须限制40亿个QQ号码互不相同。通过bitmap记录，客观上就自动完成了排序功能。

扩展练习二

文件中有40亿个互不相同的QQ号码，求这些QQ号码的中位数，内存限制1G.

我知道，一些刷题经验丰富的人，最开始想到的肯定是用堆或者文件切割，这明显是犯了本本主义错误。直接用bitmap排序，当场搞定中位数。

扩展练习三

文件中有40亿个互不相同的QQ号码，求这些QQ号码的top-K，内存限制1G.

我知道，很多人背诵过top-K问题，信心满满，想到用小顶堆或者文件切割，这明显又是犯了本本主义错误。直接用bitmap排序，当场搞定top-K问题。

扩展练习四

文件中有80亿个QQ号码，试判断其中是否存在相同的QQ号码，内存限制1G.

我知道，一些吸取了经验教训的人肯定说，直接bitmap啊。然而，又一次错了。根据容斥原理可知：

因为QQ号码的个数是43亿左右(理论值2^32 - 1)，所以80亿个QQ号码必然存在相同的QQ号码。

海量数据的问题，要具体问题具体分析，不要眉毛胡子一把抓。有些人完全不刷题，肯定不行。有些人刷题后不加思考，不会变通，也是不行的。好了，先说这么多。我们也会一步一个脚印，争取每篇文章讲清讲透一件事，也希望大家阅读后有所收获，心情愉快。

作者：爱码有道
来源：https://mp.weixin.qq.com/s/YlLYDzncB6tqbffrg__13w

✨欢迎各位小伙伴：\textcolor{blue}{欢迎各位小伙伴：}欢迎各位小伙伴：
✨ 进大厂收藏这一系列就够了，全方位搜集总结，为大家归纳出这篇面试宝典，面试途中祝你一臂之力！，共分为四个系列
✨包含Vue40道经典面试题\textcolor{green}{包含Vue40道经典面试题}包含Vue40道经典面试题
✨包含react12道高并发面试题\textcolor{green}{包含react12道高并发面试题}包含react12道高并发面试题
✨包含微信小程序34道必问面试题\textcolor{green}{包含微信小程序34道必问面试题}包含微信小程序34道必问面试题
✨包含javaScript80道扩展面试题\textcolor{green}{包含javaScript80道扩展面试题}包含javaScript80道扩展面试题
✨包含APP10道装逼面试题\textcolor{green}{包含APP10道装逼面试题}包含APP10道装逼面试题
✨包含HTML/CSS30道基础面试题\textcolor{green}{包含HTML/CSS30道基础面试题}包含HTML/CSS30道基础面试题
✨还包含Git、前端优化、ES6、Axios面试题\textcolor{green}{还包含Git、前端优化、ES6、Axios面试题}还包含Git、前端优化、ES6、Axios面试题
✨接下来让我们饱享这顿美味吧。一起来学习吧！！！\textcolor{pink}{接下来让我们饱享这顿美味吧。一起来学习吧！！！}接下来让我们饱享这顿美味吧。一起来学习吧！！！
✨本篇为《看完这篇文章保你面试稳操胜券》第五篇（react、app、git）\textcolor{pink}{本篇为《看完这篇文章保你面试稳操胜券》第五篇（react、app、git）}本篇为《看完这篇文章保你面试稳操胜券》第五篇（react、app、git）

react

React 中 keys 的作用是什么？

Keys是React用于追踪哪些列表中元素被修改、被添加或者被移除的辅助标识 在开发过程中，我们需要保证某个元素的 key 在其同级元素中具有唯一性。 在 React Diff 算法中React 会借助元素的 Key 值来判断该元素是新近创建的还是被移动而来的元素， 从而减少不必要的元素重渲染。此外，React 还需要借助 Key 值来判断元素与本地状态的关联关系， 因此我们绝不可忽视转换函数中 Key 的重要性

传入 setState 函数的第二个参数的作用是什么？

该函数会在 setState 函数调用完成并且组件开始重渲染的时候被调用，我们可以用该函数来监听渲染是否完成

React 中 refs 的作用是什么

Refs 是 React 提供给我们的安全访问 DOM元素或者某个组件实例的句柄 可以为元素添加ref属性然后在回调函数中接受该元素在 DOM 树中的句柄，该值会作为回调函数的第一个参数返回

在生命周期中的哪一步你应该发起 AJAX 请求

我们应当将AJAX 请求放到 componentDidMount 函数中执行，主要原因有下

React 下一代调和算法 Fiber 会通过开始或停止渲染的方式优化应用性能，其会影响到 componentWillMount 的触发次数。对于 componentWillMount 这个生命周期函数的调用次数会变得不确定，React 可能会多次频繁调用 componentWillMount。如果我们将 AJAX 请求放到 componentWillMount 函数中，那么显而易见其会被触发多次，自然也就不是好的选择。 如果我们将AJAX 请求放置在生命周期的其他函数中，我们并不能保证请求仅在组件挂载完毕后才会要求响应。如果我们的数据请求在组件挂载之前就完成，并且调用了setState函数将数据添加到组件状态中，对于未挂载的组件则会报错。而在 componentDidMount 函数中进行 AJAX 请求则能有效避免这个问题

shouldComponentUpdate 的作用

shouldComponentUpdate 允许我们手动地判断是否要进行组件更新，根据组件的应用场景设置函数的合理返回值能够帮我们避免不必要的更新

如何告诉 React 它应该编译生产环境版

通常情况下我们会使用 Webpack 的 DefinePlugin 方法来将 NODE_ENV 变量值设置为 production。 编译版本中 React会忽略 propType 验证以及其他的告警信息，同时还会降低代码库的大小， React 使用了 Uglify 插件来移除生产环境下不必要的注释等信息

概述下 React 中的事件处理逻辑

为了解决跨浏览器兼容性问题，React 会将浏览器原生事件（Browser Native Event）封装为合成事件（SyntheticEvent）传入设置的事件处理器中。 这里的合成事件提供了与原生事件相同的接口，不过它们屏蔽了底层浏览器的细节差异，保证了行为的一致性。 另外有意思的是，React 并没有直接将事件附着到子元素上，而是以单一事件监听器的方式将所有的事件发送到顶层进行处理。 这样 React 在更新 DOM 的时候就不需要考虑如何去处理附着在 DOM 上的事件监听器，最终达到优化性能的目的

createElement 与 cloneElement 的区别是什么

createElement 函数是 JSX 编译之后使用的创建 React Element 的函数，而 cloneElement 则是用于复制某个元素并传入新的 Props

redux中间件

中间件提供第三方插件的模式，自定义拦截 action -> reducer 的过程。变为 action -> middlewares -> reducer。 这种机制可以让我们改变数据流，实现如异步action ，action 过滤，日志输出，异常报告等功能 redux-logger：提供日志输出 redux-thunk：处理异步操作 redux-promise：处理异步操作，actionCreator的返回值是promise

react组件的划分业务组件技术组件？

根据组件的职责通常把组件分为UI组件和容器组件。 UI 组件负责 UI 的呈现，容器组件负责管理数据和逻辑。 两者通过React-Redux 提供connect方法联系起来

react旧版生命周期函数

初始化阶段

getDefaultProps:获取实例的默认属性 getInitialState:获取每个实例的初始化状态 componentWillMount：组件即将被装载、渲染到页面上 render:组件在这里生成虚拟的DOM节点 componentDidMount:组件真正在被装载之后 运行中状态

componentWillReceiveProps:组件将要接收到属性的时候调用 shouldComponentUpdate:组件接受到新属性或者新状态的时候（可以返回false，接收数据后不更新，阻止render调用，后面的函数不会被继续执行了） componentWillUpdate:组件即将更新不能修改属性和状态 render:组件重新描绘 componentDidUpdate:组件已经更新 销毁阶段

componentWillUnmount:组件即将销毁

新版生命周期

在新版本中，React 官方对生命周期有了新的 变动建议:

使用getDerivedStateFromProps替换componentWillMount； 使用getSnapshotBeforeUpdate替换componentWillUpdate； 避免使用componentWillReceiveProps； 其实该变动的原因，正是由于上述提到的 Fiber。首先，从上面我们知道 React 可以分成 reconciliation 与 commit两个阶段，对应的生命周期如下:

reconciliation

componentWillMount componentWillReceiveProps shouldComponentUpdate componentWillUpdate commit

componentDidMount componentDidUpdate componentWillUnmount 在 Fiber 中，reconciliation 阶段进行了任务分割，涉及到 暂停 和 重启，因此可能会导致 reconciliation 中的生命周期函数在一次更新渲染循环中被 多次调用 的情况，产生一些意外错误

Git相关面试题

git代码冲突处理

先将本地修改存储起来 git stash 暂存了本地修改之后，就可以pull了。 git pull 还原暂存的内容 git stash pop stash@{0}

避免重复的合并冲突

正如每个开发人员都知道的那样，修复合并冲突相当繁琐，但重复解决完全相同的冲突（例如，在长时间运行的功能分支中）更让人心烦。解决方案是：

git config --global rerere.enabled true 或者你可以通过手动创建目录在每个项目的基础上启用.git/rr-cache。

使用其他设备从GitHub中导出远程分支项目，无法成功。

其原因在于本地中根本没有其分支。解决命令如下： git fetch -- 获取所有分支的更新 git branch -a -- 查看本地和远程分支列表，remotes开头的均为远程分支 -- 导出其远程分支，并通过-b设定本地分支跟踪远程分支 git checkout remotes/branch_name -b branch_name

APP相关面试题

你平常会看日志吗, 一般会出现哪些异常（Exception）?

这个主要是面试官考察你会不会看日志，是不是看得懂java里面抛出的异常，Exception

一般面试中java Exception（runtimeException ）是必会被问到的问题 app崩溃的常见原因应该也是这些了。常见的异常列出四五种，是基本要求。

常见的几种如下：

NullPointerException - 空指针引用异常 ClassCastException - 类型强制转换异常。 IllegalArgumentException - 传递非法参数异常。 ArithmeticException - 算术运算异常 ArrayStoreException - 向数组中存放与声明类型不兼容对象异常 IndexOutOfBoundsException - 下标越界异常 NegativeArraySizeException - 创建一个大小为负数的数组错误异常 NumberFormatException - 数字格式异常 SecurityException - 安全异常 UnsupportedOperationException - 不支持的操作异常

app的日志如何抓取?

app本身的日志，可以用logcat抓取,参考这篇：http://www.cnblogs.com/yoyoketang/…

adb logcat | find “com.sankuai.meituan” >d:\hello.txt

也可以用ddms抓取，手机连上电脑，打开ddms工具，或者在Android Studio开发工具中，打开DDMS

app对于不稳定偶然出现anr和crash时候你是怎么处理的？

app偶然出现anr和crash是比较头疼的问题，由于偶然出现无法复现步骤，这也是一个测试人员必备的技能，需要抓日志。查看日志主要有3个方法：

方法一：app开发保存错误日志到本地 一般app开发在debug版本，出现anr和crash的时候会自动把日志保存到本地实际的sd卡上，去对应的app目录取出来就可以了

方法二：实时抓取 当出现偶然的crash时候，这时候可以把手机拉到你们app开发那，手机连上他的开发代码的环境，有ddms会抓日志，这时候出现crash就会记录下来日志。 尽量重复操作让bug复现就可以了

也可以自己开着logcat，保存日志到电脑本地,参考这篇：http://www.cnblogs.com/yoyoketang/…

adb logcat | find “com.sankuai.meituan” >d:\hello.txt

方法三：第三方sdk统计工具

一般接入了第三方统计sdk,比如友盟统计，在友盟的后台会抓到报错的日志

App出现crash原因有哪些？

为什么App会出现崩溃呢？百度了一下，查到和App崩溃相关的几个因素：内存管理错误，程序逻辑错误，设备兼容，网络因素等，如下： 1.内存管理错误：可能是可用内存过低，app所需的内存超过设备的限制，app跑不起来导致App crash。 或是内存泄露，程序运行的时间越长，所占用的内存越大，最终用尽全部内存，导致整个系统崩溃。 亦或非授权的内存位置的使用也可能会导致App crash。 2.程序逻辑错误：数组越界、堆栈溢出、并发操作、逻辑错误。 e.g. app新添加一个未经测试的新功能，调用了一个已释放的指针，运行的时候就会crash。 3.设备兼容：由于设备多样性，app在不同的设备上可能会有不同的表现。 4.网络因素：可能是网速欠佳，无法达到app所需的快速响应时间，导致app crash。或者是不同网络的切换也可能会影响app的稳定性。

app出现ANR，是什么原因导致的？

那么导致ANR的根本原因是什么呢？简单的总结有以下两点：

1.主线程执行了耗时操作，比如数据库操作或网络编程 2.其他进程（就是其他程序）占用CPU导致本进程得不到CPU时间片，比如其他进程的频繁读写操作可能会导致这个问题。

细分的话，导致ANR的原因有如下几点： 1.耗时的网络访问 2.大量的数据读写 3.数据库操作 4.硬件操作（比如camera) 5.调用thread的join()方法、sleep()方法、wait()方法或者等待线程锁的时候 6.service binder的数量达到上限 7.system server中发生WatchDog ANR 8.service忙导致超时无响应 9.其他线程持有锁，导致主线程等待超时 10.其它线程终止或崩溃导致主线程一直等待。

android和ios测试区别？

App测试中ios和Android有哪些区别呢？ 1.Android长按home键呼出应用列表和切换应用，然后右滑则终止应用； 2.多分辨率测试，Android端20多种，ios较少； 3.手机操作系统，Android较多，ios较少且不能降级，只能单向升级；新的ios系统中的资源库不能完全兼容低版本中的ios系统中的应用，低版本ios系统中的应用调用了新的资源库，会直接导致闪退（Crash）； 4.操作习惯：Android，Back键是否被重写，测试点击Back键后的反馈是否正确；应用数据从内存移动到SD卡后能否正常运行等； 5.push测试：Android：点击home键，程序后台运行时，此时接收到push，点击后唤醒应用，此时是否可以正确跳转；ios，点击home键关闭程序和屏幕锁屏的情况（红点的显示）； 6.安装卸载测试：Android的下载和安装的平台和工具和渠道比较多，ios主要有app store，iTunes和testflight下载； 7.升级测试：可以被升级的必要条件：新旧版本具有相同的签名；新旧版本具有相同的包名；有一个标示符区分新旧版本（如版本号）， 对于Android若有内置的应用需检查升级之后内置文件是否匹配（如内置的输入法）

另外：对于测试还需要注意一下几点： 1.并发（中断）测试：闹铃弹出框提示，另一个应用的启动、视频音频的播放，来电、用户正在输入等，语音、录音等的播放时强制其他正在播放的要暂停； 2.数据来源的测试：输入，选择、复制、语音输入，安装不同输入法输入等； 3.push（推送）测试：在开关机、待机状态下执行推送，消息先死及其推送跳转的正确性； 应用在开发、未打开状态、应用启动且在后台运行的情况下是push显示和跳转否正确； 推送消息阅读前后数字的变化是否正确； 多条推送的合集的显示和跳转是否正确；

4.分享跳转：分享后的文案是否正确；分享后跳转是否正确，显示的消息来源是否正确；

5.触屏测试：同时触摸不同的位置或者同时进行不同操作，查看客户端的处理情况，是否会crash等

app测试和web测试有什么区别？

WEB测试和App测试从流程上来说，没有区别。 都需要经历测试计划方案，用例设计，测试执行，缺陷管理，测试报告等相关活动。 从技术上来说，WEB测试和APP测试其测试类型也基本相似，都需要进行功能测试、性能测试、安全性测试、GUI测试等测试类型。

他们的主要区别在于具体测试的细节和方法有区别，比如：性能测试，在WEB测试只需要测试响应时间这个要素，在App测试中还需要考虑流量测试和耗电量测试。

兼容性测试：在WEB端是兼容浏览器，在App端兼容的是手机设备。而且相对应的兼容性测试工具也不相同，WEB因为是测试兼容浏览器，所以需要使用不同的浏览器进行兼容性测试（常见的是兼容IE6，IE8，chrome，firefox）如果是手机端，那么就需要兼容不同品牌，不同分辨率，不同android版本甚至不同操作系统的兼容。（常见的兼容方式是兼容市场占用率前N位的手机即可），有时候也可以使用到兼容性测试工具，但WEB兼容性工具多用IETester等工具，而App兼容性测试会使用Testin这样的商业工具也可以做测试。

安装测试：WEB测试基本上没有客户端层面的安装测试，但是App测试是存在客户端层面的安装测试，那么就具备相关的测试点。

还有，App测试基于手机设备，还有一些手机设备的专项测试。如交叉事件测试，操作类型测试，网络测试（弱网测试，网络切换）

交叉事件测试：就是在操作某个软件的时候，来电话、来短信，电量不足提示等外部事件。

操作类型测试：如横屏测试，手势测试

网络测试：包含弱网和网络切换测试。需要测试弱网所造成的用户体验，重点要考虑回退和刷新是否会造成二次提交。弱网络的模拟，据说可以用360wifi实现设置。

从系统架构的层面，WEB测试只要更新了服务器端，客户端就会同步会更新。而且客户端是可以保证每一个用户的客户端完全一致的。但是APP端是不能够保证完全一致的，除非用户更新客户端。如果是APP下修改了服务器端，意味着客户端用户所使用的核心版本都需要进行回归测试一遍。

还有升级测试：升级测试的提醒机制，升级取消是否会影响原有功能的使用，升级后用户数据是否被清除了。

Android四大组件

Android四大基本组件：Activity、BroadcastReceiver广播接收器、ContentProvider内容提供者、Service服务。

Activity:

应用程序中，一个Activity就相当于手机屏幕，它是一种可以包含用户界面的组件，主要用于和用户进行交互。一个应用程序可以包含许多活动，比如事件的点击，一般都会触发一个新的Activity。

BroadcastReceiver广播接收器：

应用可以使用它对外部事件进行过滤只对感兴趣的外部事件(如当电话呼入时，或者数据网络可用时)进行接收并做出响应。广播接收器没有用户界面。然而，它们可以启动一个activity或serice 来响应它们收到的信息，或者用NotificationManager来通知用户。通知可以用很多种方式来吸引用户的注意力──闪动背灯、震动、播放声音等。一般来说是在状态栏上放一个持久的图标，用户可以打开它并获取消息。

ContentProvider内容提供者:

内容提供者主要用于在不同应用程序之间实现数据共享的功能，它提供了一套完整的机制，允许一个程序访问另一个程序中的数据，同时还能保证被访问数据的安全性。只有需要在多个应用程序间共享数据时才需要内容提供者。例如：通讯录数据被多个应用程序使用，且必须存储在一个内容提供者中。它的好处：统一数据访问方式。

Service服务：

是Android中实现程序后台运行的解决方案，它非常适合去执行那些不需要和用户交互而且还要长期运行的任务（一边打电话，后台挂着QQ）。服务的运行不依赖于任何用户界面，即使程序被切换到后台，或者用户打开了另一个应用程序，服务扔然能够保持正常运行，不过服务并不是运行在一个独立的进程当中，而是依赖于创建服务时所在的应用程序进程。当某个应用程序进程被杀掉后，所有依赖于该进程的服务也会停止运行（正在听音乐，然后把音乐程序退出）。

Activity生命周期?

周期即活动从开始到结束所经历的各种状态。生命周期即活动从开始到结束所经历的各个状态。从一个状态到另一个状态的转变，从无到有再到无，这样一个过程中所经历的状态就叫做生命周期。

Activity本质上有四种状态：

1.运行（Active/Running）:Activity处于活动状态，此时Activity处于栈顶，是可见状态，可以与用户进行交互

2.暂停（Paused）:当Activity失去焦点时，或被一个新的非全面屏的Activity，或被一个透明的Activity放置在栈顶时，Activity就转化为Paused状态。此刻并不会被销毁，只是失去了与用户交互的能力，其所有的状态信息及其成员变量都还在，只有在系统内存紧张的情况下，才有可能被系统回收掉

3.停止（Stopped）:当Activity被系统完全覆盖时，被覆盖的Activity就会进入Stopped状态，此时已不在可见，但是资源还是没有被收回

4.系统回收（Killed）:当Activity被系统回收掉，Activity就处于Killed状态

如果一个活动在处于停止或者暂停的状态下，系统内存缺乏时会将其结束（finish）或者杀死（kill）。这种非正常情况下，系统在杀死或者结束之前会调用onSaveInstance()方法来保存信息，同时，当Activity被移动到前台时，重新启动该Activity并调用onRestoreInstance()方法加载保留的信息，以保持原有的状态。

在上面的四中常有的状态之间，还有着其他的生命周期来作为不同状态之间的过度，用于在不同的状态之间进行转换，生命周期的具体说明见下。

什么是activity

什么是activity，这个前两年出去面试APP测试岗位，估计问的最多了，特别是一些大厂，先问你是不是做过APP测试，那好，你说说什么是activity? 如果没看过android的开发原理，估计这个很难回答，要是第一个问题就被难住了，面试的信心也会失去一半了，士气大减。

Activity是Android的四大组件之一，也是平时我们用到最多的一个组件，可以用来显示View。 官方的说法是Activity一个应用程序的组件，它提供一个屏幕来与用户交互，以便做一些诸如打电话、发邮件和看地图之类的事情，原话如下： An Activity is an application component that provides a screen with which users can interact in order to do something, such as dial the phone, take a photo, send an email, or view a map.

Activity是一个Android的应用组件，它提供屏幕进行交互。每个Activity都会获得一个用于绘制其用户界面的窗口，窗口可以充满哦屏幕也可以小于屏幕并浮动在其他窗口之上。 一个应用通常是由多个彼此松散联系的Activity组成，一般会指定应用中的某个Activity为主活动，也就是说首次启动应用时给用户呈现的Activity。将Activity设为主活动的方法 当然Activity之间可以进行互相跳转，以便执行不同的操作。每当新Activity启动时，旧的Activity便会停止，但是系统会在堆栈也就是返回栈中保留该Activity。 当新Activity启动时，系统也会将其推送到返回栈上，并取得用在这里插入图片描述 户的操作焦点。当用户完成当前Activity并按返回按钮是，系统就会从堆栈将其弹出销毁，然后回复前一Activity 当一个Activity因某个新Activity启动而停止时，系统会通过该Activity的生命周期回调方法通知其这一状态的变化。 Activity因状态变化每个变化可能有若干种，每一种回调都会提供执行与该状态相应的特定操作的机会

语音通话功能

WebRTC实时通讯的核心 WebRTC 建立连接步骤 1.为连接的两端创建一个 RTCPeerConnection 对象，并且给 RTCPeerConnection 对象添加本地流。

2.获取本地媒体描述信息(SDP)，并与对端进行交换。

3.获取网络信息(Candidate，IP 地址和端口)，并与远端进行交换。

装逼神器

一般通过面试的短短一个小时时间，面试官需要对你的技术底子进行磨盘，如果你看完下面这些材料，相信你一定能够让他心里直呼牛逼（下面所有链接文章均是小编自己总结的）

关于scoped样式穿透问题

blog.csdn.net/JHXL_/artic…

Vue2和Vue3的区别

blog.csdn.net/JHXL_/artic…

项目中的登录流程

blog.csdn.net/JHXL_/artic…

构造函数、原型、继承

blog.csdn.net/JHXL_/artic…

项目中遇到的难点

• 前端导出文件，后端返回文件流过大直接干崩溃

• 关于“wap2app仅支持对已通过ICP备案的域名站点进行打包”问题解决

写在最后

✨原创不易，还希望各位大佬支持一下\textcolor{blue}{原创不易，还希望各位大佬支持一下}原创不易，还希望各位大佬支持一下
👍 点赞，你的认可是我创作的动力！\textcolor{green}{点赞，你的认可是我创作的动力！}点赞，你的认可是我创作的动力！
⭐️ 收藏，你的青睐是我努力的方向！\textcolor{green}{收藏，你的青睐是我努力的方向！}收藏，你的青睐是我努力的方向！
✏️ 评论，你的意见是我进步的财富！\textcolor{green}{评论，你的意见是我进步的财富！}评论，你的意见是我进步的财富！

作者：几何心凉
来源：https://juejin.cn/post/7039640038509903909

最近，陆陆续续搞 了一个 UniUsingComponentsWebpackPlugin 插件(下面介绍)，这是自己第三个开源项目，希望大家一起来维护，一起 star 呀，其它两个：

• vue-okr-tree

  基于 Vue 2的组织架构树组件

  地址：github.com/qq449245884…

• ztjy-cli

  团队的一个简易模板初始化脚手架

  地址：github.com/qq449245884…

• UniUsingComponentsWebpackPlugin

  地址：github.com/qq449245884…

  配合UniApp，用于集成小程序原生组件

  • 配置第三方库后可以自动引入其下的原生组件，而无需手动配置

  • 生产构建时可以自动剔除没有使用到的原生组件

背景

第一个痛点

用 uniapp开发小程序的小伙伴应该知道，我们在 uniapp 中要使用第三方 UI 库(vant-weapp，iView-weapp)的时候 ，想要在全局中使用，需要在 src/pages.json 中的 usingComponents 添加对应的组件声明，如：

// src/pages.json
"usingComponents": {
    "van-button": "/wxcomponents/@vant/weapp/button/index",
  }

但在开发过程中，我们不太清楚需要哪些组件，所以我们可能会全部声明一遍（PS:这在做公共库的时候更常见)，所以我们得一个个的写，做为程序员，我们绝不允许使用这种笨方法。这是第一个痛点。

第二个痛点

使用第三方组件，除了在 src/pages.json 还需要在对应的生产目录下建立 wxcomponents，并将第三方的库拷贝至该文件下，这个是 uniapp 自定义的，详细就见：uniapp.dcloud.io/frame?id=%e…

这是第二个痛点。

第三个痛点

第二痛点，我们将整个UI库拷贝至 wxcomponents，但最终发布的时候，我们不太可能全都用到了里面的全局组件，所以就将不必要的组件也发布上去，增加代码的体积。

有的小伙伴就会想到，那你将第三方的库拷贝至 wxcomponents时候，可以只拷使用到的就行啦。是这理没错，但组件里面可能还会使用到其它组件，我们还得一个个去看，然后一个个引入，这又回到了第一个痛点了。

有了这三个痛点，必须得有个插件来做这些傻事，处理这三个痛点。于是就有 UniUsingComponentsWebpackPlugin 插件，这个webpack 插件主要解决下面几个问题：

• 配置第三方库后可以自动引入其下的原生组件，而无需手动配置

• 生产构建时可以自动剔除没有使用到的原生组件

webpack 插件

webpack 的插件体系是一种基于 Tapable 实现的强耦合架构，它在特定时机触发钩子时会附带上足够的上下文信息，插件定义的钩子回调中，能也只能与这些上下文背后的数据结构、接口交互产生 side effect，进而影响到编译状态和后续流程。

从形态上看，插件通常是一个带有 apply函数的类：

class SomePlugin {
    apply(compiler) {
    }
}

Webpack 会在启动后按照注册的顺序逐次调用插件对象的 apply 函数，同时传入编译器对象 compiler ，插件开发者可以以此为起点触达到 webpack 内部定义的任意钩子，例如：

class SomePlugin {
    apply(compiler) {
        compiler.hooks.thisCompilation.tap('SomePlugin', (compilation) => {
        })
    }
}

注意观察核心语句 compiler.hooks.thisCompilation.tap，其中 thisCompilation 为 tapable 仓库提供的钩子对象；tap 为订阅函数，用于注册回调。

Webpack 的插件体系基于tapable 提供的各类钩子展开，所以有必要先熟悉一下 tapable 提供的钩子类型及各自的特点。

到这里，就不做继续介绍了，关于插件的更多 详情可以去官网了解。

这里推荐 Tecvan 大佬写的 《Webpack 插件架构深度讲解》mp.weixin.qq.com/s/tXkGx6Ckt…

实现思路

UniUsingComponentsWebpackPlugin 插件主要用到了三个 compiler 钩子。

第一个钩子是 environment:

compiler.hooks.environment.tap(
      'UniUsingComponentsWebpackPlugin',
      async () => {
        // todo someing
      }
    );

这个钩子主要用来自动引入其下的原生组件，这样就无需手动配置。解决第一个痛点。

第二个钩子 thisCompilation，这个钩子可以获得 compilation，能对最终打包的产物进行操作：

compiler.hooks.thisCompilation.tap(
      'UniUsingComponentsWebpackPlugin',
      (compilation) => {
        // 添加资源 hooks
        compilation.hooks.additionalAssets.tapAsync(
          'UniUsingComponentsWebpackPlugin',
          async (cb) => {
            await this.copyUsingComponents(compiler, compilation);
            cb();
          }
        );
      }
    );

所以这个勾子用来将 node_modules 下的第三库拷贝到我们生产 dist 目录里面的 wxcomponents ，解决第二个痛点。

ps：这里也可直接用现有的 copy-webpack-plugin 插件来实现。

第三个钩子 done，表示 compilation 执行完成：

    if (process.env.NODE_ENV === 'production') {
      compiler.hooks.done.tapAsync(
        'UniUsingComponentsWebpackPlugin',
        (stats, callback) => {
          this.deleteNoUseComponents();
          callback();
        }
      );
    }

执行完成后，表示我们已经生成 dist 目录了，可以读取文件内容，分析，获取哪些组件被使用了，然后删除没有使用到组件对应的文件。这样就可以解决我们第三个痛点了。

PS：这里我判断只有在生产环境下才会 剔除，开发环境没有，也没太必要。

使用

安装

npm install uni-using-components-webpack-plugin --save-dev

然后将插件添加到 WebPack Config 中。例如：

const UniUsingComponentsWebpackPlugin = require("uni-using-components-webpack-plugin");

module.exports = {
  plugins: [
    new UniUsingComponentsWebpackPlugin({
        patterns: [
        {
            prefix: 'van',
            module: '@vant/weapp',
        },
        {
            prefix: 'i',
            module: 'iview-weapp',
        },
        ],
    })
  ],
};

注意：uni-using-components-webpack-plugin 只适用在 UniApp 开发的小程序。

参数

Patterns

module 是指 package.json 里面的 name，如使用是 Vant 对应的 module 为@vant/weapp，如果使用是 iview，刚对应的 module 为 iview-weapp，具体可看它们各自的 package.json。

prefix 是指组件的前缀，如 Vant 使用是 van 开头的前缀，iview 使用是 i 开头的前缀，具体可看它们各自的官方文档。

PS: 这里得吐曹一下 vant，叫别人使用 van 的前缀，然后自己组件里面声明子组件时，却没有使用 van 前缀，如 picker 组件，它里面的 JSON 文件是这么写的：

{

  "component": true,

  "usingComponents": {

    "picker-column": "../picker-column/index",

    "loading": "../loading/index"

  }

}

picker-column 和 loading 都没有带 van 前缀，因为这个问题，在做 自动剔除 功能中，我是根据 前缀来判断使用哪些组件的，由于这里的 loading ，picker-column 没有加前缀，所以就被会删除，导致最终的 picker 用不了。为了解决这个问题，增加了不少工作量。

希望 Vant 官方后面的版本能优化一下。

总结

本文通用自定义 Webpack 插件来实现日常一些技术优化需求。主要为大家介绍了 Webpack 插件的基本组成和简单架构，通过三个痛点，引出了 uni-using-components-webpack-plugin 插件，并介绍了使用方式，实现思路。

最后，关于 Webpack 插件开发，还有更多知识可以学习，建议多看看官方文档《Writing a Plugin》进行学习。

代码部署后可能存在的BUG没法实时知道，事后为了解决这些BUG，花了大量的时间进行log 调试，这边顺便给大家推荐一个好用的BUG监控工具 Fundebug。

作者：前端小智
来源：https://juejin.cn/post/7039855875967696904

作者：Tzyito
链接：https://juejin.cn/post/7008422231403397134

探析它之前，我们先抛出以下几个疑问：

• 为什么需要 V8 引擎呢？

• V8 引擎到底是个啥？

• 它可以做些什么呢？

• 了解它能有什么收获呢？

接下来就针对以上几个问题进行详细描述。

由来

我们都知道，JS 是一种解释型语言，支持动态类型（明显不同于 Java 等这类静态语言就是在命名一个变量时不需要声明变量的类型）、弱类型、基于原型的语言，内置支持类型。而一般 JS 都是在前端执行（直接影响界面），需要能够快速响应用户，那么就要求语言本身可以被快速地解析和执行，JS 引擎就为此而问世。

这里提到了解释型语言和静态语言（编译型语言），先简单介绍一下二者：

• 解释型语言（JS）

  • 每次运行时需要解释器按句依次解释源代码执行，将它们翻译成机器认识的机器代码再执行

• 编译型语言（Java)

  • 运行时可经过编译器翻译成可执行文件，再由机器运行该可执行文件即可

从上面的描述中可以看到 JS 运行时每次都要根据源文件进行解释然后执行，而编译型的只需要编译一次，下次可直接运行其可执行文件，但是这样就会导致跨平台的兼容性很差，因此各有优劣。

而众多 JS 引擎（V8、JavaScriptCore、SpiderMonkey、Chakra等）中 V8 是最为出色的，加上它也是应用于当前最流行的谷歌浏览器，所以我们非常有必要去认识和了解一下，这样对于开发者也就更清楚 JS 在浏览器中到底是如何运行的了。

认识

定义

• 使用 C++ 开发

• 谷歌开源

• 编译成原生机器码（支持IA-32, x86-64, ARM, or MIPS CPUs）

• 使用了如内联缓存（inline caching）等方法来提高性能

• 运行速度快，可媲美二进制程序

• 支持众多操作系统，如 windows、linux、android 等

• 支持其他硬件架构，如 IA32,X64,ARM 等

• 具有很好的可移植和跨平台特性

运行

先来一张官方流程图：

准备

JS 文件加载（不归 V8 管）：可能来自于网络请求、本地的cache或者是也可以是来自service worker，这是 V8 运行的前提（有源文件才有要解释执行的）。 3种加载方式 & V8的优化：

• Cold load: 首次加载脚本文件时，没有任何数据缓存

• Warm load：V8 分析到如果使用了相同的脚本文件，会将编译后的代码与脚本文件一起缓存到磁盘缓存中

• Hot load: 当第三次加载相同的脚本文件时，V8 可以从磁盘缓存中载入脚本，并且还能拿到上次加载时编译后的代码，这样可以避免完全从头开始解析和编译脚本

而在 V8 6.6 版本的时候进一步改进代码缓存策略，简单讲就是从缓存代码依赖编译过程的模式，改变成两个过程解耦，并增加了可缓存的代码量，从而提升了解析和编译的时间，大大提升了性能，具体细节见V8 6.6 进一步改进缓存性能。

分析

此过程是将上面环节得到的 JS 代码转换为 AST（抽象语法树）。

词法分析

从左往右逐个字符地扫描源代码，通过分析，产生一个不同的标记，这里的标记称为 token，代表着源代码的最小单位，通俗讲就是将一段代码拆分成最小的不可再拆分的单元，这个过程称为词法标记，该过程的产物供下面的语法分析环节使用。

这里罗列一下词法分析器常用的 token 标记种类：

• 常数（整数、小数、字符、字符串等）

• 操作符（算术操作符、比较操作符、逻辑操作符）

• 分隔符（逗号、分号、括号等）

• 保留字

• 标识符（变量名、函数名、类名等）

TOKEN-TYPE TOKEN-VALUE\
-----------------------------------------------\
T_IF                 if\
T_WHILE              while\
T_ASSIGN             =\
T_GREATTHAN          >\
T_GREATEQUAL         >=\
T_IDENTIFIER name    / numTickets / ...\
T_INTEGERCONSTANT    100 / 1 / 12 / ....\
T_STRINGCONSTANT     "This is a string" / "hello" / ...

上面提到会逐个从左至右扫描代码然后分析，那么很明显就会想到两种方案，扫描完再分析（非流式处理）和边扫描边分析（流式处理），简单画一下他们的时序图就能发现流式处理效率要高得多，同时分析完也会释放分析过程中占用的内存，也能大大提高内存使用效率，可见该优化的细节处理。

语法分析

语法分析是指根据某种给定的形式文法对由单词序列构成的输入文本（例如上个阶段的词法分析产物-tokens stream），进行分析并确定其语法结构的过程，最后产出其 AST（抽象语法树）。

V8 会将语法分析的过程分为两个阶段来执行：

• Pre-parser

  • 跳过还未使用的代码

  • 不会生成对应的 AST，会产生不带有变量的引用和声明的 scopes 信息

  • 解析速度会是 Full-parser 的 2 倍

  • 根据 JS 的语法规则仅抛出一些特定的错误信息

• Full-parser

  • 解析那些使用的代码

  • 生成对应的 AST

  • 产生具体的 scopes 信息，带有变量引用和声明等信息

  • 抛出所有的 JS 语法错误

为什么要做两次解析？

如果仅有一次，那只能是 Full-parser，但这样的话，大量未使用的代码会消耗非常多的解析时间，结合实例来看下：通过 Coverage 录制的方式可以分析页面哪些代码没有用到，如下图可以看到最高有 75% 的没有被执行。

但是预解析并不是万能的，得失是并存的，很明显的一个场景：该文件中的代码全都执行了，那其实就是没必要的，当然这种情况其实还是占比远不如上面的例子，所以这里其实也是一种权衡，需要照顾大多数来达到综合性能的提升。

下面给出一个示例：

function add(x, y) {
    if (typeof x === "number") {
        return x + y;
    } else {
        return x + 'tadm';
    }
}

复制上面的代码到 web1 和 web2 可以很直观的看到他们的 tokens 和 AST 结构（也可自行写一些代码体验）。

• tokens

[
    {
        "type": "Keyword",
        "value": "function"
    },
    {
        "type": "Identifier",
        "value": "add"
    },
    {
        "type": "Punctuator",
        "value": "("
    },
    {
        "type": "Identifier",
        "value": "x"
    },
    {
        "type": "Punctuator",
        "value": ","
    },
    {
        "type": "Identifier",
        "value": "y"
    },
    {
        "type": "Punctuator",
        "value": ")"
    },
    {
        "type": "Punctuator",
        "value": "{"
    },
    {
        "type": "Keyword",
        "value": "if"
    },
    {
        "type": "Punctuator",
        "value": "("
    },
    {
        "type": "Keyword",
        "value": "typeof"
    },
    {
        "type": "Identifier",
        "value": "x"
    },
    {
        "type": "Punctuator",
        "value": "==="
    },
    {
        "type": "String",
        "value": "\"number\""
    },
    {
        "type": "Punctuator",
        "value": ")"
    },
    {
        "type": "Punctuator",
        "value": "{"
    },
    {
        "type": "Keyword",
        "value": "return"
    },
    {
        "type": "Identifier",
        "value": "x"
    },
    {
        "type": "Punctuator",
        "value": "+"
    },
    {
        "type": "Identifier",
        "value": "y"
    },
    {
        "type": "Punctuator",
        "value": ";"
    },
    {
        "type": "Punctuator",
        "value": "}"
    },
    {
        "type": "Keyword",
        "value": "else"
    },
    {
        "type": "Punctuator",
        "value": "{"
    },
    {
        "type": "Keyword",
        "value": "return"
    },
    {
        "type": "Identifier",
        "value": "x"
    },
    {
        "type": "Punctuator",
        "value": "+"
    },
    {
        "type": "String",
        "value": "'tadm'"
    },
    {
        "type": "Punctuator",
        "value": ";"
    },
    {
        "type": "Punctuator",
        "value": "}"
    },
    {
        "type": "Punctuator",
        "value": "}"
    }
]

• AST

{
  "type": "Program",
  "body": [
    {
      "type": "FunctionDeclaration",
      "id": {
        "type": "Identifier",
        "name": "add"
      },
      "params": [
        {
          "type": "Identifier",
          "name": "x"
        },
        {
          "type": "Identifier",
          "name": "y"
        }
      ],
      "body": {
        "type": "BlockStatement",
        "body": [
          {
            "type": "IfStatement",
            "test": {
              "type": "BinaryExpression",
              "operator": "===",
              "left": {
                "type": "UnaryExpression",
                "operator": "typeof",
                "argument": {
                  "type": "Identifier",
                  "name": "x"
                },
                "prefix": true
              },
              "right": {
                "type": "Literal",
                "value": "number",
                "raw": "\"number\""
              }
            },
            "consequent": {
              "type": "BlockStatement",
              "body": [
                {
                  "type": "ReturnStatement",
                  "argument": {
                    "type": "BinaryExpression",
                    "operator": "+",
                    "left": {
                      "type": "Identifier",
                      "name": "x"
                    },
                    "right": {
                      "type": "Identifier",
                      "name": "y"
                    }
                  }
                }
              ]
            },
            "alternate": {
              "type": "BlockStatement",
              "body": [
                {
                  "type": "ReturnStatement",
                  "argument": {
                    "type": "BinaryExpression",
                    "operator": "+",
                    "left": {
                      "type": "Identifier",
                      "name": "x"
                    },
                    "right": {
                      "type": "Literal",
                      "value": "tadm",
                      "raw": "'tadm'"
                    }
                  }
                }
              ]
            }
          }
        ]
      },
      "generator": false,
      "expression": false,
      "async": false
    }
  ],
  "sourceType": "script"
}

解释

该阶段就是将上面产生的 AST 转换成字节码。

这里增加字节码（中间产物）的好处是，并不是将 AST 直接翻译成机器码，因为对应的 cpu 系统会不一致，翻译成机器码时要结合每种 cpu 底层的指令集，这样实现起来代码复杂度会非常高；还有个就是内存占用的问题，因为机器码会存储在内存中，而退出进程后又会存储在磁盘上，加上转换后的机器码多出来很多信息，会比源文件大很多，导致了严重的内存占用问题。

V8 在执行字节码的过程中，使用到了通用寄存器和累加寄存器，函数参数和局部变量保存在通用寄存器里面，累加器中保存中间计算结果，在执行指令的过程中，如果直接由 cpu 从内存中读取数据的话，比较影响程序执行的性能，使用寄存器存储中间数据的设计，可以大大提升 cpu 执行的速度。

编译

这个过程主要是 V8 的 TurboFan编译器 将字节码翻译成机器码的过程。

字节码配合解释器和编译器这一技术设计，可以称为JIT（即时编译技术），Java 虚拟机也是类似的技术，解释器在解释执行字节码时，会收集代码信息，标记一些热点代码（就是一段代码被重复执行多次），TurboFan 会将热点代码直接编译成机器码，缓存起来，下次调用直接运行对应的二进制的机器码，加快执行速度。

在 TurboFan 将字节码编译成机器码的过程中，还进行了简化处理：常量合并、强制折减、代数重新组合。

比如：3 + 4 --> 7，x + 1 + 2 --> x + 3 ......

执行

到这里我们就开始执行上一阶段产出的机器码。

而在 JS 的执行过程中，经常遇到的就是对象属性的访问。作为一种动态的语言，一个简单的属性访问可能包含着复杂的语义，比如Object.xxx的形式，可能是属性的直接访问，也可能去调用的对象的Getter方法，还有可能是要通过原型链往上层对象中查找。这种不确定性而且动态判断的情况，会浪费很多查找时间，所以 V8 会把第一次分析的结果放在缓存中，当再次访问相同的属性时，会优先从缓存中去取，调用 GetProperty(Object, "xxx", feedback_cache) 的方法获取缓存，如果有缓存结果，就会跳过查找过程，又大大提升了运行性能。

除了上面针对读取对象属性的结果缓存的优化，V8 还引入了 Object Shapes（隐藏类）的概念，这里面会记录一些对象的基本信息（比如对象拥有的所有属性、每个属性对于这个对象的偏移量等），这样我们去访问属性时就可以直接通过属性名和偏移量直接定位到他的内存地址，读取即可，大大提升访问效率。

既然 V8 提出了隐藏类（两个形状相同的对象会去复用同一个隐藏类，何为形状相同的对象？两个对象满足有相同个数的相同属性名称和相同的属性顺序），那么我们开发者也可以很好的去利用它：

• 尽量创建形状相同的对象

• 创建完对象后尽量不要再去操作属性，即不增加或者删除属性，也就不会破环对象的形状

完成

到此 V8 已经完成了一份 JS 代码的读取、分析、解释、编译、执行。

总结

以上就是从 JS 代码下载到最终在 V8 引擎执行的过程分析，可以发现 V8 其实有很多实现的技术点，有着很巧妙的设计思想，比如流式处理、缓存中间产物、垃圾回收等，这里面又会涉及到很多细节，很值得继续深入研究。

作者：Tadm
来源：https://juejin.cn/post/7032278688192430117

前言

作为一个前端，对于console.log的调试可谓是相当熟悉，话不多说就是好用！帮助我们解决了很多bug^_^
但是！有因必有果（虽然不知道为什么说这句但是很顺口），如果把console发到生产环境也是很头疼的，尤其是如果打印的信息很私密的话，可能要凉凉TT

删除console方式介绍

对于在生产环境必须要清除的console语句，如果手动一个个删除，听上去就很辛苦，因此这篇文章本着看到了就要学，学到了就要用的精神我打算介绍一下手写loader的方式清除代码中的console语句，在此之前也介绍一下其他可以清除console语句的方式吧哈哈

1. 方式一：暴力清除

通过编辑器查找所有console，或者eslint编译时的报错提示定位语句，然后清除，就是有点费手，不够优雅
因此下面需要介绍几种优雅的清除方式

2. 方式二 ：uglifyjs-webpack-plugin

该插件可用于压缩我们的js代码，同时可以通过配置去掉console语句，安装后配置在webpack的optimization下，即可使用，需要注意的是：此配置只在production环境下生效

安装
npm i uglifyjs-webpack-plugin

其中drop_console和pure_funcs的区别是：

• drop_console的配置值为boolean，也就是说如果为true，那么代码中所有带console前缀的调试方式都会被清除，包括console.log,console.warn等

• pure_funcs的配置值是一个数组，也就是可以配置清除那些带console前缀的语句，截图中配的是['console.log'],因此生产环境上只会清除console.log,如果代码中包含其他带console的前缀，如console.warn则保留

但是需要注意的是，该方法只对ES5语法有效，如果你的代码中涉及ES6就会报错

3. 方式三：terser-webpack-plugin

webpack v5 开箱即带有最新版本的 terser-webpack-plugin。如果你使用的是 webpack v5 或更高版本，同时希望自定义配置，那么仍需要安装 terser-webpack-plugin。如果使用 webpack v4，则必须安装 terser-webpack-plugin v4 的版本。

安装
npm i terser-webpack-plugin@4

terser-webpack-plugin对于清楚console的配置可谓是跟uglifyjs-webpack-plugin一点没差，但是他们最大的差别就是TerserWebpackPlugin支持ES6的语法

4. 方式四：手写loader删除console

终于进入了主题了，朋友们

1. 什么是loader

众所周知，webpack只能理解js，json等文件，那么除了js，json之外的文件就需要通过loader去顺利加载，因此loader在其中担任的就是翻译工作。loader可以看作一个node模块，实际上就是一个函数，但他不能是一个箭头函数，因为它需要继承webpack的this，可以在loader中使用webpack的方法。

• 单一原则，一个loader只做一件事

• 调用方式，loader是从右向左调用，遵循链式调用

• 统一原则，输入输出都是字符串或者二进制数据

根据第三点，下面的代码就会报错，因为输出的是数字而不是字符串或二进制数据

module.exports = function(source) {
    return 111
}

1. 新建清除console语句的loader

首先新建一个dropConsole.js文件

// source：表示当前要处理的内容
const reg = /(console.log\()(.*)(\))/g;
module.exports = function(source) {
    // 通过正则表达式将当前处理内容中的console替换为空字符串
    source = source.replace(reg, "")
    // 再把处理好的内容return出去，坚守输入输出都是字符串的原则，并可达到链式调用的目的供下一个loader处理
    return source
}

1. 在webpack的配置文件中引入

module: {
    rules:[
        {
            test: /\.js/,
            use: [
               {
                loader: path.resolve(__dirname, "./dropConsole.js"),
                options: {
                 name: "前端"
                }
               }
            ]
        },
      {
   ]
}

在webpack的配置中，loader的导入需要绝对路径，否则导入失效，如果想要像第三方loader一样引入，就需要配置resolveLoader 中的modules属性，告诉webpack，当node_modules中找不到时，去别的目录下找

module: {
    rules:[
        {
            test: /\.js/,
            use: [
               {
                loader: 'dropConsole',
                options: {
                 name: "前端"
                }
               }
            ]
        },
      {
   ]
}
resolveLoader:{
    modules:["./node_modules","./build"] //此时我的loader写在build目录下
},

正常运行后，调试台将不会打印console信息

1. 最后介绍几种在loader中常用的webpack api

• this.query:返回webpack的参数即options的对象

• this.callback:同步模式，可以把自定义处理好的数据传递给webpack

const reg = /(console.log\()(.*)(\))/g;
module.exports = function(source) {
    source = source.replace(reg, "");
    this.callback(null,source);
    // return的作用是让webpack知道loader返回的结果应该在this.callback当中，而不是return中
    return     
}

• this.async():异步模式，可以大致的认为是this.callback的异步版本，因为最终返回的也是this.callback

const  path = require('path')
const util  = require('util')
const babel = require('@babel/core')


const transform = util.promisify(babel.transform)

module.exports = function(source,map,meta) {
  var callback = this.async();

  transform(source).then(({code,map})=> {
      callback(null, code,map)
  }).catch(err=> {
      callback(err)
  })
};

最后的最后，webpack博大精深，值得我们好好学习，深入研究！

作者：我也想一夜暴富
来源：https://juejin.cn/post/7038413043084034062

为什么要热更新

热更新主要是针对app上线之后页面出现bug，修改之后又得打包，上线，每次用户都得在应用市场去下载很影响用户体验，如果用户不愿意更新，一直提示都不愿意更新，这个bug就会一直存在。 可能你一不小心写错了代码，整个团队的努力都会付之东流，苦不苦，冤不冤，想想都苦，所以这个时候热更新就显得很重要了。

首先你需要在manifest.json 中修改版本号

如果之前是1.0.0那么修改之后比如是1.0.1或者1.1.0这样

然后你需要在HBuilderX中打一个wgt包

在顶部>发行>原生App-制作移动App资源升级包

包的位置会在控制台里面输出

你需要和后端约定一下接口，传递参数

然后你就可以在app.vue的onLaunch里面编写热更新的代码了，如果你有其他需求，你可以在其他页面的onLoad里面编写。

// #ifdef APP-PLUS  //APP上面才会执行
plus.runtime.getProperty(plus.runtime.appid,
function(widgetInfo) {
    uni.request({
        url: '请求url写你自己的',
        method: "POST",
        data: {
            version: widgetInfo.version,
            //app版本号
            name: widgetInfo.name //app名称
        },
        success: (result) = >{
            console.log(result) //请求成功的数据
            var data = result.data.data
            if (data.update && data.wgtUrl) {
                var uploadTask = uni.downloadFile({ //下载
                    url: data.wgtUrl,
                    //后端传的wgt文件
                    success: (downloadResult) = >{ //下载成功执行
                        if (downloadResult.statusCode === 200) {
                            plus.runtime.install(downloadResult.tempFilePath, {
                                force: flase
                            },
                            function() {
                                plus.runtime.restart();
                            },
                            function(e) {});
                        }
                    },
                }) uploadTask.onProgressUpdate((res) = >{
                    // 测试条件，取消上传任务。
                    if (res.progress == 100) { //res.progress 上传进度
                        uploadTask.abort();
                    }
                });
            }
        }
    });
});
// #endif

不支持的情况

• SDK 部分有调整，比如新增了 Maps 模块等，不可通过此方式升级，必须通过整包的方式升级。

• 原生插件的增改，同样不能使用此方式。
  对于老的非自定义组件编译模式，这种模式已经被淘汰下线。但以防万一也需要说明下，老的非自定义组件编译模式，如果之前工程没有 nvue 文件，但更新中新增了 nvue 文件，不能使用此方式。因为非自定义组件编译模式如果没有nvue文件是不会打包weex引擎进去的，原生引擎无法动态添加。自定义组件模式默认就含着weex引擎，不管工程下有没有nvue文件。

注意事项

• 条件编译，仅在 App 平台执行此升级逻辑。

• appid 以及版本信息等，在 HBuilderX 真机运行开发期间，均为 HBuilder 这个应用的信息，因此需要打包自定义基座或正式包测试升级功能。

• plus.runtime.version 或者 uni.getSystemInfo() 读取到的是 apk/ipa 包的版本号，而非 manifest.json 资源中的版本信息，所以这里用 plus.runtime.getProperty() 来获取相关信息。

• 安装 wgt 资源包成功后，必须执行 plus.runtime.restart()，否则新的内容并不会生效。

• 如果App的原生引擎不升级，只升级wgt包时需要注意测试wgt资源和原生基座的兼容性。平台默认会对不匹配的版本进行提醒，如果自测没问题，可以在manifest中配置忽略提示，详见ask.dcloud.net.cn/article/356…

• http://www.example.com 是一个仅用做示例说明的地址，实际应用中应该是真实的 IP 或有效域名，请勿直接复制粘贴使用。

关于热更新是否影响应用上架

应用市场为了防止开发者不经市场审核许可，给用户提供违法内容，对热更新大多持排斥态度。

但实际上热更新使用非常普遍，不管是原生开发中还是跨平台开发。

Apple曾经禁止过jspatch，但没有打击其他的热更新方案，包括cordovar、react native、DCloud。封杀jspatch其实是因为jspatch有严重安全漏洞，可以被黑客利用，造成三方黑客可篡改其他App的数据。

使用热更新需要注意：

• 上架审核期间不要弹出热更新提示

• 热更新内容使用https下载，避免被三方网络劫持

• 不要更新违法内容、不要通过热更新破坏应用市场的利益，比如iOS的虚拟支付要老老实实给Apple分钱

如果你的应用没有犯这些错误，应用市场是不会管的。

作者：是一个秃头
来源：https://juejin.cn/post/7039273141901721608

GC回收机制

一、前言

垃圾回收：Garbage Collection，简写 GC。JVM 中的垃圾回收器会自动回收无用的对象。

但是 GC 自动回收的代价是：当这种自动化机制出错，我们就需要深入理解 GC 回收机制，甚至需要对这些 自动化 的技术实施必要的监控与调节。

在虚拟机中，程序计数器、虚拟机栈、本地方法栈 3 个区域随线程而生，随线程而灭，栈中的栈帧随着方法的进入和退出而执行着出栈和入栈操作。所以这几个区域不需要考虑回收的问题。

而在 堆和方法区 中，一个接口中的多个实现类需要的内存可能不一样，一个方法中的多个分支需要的内存也可能不一样。这部分的只有在程序运行期间才会知道需要创建哪些对象，这部分的内存的创建和回收是动态的，也是垃圾回收器重点关注的地方。

二、什么是垃圾

垃圾 就是 内存中已经没有用的对象。既然是 垃圾回收，就必须知道哪些对象是垃圾。

Java 虚拟机中使用了一种叫做 可达性分析 的算法 来决定对象是否可以被回收。

上图中 A、B、C、D、E 与 GCRoot 直接或间接产生引用链，所以 GC 扫描到这些对象时，并不会执行回收操作；J、K、M虽然之间有引用链，但是并没有与 GCRoot 存在引用链，所以当 GC 扫描到他们时会将他们回收。

注意的是，上图中所有的对象，包括 GCRoot，都是内存中的引用。

作为 GCRoot 的几种对象

1. Java虚拟机栈（局部变量表）中的引用的对象；

2. 方法区中静态引用指向的对象；

3. 仍处于存活状态中的线程对象；

4. Native方法中 JNI 引用的对象；

三、什么时候回收

不同的虚拟机实现有着不同的 GC 实现机制，但一般情况下都会存在下面两种情况：

1. Allocation Failure：在堆内存分配中，如果因为可用剩余空间不足导致对象内存分配失败，这时系统会触发一次 GC。

2. System.gc()：在应用层，Java开发工程师可以主动调用此API来请求一次 GC。

四、验证GCRoot的几种情况

在验证之前，先了解Java命令时的参数。

-Xms：初始分配 JVM 运行时的内存大小，如果不指定则默认为物理内存的 1/64。

举个小例子

// 表示从物理内存中分配出 200M 空间给 JVM 内存
java -Xms200m HelloWorld

1.验证虚拟机栈（栈帧中的局部变量）中引用的对象作为 GCRoot

// 验证代码
public class GCRootLocalVariable {

    private int _10MB = 10 * 1024 * 1024;
    private byte[] memory = new byte[8 * _10MB];

    public static void main(String[] args) {
        System.out.println("开始时：");
        printMemory();
        method();
        System.gc();
        System.out.println("第二次GC完成");
        printMemory();
    }

    public static void method() {
        GCRootLocalVariable gc = new GCRootLocalVariable();
        System.gc();
        System.out.println("第一次GC完成");
        printMemory();
    }

    // 打印出当前JVM剩余空间和总的空间大小
    public static void printMemory() {
        long freeMemory = Runtime.getRuntime().freeMemory();
        long totalMemory = Runtime.getRuntime().totalMemory();
        System.out.println("剩余空间：" + freeMemory / 1024 / 1024 + "M");
        System.out.println("总共空间：" + totalMemory / 1024 / 1024 + "M");
    }
}
// 打印日志：
开始时：
剩余空间：119M
总共空间：123M
第一次GC完成
剩余空间：40M
总共空间：123M
第二次GC完成
剩余空间：120M
总共空间：123M

从上述代码中可以看到：

第一次打印内存信息，分别为 119M 和 123M；

第二次打印内存信息，分别为 40M 和 123M；剩余空间小了 80M，是因为在 method() 方法中创建了局部变量 gc（位于栈帧中的局部变量），并且这个 gc 对象会被作为 GCRoot。虽然创建的对象未被使用并且调用了 System.gc()，但是因为该方法未结束，所以创建的对象不能被回收。

第三次打印内存信息，分别为 120M 和 123M；method() 方法已经结束，创建的对象 gc 也随方法消失，不再有引用类型指向该 80M 对象。

【值得注意的是】

private int _10MB = 10 * 1024 * 1024;
private byte[] memory = new byte[8 * _10MB];

上面 2 行代码是必须的，如果去掉，那么 3 次打印结果将会一致，idea 也会出现Instantiation of utility class 警告信息，说这个类只存在静态方法，没必要创建这个对象。

这也就是说为什么创建 GCRootLocalVariable() 会需要 80M 的大小，是因为 GCRootLocalVariable 在创建时就会为其内部变量 memory 确定 80M 的大小。

2.验证方法区中的静态变量引用的对象作为 GCRoot

public class GCRootStaticVariable {
    private static int _10M = 10 * 1024 * 1024;
    private byte[] memory;
    private static GCRootStaticVariable staticVariable;

    public GCRootStaticVariable(int size) {
        memory = new byte[size];
    }

    public static void main(String[] args) {
        System.out.println("程序开始：");
        printMemory();
        GCRootStaticVariable g = new GCRootStaticVariable(2 * _10M);
        g.staticVariable = new GCRootStaticVariable(4 * _10M);
        // 将g设置为null，调用GC时可以回收此对象内存
        g = null;
        System.gc();
        System.out.println("GC完成");
        printMemory();
    }

    // 打印JVM剩余空间和总空间
    private static void printMemory() {
        long freeMemory = Runtime.getRuntime().freeMemory();
        long totalMemory = Runtime.getRuntime().totalMemory();
        System.out.println("剩余空间" + freeMemory/1024/1024 + "M");
        System.out.println("总共空间" + totalMemory/1024/1024 + "M");
    }
}

打印结果：
程序开始：
剩余空间119M
总共空间123M
GC完成
剩余空间81M
总共空间123M

通过上述打印结果可知：

1. 程序刚开始时打印结果为 119M；

2. 当创建 g 对象时分配 20M 内存，又为静态变量 staticVariable 分配 40M 内存；

3. 当调用 gc 回收时，非静态变量 memory 分配的 20M 内存被回收；

4. 但是作为 GCRoot 的静态变量 staticVariable 不会被回收，所以最终打印结果少了 40M 内存。

3.验证活跃线程作为GCRoot

public class GCRootThread {

    private int _10M = 10 * 1024 * 1024;
    private byte[] memory = new byte[8 * _10M];

    public static void main(String[] args) throws InterruptedException {
        System.out.println("程序开始：");
        printMemory();
        AsyncTask asyncTask = new AsyncTask(new GCRootThread());
        Thread thread = new Thread(asyncTask);
        thread.start();
        System.gc();
        System.out.println("main方法执行完成，执行gc");
        printMemory();
        thread.join();
        asyncTask = null;
        System.gc();
        System.out.println("线程代码执行完成，执行gc");
        printMemory();
    }

    private static void printMemory() {
        long freeMemory = Runtime.getRuntime().freeMemory();
        long totalMemory = Runtime.getRuntime().totalMemory();
        System.out.println("剩余内存：" + freeMemory / 1024 / 1024 + "M");
        System.out.println("总共内存：" + totalMemory / 1024 / 1024 + "M");
    }

    private static class AsyncTask implements Runnable {

        private GCRootThread gcRootThread;

        public AsyncTask(GCRootThread gcRootThread) {
            this.gcRootThread = gcRootThread;
        }

        @Override
        public void run() {
            try {
                Thread.sleep(500);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }
}
打印结果：
程序开始：
剩余内存：119M
总共内存：123M
main方法执行完成，执行gc
剩余内存：41M
总共内存：123M
线程代码执行完成，执行gc
剩余内存：120M
总共内存：123M

通过上述打印结果可知：

1. 程序刚开始时可用内存为 119M；

2. 第一次调用 gc 时，线程并没有执行结束，并且它作为 GCRoot ,所以它所引用的 80M 内存不会被 GC 回收掉；

3. thread.join() 保证线程结束后再调用后续代码，所以当第二次调用 GC 时，线程已经执行完毕并被置为 null；

4. 这时线程已经销毁，所以该线程所引用的 80M 内存被 GC 回收掉。

4.测试成员变量是否可作为GCRoot

public class GCRootClassVariable {
    private static int _10M = 10 * 1024 * 1024;
    private byte[] memory;
    private GCRootClassVariable gcRootClassVariable;

    public GCRootClassVariable(int size) {
        memory = new byte[size];
    }

    public static void main(String[] args) {
        System.out.println("程序开始：");
        printMemory();
        GCRootClassVariable g = new GCRootClassVariable(2 * _10M);
        g.gcRootClassVariable = new GCRootClassVariable(4 * _10M);
        g = null;
        System.gc();
        System.out.println("GC完成");
        printMemory();
    }

    private static void printMemory() {
        long freeMemory = Runtime.getRuntime().freeMemory();
        long totalMemory = Runtime.getRuntime().totalMemory();
        System.out.println("剩余内存：" + freeMemory / 1024 / 1024 + "M");
        System.out.println("总共内存：" + totalMemory / 1024 / 1024 + "M");
    }
}
打印结果：
程序开始：
剩余内存：119M
总共内存：123M
GC完成
剩余内存：121M
总共内存：123M

上述打印结果可知：

1. 第一次打印结果与第二次打印结果一致：全局变量 gcRootClassVariable 随着 g=null 后被销毁。

2. 所以全局变量并不能作为 GCRoot。

五、如何回收垃圾（常见的几种垃圾回收算法）

1.标记清除算法（Mark and Sweep GC）

从 “GCRoots” 集合开始，将内存整个遍历一次，保留所有可以被 GCRoots 直接或间接引用到的对象，而剩下的对象都当做垃圾对待并回收。

上述整个过程分为两步：

1. Mark标记阶段：找到内存中的所有 GC Root 对象，只要是和 GC Root 对象直接或间接相连则标记为灰色（存活对象），否则标记为黑色（垃圾对象）。

2. Sweep清楚阶段：当遍历完所有的 GC Root 之后，则将标记为垃圾的对象直接清楚。

标记清除算法优缺点

【优点】

实现简单，不需要将对象进行移动。

【缺点】

需要中断进程内其他组件的执行，并且可能产生内存碎片，提高了垃圾回收的频率。

2.复制算法（Copying）

1. 将现有的内存空间分为两块，每次只使用其中一块；

2. 在垃圾回收时将正在使用的内存中的存活对象复制到未被使用的内存块中；

3. 之后清除正在使用的内存块中的所有对象；

4. 交换两个内存的角色，完成垃圾回收（目前使用A，B是空闲，算法完成后A为空闲，设置B为使用状态）。