整合营销服务商

电脑端+手机端+微信端=数据同步管理

免费咨询热线：

setTimeout和setImmediate到底谁先执行

者以前面试的时候经常遇到写一堆setTimeout,setImmediate来问哪个先执行。本文主要就是来讲这个问题的，但是不是简单的讲讲哪个先，哪个后。笼统的知道setImmediate比setTimeout(fn, 0)先执行是不够的，因为有些情况下setTimeout(fn, 0)是会比setImmediate先执行的。要彻底搞明白这个问题，我们需要系统的学习JS的异步机制和底层原理。本文就会从异步基本概念出发，一直讲到Event Loop的底层原理，让你彻底搞懂setTimeout,setImmediate，Promise, process.nextTick谁先谁后这一类问题。

同步和异步

同步异步简单理解就是，同步的代码都是按照书写顺序执行的，异步的代码可能跟书写顺序不一样，写在后面的可能先执行。下面来看个例子：

const syncFunc = () => {
  const time = new Date().getTime();
  while(true) {
    if(new Date().getTime() - time > 2000) {
      break;
    }
  }
  console.log(2);
}

console.log(1);
syncFunc();
console.log(3);

上述代码会先打印出1，然后调用syncFunc，syncFunc里面while循环会运行2秒，然后打印出2，最后打印出3。所以这里代码的执行顺序跟我们的书写顺序是一致，他是同步代码：

再来看个异步例子：

const asyncFunc = () => {
  setTimeout(() => {
    console.log(2);
  }, 2000);
}

console.log(1);
asyncFunc();
console.log(3);

上述代码的输出是：

可以看到我们中间调用的asyncFunc里面的2却是最后输出的，这是因为setTimeout是一个异步方法。他的作用是设置一个定时器，等定时器时间到了再执行回调里面的代码。所以异步就相当于做一件事，但是并不是马上做，而是你先给别人打了个招呼，说xxx条件满足的时候就干什么什么。就像你晚上睡觉前在手机上设置了一个第二天早上7天的闹钟，就相当于给了手机一个异步事件，触发条件是时间到达早上7点。使用异步的好处是你只需要设置好异步的触发条件就可以去干别的事情了，所以异步不会阻塞主干上事件的执行。特别是对于JS这种只有一个线程的语言，如果都像我们第一个例子那样去while(true)，那浏览器就只有一直卡死了，只有等这个循环运行完才会有响应。

JS异步是怎么实现的

我们都知道JS是单线程的，那单线程是怎么实现异步的呢？事实上所谓的"JS是单线程的"只是指JS的主运行线程只有一个，而不是整个运行环境都是单线程。JS的运行环境主要是浏览器，以大家都很熟悉的Chrome的内核为例，他不仅是多线程的，而且是多进程的：

上图只是一个概括分类，意思是Chrome有这几类的进程和线程，并不是每种只有一个，比如渲染进程就有多个，每个选项卡都有自己的渲染进程。有时候我们使用Chrome会遇到某个选项卡崩溃或者没有响应的情况，这个选项卡对应的渲染进程可能就崩溃了，但是其他选项卡并没有用这个渲染进程，他们有自己的渲染进程，所以其他选项卡并不会受影响。这也是Chrome单个页面崩溃并不会导致浏览器崩溃的原因，而不是像老IE那样，一个页面卡了导致整个浏览器都卡。

对于前端工程师来说，主要关心的还是渲染进程，下面来分别看下里面每个线程是做什么的。

GUI线程

GUI线程就是渲染页面的，他解析HTML和CSS，然后将他们构建成DOM树和渲染树就是这个线程负责的。

JS引擎线程

这个线程就是负责执行JS的主线程，前面说的"JS是单线程的"就是指的这个线程。大名鼎鼎的Chrome V8引擎就是在这个线程运行的。需要注意的是，这个线程跟GUI线程是互斥的。互斥的原因是JS也可以操作DOM，如果JS线程和GUI线程同时操作DOM，结果就混乱了，不知道到底渲染哪个结果。这带来的后果就是如果JS长时间运行，GUI线程就不能执行，整个页面就感觉卡死了。所以我们最开始例子的while(true)这样长时间的同步代码在真正开发时是绝对不允许的。

定时器线程

前面异步例子的setTimeout其实就运行在这里，他跟JS主线程根本不在同一个地方，所以“单线程的JS”能够实现异步。JS的定时器方法还有setInterval，也是在这个线程。

事件触发线程

定时器线程其实只是一个计时的作用，他并不会真正执行时间到了的回调，真正执行这个回调的还是JS主线程。所以当时间到了定时器线程会将这个回调事件给到事件触发线程，然后事件触发线程将它加到事件队列里面去。最终JS主线程从事件队列取出这个回调执行。事件触发线程不仅会将定时器事件放入任务队列，其他满足条件的事件也是他负责放进任务队列。

异步HTTP请求线程

这个线程负责处理异步的ajax请求，当请求完成后，他也会通知事件触发线程，然后事件触发线程将这个事件放入事件队列给主线程执行。

所以JS异步的实现靠的就是浏览器的多线程，当他遇到异步API时，就将这个任务交给对应的线程，当这个异步API满足回调条件时，对应的线程又通过事件触发线程将这个事件放入任务队列，然后主线程从任务队列取出事件继续执行。这个流程我们多次提到了任务队列，这其实就是Event Loop，下面我们详细来讲解下。

Event Loop

所谓Event Loop，就是事件循环，其实就是JS管理事件执行的一个流程，具体的管理办法由他具体的运行环境确定。目前JS的主要运行环境有两个，浏览器和Node.js。这两个环境的Event Loop还有点区别，我们会分开来讲。

浏览器的Event Loop

事件循环就是一个循环，是各个异步线程用来通讯和协同执行的机制。各个线程为了交换消息，还有一个公用的数据区，这就是事件队列。各个异步线程执行完后，通过事件触发线程将回调事件放到事件队列，主线程每次干完手上的活儿就来看看这个队列有没有新活儿，有的话就取出来执行。画成一个流程图就是这样：

流程讲解如下:

