Python语言中提供的re模块能支持正则表达式，还提供SGML，XML分析模块，大多数的开发人员运用Python源代码进行XML程序的开发和运行，在这里拿出来和大家分享一下。
有着很多相似点，所以就用这个顺序了，Python的GC章节，我打算更多地着眼于实现和我的疑问，Java的GC章节，更多放在使用上。Python是走多种GC技术路线相结合的路线的，我以为有可取之处。
首先Python采用了原始的Ref Counting技术而对于引用计数解决不了的循环引用，Python源代码也采用了Mark-Sweeping进行GC。这样似乎有两个好处，大量的内存回收。分摊给了引用计数上。
减轻了Mark过程的负担，不会造成程序的停顿，而又可以真正的消除循环引用等造成的真实的内存泄露。PyObject_GC_New将会调用_PyObject_GC_Malloc，其中前者的返回值。
关注的是对象本身，而后者关注的是内存。实际上，在一块刚刚分配的内存上，对象和它锁在的内存有着如下的关系：从对象创建的过程来看，Python有如下几个关键的C实现函数和结构：
- typedef union _gc_head {
- struct {
- union _gc_head *gc_next;
- union _gc_head *gc_prev;
- Py_ssize_t gc_refs;
- } gc;
- long double dummy; /* force worst-case alignment */
- } PyGC_Head;
其实，我本人对这个结构稍有失望，因为要回收一块内存，所占用的资源实在是太多了。可能是我太小家子气了，我觉得8个字节也许刚刚好。老实说，在我心中，已有一个初步的想法，一个对象的管理内存，完全仅仅需要8个字节足够了，而且整个GC的过程，不需要拷贝和压缩。
当我看代码的时候，不知道是我对某些技巧不了解，还是LOCK就没有实现，我感觉Python的malloc和free摆放着一对儿没有用处的LOCK和UNLOCK，【Python 2.5.2】，不知道是不是因为我没有实际调试的缘故，还没有发现这个宏的玄机。
老实说，我跟内存泄露做了好多年的斗争了，这次又从中学到了很多东西(也有从其他的资料)，结合我曾经写过的Ref<T>类中使用的内存池，这次构造了一个全新的内存池，希望可以有用武之地。
注：
【1】我没有考证过最初的Python源代码，但是印象里最初的Python只有引用计数机制，特别是Ruby 1.9才引入垃圾回收，而以往是采用引用计数技术的。
【2】简直是迫使我查看JVM的源代码了，但是到了64位的平台上，这个结构可能发生更大的变化。
【3】等到我完成了代码，才能兑现这段话，到时候我会Open Source的。
【编辑推荐】
