解读Java语言灵巧指针与垃圾回收

在JAVA 和 C# 中都有垃圾回收功能，程序员在分配一段内存后可以不再理会，而由垃圾回收自动回收，从而使程序员从复杂的内存管理中解脱出来。这是JAVA 和 C#的一大优点。而C++程序员在用 new 分配了一段内存后，还必须用 delete 释放，否则将造成资源泄漏。因此，一些C++ 书上经常告诫程序员：要养成好的习惯，new 与 delete 要成对出现，时刻记住将内存释放回系统。但是，事情只是这么简单吗？
    经常地，在使用C++的过程中，我们会遇到下面的情形：

    这样会出问题,因为这些指针连成了一个回环,无论从那一个点开始删除,都会造成一个指针被删除两次以上,这将使得程序抛出异常。当然，也有一些方法可以用来解决这个问题，但是我要说明的是：对于C++程序员来说，养成一个好的习惯并不难，难就难在有时候这样将把你带入一种逻辑的混乱当中 ，增加一些不必要的麻烦，有时甚至不知所措。
    可是如何解决这个问题呢？如果C++也具有垃圾回收的功能，那么，这个问题当然就迎刃而解了。但是C++属于编译型语言，不会具备这个功能。长期以来，我也一直在思考这个问题，想找出一种方法来使自己从这种麻烦中解脱出来。直到最近开始学习泛型编程，看到灵巧指针的介绍以后，我灵光一闪，终于找到了办法来解决这个问题。
    大家知道，灵巧指针具有一些灵巧特性，如在构造时可以自动初始化，析构时可以自动释放所指的指针。我们就利用它的这些特性来实现我们的垃圾回收。
    首先，我们要想办法来对我们用 new 分配的每一段内存增加引用记数，即记录下当前指向它的灵巧指针个数，当最后一个指向它的指针被释放时，我们就可以释放这段内存了。由此，我们进行了new 和 delete 的全局重载，并引入了CPtrManager 类。

    顾名思义，CPtrManager 就是用来管理指针的，对于我们用new 分配的每一个指针，都存放在m_ptr[index]中，并在m_count[index]中存放它的引用记数。同时，我们对每一个指针都增加了一个标志（mark >0,<=0为无效），这个标志同时存在于灵巧指针中（后面将看到），这是为了一种双重保险，并且在这里，这个标志就等于指针在m_ptr中的索引，这也为快速查找提供了方便。
    总的思路是这样的：当我们用new分配一个指针时，这个指针将被存入CPtrManager中，当一个灵巧指针开始拥有这个指针时，CPtrManager将负责对这个指针的引用记数加 1 ，反之亦然，即一个灵巧指针开始释放该指针的拥有权时，CPtrManager将负责对这个指针的引用记数减 1 ，如果引用记数为 0 ，那么这个灵巧指针将负责对该指针 delete。
    下面是灵巧指针的部分介绍：

   当到了这里时，我便以为大功告成，忍不住摸拳搽掌，很想试一试。结果发现对于一般的情况，效果确实不错，达到了垃圾回收的效果。如下面的应用：
    auto_ptr p1=new  test;
       auto_ptrp2 = p1;
       auto_ptrp3 = new test;
    但是，很快地，我在测试前面提到的回环时，就发现了问题，我是这样测试的：

      当程序执行离开作用域后，这两块内存并没有象我想象的那样被释放，而是一直保留在堆中，直到程序结束。我仔细分析造成这种现象的原因，发现了一个非常有趣的问题，我把它称之为互锁现象。
   上面p1 所拥有的指针被两个灵巧指针所拥有，除p1外，还有p2所拥有的 test 类中的灵巧指针p，p2亦然。也就是说，这两块内存的指针的引用记数都为 2 。当程序执行离开作用域后，p1，p2被析构，使它们的引用记数都为1，此后再没有灵巧指针被析构而使它们的引用记数变为 0 ，因此它们将长期保留在堆中。这就象两个被锁住的箱子，其中每个箱子中都装着对方的钥匙，但却无法把彼此打开，这就是互锁现象。
      可是如何解决呢？看来必须对它进行改进。同时，我也发现上面的方法不支持多线程。所以，我们改进后的方法不仅要解决互锁现象，而且还要支持多线程。下面是我改进后的方法：
   首先是如何发现这种互锁现象。我们知道，互锁现象产生的根源在于拥有堆中内存的灵巧指针本身也存在于已分配的堆内存中，那么，如何发现灵巧指针是存在于堆中还是栈中就成了问题的关键。由此，我引入了一个新的类 CPtr，由它来管理用 new 分配的指针，而 CPtrManager 专门用来管理 CPtr。如下所示：

   上面的应用中加入了灵巧指针的标志，其实，这个标志就等于该灵巧指针所存在的内存的指针的标志。例如：我们用 new 分配了一个 test 指针，假如这个指针的标志 mark=1，那么，这个 test 中的灵巧指针 auto_ptr p 的标志 automark=1。如果一个灵巧指针存在于栈中，那么它的 automark=0。反之亦然，如果一个灵巧指针的 automark 等于一个指针的 mark，那么，该灵巧指针必存在于这个指针所指的内存中。可是，如何得到这个标志呢，请看下面这个函数的实现：

    这个函数的原理就在于：如果一个灵巧指针存在于一块内存中，那么该灵巧指针的指针必在这块内存的首尾指针之间。
    解决了灵巧指针的位置问题，下一步就是要找出所有被互锁的内存的指针。这个好实现，只要所有拥有这个指针的灵巧指针的 automark > 0 ，那么，这块内存就可能被互锁了(注意只是可能)，接着看下面的实现：

   这里又引入了两个类：CMark 和 CMarkTable ，这是为了在处理互锁问题之前，对 CPtrManager 中的 CPtr 进行快速拷贝，以防止影响其它线程的正常运行。其实，这里的 CMark 与 CPtr 没有什么区别，它只是简单地从 CPtr 中拷贝信息，也就是说，它等同于 CPtr 。
   为了处理互锁问题，先要把可能被互锁的内存指针找出来，看下面函数的实现：

   把这些内存找出来之后，就需要把那些假锁的内存找出来，什么是假锁呢？看下面的例子：
   对于指针 ptrA ，如果它的灵巧指针 autoA 存在于指针 ptrB 中，而 ptrB 的灵巧指针 autoB 又存在于 ptrA 中，那么 ptrA 和 ptrB 是真锁，但是如果ptrB 的灵巧指针 autoB 存在于指针 ptrC 中，而 ptrC的灵巧指针 autoC 存在于栈中，那么， ptrA 和 ptrB 属于假锁。怎么找出假锁的内存呢？看下面函数的实现：

    上面函数的原理就是：不停地删除那些灵巧指针不在CLockMarkArray所包含的指针中的指针，直到所有的指针的灵巧指针都存在于CLockMarkArray所包含的指针中。
    所有被互锁的内存被找出来了，那么，下一步就是如何解锁的问题了。由此，我对灵巧指针引入了一个父类parent_autoptr 如下：

    在灵巧指针中，对函数 Release() 进行了重载。

    在 CMarkTable 和 CMark 中对互锁内存进行了释放，如下：

       到了现在，终于算是大功告成了，我马上把它投入测试当中，发现工作得非常好，即使开辟20至30个线程，程序也工作得很好，并没有抛出异常，而且垃圾回收的功能也非常好。但是，如果线程太多，那么在 CPtrManager 中为了保证线程同步，将会造成瓶颈效应，严重者将会严重影响执行效率。同时，如果每个线程都不停地产生死锁内存，那么，垃圾回收将应接不暇，时间长了，也会造成系统的资源耗尽。

    代码的使用很简单，你只需要将我所附的两个文件加入到工程中，然后，在你的 C*App 中加入如下一段代码就行了：

     CPtrManager thePtrManager;

    这将保证 thePtrManager 在进程最后结束的时候才被析构。

    如果你是在一个新的工程中使用，这就够了，但是，如果你还要使用原来的代码，特别是有指针参数的传递时，那么，你必须注意了。

    如果需要从老代码中接收一个指针，而且这个指针需要你自己释放，那么可以使用灵巧指针，如果不需要释放，那么只能使用一般指针；
    如果需要传递一个指针给老代码，而且这个指针需要你自己释放，那么可以使用灵巧指针，否则，只能使用一般指针。