程序有内存泄露，郁闷中.msxml,com,widestring,olevariant帮顶有分！解决方法
程序有内存泄露，郁闷中...msxml,com,widestring,olevariant帮顶有分！
问题已经困扰我好几个月了，这好几个月，试了无数的办法都不得果！
我说一下情况，
1、一个服务程序，自己使用API实现
2、msxml4
3、interbase
4、COM+
5、多线程
我试过的办法有
1、为msxml*添加NoFullGC注册表值
2、使用FreeThreadedDOMDocument
3、添加OANOCACHE=1环境变量
4、全局接口表
5、每个调用成功的CoInitializeEx(nil,COINIT_MULTITHREADED)都保证有一个CoUninitialize
6、CoFreeUnusedLibraries
7、windows提供的线程池函数
8、msxml*.dll在空闲时被卸载
9、程序中使用的各个模块都单独试验过,唯独使用msxml*进行大量操作的模块有内存泄露
10、每个函数体内使用的接口变量使用后都被置为nil
等等其它办法...
现在我怀疑的是WideString和OleVariant变量没有正确释放，哪位大侠在这方面有经验，望不吝赐教！
因为我的总分并不多，考虑如果问题无果，分数会收不回来，所以问题设置分数不多！
到底是不是Memory Leak，我现在也为难！昨天使用Memory Sleuth工具测试了一下，发现是Virtual Memory在不断地变化，并逐渐呈上升趋势！当所有的线程都关闭后，Virtual Memory回落很小，仍然保持很高的内存值。
我走查了代码，真的不知道到底是什么资源没有释放了！？
现在我想了解的是：
1、使用COM组件，在释放资源方面，需要注意哪些事项？
2、对于msxml*，中类似function selectNodes(const queryString: WideString):
IXMLDOMNodeList;这样的函数，我应该使用什么方式调用呢？
1、selectNodes( '/*/bill ');
2、selectNodes(WideString( '/*/bill '));
3、var ws: WideString;ws:= '/*/bill ';selectNodes(ws);
4、WideString类型的变量需要我手动释放内存么？
3、对于msxml*中类似var n: IXMLDOMNode;n.nodeValue或n.nodeName调用后返回的值需要我手动释放么？我直接这样调用可以么？var i: integer;i:= n.nodeValue;或var s: string;s:= n.nodeValue;或var b: boolean;b:= n.nodeValue;
4、如果msxml.dll（或者其它COM组件）已经被卸载，是否它申请的内存还在被占用呢？我观察过，当程序中使用msxml的线程都终止后，msxml4.dll就被卸载了！
等待答案！谢谢！
------解决方案--------------------
费了点时间看完了贴子。
1、友情UP
2、楼主说：因为我的总分并不多，考虑如果问题无果，分数会收不回来，所以问题设置分数不多！
------100分值，应该已经不是一个低分了。现在象楼主这样大方的人不多见了。
3、内存泄露，一般都是对象没有释放引起的。找一下你手工Create之后的对象，有没有Free掉。倒不必怀疑简单类型的变量。
4、内存泄露，如果没有代码，估计很难看出问题具体所在。而整篇贴出代码，又太长......所以建议楼主还是要细心地单步执行一下试试。
5、当然，这只是我的个人拙见。希望楼下的能具体地帮楼主找到问题所在。
------解决方案--------------------
你试着把程序放到windows server 2003或者其它windows server上跑，如果你的程序没问题内存就不会涨了，我以前碰到过一个类似的，是xml自己的GC机制的问题
------解决方案--------------------
对于重复使用的东西，不要总是create和free,使用一个固定的，以免出现异常时没有free掉，或者create的太多
------解决方案--------------------
不必怀疑WIDESTRING,问题应该不在它上面.
先再缩小一点范围,楼主可以日志方式输出DELPHI内存管理器的AllocMemSize变量值,
观察当内存泄漏时,它的大小是如何变化. 这样可以大概推测是DELPHI封装代码的内存泄漏还是MS的东西内存泄漏.
------解决方案--------------------
有可能是内存碎片引起的
------解决方案--------------------
不要在 COM+ 应用程序中配置 MSXML
http://support.microsoft.com/kb/252686/
问题已经困扰我好几个月了，这好几个月，试了无数的办法都不得果！
我说一下情况，
1、一个服务程序，自己使用API实现
2、msxml4
3、interbase
4、COM+
5、多线程
我试过的办法有
1、为msxml*添加NoFullGC注册表值
2、使用FreeThreadedDOMDocument
3、添加OANOCACHE=1环境变量
4、全局接口表
5、每个调用成功的CoInitializeEx(nil,COINIT_MULTITHREADED)都保证有一个CoUninitialize
6、CoFreeUnusedLibraries
7、windows提供的线程池函数
8、msxml*.dll在空闲时被卸载
9、程序中使用的各个模块都单独试验过,唯独使用msxml*进行大量操作的模块有内存泄露
10、每个函数体内使用的接口变量使用后都被置为nil
等等其它办法...
现在我怀疑的是WideString和OleVariant变量没有正确释放，哪位大侠在这方面有经验，望不吝赐教！
因为我的总分并不多，考虑如果问题无果，分数会收不回来，所以问题设置分数不多！
到底是不是Memory Leak，我现在也为难！昨天使用Memory Sleuth工具测试了一下，发现是Virtual Memory在不断地变化，并逐渐呈上升趋势！当所有的线程都关闭后，Virtual Memory回落很小，仍然保持很高的内存值。
我走查了代码，真的不知道到底是什么资源没有释放了！？
现在我想了解的是：
1、使用COM组件，在释放资源方面，需要注意哪些事项？
2、对于msxml*，中类似function selectNodes(const queryString: WideString):
IXMLDOMNodeList;这样的函数，我应该使用什么方式调用呢？
1、selectNodes( '/*/bill ');
2、selectNodes(WideString( '/*/bill '));
3、var ws: WideString;ws:= '/*/bill ';selectNodes(ws);
4、WideString类型的变量需要我手动释放内存么？
3、对于msxml*中类似var n: IXMLDOMNode;n.nodeValue或n.nodeName调用后返回的值需要我手动释放么？我直接这样调用可以么？var i: integer;i:= n.nodeValue;或var s: string;s:= n.nodeValue;或var b: boolean;b:= n.nodeValue;
4、如果msxml.dll（或者其它COM组件）已经被卸载，是否它申请的内存还在被占用呢？我观察过，当程序中使用msxml的线程都终止后，msxml4.dll就被卸载了！
等待答案！谢谢！
------解决方案--------------------
费了点时间看完了贴子。
1、友情UP
2、楼主说：因为我的总分并不多，考虑如果问题无果，分数会收不回来，所以问题设置分数不多！
------100分值，应该已经不是一个低分了。现在象楼主这样大方的人不多见了。
3、内存泄露，一般都是对象没有释放引起的。找一下你手工Create之后的对象，有没有Free掉。倒不必怀疑简单类型的变量。
4、内存泄露，如果没有代码，估计很难看出问题具体所在。而整篇贴出代码，又太长......所以建议楼主还是要细心地单步执行一下试试。
5、当然，这只是我的个人拙见。希望楼下的能具体地帮楼主找到问题所在。
------解决方案--------------------
你试着把程序放到windows server 2003或者其它windows server上跑，如果你的程序没问题内存就不会涨了，我以前碰到过一个类似的，是xml自己的GC机制的问题
------解决方案--------------------
对于重复使用的东西，不要总是create和free,使用一个固定的，以免出现异常时没有free掉，或者create的太多
------解决方案--------------------
不必怀疑WIDESTRING,问题应该不在它上面.
先再缩小一点范围,楼主可以日志方式输出DELPHI内存管理器的AllocMemSize变量值,
观察当内存泄漏时,它的大小是如何变化. 这样可以大概推测是DELPHI封装代码的内存泄漏还是MS的东西内存泄漏.
------解决方案--------------------
有可能是内存碎片引起的
------解决方案--------------------
不要在 COM+ 应用程序中配置 MSXML
http://support.microsoft.com/kb/252686/