theme: qklhk-chocolate

对于 Race Condition

对于 Race Condition，维基上有具体介绍(英文版的更具体)：

举个例子，大略就是两个线程去批改全局资源，现实的状况：

但在短少同步锁的状况下，理论的状况可能是这样：

如何去解决：

粗心是大部分语言都提供了资源锁/同步锁这种货色，依据不同的语言选择不同的办法去解决这个问题

在前端的表现形式

javascript 是单线程的，理当不会呈现下面的状况。然而在异步渲染的时候，还是会呈现渲染的时序问题，表现形式，大略是，一个详情组件，watch/useEffect传进来的id，而后依据id向后端发送申请，而后异步的渲染。

因为是异步的，你没法保障先收回的申请就肯定是最先返回的，就会呈现了页面展现的id和详情对不上的状况：

使用同步锁的概念，能够定义一个blocked的变量，在申请时，阻止后续申请的发送：

看似解决了渲染的时序问题，但仔细观察会发现，这样解决会导致新的问题产生：

  1. 整体的渲染周期变长了很多
  2. 前端是重交互和UI的，这种“锁”也会导致用户的操作被阻塞，对用户的应用影响也是不好的
  3. 场景太过繁多，打个比方，如果解决的是输入框智能提醒的时序问题，你不可能在前一个申请未返回前阻止用户持续输出
申请1有话说

事实中的案例

登陆/切换账户场景

  1. 用户未登陆的情况下，点击登陆，在登陆胜利前点了勾销，申请是异步的，勾销是同步的，会导致，即便用户点击勾销，用户依然登陆胜利了。
  2. 用户切换账号，场景相似，就是切换胜利前勾销切换，然而切换胜利后的操作还是会执行的，如果用户感知不到账户切换，会呈现比拟大的 bug。

切换 tab/搜寻

点击什么字母就会返回什么字母，这块对接口做了解决，新近的申请响应更慢，当你间断点击a -> ab -> abc，会呈现：先展现abc->ab->a，搜寻的场景同理

后果：

起因


产生这种时序问题的起因很多，简略概括蕴含以下几点：

  1. 以后所处的网络环境差，不稳固，没法保障申请返回的稳定性
  2. 后端的解决逻辑不同。打个比方，不同的两个接口都能触发组件的更新，但后端对这两个接口的解决策略不同，或者这两个接口拜访的数据量不同，就会导致申请的解决周期不同，也就没法保障时序
  3. 此时的用户是个倒霉蛋，第1个申请就是比第2个申请返回慢

如何去解决

测试案例

一个简略的Vue组件，依据输出的内容展现不同的后果，这块的接口做了解决，先发送的申请仍然是响应最慢，会呈现搜寻和后果不匹配的状况

计划1：从最底层登程，“勾销”申请

目前的申请形式大略两种：XMLHttpRequest + Fetch，目前支流的计划还是XMLHttpRequest，Fetch因为兼容性的问题应用的还是不多，基于XMLHttpRequest，用的最多的大略是axios，这种个别都会把勾销申请的办法封装好了


咱们还是以Fetch为例子。Fetch还是比拟难堪，自身就有兼容性的问题，对于申请管制的 AbortController 的兼容性相比更差，这块先不思考这些。对于AbortControllerMDN上有具体阐明：

依照官网的例子这样解决就好了：

