async hooks 是 node8 新出来的特性，提供了一些 api 用于跟踪 nodejs 中的异步资源的生命周期，属于 nodejs 内置模块，可以直接引用。
这是一个很少使用的模块，为什么会有这个模块呢？
我们都知道，javascript在设计之初就是一门单线程语言，这和他的设计初衷有关，最初的javascript仅仅是用来进行页面的表单校验，在低网速时代降低用户等待服务器响应的时间成本。随着web前端技术的发展，虽然前端功能越来越强大，越来越被重视，但是单线程似乎也没有什么解决不了的问题，相比较而言多线程似乎更加的复杂，所以单线程依旧被沿用至今。
既然javascript是单线程，但是在日常开发中总是会有一些比较耗时的任务，比如说定时器，再比如说如今已经标准化的ajax，javascript为了解决这些问题，将自身分为了bom，dom，ecmascript，bom会帮我们解决这些耗时的任务，称之为异步任务。
正因为浏览器的bom帮我们处理了异步任务，所以大部分的程序员对异步任务除了会用几乎一无所知，比如同时有多少异步任务在队列中？异步是否拥堵等，我们都是没有办法直接获得相关信息的，很多情况下，底层确实也不需要我们关注相关的信息，但如果我们在某些情况下想要相关信息的时候，nodejs提供了一个experimental的api供我们使用，也就是async_hooks。为什么是nodejs呢，因为只有在node中定时器，http这些异步模块，才是开发者可以控制的，浏览器中的bom是不被开发者控制的，除非浏览器提供对应的api。
async_hooks规则
async_hooks约定每一个函数都会提供一个上下文，我们称之为async scope，每一个async scope中都有一个 asyncid, 是当前async scope的标志，同一个的async scope中asyncid必然相同。
这在多个异步任务并行的时候，asyncid可以使我们可以很好的区分要监听的是哪一个异步任务。
asyncid是一个自增的不重复的正整数，程序的第一个asyncid必然是1。
async scope通俗点来说就是一个不能中断的同步任务，只要是不能中断的，无论多长的代码都共用一个asyncid，但如果中间是可以中断的，比如是回调，比如中间有await，都会创建一个新的异步上下文，也会有一个新的asyncid。
每一个async scope中都有一个triggerasyncid表示当前函数是由那个async scope触发生成的；
通过 asyncid 和 triggerasyncid 我们可以很方便的追踪整个异步的调用关系及链路。
async_hooks.executionasyncid()用于获取asyncid，可以看到全局的asyncid是1。
async_hooks.triggerasyncid()用于获取triggerasyncid，目前值为0。
我们这里使用fs.open打开一个文件，可以发现fs.open的asyncid是7，而fs.open的triggerasyncid变成了1，这是因为fs.open是由全局调用触发的，全局的asyncid是1。
异步函数的生命周期
当然实际应用中的async_hooks并不是这样使用的，他正确的用法是在所有异步任务创建、执行前、执行后、销毁后，触发回调，所有回调会传入asyncid。
我们可以使用async_hooks.createhook来创建一个异步资源的钩子，这个钩子接收一个对象作为参数来注册一些关于异步资源生命周期中可能发生事件的回调函数。每当异步资源被创建/执行/销毁时这些钩子函数会被触发。
目前 createhook 函数可以接受五类 hook callbacks 如下：
1.init(asyncid, type, triggerasyncid, resource)
- init 回调函数一般在异步资源初始化的时候被触发。
- asyncid: 每一个异步资源都会生成一个唯一性标志
- type: 异步资源的类型，一般都是资源的构造函数的名字。
fseventwrap, fsreqcallback, getaddrinforeqwrap, getnameinforeqwrap, httpincomingmessage,
httpclientrequest, jsstream, pipeconnectwrap, pipewrap, processwrap, querywrap,
shutdownwrap, signalwrap, statwatcher, tcpconnectwrap, tcpserverwrap, tcpwrap,
ttywrap, udpsendwrap, udpwrap, writewrap, zlib, sslconnection, pbkdf2request,
randombytesrequest, tlswrap, microtask, timeout, immediate, tickobject
- triggerasyncid: 表示触发当前异步资源被创建的对应的 async scope 的 asyncid
- resource: 代表被初始化的异步资源对象
我们可以通过 async_hooks.createhook 函数来注册关于每个异步资源在生命周期中发生的 init/before/after/destory/promiseresolve 等相关事件的监听函数；
同一个 async scope 可能会被调用及执行多次，不管执行多少次，其 asyncid 必然相同，通过监听函数，我们很方便追踪其执行的次数及时间及上线文关系；
2.before(asyncid)
before函数一般在 asyncid 对应的异步资源操作完成后准备执行回调前被调用，before回调函数可能被执行多次，由其被回调的次数来决定，使用时这里需要注意。
3.after(asyncid)
after回调函数一般在异步资源执行完回调函数后会立即被调用，如果在执行回调函数的过程中发生未捕获的异常，after 事件会在触发 “uncaughtexception” 事件后被调用。
4.destroy(asyncid)
当asyncid对应的异步资源被销毁时调用，有些异步资源的销毁要依赖垃圾回收机制，所以有些情况下由于内存泄漏的原因，destory事件可能永远不会被触发。
5.promiseresolve(asyncid)
当 promise 构造器中的 resovle 函数被执行时，promiseresolve 事件被触发。有些情况下，有些 resolve 函数是被隐式执行的，比如 .then 函数会返回一个新的 promise，这个时候也会被调用。
promise
promise是比较特殊的一种情况，如果足够细心init方法中的type中你就会发现其中并没有promise。如果仅使用ah.executionasyncid()来获取promise的的asyncid的话，是不能取得正确的id的，只有在添加了实际的hook只后，async_hooks才会给promise的回调创建asyncid。
换句话说，由于v8对于获取 asyncid 的执行成本比较高，所以默认情况下，我们是不给 promise 分配新的 asyncid。
也就是说默认情况下，我们使用promises或者 async/await 时是获取不到当前上下文正确的asyncid和triggerid。不过没关系，我们可以通过执行async_hooks.createhook(callbacks).enable()函数强制开启对promise分配asyncid。
另外promise只会触发init和promiseresolve钩子事件函数，而before和after事件的钩子函数只会在promise的链式调用时被触发，也就是说只有在.then/.catch函数中生成的promise时才会被触发。
可以发现，上面的存在两个promise，第一个是new实例化创建的，第二个是then创建的(不明白的可以查看之前的promise源码文章)。
这里的顺序是执行new promise的时候会调用自身的init函数，然后在执行resolve的时候调用promiseresolve函数。接着在then方法中执行第二个promise的init函数，然后执行第二个promise的before，promiseresovle，after函数。
异常处理
如果注册的async-hook回调函数中发生异常，那么服务将打印错误日志并立即退出，同时所有de 监听器将被移除，同时会触发 ‘exit’ 事件退出程序。
之所以会立即退出进程，是因为如果这些async-hook 函数运行不稳定，下一个相同事件被触发时很可能又抛出异常，这些函数主要就是为了监听异步事件的，如果不稳定应该及时发现并进行更正。
在异步钩子回调中打印日志
由于 console.log 函数也是一个异步调用，如果我们在 async-hook 函数中再调用 console.log 那么将再次触发相应的 hook 事件，造成死循环调用，所以我们在 async-hook 函数中必须使用同步打印日志方式来跟踪，可以使用 fs.writesync 函数：
[参考文献-asynchooks] ()
到此这篇关于node8中asynchooks异步生命周期的文章就介绍到这了,更多相关node asynchooks异步生命周期内容请搜索www.887551.com以前的文章或继续浏览下面的相关文章希望大家以后多多支持www.887551.com！