主线程每次执行时，先看看要执行的是同步任务，还是异步的API同步任务就继续执行，一直执行完遇到异步API就将它交给对应的异步线程，自己继续执行同步任务异步线程执行异步API，执行完后，将异步回调事件放入事件队列上主线程手上的同步任务干完后就来事件队列看看有没有任务主线程发现事件队列有任务，就取出里面的任务执行主线程不断循环上述流程

定时器不准

Event Loop的这个流程里面其实还是隐藏了一些坑的，最典型的问题就是总是先执行同步任务，然后再执行事件队列里面的回调。这个特性就直接影响了定时器的执行，我们想想我们开始那个2秒定时器的执行流程：

主线程执行同步代码遇到setTimeout，将它交给定时器线程定时器线程开始计时，2秒到了通知事件触发线程事件触发线程将定时器回调放入事件队列，异步流程到此结束主线程如果有空，将定时器回调拿出来执行，如果没空这个回调就一直放在队列里。

上述流程我们可以看出，如果主线程长时间被阻塞，定时器回调就没机会执行，即使执行了，那时间也不准了，我们将开头那两个例子结合起来就可以看出这个效果：

const syncFunc = (startTime) => {
  const time = new Date().getTime();
  while(true) {
    if(new Date().getTime() - time > 5000) {
      break;
    }
  }
  const offset = new Date().getTime() - startTime;
  console.log(`syncFunc run, time offset: ${offset}`);
}

const asyncFunc = (startTime) => {
  setTimeout(() => {
    const offset = new Date().getTime() - startTime;
    console.log(`asyncFunc run, time offset: ${offset}`);
  }, 2000);
}

const startTime = new Date().getTime();

asyncFunc(startTime);

syncFunc(startTime);

执行结果如下：

通过结果可以看出，虽然我们先调用的asyncFunc，虽然asyncFunc写的是2秒后执行，但是syncFunc的执行时间太长，达到了5秒，asyncFunc虽然在2秒的时候就已经进入了事件队列，但是主线程一直在执行同步代码，一直没空，所以也要等到5秒后，同步代码执行完毕才有机会执行这个定时器回调。所以再次强调，写代码时一定不要长时间占用主线程。

引入微任务

前面的流程图我为了便于理解，简化了事件队列，其实事件队列里面的事件还可以分两类：宏任务和微任务。微任务拥有更高的优先级，当事件循环遍历队列时，先检查微任务队列，如果里面有任务，就全部拿来执行，执行完之后再执行一个宏任务。执行每个宏任务之前都要检查下微任务队列是否有任务，如果有，优先执行微任务队列。所以完整的流程图如下：

上图需要注意以下几点：

一个Event Loop可以有一个或多个事件队列，但是只有一个微任务队列。微任务队列全部执行完会重新渲染一次每个宏任务执行完都会重新渲染一次requestAnimationFrame处于渲染阶段，不在微任务队列，也不在宏任务队列

所以想要知道一个异步API在哪个阶段执行，我们得知道他是宏任务还是微任务。

常见宏任务有：

script (可以理解为外层同步代码)setTimeout/setIntervalsetImmediate(Node.js)I/OUI事件postMessage

常见微任务有：

Promiseprocess.nextTick(Node.js)Object.observeMutaionObserver

上面这些事件类型中要注意Promise，他是微任务，也就是说他会在定时器前面运行，我们来看个例子:

console.log('1');
setTimeout(() => {
  console.log('2');
},0);
Promise.resolve().then(() => {
  console.log('5');
})
new Promise((resolve) => {
  console.log('3');
  resolve();
}).then(() => {
  console.log('4');
})

上述代码的输出是1,3,5,4,2。因为：

先输出1，这个没什么说的，同步代码最先执行console.log('2');在setTimeout里面，setTimeout是宏任务，“2”进入宏任务队列console.log('5');在Promise.then里面，进入微任务队列console.log('3');在Promise构造函数的参数里面，这其实是同步代码，直接输出console.log('4');在then里面，他会进入微任务队列，检查事件队列时先执行微任务同步代码运行结果是“1，3”然后检查微任务队列，输出“5，4”最后执行宏任务队列，输出“2”

Node.js的Event Loop

Node.js是运行在服务端的js，虽然他也用到了V8引擎，但是他的服务目的和环境不同，导致了他API与原生JS有些区别，他的Event Loop还要处理一些I/O，比如新的网络连接等，所以与浏览器Event Loop也是不一样的。Node的Event Loop是分阶段的，如下图所示：

timers: 执行setTimeout和setInterval的回调pending callbacks: 执行延迟到下一个循环迭代的 I/O 回调idle, prepare: 仅系统内部使用poll: 检索新的 I/O 事件;执行与 I/O 相关的回调。事实上除了其他几个阶段处理的事情，其他几乎所有的异步都在这个阶段处理。check: setImmediate在这里执行close callbacks: 一些关闭的回调函数，如：socket.on('close', ...)

每个阶段都有一个自己的先进先出的队列，只有当这个队列的事件执行完或者达到该阶段的上限时，才会进入下一个阶段。在每次事件循环之间，Node.js都会检查它是否在等待任何一个I/O或者定时器，如果没有的话，程序就关闭退出了。我们的直观感受就是，如果一个Node程序只有同步代码，你在控制台运行完后，他就自己退出了。

还有个需要注意的是poll阶段，他后面并不一定每次都是check阶段，poll队列执行完后，如果没有setImmediate但是有定时器到期，他会绕回去执行定时器阶段：

setImmediate和setTimeout

上面的这个流程说简单点就是在一个异步流程里，setImmediate会比定时器先执行，我们写点代码来试试：

console.log('outer');

setTimeout(() => {
  setTimeout(() => {
    console.log('setTimeout');
  }, 0);
  setImmediate(() => {
    console.log('setImmediate');
  });
}, 0);

上述代码运行如下:

和我们前面讲的一样，setImmediate先执行了。我们来理一下这个流程：

