用Memproof检查js内存泄漏问题露，求助一个小问题

来源：蜘蛛抓取(WebSpider) 时间：2018-11-18 08:23 标签： js内存泄漏问题

将内存错误和泄漏检测、应用程序性能描述、代码覆盖分析等功能组合在一个单一、完整的工具包中

开发者提供完整的错误诊断，和运行时性能分析工具包

，或其它.Net程序

和Windows程序生成全面细致的报告，从而帮助您轻松隔离并排除代码中含有的性能问题和内存/资源泄露问题支持.Net 1.0,1.1,2.0,3.0和Windows 32/64位应用程序。

发布的┅款调试工具用来探测JavaScript代码中的js内存泄漏问题漏，运行为IE系列的一个插件

附录：js内存泄漏问题漏的发生方式

1.     常发性js内存泄漏问题漏。發生js内存泄漏问题漏的代码会被多次执行到每次被执行的时候都会导致一块js内存泄漏问题漏。

2.     偶发性js内存泄漏问题漏发生js内存泄漏问題漏的代码只有在某些特定环境或操作过程下才会发生。常发性和偶发性是相对的对于特定的环境，偶发性的也许就变成了常发性的所以测试环境和测试方法对检测js内存泄漏问题漏至关重要。

3.     一次性js内存泄漏问题漏发生js内存泄漏问题漏的代码只会被执行一次，或者由於算法上的缺陷导致总会有一块且仅有一块内存发生泄漏。

隐式js内存泄漏问题漏程序在运行过程中不停的分配内存，但是直到结束的時候才释放内存严格的说这里并没有发生js内存泄漏问题漏，因为最终程序释放了所有申请的内存但是对于一个服务器程序，需要运行幾天几周甚至几个月，不及时释放内存也可能导致最终耗尽系统的所有内存所以，我们称这类js内存泄漏问题漏为隐式js内存泄漏问题漏

当应用程序在Windows中运行时，Windows必须实时"跟踪"该应用程序的运行并保留与之相关的许多信息，如按钮、光标、菜单的位置和位图、窗口的状況等这些信息由Windows保留在一种叫堆的内存块中，堆的英文为Heap简单地说，堆是采用特殊机制管理的内存块由Windows的一个系统内核User.exe管理的堆叫莋User资源堆（User

　　微软将Windows的系统资源（堆）分为五个堆，其中User资源堆为三个而GDI资源堆为两个。

　　三个User资源堆分别是：16位的用户堆（User

　　兩个GDI资源堆分别是：16位的GDI堆（GDI

　　从这里的系统资源分类和大小我们应该明白不管CPU是P4还是486，内存是8M还是1G所有Windows的用户都拥有同样大小的系统资源（堆），用户不能自已增加或减少系统资源的大小这是由操作系统决定的，与硬件档次没有任何关系

　　Windows的User资源堆和GDI资源堆嘚可用（Free）空间称为可用 User资源和可用GDI资源，Windows中以百分数表示它们用户可以选择 "开始/附件/系统工具/系统信息"，来实时查看它们的大小

要使用memproof来对程序进行检查js内存泄漏问题漏等步骤如下：
1. 先配置delphi的编译环境，以便输出相应的信息给memproof使用
2. 将程序编译好，然后再打开memproof在memproof里打开该程序的可执行文件，
3.操作程序查看memproof所报的一些信息，
4. 退出程序 此时memproof会报出有js内存泄漏问题漏或是别的；

一切准备就绪，现在可以开始调试了
1. 下面是用于調试的一段测试程序：

新建一个空白工程，在OnCreate事件中加入以下代码：

再根据上面的介绍设置好工程选项打开MemProof：

选择File-Open 打开要调试的执行文件，再选择Run-Run 开始运行再正常退出目标程序，如果有资源泄漏MemProof会自动打开Resources Details面板：
MemProof共列出5个js内存泄漏问题漏我们可以看到每个js内存泄漏问題漏都有详细的调用栈情况，以及相对应的源码位置

有时它会提示我们找不到对应的源码，这是应为没有指定源码搜索路径的原因MemProof有兩个位置可以设置源码搜索路径，一个在Configure- Search Directories一个在Projects-Search Directories。前者是设置全局路径后者是设置当前路径。一般建议在前者中设置DELPHI的VCL以及共用库代碼的路径后者设置工程本身源码的路径。MemProof还为用户提供了快捷搜索VCL源码路径的按钮Get Default for 使用这个按钮可以快捷的获取DELPHI的Libray Path（有的用户安装了VC覆盖了默认调试工具选项，所以有可能得到的是VC的Libray

1. 渐进式测试从最易发现的错误开始解决

一个大型的软件可能会有很多泄漏或者错误，這个时候可以渐进式的来测试第一次测试可以直接运行后立即退出，检测在加载的过程中是否存在泄漏然后逐一更正。再分功能模块進行测试比如只针对某个功能进行操作，然后退出检测该模块是否存在泄漏如果存在，更正最后再进行整体测试。这样可以避免一些关联性错误导致重复测试而且可以节省测试时间，可以使测试更有针对性

2. 分模块测试，从单个的模块开始解决

和上一条原则一样為了缩小测试面。在Projects的Moudle Configers中选择测试的模块开始每次只选择一个模块针对性测试，最后再选择所有模块测试

3. 错误优先，发现错误与泄漏並存时优先解决错误

测试过程中，代表错误这些错误往往是由于错误的使用系统API导致，如：释放不存在的句柄访问权限不够的资源，传递了错误的调用参数等这些错误往往会导致代码没有按照预计的方式运行，触发一些js内存泄漏问题漏所以，需要优先修正这些位置

系统资源泄漏往往是由于窗体、画布等资源没有及时释放，这些错误非常明显而且这种错误往往会带有很多的Pointers、Memory泄漏，所以优先修正。

VCL并不是完美的有时运行程序出现很多LoadCursor错误也可以忽略。

还有更多的关于DELPHI和C++Builder本身导致的js内存泄漏问题漏可以参见：

l         发现泄漏的位置茬VCL单元中的时候不要去考究VCL的代码，找到调用栈中涉及到的外部单元去检查相信VCL吧，绝大多数情况些它是不会导致js内存泄漏问题漏的

MemProof尽管非常优秀，同样存在不少缺陷如上面提到的不能Attach Process，这样就不能够调试ISAPI、服务程序等；还有当程序由于访问保护内存、或强制结束进程等原因导致非正常退出时，MemProof将不会有任何结果报告；另外MemProof的机制决定它不可能实现远程调试；最后，MemProof是个免费性质的软件在帮助支持方面做得不够，连一个像样的帮助都没有同类的商业软件BoundCheker在这方面做得非常不错，每个错误都可以在帮助中得到详细的解释MemProof的這个缺点导致新手不容易上手。

做了持久压力测试发现内存增長的很快，注释大法查了半天发现两个泄漏点不过代码太多了，分开调试又很麻烦所以就想看看内存里面到底是啥。

4）触发内存增长（我这个程序是发包）等到内存增长足够多的时候

我要回帖

更多关于 js内存泄漏问题 的文章

 

随机推荐