写出本文仅仅是处于备忘的目的。
最近为现在做的软件添加了一个内存回收机制（以前处于某种内存只申请不释放，这并不等于内存泄露，因为我们知道这些内存块在内存中的位置）-- 某一个块内存在不使用的时候将其释放掉，以防止内存缓慢增长。
由于以前没有释放内存，所以就不存在野指针的问题。于是乎肯定坑爹的事情就从内存释放开始了 。。。 /大哭
只从添加了内存释放机制之后软件就出现了各种崩溃 。。。
好了，闲话少说，直奔主题。
一个内存块很多地方引用，一旦一个地方释放内存，而且其他地方还在引用，那后果就 。。。
1.
当时我就想这个问题很简单啊，典型的野指针问题嘛 。。。
于是就给内存块的指针加了个引用计数（引用一次引用计数就加一次（原子操作）），释放内存块时并不是真的释放而是把引用计数减一（原子操作），当引用计数减到0时才会把内存给释放掉 。。。
说道这个各位看客一定以为这个问题就圆满解决了 。 其实 。。。 坑爹的事还没完 才 真正的刚刚开始 。。。 /大哭/大哭/大哭
加了引用计数之后，程序稳定比以前好多了，但是基本上每个1个小时就会崩溃一次 。。。
于是开始各种查找问题 。。。
后来发现问题还是出在资源释放的问题上，请看如下代码：
int Release()
{
InterlockedDecrement(&m_nRefCount);
if (m_nRefCount <= 0)
{ delete this;
} else{ //do something ... }
return(m_nRefCount);
}
InterlockedDecrement的确是原子操作，但是后面的语句却不是，当多线程存在的时候可能 InterlockedDerement 会被执行两次 之后 第一个 的if 语句才会执行（如果想不明白就好好想，哈哈），这样的问题就是会导致 改内存块被释放两次 。。。
2.
吃一堑长一智 。。。 后来代码改成了这个样子
HRESULT Release()
{
int refCount = InterlockedDecrement(&m_nRefCount);
if (refCount <= 0)
{ delete this;
} else{ //do something ... }
return(m_nRefCount);
}
这样调用InterlockedDerement之后得到的引用计数就不会受影响了 。。。 至少不会重复delete 自己吧 。。。
3.
这样修改之后软件的确更加稳定啦，运行5-6个小时没问题 。。。 但是 。。。 5-6个小时之后 ，软件依然崩溃，依然崩溃，依然崩溃 。。。
为什么呢？当时也是各种想不通 。。。 后来经过苦思冥想和各种极端调试手段终于发现了问题：
请看我增加引用的方法：
ULONG AddRef( void )
{
return InterlockedIncrement(&m_nRefCount) ;}
原来我对内存的引用并不是先引用而后释放，而是 引用和释放穿插使用的，由于是多线程，同时增加引用和资源释放并不是互斥执行的，有可能会同时执行，同时执行，同时执行 。。。
当同时执行的时候就会有极小的概率导致引用计数减为0，到delete语句被执行的间隙，存在一次引用计数加一的动作 ，这样内存块看似没有被释放（引用计数为1）其实已经释放了，这样就产生了野指针，产生了野指针，产生了野指针！！！
找到了问题，却不好解决 。。。 因为不能再release和addref里面添加锁，因为使用它的地方太多了，影响效率不说 还可能会导致死锁。
后来只能在可能会出现这种状况的地方添加锁，还好能够产生这种状况的地方不多。
后来问题圆满解决 。。。