外层是一个setTimeout，所以执行他的回调的时候已经在timers阶段了处理里面的setTimeout，因为本次循环的timers正在执行，所以他的回调其实加到了下个timers阶段处理里面的setImmediate，将它的回调加入check阶段的队列外层timers阶段执行完，进入pending callbacks，idle, prepare，poll，这几个队列都是空的，所以继续往下到了check阶段，发现了setImmediate的回调，拿出来执行然后是close callbacks，队列时空的，跳过又是timers阶段，执行我们的console

但是请注意我们上面console.log('setTimeout')和console.log('setImmediate')都包在了一个setTimeout里面，如果直接写在最外层会怎么样呢？代码改写如下:

console.log('outer');

setTimeout(() => {
  console.log('setTimeout');
}, 0);

setImmediate(() => {
  console.log('setImmediate');
});

我们来运行下看看效果：

好像是setTimeout先输出来，我们多运行几次看看:

怎么setImmediate又先出来了，这代码是见鬼了还是啥？这个世界上是没有鬼怪的，所以事情都有原因的，我们顺着之前的Event Loop再来理一下。在理之前，需要告诉大家一件事情，node.js里面setTimeout(fn, 0)会被强制改为setTimeout(fn, 1),这在官方文档中有说明。(说到这里顺便提下，HTML 5里面setTimeout最小的时间限制是4ms)。原理我们都有了，我们来理一下流程：

外层同步代码一次性全部执行完，遇到异步API就塞到对应的阶段遇到setTimeout，虽然设置的是0毫秒触发，但是被node.js强制改为1毫秒，塞入times阶段遇到setImmediate塞入check阶段同步代码执行完毕，进入Event Loop先进入times阶段，检查当前时间过去了1毫秒没有，如果过了1毫秒，满足setTimeout条件，执行回调，如果没过1毫秒，跳过跳过空的阶段，进入check阶段，执行setImmediate回调

通过上述流程的梳理，我们发现关键就在这个1毫秒，如果同步代码执行时间较长，进入Event Loop的时候1毫秒已经过了，setTimeout执行，如果1毫秒还没到，就先执行了setImmediate。每次我们运行脚本时，机器状态可能不一样，导致运行时有1毫秒的差距，一会儿setTimeout先执行，一会儿setImmediate先执行。但是这种情况只会发生在还没进入timers阶段的时候。像我们第一个例子那样，因为已经在timers阶段，所以里面的setTimeout只能等下个循环了，所以setImmediate肯定先执行。同理的还有其他poll阶段的API也是这样的，比如：

var fs = require('fs')

fs.readFile(__filename, () => {
    setTimeout(() => {
        console.log('setTimeout');
    }, 0);
    setImmediate(() => {
        console.log('setImmediate');
    });
});

这里setTimeout和setImmediate在readFile的回调里面，由于readFile回调是I/O操作，他本身就在poll阶段，所以他里面的定时器只能进入下个timers阶段，但是setImmediate却可以在接下来的check阶段运行，所以setImmediate肯定先运行，他运行完后，去检查timers，才会运行setTimeout。

类似的，我们再来看一段代码，如果他们两个不是在最外层，而是在setImmediate的回调里面，其实情况跟外层一样，结果也是随缘的，看下面代码:

console.log('outer');

setImmediate(() => {
  setTimeout(() => {
    console.log('setTimeout');
  }, 0);
  setImmediate(() => {
    console.log('setImmediate');
  });
});

原因跟写在最外层差不多，因为setImmediate已经在check阶段了，里面的循环会从timers阶段开始，会先看setTimeout的回调，如果这时候已经过了1毫秒，就执行他，如果没过就执行setImmediate。

process.nextTick()

process.nextTick()是一个特殊的异步API，他不属于任何的Event Loop阶段。事实上Node在遇到这个API时，Event Loop根本就不会继续进行，会马上停下来执行process.nextTick()，这个执行完后才会继续Event Loop。我们写个例子来看下：

var fs = require('fs')

fs.readFile(__filename, () => {
    setTimeout(() => {
        console.log('setTimeout');
    }, 0);

    setImmediate(() => {
        console.log('setImmediate');
        
        process.nextTick(() => {
          console.log('nextTick 2');
        });
    });

    process.nextTick(() => {
      console.log('nextTick 1');
    });
});

这段代码的打印如下：

我们还是来理一下流程:

我们代码基本都在readFile回调里面，他自己执行时，已经在poll阶段遇到setTimeout(fn, 0)，其实是setTimeout(fn, 1)，塞入后面的timers阶段遇到setImmediate，塞入后面的check阶段遇到nextTick，立马执行，输出'nextTick 1'到了check阶段，输出'setImmediate',又遇到个nextTick,立马输出'nextTick 2'到了下个timers阶段，输出'setTimeout'

这种机制其实类似于我们前面讲的微任务，但是并不完全一样,比如同时有nextTick和Promise的时候，肯定是nextTick先执行，原因是nextTick的队列比Promise队列优先级更高。来看个例子:

const promise = Promise.resolve()
setImmediate(() => {
  console.log('setImmediate');
});
promise.then(()=>{
    console.log('promise')
})
process.nextTick(()=>{
    console.log('nextTick')
})

代码运行结果如下：

总结

本文从异步基本概念出发一直讲到了浏览器和Node.js的Event Loop，现在我们再来总结一下：

  1. JS所谓的“单线程”只是指主线程只有一个，并不是整个运行环境都是单线程
  2. JS的异步靠底层的多线程实现
  3. 不同的异步API对应不同的实现线程
  4. 异步线程与主线程通讯靠的是Event Loop
  5. 异步线程完成任务后将其放入任务队列
  6. 主线程不断轮询任务队列，拿出任务执行
  7. 任务队列有宏任务队列和微任务队列的区别
  8. 微任务队列的优先级更高，所有微任务处理完后才会处理宏任务
  9. Promise是微任务
  10. Node.js的Event Loop跟浏览器的Event Loop不一样，他是分阶段的
  11. setImmediate和setTimeout(fn, 0)哪个回调先执行，需要看他们本身在哪个阶段注册的，如果在定时器回调或者I/O回调里面，setImmediate肯定先执行。如果在最外层或者setImmediate回调里面，哪个先执行取决于当时机器状况。
  12. process.nextTick不在Event Loop的任何阶段，他是一个特殊API，他会立即执行，然后才会继续执行Event Loop

