哈希表存储桶内存泄漏 [英] Hashtable bucket Memory Leak

问题描述

我正在寻找应用程序中的内存泄漏.
我有一个哈希表，其中包含类型为List< IMxCallBack>的元素. (其中IMxCallBack是本机接口).我发现哈希表的每个列表元素中的IMxCallback对象都没有被处置.我成功地处置了它们，并发现从我的应用程序采取的泄漏转储中也将其从堆中删除. /> 但是，但是我发现堆上仍然有Hashtable对象，堆上也有相同数量的Hashtable + bucket []对象.但是我也已经在处理过程中处理了哈希表.
每次在我的窗口上单击都会创建一个aaCalConnection obj(切换到另一个窗口)，每单击3秒钟就会处理一次现有的aaCalConnection obj，因此也会创建哈希表，然后又创建了一个新的aaCalConnection对象，该对象又创建了一个新的Hashtable.请在下面找到代码

Hi,
I am working on finding memory leaks in my application.
I have a hashtable which has elements of type List<IMxCallBack> (where IMxCallBack is native interface).I found that the IMxCallback objects in each list element of hashtable are not disposed.I successfully disposed them and found that there are removed from the heap as well in the leak Dump taken on my application.
But however I found that there are Hashtable objects still on the heap, also the same number of Hashtable+bucket[] objects on heap.But I have disposed the hashtable in dispose as well.
An aaCalConnection obj is created for every click on my window(which switches to another window).Upon click for every 3 seconds the existing aaCalConnection obj is disposed and hence the hashtable as well.And again a new aaCalConnection object is created which inturn creates a new Hashtable.Please find the code below

public aaCalConnection(CONNECTIONTYPE ConnType, string Node, string Application, string Topic, aaDataSubscriptionManager Callback, bool isLocalConnection, aaAccessName accessname, aaCalConnectionManager CalMgr)
        {
            -------------
            ------------
            m_CalbackCache = new Hashtable();
}

void AddCallbackToCache(int datasourceId, IMxCallback callback)
		{
			//Add this callback to the queue of pending writes
			List<IMxCallback> callbackList = m_CalbackCache[datasourceId] as List<IMxCallback>;
			if (callbackList == null)
			{
				callbackList = new List<IMxCallback>();
				m_CalbackCache[datasourceId] = callbackList;
			}
			if (callbackList != null)
			{
				callbackList.Add(callback);
			}
		}

public void RemoveCallbackFromCache(int datasourceId, IMxCallback callback) 
		{
			//Remove this callback from the queue of pending writes
			List<IMxCallback> callbackList = m_CalbackCache[datasourceId] as List<IMxCallback>;
			if (callbackList != null)
			{
				callbackList.Remove(callback);
        		        if (callbackList.Count == 0)
	                	    m_CalbackCache[datasourceId] = null;
		                callbackList = null;
			}
		}

public virtual void Dispose()
        {
			---------------
			----------
			m_CalbackCache.Clear();
			m_CalbackCache = null; 
         }
// Disposing the IMxCallback object which is a userconnection callback object from another class
m_CalConnection.RemoveCallbackFromCache(callback.DataSourceID, callback);
Callback.Dispose();

现在即使清理工作已正确完成，我仍然可以看到哈希表和哈希表存储桶上的对象正在占用内存.谁能告诉我为什么它们没有被垃圾收集.我应该如何解决此泄漏?

谢谢
Satya

Now eventhough the cleanoffs are properly done I could see hashtable and HashTable buckets objects on Heap occupying memory.Can anyone tell me why they are not Garbage collected.How should i go about resolving this leak?

Thanks
Satya

推荐答案

由于您使用的是本机接口，因此您可能需要清理非托管资源.请查看此链接以获取更多信息:
http://msdn.microsoft.com/en-us/library/b1yfkh5e.aspx [ ^ ]

祝您好运！

Because you are using a native interface, you probably have unmanaged resources that need to be cleaned up. Have a look at this link for more info:
http://msdn.microsoft.com/en-us/library/b1yfkh5e.aspx[^]

Good luck!

在您坚持要处置所有一次性物品的地方，我已经看到了您的评论.
记录一下:我确信使用纯CLI可以很好地实现基于存储桶的哈希，而无需任何非托管代码.

现在，还有什么?

您可以在纯托管代码中生成内存泄漏.您的库中是否有任何静态的东西，甚至即使您测试应用程序也是如此?

如果没有，请考虑使用寿命长的任何东西.您可以简单地累积一些引用和此类对象，而从不释放它们. GC需要完全丢失对行为的引用.
请记住，托管代码内存泄漏很有可能发生.定义什么是泄漏并不是一件容易的事.基本上，您只需要执行一些循环并返回到某个状态，该状态在功能上与先前的状态等效即可，但是消耗的内存要比第一次更多.这不是很明显，因为GC可能会将回收内存推迟到更方便的稍后时间.要进行更清晰的实验，可以使用System.GC强制使用System.GC.Collect在某些检查点进行垃圾收集，请参阅 http://msdn.microsoft.com/en- us/library/system.weakreference.aspx [ ^ ].

—SA

I already saw your comment where you insist that you dispose all disposable objects.
For a record: I''m sure the bucket-based hash can be well implemented using pure CLI, with no unmanaged code.

Now, what else?

You can generate a memory leak in pure managed code. Do you have anything static in your library or even if you test application?

If not, look at anything with long life time. You can simply accumulate some references and such object and never release them. GC need totally lost references to act.
Remember, managed code memory leaks are quite possible. It''s not so trivial to defined what''s a leak. Basically, it only makes sense you do some cycles and come back to some state which is functionally equivalent to the previous state, but the consumed memory is more then in the first time. This is not so apparent because GC may defer reclaiming memory until more convenient later moment of time. For more clear experiment you can use System.GC to force garbage collection at some check points using System.GC.Collect, see http://msdn.microsoft.com/en-us/library/system.gc.aspx[^].

Also, you can consider using weak references, http://msdn.microsoft.com/en-us/library/system.weakreference.aspx[^].

—SA

这篇关于哈希表存储桶内存泄漏的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！