这里的大多数答案都是错误的，或者至少是过时的。没有理由JavaScript必须是单线程的，事实上也不是。今天，所有主流浏览器都支持工人。在此之前，Rhino和Node.js等其他JavaScript运行时支持多线程。

“JavaScript是单线程的”不是有效答案。例如，在工作线程中运行睡眠函数不会阻止UI线程中运行的任何代码。

在支持生成器和yield的较新运行时中，可以在单线程环境中为sleep函数带来类似的功能：

// This is based on the latest ES6 drafts.
// JavaScript 1.7+ (SpiderMonkey/Firefox 2+) syntax is slightly different

// Run code you want to sleep here (omit star if using JavaScript 1.7)
function* main(){
    for (var i = 0; i < 10; i++) {
        // To sleep for 10 milliseconds 10 times in a row
        yield 10;
    }

    yield 5;
    console.log('I just slept 5 milliseconds!');
}

// Resume the given generator after ms milliseconds
function resume(ms, generator){
    setTimeout(function(){
        // Omit .value if using JavaScript 1.7
        var nextSleep = generator.next().value;
        resume(nextSleep, generator);
    }, ms);
}

// Initialize a generator and get first sleep for the recursive function
var
    generator = main(),
    firstSleep = generator.next().value;

// Initialize recursive resume function
resume(firstSleep, generator);

这种对睡眠的模仿不同于真正的睡眠函数，因为它不会阻塞线程。它只是JavaScript当前setTimeout函数之上的糖。这种功能类型已经在Task.js中实现，现在应该可以在Firefox中使用。

到目前为止，我读到的每一个解决方案都是“让我们睡觉，看看明天发生了什么”。

setInterval（callback，time）将等待很长时间，然后调用回调，同时阻塞运行时。“setInterval”的当前实现远非线程保存，甚至不考虑并发性。

虽然上面提到的稀疏解决方案看起来像，猜猜看，C#（笑），但它们仍然不像在C#/.NET中那样工作。

JavaScript目前没有提供实现真正多线程的架构。最好的方法是TypeScript，但这仍然缺乏太多真正的解决方案，以至于它……令人痛苦。JavaScript、jQuery、AJAX、jNode，甚至TypeScript都只是一群依赖于实现者心情好坏的人。事实句点

实际上，您可以使用与pausecomp函数相同的while循环实现sleep（）（这基本上是相同的）：

const sleep = (seconds) => {
    const waitUntil = new Date().getTime() + seconds * 1000
    while(new Date().getTime() < waitUntil) {
        // do nothing
    }
}

您可以像这样使用sleep（）方法：

const main = () => {
    const a = 1 + 3

    // Sleep 3 seconds before the next action
    sleep(3)
    const b = a + 4

    // Sleep 4 seconds before the next action
    sleep(4)
    const c = b + 5
}

main()

这就是我想象你会使用睡眠功能的方式，而且读起来相对简单。我借鉴了另一篇文章《JavaScript中的睡眠——动作之间的延迟》，以展示您可能打算如何使用它。

不幸的是，你的电脑会变热，所有工作都会受阻。如果在浏览器中运行，该选项卡将停止，用户将无法与页面交互。

如果您将代码重组为异步的，那么您可以将setTimeout（）作为与其他文章相同的睡眠函数。

// define sleep using setTimeout
const sleep = (seconds, callback) => setTimeout(() => callback(), seconds * 1000)

const main = () => {
    const a = 1 + 3
    let b = undefined
    let c = undefined

    // Sleep 3 seconds before the next action
    sleep(3, () => {
        b = a + 4

        // Sleep 4 seconds before the next action
        sleep(4, () => {
            c = b + 5
        })
    })
}

main()

正如你所说，这不是你想要的。我修改了Sleep in JavaScript中的示例-动作之间的延迟，以说明为什么会出现这种情况。当您添加更多动作时，要么需要将逻辑拉入单独的函数，要么将代码嵌套得越来越深（回调地狱）。

为了解决“回调地狱”，我们可以使用promise来定义睡眠：

const sleep = (seconds) => new Promise((resolve => setTimeout(() => resolve(), seconds * 1000)))

const main = () => {
    const a = 1 + 3
    let b = undefined
    let c = undefined

    // Sleep 3 seconds before the next action
    return sleep(3)
        .then(() => {
            b = a + 4

            // Sleep 4 seconds before the next action
            return sleep(4)
        })
        .then(() => {
            c = b + 5
        })
}

main()

