Javascript Websockets onMessage函数：如果onMessage中的代码块运行时间长于两条消息之间的时间间隔，会发生什么情况？

作为websocket客户机，我们可以访问onMessage函数，该函数在客户机每次收到来自服务器的消息时启动。我试图理解，如果在onMessage事件上调用的代码块在下一条消息被接收到之间的间隔运行时间更长，会发生什么情况

例如，我测试了以下代码：

client.onMessage = (event) => {
    console.log('Message Received')
    setTimeout(() => console.log('Delay of 10 seconds'), 10000)
}

我得到的结果很奇怪：

Message Received
Message Received
Message Received
Message Received
Message Received
Message Received
Message Received
Message Received
Message Received
Message Received
Message Received
Message Received
Delay of 10 seconds
Message Received
Delay of 10 seconds
Delay of 10 seconds
Delay of 10 seconds
Message Received
Delay of 10 seconds
Delay of 10 seconds
Message Received
Delay of 10 seconds
Delay of 10 seconds
Delay of 10 seconds
Message Received
Delay of 10 seconds
Message Received
Message Received
Message Received
Message Received
Message Received
Delay of 10 seconds
Message Received

有人知道这是怎么回事吗

另一方面，如果在块中调用的函数是如下所示的异步函数，会发生什么情况

client.onMessage = async(event) => {
    console.log('Message Received')
    await setTimeout(() => console.log('Delay of 10 seconds'), 10000)
}

这是否会一直执行并将console.log添加到异步队列的末尾，直到内存已满并出现缓冲区错误

---

谢谢你的见解！：）

设置超时

不阻塞。看起来你只是在头10秒内收到了很多信息。许多

onMessage

回调会立即运行，许多未来的

setTimeout

回调会排队，但第一个

setTimeout

回调只在10秒后开始运行

另一方面，如果在块中调用的函数是如下所示的异步函数，会发生什么情况

client.onMessage = async(event) => {
    console.log('Message Received')
    await setTimeout(() => console.log('Delay of 10 seconds'), 10000)
}

Nothing-

异步

函数也不会阻塞

wait

ing a

setTimeout

没有任何作用，因为

setTimeout

返回的是一个数字，而不是承诺

即使

setTimeout

返回了承诺，承诺仍然不会被阻止，因此情况也是一样的

这是否会一直执行并将console.log添加到异步队列的末尾，直到内存已满并出现缓冲区错误

只有当您有实际的阻塞代码时，这才是一种风险，例如：

client.onMessage = (event) => {
    const now = Date.now();
    console.log('Message Received')
    while (Date.now() - now < 10000);
    console.log('Delay of 10 seconds');
}

client.onMessage=（事件）=>{
const now=Date.now（）；
console.log（'收到消息'）
while（Date.now（）-now<10000）；
console.log（“延迟10秒”）；
}

---

在这里，最终（可能需要很长时间），将有太多的事件需要计算机内存处理，脚本将失败。但是，这种昂贵的阻塞代码非常罕见，而且常常表明逻辑中存在问题，因此在几乎任何正常情况下都不必担心。

看起来，在第一次日志发生之前的前10秒内，您收到了很多消息。似乎不是strange@CertainPerformance啊，看来所有的设置超时都会在以后执行。如果不使用异步函数，我认为节点是单线程的，那么这种情况是如何发生的？

setTimeout

不会阻塞，它只是在超时过期后对运行的消息进行排队。是的，它是单螺纹的。如果超时过期时它正忙（例如

while（true）；

），则超时将等待另一条消息完成后再运行下一条消息task@CertainPerformance实际上刚刚检查过，它每10秒打印一条“延迟10秒”以上的消息，所以这里有点不对劲。编辑：啊，nvm找到了答案。这是因为每10秒有多个触发器打开一次消息。不，这是完全可以理解的-同样，

setTimeout

不会阻止（并且

wait

等待

setTimeout

无论如何都没有意义，因为

setTimeout

返回一个数字，而不是一个承诺）