历下区住房和城市建设局网站广西建设网官网培训中心

历下区住房和城市建设局网站,广西建设网官网培训中心,做药品网站有哪些,做网站教程大家好#xff0c;欢迎来到今天的技术讲座。今天我们将深入探讨一个在现代应用程序开发中普遍存在且令人头疼的问题#xff1a;内存泄漏和内存增长。特别是对于那些需要长时间运行、对性能和稳定性有较高要求的应用#xff0c;内存管理变得至关重要。我们将聚焦于一个强大而…大家好欢迎来到今天的技术讲座。今天我们将深入探讨一个在现代应用程序开发中普遍存在且令人头疼的问题内存泄漏和内存增长。特别是对于那些需要长时间运行、对性能和稳定性有较高要求的应用内存管理变得至关重要。我们将聚焦于一个强大而又常常被低估的工具——堆快照Heap Snapshot并着重讲解如何利用其“对比模式”来快速、精准地定位内存增长点。内存泄漏与内存增长概念与危害在深入技术细节之前我们首先要明确一些基本概念。内存泄漏Memory Leak指程序中已分配的内存在不再需要时未能被正确释放导致这部分内存无法被垃圾回收器GC回收从而持续占用系统资源。从应用程序的角度看这些对象是“不可达”的但从垃圾回收器的角度看它们仍然被某个活跃的引用链所持有因此不能被回收。内存增长Memory Growth这是一个更宽泛的概念它包括内存泄漏但也包括那些“合法”的内存占用增加。例如一个缓存机制如果它没有明确的容量限制或淘汰策略可能会随着时间的推移不断累积数据从而导致内存持续增长。虽然这些对象在逻辑上可能仍然是“可达”的但它们的无限增长最终也会导致应用程序性能下降甚至崩溃。无论是内存泄漏还是内存增长其危害都是显而易见的性能下降内存占用过高会导致操作系统频繁进行页面交换Swapping降低I/O性能。应用程序卡顿垃圾回收器需要花费更多时间来扫描和回收内存导致应用程序响应变慢出现卡顿。系统崩溃内存耗尽可能导致应用程序崩溃甚至影响整个操作系统的稳定性。用户体验差慢响应、卡顿和崩溃都会严重损害用户体验。因此有效地识别和解决内存问题是确保应用程序健壮性的关键一环。堆快照内存侦探的利器堆快照顾名思义是应用程序在某一特定时刻其JavaScript堆内存中所有对象的一个“照片”。它记录了当时堆中所有对象的信息包括它们的类型、大小、引用关系以及由哪个构造函数创建等。这些信息对于理解应用程序的内存使用情况至关重要。堆快照包含的关键信息一个典型的堆快照通常会提供以下视图和数据Summary (概览)按构造函数分组的所有对象。每个构造函数创建的对象数量。浅层大小Shallow Size对象本身直接占用的内存大小。保留大小Retained Size当该对象被垃圾回收时能够被回收的总内存大小包括该对象自身及其所有仅被它引用的子对象。保留大小通常更能反映一个对象对内存的“实际贡献”。Comparison (对比)这是我们今天讲座的重点它允许您比较两个快照之间的内存变化。Containment (包含)显示对象的层级结构即哪些对象包含了哪些其他对象。Statistics (统计)提供不同内存类型如JS数组、字符串、系统对象等的统计信息。如何获取堆快照以Chrome DevTools和Node.js为例1. 在浏览器环境 (Chrome DevTools)这是最常用也最直观的方式。打开Chrome浏览器访问您的Web应用程序。按F12或CtrlShiftI(Windows/Linux) /CmdOptionI(macOS) 打开开发者工具。切换到Memory(内存) 面板。在左侧的 PROFILES (配置文件) 部分选择Heap snapshot(堆快照)。点击Take snapshot(获取快照) 按钮。稍等片刻快照就会被生成并显示在面板中。2. 在 Node.js 环境Node.js应用程序通常在服务器端运行没有图形界面。您可以使用内置的v8模块或第三方库来生成堆快照。使用v8模块Node.js 11.13.0v8.getHeapSnapshot()方法可以生成一个堆快照并返回一个可读流。const v8 require(v8); const fs require(fs); function takeSnapshot(filename) { const snapshotStream v8.getHeapSnapshot(); const fileStream fs.createWriteStream(filename); snapshotStream.pipe(fileStream); fileStream.on(finish, () { console.log(Heap snapshot written to ${filename}); }); } // 示例在程序启动后和执行某个操作后分别获取快照 console.log(Application started...); takeSnapshot(heap-snapshot-1.heapsnapshot); // 模拟一些内存增长的操作 let cache []; setInterval(() { for (let i 0; i 1000; i) { cache.push(new Array(100).fill(some_data_ Math.random())); } console.log(Cache size increased.); // 为了演示这里不清理cache导致内存增长 }, 5000); // 假设在某个时刻我们想要获取第二个快照 setTimeout(() { takeSnapshot(heap-snapshot-2.heapsnapshot); console.log(Second snapshot taken. You can now compare them in Chrome DevTools.); // process.exit(); // 或者让程序继续运行 }, 15000);生成的.heapsnapshot文件可以通过Chrome DevTools加载和分析在Memory面板中点击左上角的Load(加载) 按钮一个向上箭头的图标。选择您生成的.heapsnapshot文件。使用node --inspect结合 Chrome DevTools这种方式更加灵活可以像调试浏览器应用一样调试Node.js应用。启动您的Node.js应用并添加--inspect标志node --inspect your_app.jsChrome浏览器会自动在控制台输出一个ws://地址或者您可以直接访问chrome://inspect。在chrome://inspect页面您会看到一个Remote Target(远程目标) 列表点击您的Node.js应用的inspect(检查) 链接。这将打开一个新的DevTools窗口您可以像在浏览器中一样使用Memory面板来获取堆快照。为什么选择对比模式单个堆快照可以告诉您应用程序在某个特定时间点的内存使用情况但它很难揭示“动态”的内存问题比如内存泄漏或持续增长。您可能会看到一个很大的Array或Object实例但无法确定它是应用程序正常运行的一部分还是一个正在失控增长的泄漏点。这就是对比模式的价值所在。通过比较两个或多个在不同时间点获取的堆快照我们可以识别新增对象哪些对象在第一个快照之后被创建并且在第二个快照时仍然存活这些是内存增长点的主要嫌疑犯。量化增长新增对象的数量和它们占用的总内存大小保留大小是多少跟踪变化哪些对象的数量或大小发生了显著变化对比模式使得我们能够从海量的内存数据中迅速过滤出那些“异常”的、具有增长趋势的对象从而将我们的注意力集中在真正的问题所在。利用对比模式快速寻找内存增长点的技巧实战演练现在让我们来详细讲解如何利用对比模式进行内存分析。我们将以一个浏览器应用程序为例假设我们怀疑某个交互操作导致了内存泄漏。第一步设计可重复的内存增长场景这是最关键的一步。您需要找到一个能够模拟或触发内存增长的操作序列。这个操作序列应该可重复能够多次执行。有影响每次执行都会导致您怀疑的内存增长。相对独立尽量减少无关操作聚焦于目标。示例场景假设我们有一个单页面应用其中有一个列表页面每次点击“加载更多”按钮都会从服务器获取数据并渲染新的列表项。我们怀疑每次加载更多时旧的列表项或相关数据没有被正确清理导致内存持续增长。第二步获取第一个基线快照 (Snapshot A)加载应用并稳定打开您的应用程序导航到目标页面例如列表页面确保所有初始加载和渲染都已完成应用程序处于相对稳定的状态。强制垃圾回收可选但推荐在Chrome DevTools的Memory面板中点击垃圾桶图标Collect garbage强制执行一次垃圾回收。这有助于清理掉所有当前不可达的对象使我们的基线快照更“干净”。获取快照 A点击Take snapshot按钮。给它一个有意义的名字例如BeforeActivity。第三步执行可疑操作并放大增长执行操作在应用程序中执行您怀疑会导致内存增长的操作。在我们的例子中就是点击“加载更多”按钮。重复操作为了让内存增长更显著建议重复执行该操作多次例如3-5次。一次操作可能产生的内存增长很小难以察觉。多次重复可以放大问题使其更容易在快照对比中浮现。等待稳定每次操作后等待应用程序再次稳定下来确保所有异步操作和渲染都已完成。第四步获取第二个对比快照 (Snapshot B)强制垃圾回收再次推荐再次点击垃圾桶图标强制垃圾回收。获取快照 B点击Take snapshot按钮。给它一个有意义的名字例如AfterActivityRepeated。第五步进入对比模式并分析结果选择对比基线在Memory面板的左侧快照列表中选择您刚刚获取的Snapshot B。设置对比模式在Summary视图的顶部下拉菜单中将Comparison(对比) 模式从No comparison(无对比) 更改为Snapshot A(即BeforeActivity)。现在您将看到一个不同寻常的视图。表格中的数据不再是绝对值而是Snapshot B相对于Snapshot A的变化量。关键的筛选和排序技巧筛选器 (Filter)在表格上方的筛选框中输入。这将只显示在Snapshot B中新增的对象即Delta列为正数的条目。这是我们最关心的。排序 (Sort)点击表格列头进行排序。#Delta(对象数量变化)点击此列头按降序排列。这将显示哪些构造函数创建的对象数量增加最多。通常这是寻找泄漏点的最佳起点。Retained Size Delta(保留大小变化)点击此列头按降序排列。这将显示哪些新增对象占用了最多的内存。有时少量的大对象比大量的小对象更值得关注。表格结构示例对比模式下Constructor (构造函数)#Delta (数量变化)Shallow Size Delta (浅层大小变化)Retained Size Delta (保留大小变化)(string)100050KB50KBArray500200KB800KBMyCustomComponent510KB500KBEventListener101KB10KB(object)20020KB100KBDetached HTMLDivElement33KB30KB…………第六步深入分析可疑增长点Retainers View现在您已经通过筛选和排序找到了最可疑的增长点。接下来是“侦探工作”的核心环节找出谁在引用这些对象导致它们无法被垃圾回收。展开可疑条目在对比视图中点击带有显著数量或Retained Size Delta的构造函数例如MyCustomComponent或Array。检查单个实例展开后您会看到该构造函数下新增的各个对象实例。选择一个实例。查看 Retainers (引用者)在下方的面板中切换到Retainers(引用者) 视图。这个视图会显示一个树状结构揭示了从“GC Root”垃圾回收根对象如window或全局作用域到您选定对象的引用链。这个引用链是理解为什么对象没有被回收的关键。它告诉您“谁”正在持有对这个对象的引用。从底向上追溯引用链直到找到您代码中的某个变量、函数或DOM元素它不应该再持有对这个对象的引用但却依然持有。常见的泄漏模式和对应的Retainer链未解绑的事件监听器Retainer链通常会显示EventTarget(例如HTMLButtonElement或Window) -EventListeners- 您泄漏的对象。解决方案确保在组件销毁或不再需要时调用removeEventListener。闭包捕获了不必要的外部变量Retainer链会显示一个匿名函数closure捕获了包含泄漏对象的外部作用域变量。解决方案仔细检查闭包内部是否意外地引用了外部作用域中不再需要的大对象。有时可以通过将大对象赋值为null来辅助GC或者重构代码以避免不必要的捕获。全局变量或静态属性意外引用Retainer链可能直接指向(global property)或Window对象然后指向您的变量。解决方案避免在全局作用域下声明变量来持有临时对象或者确保在使用完毕后将其设为null。无限增长的缓存Retainer链会显示一个Map、Set或普通Object实例作为缓存它持有对泄漏对象的引用。解决方案为缓存设置容量限制和淘汰策略例如 LRU, LFU或使用WeakMap/WeakSet如果对象的生命周期可以由其在DOM或其他地方的引用决定。分离的DOM元素 (Detached DOM tree)在对比视图中您可能会看到Detached HTMLDivElement、Detached HTMLSpanElement等条目。这意味着这些DOM元素已经从文档树中移除但仍然被JavaScript代码引用导致无法被回收。Retainer链会显示是哪个JavaScript对象或变量持有对这些分离DOM元素的引用。解决方案确保在移除DOM元素时同时清理所有对它们的JavaScript引用。示例一个事件监听器泄漏的Retainer链假设我们发现MyCustomComponent的实例数量持续增加选中一个实例后Retainer视图可能看起来像这样► (GC Root) ► Window ► document ► HTMLButtonElement idmyButton ► (event listeners) ► (Closure) ► context: Closure (MyCustomComponent) ► this: MyCustomComponent ► (object) 123456 (MyCustomComponent instance)这个链表明垃圾回收的根对象Window引用了documentdocument引用了HTMLButtonElement idmyButton这个按钮又持有一个事件监听器。这个事件监听器是一个闭包它捕获了MyCustomComponent的this上下文从而导致MyCustomComponent的实例无法被回收即使它在逻辑上已经“不再需要”。第七步定位代码并修复根据 Retainer 链提供的信息您可以回到您的代码中找到对应的引用点并进行修复。代码示例与修复策略1. 事件监听器泄漏泄漏代码class LeakyComponent { constructor() { this.largeData new Array(1000).fill(some_data); // 每次创建组件都会给按钮添加一个监听器 // 但如果组件销毁时没有移除就会泄漏 document.getElementById(myButton).addEventListener(click, this.handleClick.bind(this)); } handleClick() { console.log(Button clicked, data size:, this.largeData.length); } // 缺少一个清理方法 } // 假设我们多次创建并“销毁”组件但实际上并未清理 function createAndDisposeLeakyComponent() { const comp new LeakyComponent(); // 模拟组件销毁但未执行清理 // comp null; // 无法回收 } // 运行多次模拟内存增长 // setInterval(createAndDisposeLeakyComponent, 1000);修复代码class FixedComponent { constructor() { this.largeData new Array(1000).fill(some_data); // 绑定一次并在需要时使用这个绑定的函数 this.boundHandleClick this.handleClick.bind(this); document.getElementById(myButton).addEventListener(click, this.boundHandleClick); } handleClick() { console.log(Button clicked, data size:, this.largeData.length); } // 添加一个清理方法在组件销毁时调用 cleanup() { document.getElementById(myButton).removeEventListener(click, this.boundHandleClick); this.largeData null; // 帮助GC回收 console.log(FixedComponent cleaned up.); } } // 模拟组件的生命周期管理 let currentComponent null; function createAndDisposeFixedComponent() { if (currentComponent) { currentComponent.cleanup(); // 清理旧组件 } currentComponent new FixedComponent(); // 创建新组件 } // 运行多次观察内存不再持续增长 // setInterval(createAndDisposeFixedComponent, 1000);分析在泄漏代码中this.handleClick.bind(this)每次都会创建一个新的函数实例。如果removeEventListener没有被调用那么document.getElementById(myButton)将会持有对所有这些bound函数实例的引用而这些函数实例又会通过闭包持有LeakyComponent实例的引用导致泄漏。修复后的代码通过在cleanup方法中调用removeEventListener并使用同一个绑定的函数实例来解决此问题。2. 闭包泄漏未清理的计时器泄漏代码function setupLeakyTimer() { let heavyObject { data: new Array(10000).fill(big_data) }; // 每隔一秒打印一次但这个定时器永远不会被清除 setInterval(() { console.log(Timer ticking with heavy object:, heavyObject.data.length); }, 1000); // heavyObject 永远无法被回收因为它被闭包捕获 } // 多次调用每次都会启动一个新的未清理的计时器 // setupLeakyTimer(); // setupLeakyTimer();修复代码function setupFixedTimer() { let heavyObject { data: new Array(10000).fill(big_data) }; const intervalId setInterval(() { console.log(Timer ticking with heavy object:, heavyObject.data.length); }, 1000); // 返回清理函数以便外部可以控制 return () { clearInterval(intervalId); heavyObject null; // 辅助GC console.log(Timer cleaned up.); }; } // 示例使用 const cleanupTimer1 setupFixedTimer(); // ... 稍后 // cleanupTimer1(); // 停止并清理第一个计时器分析泄漏代码中heavyObject被setInterval的回调函数一个闭包捕获由于setInterval没有被clearInterval清除其回调函数会一直存活进而导致heavyObject也无法被回收。修复后的代码通过返回一个清理函数允许外部在不再需要时显式地停止计时器并解除引用。3. 未受控的缓存增长泄漏代码const leakyCache {}; function addToLeakyCache(key, value) { leakyCache[key] value; // 缓存无限制增长 } // 模拟不断添加数据 // for (let i 0; i 10000; i) { // addToLeakyCache(item_ i, { id: i, data: new Array(100).fill(cached_data) }); // }修复代码简单LRU缓存示例class LRUCache { constructor(maxSize) { this.maxSize maxSize; this.cache new Map(); // 使用Map保持插入顺序 } get(key) { const item this.cache.get(key); if (item) { // 将最近访问的项移到Map末尾 this.cache.delete(key); this.cache.set(key, item); } return item; } set(key, value) { if (this.cache.has(key)) { this.cache.delete(key); } else if (this.cache.size this.maxSize) { // 移除最旧的项Map的第一个元素 const oldestKey this.cache.keys().next().value; this.cache.delete(oldestKey); } this.cache.set(key, value); } } const fixedCache new LRUCache(100); // 设置最大容量为100 // for (let i 0; i 10000; i) { // fixedCache.set(item_ i, { id: i, data: new Array(100).fill(cached_data) }); // }分析泄漏代码中的leakyCache是一个全局对象且没有任何容量限制导致其内部的Map或Object会无限增长。修复后的代码实现了一个简单的 LRU (Least Recently Used) 缓存策略确保缓存不会超过预设的最大容量从而防止内存无限增长。4. 分离的DOM元素泄漏代码let globalLeakedDiv null; // 意外地将DOM元素赋值给全局变量 function createAndRemoveDomElement() { const container document.getElementById(container); const div document.createElement(div); div.textContent Temporary content; container.appendChild(div); globalLeakedDiv div; // 错误的引用 container.removeChild(div); // DOM元素从文档中移除但仍被 globalLeakedDiv 引用 } // 多次调用 // setInterval(createAndRemoveDomElement, 1000);修复代码function createAndRemoveDomElementFixed() { const container document.getElementById(container); const div document.createElement(div); div.textContent Temporary content; container.appendChild(div); // 确保没有外部引用 // container.removeChild(div); // div null; // 如果不再需要可以显式解除引用 } // 如果确实需要临时引用确保在使用后清理 let tempDivRef null; function createAndRemoveWithTempRef() { const container document.getElementById(container); const div document.createElement(div); div.textContent Temporary content; container.appendChild(div); tempDivRef div; // 临时引用 container.removeChild(div); // 及时清理临时引用 tempDivRef null; }分析当DOM元素从文档树中移除后如果JavaScript代码仍然持有对它的引用例如通过globalLeakedDiv那么这个DOM元素及其所有子元素、事件监听器等将无法被垃圾回收。在堆快照中它们会显示为Detached HTMLDivElement等。修复的关键是确保在元素从DOM中移除后所有对它的JavaScript引用也被解除。第八步验证修复效果修复代码后重复之前的堆快照对比分析步骤。获取Snapshot A(修复前稳定状态)。执行多次操作。获取Snapshot B(修复后操作多次)。比较Snapshot B和Snapshot A。如果修复成功您应该会看到之前那些持续增长的构造函数条目其#Delta和Retained Size Delta变为 0 或接近 0。这表明内存增长问题已经得到有效解决。高级技巧与注意事项多轮对比对于非常微妙的泄漏两次快照可能不足以显示清晰的趋势。您可以尝试 A - B - C 多轮对比。先比较 B 和 A再比较 C 和 B。如果每次都有相似的增长模式那么泄漏点就更明确了。内存时间线 (Memory Timeline)在Memory面板中除了堆快照还有“Allocation instrumentation on timeline”选项。它可以实时记录JS堆内存的分配情况。虽然它不直接显示引用链但可以帮助您快速识别哪些操作导致了大量的内存分配和回收“churn”这有助于优化性能即使没有泄漏。WeakMap和WeakSet当您需要将数据与对象关联但不希望这种关联阻止对象被垃圾回收时WeakMap和WeakSet是非常有用的工具。它们持有的引用是“弱引用”不会阻止垃圾回收器回收其键或值对于WeakMap的键WeakSet的值。理解“Shallow Size”与“Retained Size”Shallow Size (浅层大小)对象本身所占用的内存。例如一个空对象{}的浅层大小可能只有几十字节。Retained Size (保留大小)如果该对象被垃圾回收能够释放的总内存。这包括对象本身的浅层大小以及所有只被它引用的子对象的内存。在定位内存泄漏时Retained Size通常比Shallow Size更具指导意义因为它反映了一个泄漏对象“拖累”了多少内存。GC Root (垃圾回收根)垃圾回收器从一组“根”对象如全局window对象、DOM树、活动堆栈中的变量等开始遍历所有能从根对象访问到的对象都被认为是“可达”的不能被回收。Retainers视图就是追溯这个从 GC Root 到您对象的路径。假阳性 (False Positives)并非所有增长都是泄漏。应用程序可能有意地缓存数据或者在处理大量数据时临时占用大量内存。理解应用程序的设计和预期行为至关重要。例如一个设计为缓存1000个对象的LRU缓存在达到容量上限之前其内存会持续增长这并非泄漏。总结堆快照的对比模式是解决JavaScript内存泄漏和内存增长问题的“瑞士军刀”。它提供了一种系统化、可视化的方法来识别应用程序中的内存热点。通过设计可重复的场景获取前后快照并利用对比模式的筛选和排序功能您可以迅速锁定可疑的增长点。随后通过深入分析“Retainers”视图追溯引用链就能精准定位代码中的泄漏源。掌握这项技能不仅能帮助您解决棘手的内存问题更能提升您对应用程序内部工作机制的理解从而编写出更健壮、更高效的代码。内存管理是一场持久战但有了堆快照对比分析这个强大的工具您将更有信心赢得这场战斗。