内存泄漏问题可能的原因是什么?
我为数据库构建了一个包装 DLL,它为我的数据库提供了一个对象 API 层。我遇到的问题是,当我销毁对象时,VB.net 中的垃圾收集器似乎没有清理混乱的情况。我相对确定我已经完成了清理对象的所有操作,包括在每个对象上实现 IDispose 接口以销毁所有内容。
事情变得丑陋的是,当我实例化对象时,我会读取数据库并根据数据库中的相应条目填充对象。这很有效,但是,当我迭代创建和销毁 1000 个和 1000 个这些对象时,内存会不断增加。
然后我想到:我的对象是否不会清理,是因为我在对象内使用共享 ODBC 数据库引用吗?尽管我尽了最大努力,这会让我的物体保持活力吗?
例如:(注意: clsSharedConfig.g_objDatabaseConn 是一个共享的 ODBCConnection 实例)
Dim cmd As New OdbcCommand("SELECT * FROM FILES WHERE CID = " & p_lngID, clsSharedConfig.g_objDatabaseConn)
Dim data As OdbcDataReader
Try
cmd.CommandType = CommandType.Text
data = cmd.ExecuteReader()
任何人都可以提供我发生这种情况的任何其他原因吗?我不想在任何地方都使用 GC.Collect 语句来控制这种情况!
谢谢,
安德鲁
I have built a wrapper DLL for a database that gives me an object API layer for my database. Where I am having issues is that the Garbage Collector in VB.net doesn't seem to be cleaning up the mess when I destroy the objects. I am relatively certain that I have done everything to clean up the object, including implementing the IDispose interface on every object to destroy everything.
Where things get ugly is when I instantiate the object, I do a database read and populate the object based on it's corresponding entry in the database. This works well, however, when I iterate through the creation and destruction of 1000's and 1000's of these objects, the memory just keeps ramping up.
Then it occurred to me: Could it be that my objects won't clean up because I am using a shared ODBC database reference inside my objects? would that keep my objects alive despite my best efforts?
For example: (note: clsSharedConfig.g_objDatabaseConn is a shared ODBCConnection instance)
Dim cmd As New OdbcCommand("SELECT * FROM FILES WHERE CID = " & p_lngID, clsSharedConfig.g_objDatabaseConn)
Dim data As OdbcDataReader
Try
cmd.CommandType = CommandType.Text
data = cmd.ExecuteReader()
Can anyone offer any other reason I am having this happen? I don't want to have to resort to shoving GC.Collect statments in everywhere to keep this under control!
Thanks,
Andrew
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
您必须关闭阅读器才能释放资源。参见下文
还要检查您的对象何时从阅读器加载,您也可以在那里保留引用。
使用内存分析器可以更好地追踪内存泄漏,例如 Ants 内存分析器< /a>
You have to close the reader to free up resources. See below
Also check when your objects are loaded from reader, you maybe keeping a reference there as well.
Memory leaks are better chased by using memory profiler like Ants memory profiler
您是否尝试过每次都实例化一个新的连接对象? .net 框架将在后台处理实际的连接池,因此我不确定尝试共享该对象对您有多大帮助。
Have you tried just instantiating a new connection object each time? the .net framework will handle the actuall connection pooling under the hood, so I'm not sure that trying to share that object helps you alot anyhow.
所以,我尝试了你的建议(谢谢顺便说一句!),但是唉,没有改变......
然后,只是为了一个幼虫,我在我的 DLL 的应用程序设置中查找。我注意到由于某些愚蠢/未知的原因,我打开了 COM 兼容性。
因此,我取消了这一点,前提是我不需要 COM 兼容性,而这只会让寻找解决方案的过程变得更加混乱。一旦我这样做了,我重新运行它,内存泄漏就消失了!
严重地?那是IT?我需要有人慢慢地向我解释这个问题,也许可以使用布偶。
内存分析器确认我的泄漏发生在非托管内存中。
已经两天了,我还没有回来……
安德鲁
So, I tried your suggestions (thanks BTW!), but alas, no change...
Then, just for a larf, I was looking around in the application settings for my DLL. I noticed that for some dumb/unknown reason, I had COM compatibility turned on.
So, I unchecked that, on the premise that I didn't NEED COM compatibility and that was just muddying the waters in finding a solution. As soon as I did, and I re-ran it, The memory leak was GONE!
Seriously? that was IT? I need someone to 'splain that one to me slowly, perhaps using hand puppets.
A memory profiler confirmed that my leak was in unmanaged memory.
that's 2 days Im not getting back...
Andrew