于超时，可以把开发者分为两类：一类是了解超时多么难以捉摸的人，另一类是正在感受超时如何难以捉摸的人。

超时既难以捉摸，却又真实地存在于我们生活的由网络连接的世界中。在我写这篇文章的同时，隔壁两个同事正在用他们的智能手机打字，也许是在跟与他们相距万里的人聊天。网络使这一切变为可能。

这里要说的是网络及其复杂性，作为写网络服务的我们，必须掌握如何高效地驾驭它们，并规避它们的缺陷。

闲话少说，来看看超时和它们是如何影响我们的 net/http 服务的。

服务超时 — 基本原理

web 编程中，超时通常分为客户端和服务端超时两种。我之所以要研究这个主题，是因为我自己遇到了一个有意思的服务端超时的问题。这也是本文我们将要重点讨论服务侧超时的原因。

先解释下基本术语：超时是一个时间间隔（或边界），用来标识在这个时间段内要完成特定的行为。如果在给定的时间范围内没有完成操作，就产生了超时，这个操作会被取消。

从一个 net/http 的服务的初始化中，能看出一些超时的基础配置：

srv := &http.Server{
    ReadTimeout:       1 * time.Second,
    WriteTimeout:      1 * time.Second,
    IdleTimeout:       30 * time.Second,
    ReadHeaderTimeout: 2 * time.Second,
    TLSConfig:         tlsConfig,
    Handler:           srvMux,
}

http.Server 类型的服务可以用四个不同的 timeout 来初始化：

  • ReadTimeout：读取包括请求体的整个请求的最大时长
  • WriteTimeout：写响应允许的最大时长
  • IdleTimetout：当开启了保持活动状态（keep-alive）时允许的最大空闲时间
  • ReadHeaderTimeout：允许读请求头的最大时长

对上述超时的图表展示：

服务生命周期和超时

当心！不要以为这些就是你所需要的所有的超时了。除此之外还有很多超时，这些超时提供了更小的粒度控制，对于我们的持续运行的 HTTP 处理器不会生效。

请听我解释。

timeout 和 deadline

如果我们查看 net/http 的源码，尤其是看到 `conn` 类型[1] 时，我们会发现 conn 实际上使用了 net.Conn 连接，net.Conn 表示底层的网络连接：

// Taken from: https://github.com/golang/go/blob/bbbc658/src/net/http/server.go#L247
// A conn represents the server-side of an HTTP connection.
type conn struct {
    // server is the server on which the connection arrived.
    // Immutable; never nil.
    server *Server

    // * Snipped *

    // rwc is the underlying network connection.
    // This is never wrapped by other types and is the value given out
    // to CloseNotifier callers. It is usually of type *net.TCPConn or
    // *tls.Conn.
    rwc net.Conn

    // * Snipped *
}

换句话说，我们的 HTTP 请求实际上是基于 TCP 连接的。从类型上看，TLS 连接是 *net.TCPConn 或 *tls.Conn 。

serve 函数[2]处理每一个请求[3]时调用 readRequest 函数。readRequest 使用我们设置的 timeout 值[4]来设置 TCP 连接的 deadline：

// Taken from: https://github.com/golang/go/blob/bbbc658/src/net/http/server.go#L936
// Read next request from connection.
func (c *conn) readRequest(ctx context.Context) (w *response, err error) {
        // *Snipped*

        t0 := time.Now()
        if d := c.server.readHeaderTimeout(); d != 0 {
                hdrDeadline = t0.Add(d)
        }
        if d := c.server.ReadTimeout; d != 0 {
                wholeReqDeadline = t0.Add(d)
        }
        c.rwc.SetReadDeadline(hdrDeadline)
        if d := c.server.WriteTimeout; d != 0 {
                defer func() {
                        c.rwc.SetWriteDeadline(time.Now().Add(d))
                }()
        }

        // *Snipped*
}

从上面的摘要中，我们可以知道：我们对服务设置的 timeout 值最终表现为 TCP 连接的 deadline 而不是 HTTP 超时。

所以，deadline 是什么？工作机制是什么？如果我们的请求耗时过长，它们会取消我们的连接吗？

一种简单地理解 deadline 的思路是，把它理解为对作用于连接上的特定的行为的发生限制的一个时间点。例如，如果我们设置了一个写的 deadline，当过了这个 deadline 后，所有对这个连接的写操作都会被拒绝。

尽管我们可以使用 deadline 来模拟超时操作，但我们还是不能控制处理器完成操作所需的耗时。deadline 作用于连接，因此我们的服务仅在处理器尝试访问连接的属性（如对 http.ResponseWriter 进行写操作）之后才会返回（错误）结果。

为了实际验证上面的论述，我们来创建一个小的 handler，这个 handler 完成操作所需的耗时相对于我们为服务设置的超时更长：

package main

import (
 "fmt"
 "io"
 "net/http"
 "time"
)

func slowHandler(w http.ResponseWriter, req *http.Request) {
 time.Sleep(2 * time.Second)
 io.WriteString(w, "I am slow!\n")
}

func main() {
 srv := http.Server{
  Addr:         ":8888",
  WriteTimeout: 1 * time.Second,
  Handler:      http.HandlerFunc(slowHandler),
 }

 if err := srv.ListenAndServe(); err != nil {
  fmt.Printf("Server failed: %s\n", err)
 }
}

上面的服务有一个 handler，这个 handler 完成操作需要两秒。另一方面，http.Server 的 WriteTimeout 属性设为 1 秒。基于服务的这些配置，我们猜测 handler 不能把响应写到连接。

我们可以用 go run server.go 来启动服务。使用 curl localhost:8888 来发送一个请求：

$ time curl localhost:8888
curl: (52) Empty reply from server
curl localhost:8888  0.01s user 0.01s system 0% CPU 2.021 total

这个请求需要两秒来完成处理，服务返回的响应是空的。虽然我们的服务知道在 1 秒之后我们写不了响应了，但 handler 还是多耗了 100% 的时间（2 秒）来完成处理。

