詳細剖析Python源代碼編制過程
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的。
【編輯推薦】
