@goofect

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

你所說“myGlobalObject只是一個變量,指向domobj,而自身并不是一個jsobject.” 沒有錯，但是不是“jsobject”不是重點。

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

關鍵字是“References引用”：）

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

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

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

Luby:
Proc.new & lambda

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

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

因此UTF-8中約定，D800-DFFF無意義。
當然，這兒lucene的實現是可靠的并且可逆的轉換，但它其實使用2個UTF-8來表示本應該用一個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)，估計是因為J2SE 1.4中的字符處理是基于Unicode 3.0標準的。
目前完整的unicode需要4 bytes utf-8才能實現。

參考
http://zh.wikipedia.org/wiki/UTF-8
http://www.aygfsteel.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標準的。
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://www.aygfsteel.com/tim-wu/archive/2007/12/07/165989.html

發現更好玩的，
SmallFloat.byte52ToFloat()和SmallFloat.byte315ToFloat()
的計算結果千差萬別，

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

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

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

@emu
多謝:) 已修正。

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

@THEMAX

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

這樣myGlobalObject和DOM對象 " LeakedDiv "分別有引用指向對方，所以就循環引用了。


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

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

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

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

I agree. :) Gis確實很廣泛，偶沒有做過Gis，只是被一個項目逼了一下才玩次擦邊球。
zkjbeyond好像是做Gis的吧？有機會多交流。