这段前端代码存在并发读取竞态的问题吗？

[supuwoerc]

这两天调试别人项目中的一段 js 代码，作用是刷新 token ，但是验证下来发现有很小的几率会触发多次刷新 token 的动作(下面代码中的 FIXME 位置)，特别是 Promise.all 去发送一批请求的时候，我 google 了一圈，没研究明白，因为复现起来很困难，所以请教大家，代码中读取 isRefreshing 是安全的吗？我让 cursor 和 copilot 解释都是说 js 不启用 worker 是不存在并发问题的，但是从结果来看，确实有不止一个请求进入了刷新 token 的分支，我把这个情况描述完，cursor 让我引入 sync-mutex 加锁，和一开始的解释完全不一样，我在 StackOverflow 和 medium 中也找到几篇类似的文章，都是借助了防抖/记忆函数来解决，实在弄不清楚这块读写 isRefreshing 到底是不是安全的。

还看到了一篇锁的文章，感觉很类似我遇到的这个问题： https://jackpordi.com/posts/locks-in-js-because-why-not

伪代码如下：

let isRefreshing = false // 标记是否正在刷新 token 
let requests: Array<(token: string, err?: string) => void> = [] // 需要重试的请求列表

client.interceptors.response.use((response: AxiosResponse) => {
            const { config, status } = response
            const { code } = response.data
            if (status >= 500) {
                return Promise.reject("服务器错误")
            } else if (code == 10003) {
                // access token 过期，尝试刷新 token
                const { refreshToken } = user.useLoginStore.getState()
                if (refreshToken) {
                    // FIXME： ?? 存在并发读取 isRefreshing 为 false 导致发出多次刷新 token 的请求
                    if (!isRefreshing) {
                        isRefreshing = true
                        return refreshToken()
                            .then(({ data }) => {
                                const { code } = data
                                if (code === 10000) {
                                    user.useLoginStore.setState((state) => {
                                        state.token = data.data.token
                                    })
                                    config.headers["Authorization"] = data.data.token
                                    const retry = client(config)
                                    requests.forEach((cb) => cb(data.data.token))
                                    requests = []
                                    return retry
                                } else {
                                    return Promise.reject(data.message)
                                }
                            })
                            .catch((err) => {
                                const msg = isError(err) ? err.message : err
                                requests.forEach((cb) => cb("", msg))
                                requests = []
                                publishInvalidTokenEvent(msg)
                            })
                            .finally(() => {
                                isRefreshing = false
                            })
                    } else {
                        return new Promise((resolve, reject) => {
                            requests.push((token: string, err?: string) => {
                                if (err) {
                                    reject(err)
                                } else {
                                    config.headers["Authorization"] = token
                                    resolve(client(config))
                                }
                            })
                        })
                    }
                } else {
                    requests.forEach((cb) => cb("", "登录过期")
                    requests = []
                    publishInvalidTokenEvent("登录过期")
                }
            } else if (code === 10000) {
                return response.data.data
            } else if (code == 10006) {
                // 长 token 失效
                requests.forEach((cb) => cb("", "登录过期")
                requests = []
                publishInvalidTokenEvent("登录过期")
            } else {
                return Promise.reject(response.data.message || response.data.msg)
            }
        })

楼下已经有几位大佬给出了分析，是请求返回时序问题导致的，并非对变量的判断导致，感谢各位大佬的解答！

[irisdev]

想想也知道存在并发啊。。一个页面发十个请求，浏览器会等十个请求全部完成再加载页面吗。。

[chairuosen]

多个 tab ，或者框架网页，就会出现

[crazzy]

这都是异步，肯定会出现一个请求检查完 isRefreshing 准备赋值前，另一个请求也在检查 isRefreshing 了。

一个异步的整个生命周期中，事件循环会处理其他任务

[IWSR]

axios 设置拦截器会在每个 HTTP 请求发送时被调用，如果你前端代码内存在同时发送多个请求的逻辑那拦截器内的回调会多次触发，所以多次刷新 token 的现象出现不奇怪，解决办法就是增加一个全局变量去标记刷新 token 这个操作是否已经被触发，如果被触发就不执行刷新 token 的逻辑

[zhhcnn]

用 promise 加锁就行了，读 token 之前 await 一下等 promise 返回

[geelaw]

不存在针对 isRefreshing 的竞态条件，原因很简单：JavaScript 没有多线程，而只有 JavaScript 代码会读写 isRefreshing 。

和 worker 也没有任何关系，因为 worker thread 之间不共享对象，要共享数据必须 postMessage 。

[supuwoerc]

@IWSR 代码里面的 isRefreshing 就是全局变量啊🤔️，只是依靠这个变量也卡不住

[irisdev]

@chairuosen #2 老板，多 tab 这种情况把 isrefreshing 放在 localstorage 里面共享一下是不是就行了

[supuwoerc]

@geelaw 但是从请求记录来看确实触发了多次刷新动作，我很疑惑。

[JoeJoeJoe]

虽然 js 不开 worker 是单线程的, 但是你的请求是异步的, 也就是说你的刷新 token 也是异步的, 不会阻塞后续的其他请求, 在等待新 token 的时候, 其他的接口如果有返回值回来, 同样, 他们的 token 也是过期的, 也是会触发你的刷新 token 逻辑的.
比如: 现在的 token 是过期的, 同时发送了 A,B,C3 个请求
1. A 请求发送之后, 接口返回 token 过期, 然后刷新 token, 获取到新的 token, 如果这期间 B,C 还没有发出去, 那么是没有问题的.
2. A 请求发送之后, B,C 请求同时发出去了, 那么那么 BC 请求带的 token 也是过期 Token, 也会触发你说的现象.
3. A 请求发送之后, BC 请求还没有发送, A 请求收到了 token 过期的响应, 开始请求刷新 token, 这期间 BC 请求发出去了, 这种场景也会触发你说的现象.

ps: 我大概猜的, 佬们轻喷

[ccccccc]

我建议不要搞得那么复杂，过期该重新登录就重新登录。用户根本不 care 重新登录带来的不方便，除非你几分钟就要用户登录一次

[supuwoerc]

@ccccccc 这个是别人的项目我帮着修 bug 的，物流程序，token 有效期只有 5 分钟，用的长短 token 方案，不断重新登录应该是要爆炸的😂

[supuwoerc]

@JoeJoeJoe 应该不是同时发出去，而是同时返回，同时执行到 if (!isRefreshing)的判断才会引发这个问题，我理解是这样的。

[chairuosen]

@irisdev 不是，他这个逻辑是在加锁的刷新线程里最后处理其他等待线程的后续，多 tab 是处理不了的，得改造一下等待的线程轮询锁自己处理后续

[geelaw]

@chairuosen #2 每个 tab 里都有自己的 isRefreshing 。

@crazzy #3 在 if (!isRefreshing) 和 isRefreshing = true 之间不可能有任何 JavaScript 代码执行。

@IWSR #4 这个好像是楼主代码的意思。

@supuwoerc #9

楼主可以多考虑一下读者，尝试简化代码，使之不需要借助外部语境就很容易理解，比如我们不知道 user.useLoginStore.getState() 的状态是否是 session/local 级别的，还是 tab 级别的。如果 user.useLoginStore.getState() 是 session/local 的状态，那么不同的 tab 有自己的 isRefreshing ，当然两个 tab 可以同时看到过期的 token 并分别决定刷新。

@irisdev #8 放在 local/session 都不好，因为用户可以在 tab 1 刷新的时候关闭之，但 tab 1 通过共享的 isRefreshing 锁定了刷新的权力，这会导致 local/session 清空之前不再有任何 tab 会进入刷新的逻辑。

[JoeJoeJoe]

@supuwoerc #13 我分析错了, 这个 isRefreshing 是个全局的, sorry.

[kamilic]

isRefreshing 肯定是能锁着的，都是单个线程执行的，cursor 和 copilot 说的没错。
我推测这种情况是不是并发发出的时候，出现这种情况：
| ----- req1 / res1 / refresh ----- | ------------------------ isRefreshing = false ------------------------------------ |
| ----- req2 ------------------------------------------------------------- | --------- res2 / isRefreshing = false ------ |

有可能你并发 req1 / req2 都是返回 10003 的，恰好 req1 刷新 token 后状态还原 isRefreshing ，req2 才返回 10003 ，那不就再刷一次喽。
是不是你的 requests 变量要再记录下在 isRefreshing = true 过程中的所有待返回请求？

[supuwoerc]

@geelaw 感谢大佬，user.useLoginStore.getState()是从 zustand 中读存储的 token/refresh_token 的，我复现的情况没有开多个 tab ，单独一个 tab 就偶发的出现多次刷新 token 的行为。

[Niphor]

F12 network 里多看看就知道拉，并发的多个请求+长短不一的响应时间 就会触发这个

[LuckyRock]

假设 token 过期，发了 A 和 B 两个请求，A 请求收到响应之后过期，刷新 token ，刷新 token 的请求先于 B 请求返回，那么此时 isRefreshing 被重置为 false ，然后 B 请求（携带过期 token ）返回了，自然就重新走了刷新 token 的逻辑。

[Niphor]

根源是 有的请求已经进 finally 了，但是有的请求 response 刚进 interceptor

[InDom]

isRefreshing 这个锁不应该是 bool 型 ,而应该是最少三个状态

false, refreshing, true

更好的方案是记录 refreshing 的时间, 再加一个超时的机制.

如果发现 true 就直接使用, 如果是 false 就设置为当前时间并开始更新 token,

如果是 refreshing 的时间, 就检查是否超时(指上一个任务太久未完成)

如果 refreshing 超时, 就自己重新设置 refreshing 时间并开始更新 token

如果 refreshing 未超时, 就设置个随机时间后重新检查 isRefreshing 状态.

[supuwoerc]

@kamilic 醍醐灌顶！我觉得这个分析才解释了真正导致问题的原因，我之前已经怀疑人生了，没想到这种时序导致的问题。

[duuu]

你的 isRefreshing 不要做成全局的，改成单个接口自己判断使用。

[supuwoerc]

@LuckyRock
@InDom
@geelaw 感谢各位大佬，我依然意识到请求时序才是真正导致问题的原因，之前一直盯着判断看，钻牛角尖已经怀疑人生了😂

[mrzhiin]

当接口的响应为令牌过期错误的时候，在刷新令牌之前，先判断下接口使用的令牌和当前状态里的令牌是否一致，如果不一致，替换为当前状态里令牌重新再发起请求

[LOWINC]

let isRefreshing = false;

function request(success, time) {
return new Promise((resolve, reject) => {
setTimeout(() => {
if (success) {
resolve({});
} else {
reject();
}
}, time);
});
}

Promise.all([
request(false, 100)
.then(() => {})
.catch(() => {
if (!isRefreshing) {
isRefreshing = true;
console.log('refresh1:', isRefreshing);
setTimeout(() => {
isRefreshing = false;
}, 100);
}
}),
request(false, 3000)
.then(() => {})
.catch(() => {
if (!isRefreshing) {
isRefreshing = true;
console.log('refresh2:', isRefreshing);
setTimeout(() => {
isRefreshing = false;
}, 3000);
}
}),
]);




可能就是两次 10003

[supuwoerc]

@mrzhiin 嗯嗯，感谢大佬，知道原因的我也想到了这样判断来解决～

[canvascat]

不用加锁，复用一下 `refreshTokenPromise`应该就行了

```
declare const orginalRefreshToken: () => Promise<any>;

const refreshToken = () => {
refreshToken.current ??= orginalRefreshToken().finally(() => {
refreshToken.current = null;
});
return refreshToken.current;
};

refreshToken.current = null as Promise<any> | null;
```

[supuwoerc]

@canvascat 你的这个实际上也是一种锁，还是会有楼上的时序问题～

[NotLongNil]

这段代码一堆 if ，看得好难受

[bli22ard]

js 单线程没有并发读写问题，js 的 io 都是异步的，只有开了异步后，异步唤醒后的顺序问题。在执行 if (!isRefreshing) {
isRefreshing = true; } 这个过程中，不会有其他线程来竞争， 但是如果你执行了 settimeout setinterval 或者 ajax 等异步，那就会去检查其他事件是否就绪，然后执行其他的地方。

[leoskey]

在多个请求响应时间不同的情况下，可能会出现重复刷新 token 。

例如，A 请求响应时间 100ms ，B 请求响应时间 300ms 。
A 请求响应 token 过期，在 100ms 内完成: isRefreshing = true , 执行 refresh 流程，isRefreshing = false 。
此时才过去 200ms 。

再过 100ms 后，B 请求响应 token 过期，发现 isRefreshing = false ，再次执行 refresh 。

试试双重检查：
1. 如果是 JWT ，先检查本地 token 是否过期
2. 如果服务器响应 token 无效
3. 再检查一次本地 token 是否与上次相同，不相同说明刷新过了，相同就执行 refresh

[shintendo]

用一个 outdatedToken 变量代替 isRefreshing

if (!isRefreshing){ isRefreshing = true }
换成
if(outdatedToken !== config.token) { outdatedToken = config.token }

去掉 isRefreshing = false 的操作

其它不变

[GGbeng1]

还有一种方法，过期时将所有请求地址记录；同时 cancel 掉所有请求；刷新后从新发送或者直接刷新页面😂

[LiuJiang]

没用 AI 去理解代码吗

[dcatfly]

这个问题打断点调试应该很快就能发现是时序的问题。
不过这个问题还挺适合测 AI 的，拿给各家 AI 问了下，只有 gpt5 thinking 能一次给对答案，claude sonnet/opus4 需多轮对话、gemini 、qwen3/glm4.5/k2 都不能给出正确答案。

[unclejoker]

丢给 gpt 一下不就得出答案了吗...