Promise可以避免深度嵌套，但看起来仍然不像我们最初使用的常规同步代码。我们希望编写看起来同步的代码，但没有任何缺点。

让我们再次使用async/await重写我们的主方法：

const sleep = (seconds) => new Promise((resolve => setTimeout(() => resolve(), seconds * 1000)))

const main = async () => {
    const a = 1 + 3

    // Sleep 3 seconds before the next action
    await sleep(3)
    const b = a + 4

    // Sleep 4 seconds before the next action
    await sleep(4)
    const c = b + 5
}

main()

使用async/await，我们可以调用sleep（），就好像它是一个同步的阻塞函数一样。这解决了您可能在其他帖子中使用回调解决方案时遇到的问题，并避免了长时间循环的问题。

现在还可以使用本机模块util来提供常规同步函数。

const { promisify } = require('util')
const sleep = promisify(setTimeout)

module.exports = () => {
  await someAsyncFunction()
  await sleep(2000)
  console.log('2 seconds later...')
}

如果您真的想完全阻塞主线程并防止事件循环从事件队列中拉出，那么这里有一个很好的方法可以做到这一点，而不需要创建任何函数、新的Date对象或泄漏任何变量。我知道这个愚蠢的问题已经有一百万个答案了，但我没有看到有人使用这个精确的解决方案。这仅适用于现代浏览器。

警告：这不是你会投入生产的东西。它只是有助于理解浏览器事件循环。它可能对任何测试都没有用处。它不像一个正常的系统睡眠函数，因为JavaScript运行时仍然在每个循环中工作。

for (let e = performance.now() + 2000; performance.now() < e; ) {}

这里使用setTimeout回调，即使它几乎立即进入事件队列，也要在至少两秒后才能调用：

setTimeout(function() {
  console.log("timeout finished");
}, 0);

for (let e = performance.now() + 2000; performance.now() < e; ) {}
console.log("haha wait for me first");

您将经历大约两秒的暂停，然后看到：

haha wait for me first
timeout finished

在Date.now（）上使用performance.now（（）的好处是Date对象是

受到时钟偏斜和系统时钟调整的影响。这个时间的价值可能不总是单调增加随后的值可以减小或保持不变。*

通常，performance.now（）更适合高精度地测量时间差异。

使用for循环的好处是可以在运行之前设置块的本地变量。这允许您在循环外进行加法运算，同时仍然是“单行”。这应该可以最大限度地减少这种热循环燃烧的CPU负载。

2019更新使用Atomics.wait

它应该在Node.js 9.3或更高版本中工作。

我在Node.js中需要一个非常精确的计时器，它非常适合。

然而，浏览器中的支持似乎非常有限。

设ms＝10000；Atomics.wait（新Int32Array（新SharedArray Buffer（4）），0，0，ms）；

运行了几次10秒计时器基准测试。

使用setTimeout，我得到的错误高达7000微秒（7毫秒）。

使用Atomics，我的错误似乎保持在600微秒（0.6毫秒）以下

2020年更新：总结

function sleep(millis){ // Need help of a server-side page
  let netMillis = Math.max(millis-5, 0); // Assuming 5 ms overhead
  let xhr = new XMLHttpRequest();
  xhr.open('GET', '/sleep.jsp?millis=' + netMillis + '&rand=' + Math.random(), false);
  try{
    xhr.send();
  }catch(e){
  }
}

function sleepAsync(millis){ // Use only in async function
  let netMillis = Math.max(millis-1, 0); // Assuming 1 ms overhead
  return new Promise((resolve) => {
    setTimeout(resolve, netMillis);
  });
}
function sleepSync(millis){ // Use only in worker thread, currently Chrome-only
  Atomics.wait(new Int32Array(new SharedArrayBuffer(4)), 0, 0, millis);
}

function sleepTest(){
  console.time('sleep');
  sleep(1000);
  console.timeEnd('sleep');
}

async function sleepAsyncTest(){
  console.time('sleepAsync');
  await sleepAsync(1000);
  console.timeEnd('sleepAsync');
}

function sleepSyncTest(){
  let source = `${sleepSync.toString()}
    console.time('sleepSync');
    sleepSync(1000);
    console.timeEnd('sleepSync');`;
  let src = 'data:text/javascript,' + encodeURIComponent(source);
  console.log(src);
  var worker = new Worker(src);
}

其中服务器端页面，例如sleep.jsp，看起来像：

<%
try{
  Thread.sleep(Long.parseLong(request.getParameter("millis")));
}catch(InterruptedException e){}
%>