hyj1991_个人页

逆工程 JS 对象 (一): 浅谈 V8 对象布局

逆工程 JS 对象其实就是根据 V8 设计的对 JS 对象存储结构的描述，开发者可以实现在进程运行内存空间中或者进程崩溃后的 Core 文件还原的内存空间中来反推出当前 JS 代码运行状态和 JS 对象在堆空间的分配状况的一种技术。

Node.js 应用故障排查手册 —— 雪崩型内存泄漏问题

还有一些问题场景下下应用的内存泄漏非常严重和迅速，甚至于在我们的告警系统感知之前就已经造成应用的 OOM 了，这时我们来不及或者说根本没办法获取到堆快照，因此就没有办法借助于之前的办法来分析为什么进程会内存泄漏到溢出进而 Crash 的原因了。

Node.js 应用故障排查手册 —— 类死循环导致进程阻塞

在实践篇一中我们看到了两个表象都是和 CPU 相关的生产问题，它们基本也是我们在线上可能遇到的这一类问题的典型案例，而实际上这两个案例也存在一个共同点：我们可以通过 [Node.js 性能平台](https://www.aliyun.com/product/nodejs) 导出进程对应的 CPU Profile 信息来进行分析定位问题，但是实际在线上的一些极端情况下，我们遇到的故障是没有办法通过轻量的 V8 引擎暴露的 CPU Profile 接口（仅部分定制的 AliNode runtime 版本支持，详见下文）来获取足够的进程状态信息进行分析的，此时我们又回到了束手无策的状态。

Node.js 应用故障排查手册 —— 综合性 GC 问题和优化

本章前面两节生产案例分别侧重于单一的 CPU 高和单一的内存问题，我们也给大家详细展示了问题的定位排查过程，那么实际上还有一类相对更复杂的场景——它本质上是 V8 引擎的 GC 引发的问题。

Node.js 应用故障排查手册 —— 冗余配置传递引发的内存溢出

前面一小节我们以一个真实的压测案例来给大家讲解如何利用 [Node.js 性能平台](https://www.aliyun.com/product/nodejs) 生成的 CPU Profile 分析来进行压测时的性能调优。

Node.js 应用故障排查手册 —— 利用 CPU 分析调优吞吐量

在我们想要新上线一个 Node.js 应用之前，尤其是技术栈切换的第一个 Node.js 应用，由于担心其在线上的吞吐量表现，肯定会想要进行性能压测，以便对其在当前的集群规模下能抗住多少流量有一个预估。

Node.js 应用故障排查手册 —— Node.js 性能平台使用指南

实际上预备章中除了 CPU/Memory 的问题，我们还会遇到一些需要分析错误日志、磁盘和核心转储文件等才能定位问题的状况，因此在这些场景下，仅仅靠 Chrome devtools 显然会有一些力不从心。

Node.js 应用故障排查手册 —— 正确打开 Chrome devtools

前面的预备章节中我们大致了解了如何在服务器上的 Node.js 应用出现问题时，从常规的错误日志、系统/进程指标以及兜底的核心转储这些角度来排查问题。这样就引出了下一个问题：我们知道进程的 CPU/Memory 高，或者拿到了进程 Crash 后的核心转储，要如何去进行分析定位到具体的 JavaScript 代码段。

Node.js 应用故障排查手册 —— 大纲与常规问题指标简介

JavaScript 发展到今天，早已脱离原本浏览器的战场，借助于 Node.js 的诞生将其触角伸到了服务端、PC 跨平台客户端方案等各个领域，但是与此同时，JS Runtime 对于绝大部分的开发者来说又一如既往的处于黑盒状态——开发者无法感知其运行状态，出现一些性能、内存问题时也没有很好的工具链进行更深入的支持。

如何进行 GC 调优提升 Node 应用性能

Node 案发现场揭秘 —— Core dump 还原线上应用异常

快速定位线上 Node.js 内存泄漏问题

想要分析定位内存泄漏问题，首先我们要去获取 Node.js 进程在发生泄漏时的堆上各个对象和它们间的引用关系，这个保存了堆上各个对象以及其引用关系的文件就是堆快照。

Co、递归调用引发的内存泄漏

我们知道，同步的递归写法，如果在退出递归条件失效时，会快速因为栈溢出导致进程挂掉。而在某些场景下，我们会采用异步的递归写法来规避这个问题：

Node.js 性能平台新功能——模块仓库

Node.js 性能平台推出的模块仓库，在完全覆盖 cnpm 私有仓库功能的基础上，提供了一套多用户隔离 + 精确权限控制的模式，能够覆盖企业开发中面临的多种场景，最关键的是这一切功能目前是免费提供的。