JavaScript如何工作：垃圾回收机制 + 常见的4种内存泄漏
标记和扫描算法行为的可视化。
因为“一个对象有零引用”导致该对象不可达，所以这个算法比前一个算法更好。我们在周期中看到的情形恰巧相反，是不正确的。 截至 2012 年，所有现代浏览器都内置了标记扫描式的垃圾回收器。去年在 JavaScript 垃圾收集（通用/增量/并发/并行垃圾收集）领域中所做的所有改进都是基于这种算法（标记和扫描）的实现改进，但这不是对垃圾收集算法本身的改进，也不是对判断一个对象是否可访问这个目标的改进。
即使两个对象之间有引用，根节点它们不在被访问。
; } function removeImage() { // image 元素是body的直接子元素。 document.body.removeChild(document.getElementById('image')); // 我们仍然可以在全局元素对象中引用button。换句话说，button元素仍在内存中，无法由GC收集 }
在涉及 DOM 树内的内部节点或子节点时，还有一个额外的因素需要考虑。如果你在代码中保留对table表格单元格（td 标记）的引用，并决定从 DOM 中删除该table表格但保留对该特定单元格td的引用，则可以预见到严重的内存泄漏。你可能会认为垃圾收集器会释放除了那个单元格td之外的所有东西。但情况并非如此。由于单元格td是table表格的子节点，并且子节点保持对父节点的引用，所以对table表格对单元格td的这种单引用会把整个table表格保存在内存中。
我们在 SessionStack 尝试遵循这些最佳实践，编写正确处理内存分配的代码，原因如下：
一旦将 SessionStack 集成到你的生产环境的 Web 应用程序中，它就会开始记录所有的事情：所有的 DOM 更改，用户交互，JavaScript 异常，堆栈跟踪，失败网络请求，调试消息等。
通过 SessionStack web 应用程序中的问题，并查看所有的用户行为。所有这些都必须在您的网络应用程序没有性能影响的情况下进行。
由于用户可以重新加载页面或导航你的应用程序，所有的观察者，拦截器，变量分配等都必须正确处理，这样它们才不会导致任何内存泄漏，也不会增加我们正在整合的Web应用程序的内存消耗。
这里有一个免费的计划所以你可以试试看.
#Resources
How JavaScript works: memory management + how to handle 4 common memory leaks
ps: 顺便推一下自己的个人公众号：Yopai，有兴趣的可以关注，每周不定期更新，分享可以增加世界的快乐https://www.cnblogs.com/liuheng/p/11750993.html