虽然这是个类似超时的处理，但它更大的作用是在到达超时时间时，阻止服务进行更多的操作，结束请求。在我们上面的例子中，handler 在完成之前一直在处理请求，即使已经超出响应写超时时间（1 秒）100%（耗时 2 秒）。

最根本的问题是，对于处理器来说，我们应该怎么设置超时时间才更有效？

处理超时

我们的目标是确保我们的 slowHandler 在 1s 内完成处理。如果超过了 1s，我们的服务会停止运行并返回对应的超时错误。

在 Go 和一些其它编程语言中，组合往往是设计和开发中最好的方式。标准库的 `net/http` 包[5]有很多相互兼容的元素，开发者可以不需经过复杂的设计考虑就可以轻易将它们组合在一起。

基于此，net/http 包提供了`TimeoutHandler`[6] — 返回了一个在给定的时间限制内运行的 handler。

函数签名：

func TimeoutHandler(h Handler, dt time.Duration, msg string) Handler

第一个参数是 Handler，第二个参数是 time.Duration （超时时间），第三个参数是 string 类型，当到达超时时间后返回的信息。

用 TimeoutHandler 来封装我们的 slowHandler，我们只需要：

package main

import (
 "fmt"
 "io"
 "net/http"
 "time"
)

func slowHandler(w http.ResponseWriter, req *http.Request) {
 time.Sleep(2 * time.Second)
 io.WriteString(w, "I am slow!\n")
}

func main() {
 srv := http.Server{
  Addr:         ":8888",
  WriteTimeout: 5 * time.Second,
  Handler:      http.TimeoutHandler(http.HandlerFunc(slowHandler), 1*time.Second, "Timeout!\n"),
 }

 if err := srv.ListenAndServe(); err != nil {
  fmt.Printf("Server failed: %s\n", err)
 }
}

两个需要留意的地方是：

  • 我们在 http.TimetoutHandler 里封装 slowHanlder，超时时间设为 1s，超时信息为 “Timeout!”。
  • 我们把 WriteTimeout 增加到 5s，以给予 http.TimeoutHandler足够的时间执行。如果我们不这么做，当 TimeoutHandler 开始执行时，已经过了 deadline，不能再写到响应。

如果我们再启动服务，当程序运行到 slow handler 时，会有如下输出：

$ time curl localhost:8888
Timeout!
curl localhost:8888  0.01s user 0.01s system 1% CPU 1.023 total

1s 后，我们的 TimeoutHandler 开始执行，阻止运行 slowHandler，返回文本信息 ”Timeout!“。如果我们设置信息为空，handler 会返回默认的超时响应信息，如下：

<html>
  <head>
    <title>Timeout</title>
  </head>
  <body>
   <h1>Timeout</h1>
  </body>
</html>

如果忽略掉输出，这还算是整洁，不是吗？现在我们的程序不会有过长耗时的处理；也避免了有人恶意发送导致长耗时处理的请求时，导致的潜在的 DoS 攻击。

尽管我们设置超时时间是一个伟大的开始，但它仍然只是初级的保护。如果你可能会面临 DoS 攻击，你应该采用更高级的保护工具和技术。（可以试试 Cloudflare[7] ）

我们的 slowHandler 仅仅是个简单的 demo。但是，如果我们的程序复杂些，能向其他服务和资源发出请求会发生什么呢？如果我们的程序在超时时向诸如 S3 的服务发出了请求会怎么样？

会发生什么？

未处理的超时和请求取消

我们稍微展开下我们的例子：

func slowAPICall() string {
 d := rand.Intn(5)
 select {
 case <-time.After(time.Duration(d) * time.Second):
  log.Printf("Slow API call done after %s seconds.\n", d)
  return "foobar"
 }
}

func slowHandler(w http.ResponseWriter, r *http.Request) {
 result := slowAPICall()
 io.WriteString(w, result+"\n")
}

我们假设最初我们不知道 slowHandler 由于通过 slowAPICall 函数向 API 发请求导致需要耗费这么长时间才能处理完成，

slowAPICall 函数很简单：使用 select 和一个能阻塞 0 到 5 秒的 time.After 。当经过了阻塞的时间后，time.After 方法通过它的 channel 发送一个值，返回 "foobar" 。

（另一种方法是，使用 sleep(time.Duration(rand.Intn(5)) * time.Second)，但我们仍然使用 select，因为它会使我们下面的例子更简单。）

如果我们运行起服务，我们预期超时 handler 会在 1 秒之后中断请求处理。来发送一个请求验证一下：

$ time curl localhost:8888
Timeout!
curl localhost:8888  0.01s user 0.01s system 1% CPU 1.021 total

通过观察服务的输出，我们会发现，它是在几秒之后打出日志的，而不是在超时 handler 生效时打出：

$ Go run server.go
2019/12/29 17:20:03 Slow API call done after 4 seconds.

这个现象表明：虽然 1 秒之后请求超时了，但是服务仍然完整地处理了请求。这就是在 4 秒之后才打出日志的原因。

虽然在这个例子里问题很简单，但是类似的现象在生产中可能变成一个严重的问题。例如，当 slowAPICall 函数开启了几个百个协程，每个协程都处理一些数据时。或者当它向不同系统发出多个不同的 API 发出请求时。这种耗时长的的进程，它们的请求方/客户端并不会使用服务端的返回结果，会耗尽你系统的资源。

所以，我们怎么保护系统，使之不会出现类似的未优化的超时或取消请求呢？

上下文超时和取消

Go 有一个包名为 `context`[8] 专门处理类似的场景。

context 包在 Go 1.7 版本中提升为标准库，在之前的版本中，以golang.org/x/net/context[9] 的路径作为 Go Sub-repository Packages[10] 出现。

这个包定义了 Context 类型。它最初的目的是保存不同 API 和不同处理的截止时间、取消信号和其他请求相关的值。如果你想了解关于 context 包的其他信息，可以阅读 Golang's blog[11] 中的 “Go 并发模式：Context”（译注：Go Concurrency Patterns: Context） .

