@goofect

你想多了:)，變量是什么？

你所說“myGlobalObject只是一個(gè)變量,指向domobj,而自身并不是一個(gè)jsobject.” 沒有錯(cuò)，但是不是“jsobject”不是重點(diǎn)。

重點(diǎn)在于“IE 6處理不了的是JScript與Native Object(例如Dom、ActiveX Object)之間的Circular References”。

關(guān)鍵字是“References引用”：）

你只要考慮一下GC是憑什么來決定是否回收的就可以明白。

最新的2.3版本，不再只使用doc個(gè)數(shù)作為合并segments與否的唯一參數(shù)，
而是允許設(shè)置不同的策略，默認(rèn)的策略也改為了索引信息的數(shù)據(jù)量闕值(bytes)

備忘：這個(gè)類中：
top()返回的是heap[1]的數(shù)值，但不移除，heap[1]永遠(yuǎn)要求是最小的值
pop()會(huì)移出heap[1]的數(shù)值，而后把heap[size]的值移到heap[1]，而后使用downHeap() 把heap[1]下移到適合位置
put(element)是往隊(duì)列尾部heap[size]，也就是buttom追加
insert(element)類似put，區(qū)別在于如果數(shù)組已經(jīng)填滿時(shí)，如果element比top大時(shí)，就把heap[1]的數(shù)值緩存element，再重新排序
upHeap() 表示尾部(buttom)heap[size]追加了一個(gè)數(shù)值，因此，需要把這個(gè)數(shù)up到對(duì)應(yīng)的位置。
downHeap() 表示top,即heap[1]的數(shù)值變化了，把它下移到適合的位置。
adjustTop() 同downHeap()

Luby:
Proc.new & lambda

http://www.hostingforum.ca/208932-proc-vs-lambda-vs-proc.html

補(bǔ)充：
BMP中約定了：
D800-DBFF：High-half zone of UTF-16
DC00-DFFF：Low-half zone of UTF-16

因此UTF-8中約定，D800-DFFF無意義。
當(dāng)然，這兒lucene的實(shí)現(xiàn)是可靠的并且可逆的轉(zhuǎn)換，但它其實(shí)使用2個(gè)UTF-8來表示本應(yīng)該用一個(gè)4 bytes 來表示的UTF-8符，也就是輔助平面的字符


BMP
http://zh.wikipedia.org/w/index.php?title=%E5%9F%BA%E6%9C%AC%E5%A4%9A%E6%96%87%E7%A8%AE%E5%B9%B3%E9%9D%A2&variant=zh-cn

輔助平面
http://zh.wikipedia.org/wiki/%E8%BE%85%E5%8A%A9%E5%B9%B3%E9%9D%A2

從這看出Lucene只支持到了BMP(3 bytes utf-8)，估計(jì)是因?yàn)镴2SE 1.4中的字符處理是基于Unicode 3.0標(biāo)準(zhǔn)的。
目前完整的unicode需要4 bytes utf-8才能實(shí)現(xiàn)。

參考
http://zh.wikipedia.org/wiki/UTF-8
http://m.tkk7.com/tim-wu/archive/2008/01/25/177788.html

另：
Java 1.0 supports Unicode version 1.1.
Java 1.1 onwards supports Unicode version 2.0.
J2SE 1.4中的字符處理是基于Unicode 3.0標(biāo)準(zhǔn)的。
J2SE v 1.5 supports Unicode 4.0 character set.

而：
Unicode 3.0：1999年九月；涵蓋了來自ISO 10646-1的十六位元通用字元集（UCS）基本多文種平面（Basic Multilingual Plane）

Unicode 3.1：2001年三月；新增從ISO 10646-2定義的輔助平面（Supplementary Planes)

修正一下,還有4 bytes的utf-8字符集

http://m.tkk7.com/tim-wu/archive/2007/12/07/165989.html

發(fā)現(xiàn)更好玩的，
SmallFloat.byte52ToFloat()和SmallFloat.byte315ToFloat()
的計(jì)算結(jié)果千差萬別，

汗，難道lucene是只是把它作為一個(gè)可逆的碼表來用？

好在通過這個(gè)熟悉了IEEE 754規(guī)范，不算沒所得:) 呵呵

Display display = textViewer.getTextWidget().getDisplay();
display.asyncExec(new Runnable() {
public void run() {
textViewer.setDocument(new Document(textString));
}

@emu
多謝:) 已修正。

不過向毛主席保證，“溢出”一定不是偶翻譯的，哈哈~~

@THEMAX

SetupLeak() 函數(shù)中
myGlobalObject = document.getElementById( " LeakedDiv " );
則 myGlobalObject有了一個(gè)指向DOM對(duì)象 " LeakedDiv " 的引用，
而后
document.getElementById( " LeakedDiv " ).expandoProperty = myGlobalObject;
使得DOM對(duì)象 " LeakedDiv " 有一個(gè)屬性expandoProperty引用指向myGlobalObject;

這樣myGlobalObject和DOM對(duì)象 " LeakedDiv "分別有引用指向?qū)Ψ剑跃脱h(huán)引用了。


函數(shù)BreakLeak() 則清除了DOM對(duì)象" LeakedDiv " 向myGlobalObject的引用，
解決循環(huán)引用問題。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
如果你問的是第二段代碼，那么就比較復(fù)雜了。

這涉及到Closure的問題，你可以看看文章中給出的其他鏈接文章，例如zkjbeyond對(duì)Closure一文的翻譯。

大致的原因是因?yàn)镃lickEventHandler()是AttachEvents()的一個(gè)內(nèi)嵌函數(shù)，
AttachEvents()函數(shù)執(zhí)行后，把ClickEventHandler()函數(shù)綁定在element對(duì)象的"onclick"事件上。這樣，element對(duì)象就有個(gè)間接引用指向ClickEventHandler()函數(shù)的一個(gè)實(shí)例。
又正是因?yàn)镃lickEventHandler()是一個(gè)內(nèi)嵌函數(shù)，因此會(huì)為這個(gè)實(shí)例構(gòu)造一個(gè)scope，這個(gè)scope中包括了父函數(shù)，也就是AttachEvents()函數(shù)中的局部變量和參數(shù)，而這兒的參數(shù)剛好就是element，所以ClickEventHandler()函數(shù)的實(shí)例同時(shí)又間接引用了element。

說得有些繞.......呵呵

I agree. :) Gis確實(shí)很廣泛，偶沒有做過Gis，只是被一個(gè)項(xiàng)目逼了一下才玩次擦邊球。
zkjbeyond好像是做Gis的吧？有機(jī)會(huì)多交流。