詳細(xì)剖析Python源代碼編制過(guò)程
Python語(yǔ)言中提供的re模塊能支持正則表達(dá)式，還提供SGML，XML分析模塊，大多數(shù)的開(kāi)發(fā)人員運(yùn)用Python源代碼進(jìn)行XML程序的開(kāi)發(fā)和運(yùn)行，在這里拿出來(lái)和大家分享一下。
有著很多相似點(diǎn)，所以就用這個(gè)順序了，Python的GC章節(jié)，我打算更多地著眼于實(shí)現(xiàn)和我的疑問(wèn)，Java的GC章節(jié)，更多放在使用上。Python是走多種GC技術(shù)路線相結(jié)合的路線的，我以為有可取之處。
首先Python采用了原始的Ref Counting技術(shù)而對(duì)于引用計(jì)數(shù)解決不了的循環(huán)引用，Python源代碼也采用了Mark-Sweeping進(jìn)行GC。這樣似乎有兩個(gè)好處，大量的內(nèi)存回收。分?jǐn)偨o了引用計(jì)數(shù)上。
減輕了Mark過(guò)程的負(fù)擔(dān)，不會(huì)造成程序的停頓，而又可以真正的消除循環(huán)引用等造成的真實(shí)的內(nèi)存泄露。PyObject_GC_New將會(huì)調(diào)用_PyObject_GC_Malloc，其中前者的返回值。
關(guān)注的是對(duì)象本身，而后者關(guān)注的是內(nèi)存。實(shí)際上，在一塊剛剛分配的內(nèi)存上，對(duì)象和它鎖在的內(nèi)存有著如下的關(guān)系：從對(duì)象創(chuàng)建的過(guò)程來(lái)看，Python有如下幾個(gè)關(guān)鍵的C實(shí)現(xiàn)函數(shù)和結(jié)構(gòu)：
- 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;
其實(shí)，我本人對(duì)這個(gè)結(jié)構(gòu)稍有失望，因?yàn)橐厥找粔K內(nèi)存，所占用的資源實(shí)在是太多了?？赡苁俏姨〖易託饬?，我覺(jué)得8個(gè)字節(jié)也許剛剛好。老實(shí)說(shuō)，在我心中，已有一個(gè)初步的想法，一個(gè)對(duì)象的管理內(nèi)存，完全僅僅需要8個(gè)字節(jié)足夠了，而且整個(gè)GC的過(guò)程，不需要拷貝和壓縮。
當(dāng)我看代碼的時(shí)候，不知道是我對(duì)某些技巧不了解，還是LOCK就沒(méi)有實(shí)現(xiàn)，我感覺(jué)Python的malloc和free擺放著一對(duì)兒沒(méi)有用處的LOCK和UNLOCK，【Python 2.5.2】，不知道是不是因?yàn)槲覜](méi)有實(shí)際調(diào)試的緣故，還沒(méi)有發(fā)現(xiàn)這個(gè)宏的玄機(jī)。
老實(shí)說(shuō)，我跟內(nèi)存泄露做了好多年的斗爭(zhēng)了，這次又從中學(xué)到了很多東西(也有從其他的資料)，結(jié)合我曾經(jīng)寫過(guò)的Ref<T>類中使用的內(nèi)存池，這次構(gòu)造了一個(gè)全新的內(nèi)存池，希望可以有用武之地。
注：
【1】我沒(méi)有考證過(guò)最初的Python源代碼，但是印象里最初的Python只有引用計(jì)數(shù)機(jī)制，特別是Ruby 1.9才引入垃圾回收，而以往是采用引用計(jì)數(shù)技術(shù)的。
【2】簡(jiǎn)直是迫使我查看JVM的源代碼了，但是到了64位的平臺(tái)上，這個(gè)結(jié)構(gòu)可能發(fā)生更大的變化。
【3】等到我完成了代碼，才能兌現(xiàn)這段話，到時(shí)候我會(huì)Open Source的。
【編輯推薦】