net/http 包中的的 Request 类型已经有 context 与之绑定。从 Go 1.7 开始，Request 新增了一个返回请求的上下文的 `Context` 方法[12]。对于进来的请求，在客户端关闭连接、请求被取消（HTTP/2 中）或 ServeHTTP 方法返回后，服务端会取消上下文。

我们期望的现象是，当客户端取消请求（输入了 CTRL + C）或一段时间后 TimeoutHandler 继续执行然后终止请求时，服务端会停止后续的处理。进而关闭所有的连接，释放所有被运行中的处理进程（及它的所有子协程）占用的资源。

我们把 Context 作为参数传给 slowAPICall 函数：

func slowAPICall(ctx context.Context) string {
 d := rand.Intn(5)
 select {
 case <-time.After(time.Duration(d) * time.Second):
  log.Printf("Slow API call done after %d seconds.\n", d)
  return "foobar"
 }
}

func slowHandler(w http.ResponseWriter, r *http.Request) {
 result := slowAPICall(r.Context())
 io.WriteString(w, result+"\n")
}

在例子中我们利用了请求上下文，实际中怎么用呢？`Context` 类型[13]有个 Done 属性，类型为 <-chan struct{}。当进程处理完成时，Done 关闭，此时表示上下文应该被取消，而这正是例子中我们需要的。

我们在 slowAPICall 函数中用 select 处理 ctx.Done 通道。当我们通过 Done 通道接收一个空的 struct 时，意味着上下文取消，我们需要让 slowAPICall 函数返回一个空字符串。

func slowAPICall(ctx context.Context) string {
 d := rand.Intn(5)
 select {
 case <-ctx.Done():
  log.Printf("slowAPICall was supposed to take %s seconds, but was canceled.", d)
  return ""
        //time.After() 可能会导致内存泄漏
 case <-time.After(time.Duration(d) * time.Second):
  log.Printf("Slow API call done after %d seconds.\n", d)
  return "foobar"
 }
}

（这就是使用 select 而不是 time.Sleep -- 这里我们只能用select 处理 Done 通道。）

在这个简单的例子中，我们成功得到了结果 -- 当我们从 Done 通道接收值时，我们打印了一行日志到 STDOUT 并返回了一个空字符串。在更复杂的情况下，如发送真实的 API 请求，你可能需要关闭连接或清理文件描述符。

我们再启动服务，发送一个 cRUL 请求：

# The cURL command:
$ curl localhost:8888
Timeout!

# The server output:
$ Go run server.go
2019/12/30 00:07:15 slowAPICall was supposed to take 2 seconds, but was canceled.

检查输出：我们发送了 cRUL 请求到服务，它耗时超过 1 秒，服务取消了 slowAPICall 函数。我们几乎不需要写任何代码。TimeoutHandler 为我们代劳了 -- 当处理耗时超过预期时，TimeoutHandler 终止了处理进程并取消请求上下文。

TimeoutHandler 是在 `timeoutHandler.ServeHTTP` 方法[14] 中取消上下文的：

// Taken from: https://github.com/golang/go/blob/bbbc658/src/net/http/server.go#L3217-L3263
func (h *timeoutHandler) ServeHTTP(w ResponseWriter, r *Request) {
        ctx := h.testContext
        if ctx == nil {
         var cancelCtx context.CancelFunc
         ctx, cancelCtx = context.WithTimeout(r.Context(), h.dt)
         defer cancelCtx()
        }
        r = r.WithContext(ctx)

        // *Snipped*
}

上面例子中，我们通过调用 context.WithTimeout 来使用请求上下文。超时值 h.dt （TimeoutHandler 的第二个参数）设置给了上下文。返回的上下文是请求上下文设置了超时值后的一份拷贝。随后，它作为请求上下文传给 r.WithContext(ctx)。

context.WithTimeout 方法执行了上下文取消。它返回了 Context 设置了一个超时值之后的副本。当到达超时时间后，就取消上下文。

这里是执行的代码：

// Taken from: https://github.com/golang/go/blob/bbbc6589/src/context/context.go#L486-L498
func WithTimeout(parent Context, timeout time.Duration) (Context, CancelFunc) {
 return WithDeadline(parent, time.Now().Add(timeout))
}

// Taken from: https://github.com/golang/go/blob/bbbc6589/src/context/context.go#L418-L450
func WithDeadline(parent Context, d time.Time) (Context, CancelFunc) {
        // *Snipped*

        c := &timerCtx{
         cancelCtx: newCancelCtx(parent),
         deadline:  d,
        }

        // *Snipped*

        if c.err == nil {
         c.timer = time.AfterFunc(dur, func() {
          c.cancel(true, DeadlineExceeded)
         })
        }
        return c, func() { c.cancel(true, Canceled) }
}

这里我们又看到了截止时间。WithDeadline 函数设置了一个 d 到达之后执行的函数。当到达截止时间后，它调用 cancel 方法处理上下文，此方法会关闭上下文的 done 通道并设置上下文的 timer 属性为nil。

Done 通道的关闭有效地取消了上下文，使我们的 slowAPICall 函数终止了它的执行。这就是 TimeoutHandler 终止耗时长的处理进程的原理。

（如果你想阅读上面提到的源码，你可以去看 `cancelCtx` 类型[15]和 `timerCtx` 类型[16]）

有弹性的 net/http 服务

连接截止时间提供了低级的细粒度控制。虽然它们的名字中含有“超时”，但它们并没有表现出人们通常期望的“超时”。实际上它们非常强大，但是使用它们有一定的门槛。

另一个角度讲，当处理 HTTP 时，我们仍然应该考虑使用 TimeoutHandler。Go 的作者们也选择使用它，它有多种处理，提供了如此有弹性的处理以至于我们甚至可以对每一个处理使用不同的超时。TimeoutHandler 可以根据我们期望的表现来控制执行进程。

除此之外，TimeoutHandler 完美兼容 context 包。context 包很简单，包含了取消信号和请求相关的数据，我们可以使用这些数据来使我们的应用更好地处理错综复杂的网络问题。