async handleSearch() {  try {    this.isCanceled = false;    if (this.controller) {      this.controller.abort();      this.isCanceled = true;    }    this.controller = new AbortController();    const { result } = await fetch(      `http://localhost:3000/list?search=${this.text}`,      {        signal: this.controller.signal,      }    ).then((response) => response.json());    this.result = result;    console.log("result", result);  } catch (err) {    console.log("err", err);    // this.controller.signal.aborted    if (this.isCanceled) {      console.log("aborted");    } else {      this.$message("申请出错了");    }  }}

⚠️须要留神的点：

  1. 勾销的申请会走到catch，会和一些异样场景耦合，所以须要独自解决
  2. 这块每次都去生成新的实例，我没有找到绝对应的reset办法
  3. error拿不到勾销申请的信息,controller.signal.aborted可能判断申请是否aborted，但因为每次生成新实例的起因，只能用变量去管制

不会吧不会吧，难道真有人会去勾销申请的？
  1. 百度，只会保留最新的申请，后面的申请都会被勾销：

  1. 谷歌，谷歌会保留最大4个的并行申请，而后勾销后面的所有申请：

奇怪的是，都没有做防抖解决

勾销 Promise

勾销Promise，其实就是让Promise提前resolved或者rejected。对于勾销的具体姿态，能够看下how-to-cancel-your-promise

就是上面几点：

  1. Pure Promises
  2. Switch to generators
  3. Note on async/await

简略写法：

const request = (...arg) => {  let cancel;  const promise = new Promise((resolve, reject) => {    cancel = () => reject("aborted");    fetch(...arg).then(resolve, reject);  });  return [promise, cancel];};// ...async handleSearch() {  try {    if (this.cancel) {      this.cancel();    }    const [promise, cancel] = request(      `http://localhost:3000/list?search=${this.text}`    );    this.cancel = cancel;    const result = (await promise.then((response) => response.json()))      .result;    this.result = result;    console.log("result", result);  } catch (err) {    if (err === "aborted") {      console.log(err);    } else {      this.$message("申请出错了");    }  }}

匹配申请

只有以后解决的是申请匹配时才解决，否则不论，这里分为两种状况：

  1. 有惟一key辨别的，例如商品详情：

    // 存在 idasync handleSearch() {  try {    const detail = await fetch(`xx/${this.id}`);    if (detail.id === this.id) {        this.detail = detail;    }  } catch (err) {    this.$message("申请出错了");  }}

  2. 不存在惟一key，记录最初Promise援用，再匹配

    async handleSearch() {  try {    const curPromise = fetch(`xx/${this.id}`);    this.promiseRef = curPromise;        const detail = await curPromise;        if (this.promiseRef === curPromise) {        this.detail = detail;    }  } catch (err) {    this.$message("申请出错了");  }}

我用过的库

redux-saga

redux-saga，我以前应用React的时候喜爱用，是Redux的一个中间件，次要就是解决副作用的，即申请。感觉这个库实现了个小型的IO零碎，这块内容感兴趣的同学自行理解，我只说下解决办法，redux-saga提供了TakeLatest的辅助辅助函数去解决这种问题：

function* loadStarwarsHeroSaga() {  yield* takeLatest(    'LOAD_STARWARS_HERO',    function* loadStarwarsHero({ payload }) {      try {        const hero = yield call(fetchStarwarsHero, [          payload.id,        ]);        yield put({          type: 'LOAD_STARWARS_HERO_SUCCESS',          hero,        });      } catch (err) {        yield put({          type: 'LOAD_STARWARS_HERO_FAILURE',          err,        });      }    },  );}

rx-js

rx-js是一个响应式的库，官网说了，算是异步的lodash。把所有的数据封装成流的模式进行解决。用到的操作方法次要就是SwitchMap：

import { Subject, merge, of } from "rxjs";import { ajax } from "rxjs/ajax";import { switchMap, catchError, tap } from "rxjs/operators";export default {  name: "HelloWorld",  data() {    return {      text: "",      result: "holder",    };  },  mounted() {    this.subject = new Subject();    this.subject      .pipe(        tap(() => {          console.log("text:", this.text);        }),        switchMap((str) =>          ajax(`http://localhost:3000/list?search=${this.text}`)        ),        catchError((err, caught$) => {          return merge(of({ err }), caught$);        })      )      .subscribe((response) => {        if (response.err) {          this.$message("申请失败");        } else {          const result = response.response.result;          console.log("result:", result);          this.result = result;        }      });  },  beforeDestroy() {    this.subject.unsubscribe();  },  methods: {    handleSearch() {      this.subject.next();    },  },};


因为把数据当作流去解决，防止了时序的问题：

结束语

我整顿的大略这么多，解决形式不止这些，还有像GraphQL等，理解的不多，就没写了。“竞态”问题呈现在一些简略利用中的概率绝对小很多，但在一些简单利用中就会比拟容易呈现，自从我从B端我的项目切换到流动页当前，就再也没有碰到这种问题了（流动页赛高），只是我敌人碰到了这个问题，所以就简略整顿了下，大略这么多，谢谢浏览。