结束之前，有三个建议。写 HTTP 服务时，怎么设计超时：

  1. 最常用的，到达 TimeoutHandler 时，怎么处理。它进行我们通常期望的超时处理。
  2. 不要忘记上下文取消。context 包使用起来很简单，并且可以节省你服务器上的很多处理资源。尤其是在处理异常或网络状况不好时。
  3. 一定要用截止时间。确保做了完整的测试，验证了能提供你期望的所有功能。

更多关于此主题的文章：

  • “The complete guide to Go net/http timeouts” onCloudflare's blog[17]
  • “So you want to expose Go on the Internet” onCloudflare's blog[18]
  • “Use http.TimeoutHandler or ReadTimeout/WriteTimeout?” on Stackoverflow[19]
  • “Standard net/http config will break your production environment” on Simon Frey's blog[20]

via: https://ieftimov.com/post/make-resilient-golang-net-http-servers-using-timeouts-deadlines-context-cancellation/

作者：Ilija Eftimov[21]译者：lxbwolf[22]校对：polaris1119[23]

本文由 GCTT[24] 原创编译，Go 中文网[25] 荣誉推出

参考资料

[1]

conn 类型: https://github.com/golang/go/blob/bbbc658/src/net/http/server.go#L248

[2]

函数: https://github.com/golang/go/blob/bbbc658/src/net/http/server.go#L1765

[3]

处理每一个请求: https://github.com/golang/go/blob/bbbc658/src/net/http/server.go#L1822

[4]

timeout 值: https://github.com/golang/go/blob/bbbc658/src/net/http/server.go#L946-L958

[5]

net/http 包: https://golang.org/pkg/net/http

[6]

TimeoutHandler: https://golang.org/pkg/net/http/#TimeoutHandler

[7]

Cloudflare: https://www.cloudflare.com/ddos/

[8]

context: https://golang.org/pkg/context/

[9]

golang.org/x/net/context: https://godoc.org/golang.org/x/net/context

[10]

Go Sub-repository Packages: https://godoc.org/-/subrepo

[11]

Golang's blog: https://blog.golang.org/context

[12]

Context 方法: https://golang.org/pkg/net/http/#Request.Context

[13]

Context 类型: https://golang.org/pkg/context/#Context

[14]

timeoutHandler.ServeHTTP 方法: https://github.com/golang/go/blob/bbbc658/src/net/http/server.go#L3217-L3263

[15]

cancelCtx 类型: https://github.com/golang/go/blob/bbbc6589dfbc05be2bfa59f51c20f9eaa8d0c531/src/context/context.go#L389-L416

[16]

timerCtx 类型: https://github.com/golang/go/blob/bbbc6589dfbc05be2bfa59f51c20f9eaa8d0c531/src/context/context.go#L472-L484

[17]

Cloudflare's blog: https://blog.cloudflare.com/the-complete-guide-to-golang-net-http-timeouts/

[18]

Cloudflare's blog: https://blog.cloudflare.com/exposing-go-on-the-internet/

[19]

Stackoverflow: https://stackoverflow.com/questions/51258952/use-http-timeouthandler-or-readtimeout-writetimeout

[20]

Simon Frey's blog: https://blog.simon-frey.eu/go-as-in-golang-standard-net-http-config-will-break-your-production

[21]

Ilija Eftimov: https://ieftimov.com/

[22]

lxbwolf: https://github.com/lxbwolf

[23]

polaris1119: https://github.com/polaris1119

[24]

GCTT: https://github.com/studygolang/GCTT

[25]

Go 中文网: https://studygolang.com/

xios是什么？

Axios 是一个基于 promise 的 HTTP 库，可以用在浏览器和 node.js 中。我们知道 Promise 是 js 异步的一种解决方案，它最大的特性就是可以通过 .then 的方式来进行链式调用。

其实说白了axios是对ajax的封装，axios有的ajax都有，ajax有的axios不一定有，总结一句话就是axios是ajax，ajax不止axios。

为什么选择axios?

  1. vue的作者尤雨溪推荐使用axios.
  2. 符合前后端分离的趋势，及前端的MVVM的浪潮

功能特点：

  • 在浏览器中发送XMLHttpRequests请求
  • 在node.js中发送http请求
  • 支持Promise API
  • 拦截请求和响应
  • 转换请求和响应数据
  • 取消请求
  • 自动转换 JSON 数据
  • 客户端支持防御 XSRF

    • 支持多种请求方式：

  • axios(config)
  • axios.request(config)
  • axios.get(url, [, config])
  • axios.delete(url, [, config])
  • axios.head(url, [, config])
  • axios.post(url, [,data[,config] ])
  • axios.put(url, [,data[,config] ])
  • axios.patch(url, [,data[,config] ])

    • Axios的基本使用

    axios的使用比较简单，文档讲得也非常清晰，你应该先阅读axios的官方文档：axios文档。

    在html页面中直接引入使用:

    <script src="https://unpkg.com/axios/dist/axios.min.js"></script>

    Html页面基本使用

    以下案例中的get请求地址为crmeb相关演示站地址，可用于测试获取！

    1. 获取一个get请求
    <script>
  const url = 'https://store.crmeb.net/api/pc/get_category_product'
  axios({
    url: url,
    method: 'get',  // 这里可以省略，默认为get
  }).then(res => {
    // 返回请求到的数据
    console.log(res)
  }).catch(err => {
    // 返回错误信息
    console.log(err)
  })  
</script>
    1. 在get请求的url中传参，只需要定义一个params:{}即可！
    <script>
  const url = 'https://store.crmeb.net/api/pc/get_category_product'
  axios({
    url: url,
    method: 'get',  // 这里可以省略，默认为get
    // 这里的键值对会拼接成这样url?page=1&limit=3
    params: {
      page: 1,
      limit: 3
    }
  }).then(res => {
    // 返回请求到的数据
    console.log(res)
  }).catch(err => {
    // 返回错误信息
    console.log(err)
  })  
</script>
    1. 发送一个post请求，与get请求类似，只需要将method改为post，定义一个data:{}即可,data中的数据则是服务器需要接收的字段数据！
    <script>
axios({
  method: 'post',
  url: '/user/12345',
  data: {
    firstName: 'Fred',
    lastName: 'Flintstone'
  }
}).then(res => {
    // 返回请求到的数据
    console.log(res)
  }).catch(err => {
    // 返回错误信息
    console.log(err)
  });
</script>
    1. 发送一个并发请求

    如果在开发中需要等到多个接口的数据同时请求到后才能继续后边的逻辑，那么即可使用并发请求，axios并发请求，使用all方法，all方法的参数为一个数组，数组的每个值可以为一次请求，请求完成后直接.then即可合并两次请求的数据，返回结果为一个数组！

    <script>
axios.all([
    axios({
        url: 'https://store.crmeb.net/api/pc/get_products',
        params: {
            page: 1,
            limit: 20,
            cid: 57,
            sid: 0,
            priceOrder: '', 
            news: 0,
        }
    }),
    axios({
        url: 'https://store.crmeb.net/api/pc/get_company_info',
    })
]).then(results => {
    console.log(results)
})
</script>

    如果你想自动把这个数组展开的话在then()方法中传入axios.spread()方法即可，如下所示：

    <script>
axios.all([
    axios({
        url: 'https://store.crmeb.net/api/pc/get_products',
        params: {
            page: 1,
            limit: 20,
            cid: 57,
            sid: 0,
            priceOrder: '', 
            news: 0,
        }
    }),
    axios({
        url: 'https://store.crmeb.net/api/pc/get_company_info',
    })
]).then(axios.spread((res1, res2) => {
    console.log(res1);
    console.log(res2);
}))
</script>

    但在使用vue组件化开发的时候一般我们会通过npm安装，引入项目！

    组件化开发中使用

    1. 使用npm进行安装
    npm install axios --save

    一般在实际项目中我们并不会像上边这样直接去使用axios请求数据，而是将axios封装在一个单独的文件，这样做的目的主要是用来抽取公共逻辑到一个配置文件里，对这些公共逻辑做一个封装，即使某一天这个axios框架不维护了，或者出现了重大bug也不再修复的时候，我们可以只修改配置文件即可达到全局修改的目的，如果把每次请求逻辑都写到对应的组件中，那修改起来简直就是一个噩梦！

    1. 封装一个axios的请求文件request.js

    在项目的src目录下创建一个network文件夹，再在其中创建一个request.js文件，路径为：src/network/request.js

    // src/network/request.js

// 引入axios
import axios from 'axios'

// 这里未使用default导出，是为了以后的扩展，便于导出多个方法
export function request(config){
    // 创建axios实例
    const instance = axios.create({
        // 这里定义每次请求的公共数据，例如全局请求头，api根地址，过期时间等
        // 具体参数可参考axios的官方文档
        baseURL: 'http://demo26.crmeb.net/api',
        timeout: 5000
    })
    
    // 拦截请求，如果获取某个请求需要携带一些额外数据
    instance.interceptors.request.use(
        config => {
            console.log(config);
            return config;
        }, err => {
            console.log(err);
        })
        
    // 拦截响应
    instance.interceptors.response.use(
        res => {
            console.log(res)
            return res.data
        }, err => {
            console.log(err)
        }
    )
    
    // 发送请求
    return instance(config)
    1. 使用我们封装的request请求

    一般我们会将所有的请求放在一个api.js文件中，将每次请求封装为一个方法,比如我这里会在request.js的同目录创建一个api.js文件封装我们所有的请求。

    import { request } from '../api/request'

// 获取分类
export const getHomeCategory = () => {
    return request({
        url: '/category'
    })
}

// 获取banner图
export const getHomeBanner = () => {
    return request({
        url: '/pc/get_banner'
    })
}

    之后再在组件中引入调用导出的相关接口方法即可，如：

    import { getHomeBanner } from "../network/api"

getHomeBanner().then(res => {
	console.log(res)
})

    以上就是一个简单的封装，其中有个拦截请求和拦截响应，可能很多初学的人理解起来有点吃力，我在这里以个人浅见阐述，希望能带给你些许启发！

    何为拦截器？

    还是发挥阅读理解能力，拦截拦截其实就是此路是我开，此树是我栽，要想过此路，留下买路钱，拦截请求就是比如某些请求需要携带一些额外的信息才能访问，实际项目中最常见的就是需要登录后才能查看的信息，请求中就必须携带token才能访问，就可以在这里处理，还有拦截响应，比如请求到数据之后，发现不符合要求，先拦下来处理一下，再返回给前端，这就是一个拦截器的基本工作流程！

  • axios有一个全局拦截的方式：axios.interceptors()
  • 拦截成功后必须return返回，否则数据无法请求到

    • 如下所示：

      // 拦截请求，如果获取某个请求需要携带一些额外数据
    instance.interceptors.request.use(
        config => {
            console.log(config);
            return config;
        }, err => {
            console.log(err);
        })
        
    // 拦截响应
    instance.interceptors.response.use(
        res => {
            console.log(res)
            return res.data
        }, err => {
            console.log(err)
        }
    )

    axios还为我们提供了一些全局配置，如下：

    axios.defaults.baseURL = 'https://api.example.com';
axios.defaults.headers.common['Authorization'] = AUTH_TOKEN;
axios.defaults.headers.post['Content-Type'] = 'application/x-www-form-urlencoded';

    当然也可以将其配置在我们之前创建的axios实例中，使其只作用于某个实例！

    然后来看一下 axios 的所有配置信息:

    数据来自axios中文文档


    在线咨询
    上一篇：Space.js – HTML 驱动的页面 3D 滚动效果
    下一篇：精选13个HTML5学习必备网站

    您的项目需求

    *请认真填写需求信息，我们会在24小时内与您取得联系。

    推荐阅读
    友情链接 浮梁县 霍州市 吴堡县 王益区 高要市 鹿邑县 网站制作
    Copyright © 2002-2019 雨点网络设计有限公司 版权所有   冀ICP备11025394号
    联系电话：   E-mail：279303980@qq.com  
    主营业务：技术文章网站建设、网站定制、技术文章营销型网站建设、技术文章网站优化、技术文章微商城制作、三级分销系统开发
    电话沟通
    在线客服