lsbwahaha

1. sudo -s
2. cd /System/Library/Frameworks/JavaVM.framework/Home
3. ln -s /Library/Java/JavaVirtualMachines/1.6.0_35-b10-428.jdk/Contents/Home/docs.jar
4. ln -s  /Library/Java/JavaVirtualMachines/1.6.0_35-b10-428.jdk/Contents/Home/src.jar
5. 最后跟windows類似，在eclipse中用command + click點擊查看一個類的源碼。然后選“add source"，選中上面的 src.jar 文件即可

地理位置索引支持是MongoDB的一大亮點，這也是全球最流行的LBS服務foursquare 選擇MongoDB的原因之一。我們知道，通常的數據庫索引結構是B+ Tree，如何將地理位置轉化為可建立B+Tree的形式，下文將為你描述。

首先假設我們將需要索引的整個地圖分成16×16的方格，如下圖（左下角為坐標0,0 右上角為坐標16,16）：

單純的［x，y］的數據是無法建立索引的，所以MongoDB在建立索引的時候，會根據相應字段的坐標計算一個可以用來做索引的hash值，這個值叫做geohash，下面我們以地圖上坐標為［4，6］的點（圖中紅叉位置）為例。

我們第一步將整個地圖分成等大小的四塊，如下圖：

劃分成四塊后我們可以定義這四塊的值，如下（左下為00，左上為01，右下為10，右上為11）：

01	11
00	10

這樣［4，6］點的geohash值目前為 00

然后再將四個小塊每一塊進行切割，如下：

這時［4，6］點位于右上區域，右上的值為11，這樣［4，6］點的geohash值變為：0011

繼續往下做兩次切分：

最終得到［4，6］點的geohash值為：00110100

這樣我們用這個值來做索引，則地圖上點相近的點就可以轉化成有相同前綴的geohash值了。

我們可以看到，這個geohash值的精確度是與劃分地圖的次數成正比的，上例對地圖劃分了四次。而MongoDB默認是進行26次劃分，這個值在建立索引時是可控的。具體建立二維地理位置索引的命令如下：

db.map.ensureIndex({point : "2d"}, {min : 0, max : 16, bits : 4})

其中的bits參數就是劃分幾次，默認為26次。

單例創建模式是一個通用的編程習語。和多線程一起使用時，必需使用某種類型的同步。在努力創建更有效的代碼時，Java 程序員們創建了雙重檢查鎖定習語，將其和單例創建模式一起使用，從而限制同步代碼量。然而，由于一些不太常見的 Java 內存模型細節的原因，并不能保證這個雙重檢查鎖定習語有效。它偶爾會失敗，而不是總失敗。此外，它失敗的原因并不明顯，還包含 Java 內存模型的一些隱秘細節。這些事實將導致代碼失敗，原因是雙重檢查鎖定難于跟蹤。在本文余下的部分里，我們將詳細介紹雙重檢查鎖定習語，從而理解它在何處失效。

單例創建習語

要理解雙重檢查鎖定習語是從哪里起源的，就必須理解通用單例創建習語，如清單 1 中的闡釋：

                        import java.util.*;
            class Singleton
            {
            private static Singleton instance;
            private Vector v;
            private boolean inUse;
            private Singleton()
            {
            v = new Vector();
            v.addElement(new Object());
            inUse = true;
            }
            public static Singleton getInstance()
            {
            if (instance == null)          //1
            instance = new Singleton();  //2
            return instance;               //3
            }
            }
            

此類的設計確保只創建一個 Singleton 對象。構造函數被聲明為 private，getInstance() 方法只創建一個對象。這個實現適合于單線程程序。然而，當引入多線程時，就必須通過同步來保護 getInstance() 方法。如果不保護 getInstance() 方法，則可能返回 Singleton 對象的兩個不同的實例。假設兩個線程并發調用 getInstance() 方法并且按以下順序執行調用：

1. 線程 1 調用 getInstance() 方法并決定 instance 在 //1 處為 null。
   
   
2. 線程 1 進入 if 代碼塊，但在執行 //2 處的代碼行時被線程 2 預占。
   
   
3. 線程 2 調用 getInstance() 方法并在 //1 處決定 instance 為 null。
   
   
4. 線程 2 進入 if 代碼塊并創建一個新的 Singleton 對象并在 //2 處將變量 instance 分配給這個新對象。
   
   
5. 線程 2 在 //3 處返回 Singleton 對象引用。
   
   
6. 線程 2 被線程 1 預占。
   
   
7. 線程 1 在它停止的地方啟動，并執行 //2 代碼行，這導致創建另一個 Singleton 對象。
   
   
8. 線程 1 在 //3 處返回這個對象。

結果是 getInstance() 方法創建了兩個 Singleton 對象，而它本該只創建一個對象。通過同步 getInstance() 方法從而在同一時間只允許一個線程執行代碼，這個問題得以改正，如清單 2 所示：

                        public static synchronized Singleton getInstance()
            {
            if (instance == null)          //1
            instance = new Singleton();  //2
            return instance;               //3
            }
            

清單 2 中的代碼針對多線程訪問 getInstance() 方法運行得很好。然而，當分析這段代碼時，您會意識到只有在第一次調用方法時才需要同步。由于只有第一次調用執行了 //2 處的代碼，而只有此行代碼需要同步，因此就無需對后續調用使用同步。所有其他調用用于決定 instance 是非 null 的，并將其返回。多線程能夠安全并發地執行除第一次調用外的所有調用。盡管如此，由于該方法是 synchronized 的，需要為該方法的每一次調用付出同步的代價，即使只有第一次調用需要同步。

為使此方法更為有效，一個被稱為雙重檢查鎖定的習語就應運而生了。這個想法是為了避免對除第一次調用外的所有調用都實行同步的昂貴代價。同步的代價在不同的 JVM 間是不同的。在早期，代價相當高。隨著更高級的 JVM 的出現，同步的代價降低了，但出入 synchronized 方法或塊仍然有性能損失。不考慮 JVM 技術的進步，程序員們絕不想不必要地浪費處理時間。

因為只有清單 2 中的 //2 行需要同步，我們可以只將其包裝到一個同步塊中，如清單 3 所示：

                        public static Singleton getInstance()
            {
            if (instance == null)
            {
            synchronized(Singleton.class) {
            instance = new Singleton();
            }
            }
            return instance;
            }
            

清單 3 中的代碼展示了用多線程加以說明的和清單 1 相同的問題。當 instance 為 null 時，兩個線程可以并發地進入 if 語句內部。然后，一個線程進入 synchronized 塊來初始化 instance，而另一個線程則被阻斷。當第一個線程退出 synchronized 塊時，等待著的線程進入并創建另一個 Singleton 對象。注意：當第二個線程進入 synchronized 塊時，它并沒有檢查 instance 是否非 null。

雙重檢查鎖定

為處理清單 3 中的問題，我們需要對 instance 進行第二次檢查。這就是“雙重檢查鎖定”名稱的由來。將雙重檢查鎖定習語應用到清單 3 的結果就是清單 4 。

                        public static Singleton getInstance()
            {
            if (instance == null)
            {
            synchronized(Singleton.class) {  //1
            if (instance == null)          //2
            instance = new Singleton();  //3
            }
            }
            return instance;
            }
            

雙重檢查鎖定背后的理論是：在 //2 處的第二次檢查使（如清單 3 中那樣）創建兩個不同的 Singleton 對象成為不可能。假設有下列事件序列：

1. 線程 1 進入 getInstance() 方法。
   
   
2. 由于 instance 為 null，線程 1 在 //1 處進入 synchronized 塊。
   
   
3. 線程 1 被線程 2 預占。
   
   
4. 線程 2 進入 getInstance() 方法。
   
   
5. 由于 instance 仍舊為 null，線程 2 試圖獲取 //1 處的鎖。然而，由于線程 1 持有該鎖，線程 2 在 //1 處阻塞。
   
   
6. 線程 2 被線程 1 預占。
   
   
7. 線程 1 執行，由于在 //2 處實例仍舊為 null，線程 1 還創建一個 Singleton 對象并將其引用賦值給 instance。
   
   
8. 線程 1 退出 synchronized 塊并從 getInstance() 方法返回實例。
   
   
9. 線程 1 被線程 2 預占。
   
   
10. 線程 2 獲取 //1 處的鎖并檢查 instance 是否為 null。
    
    
11. 由于 instance 是非 null 的，并沒有創建第二個 Singleton 對象，由線程 1 創建的對象被返回。

雙重檢查鎖定背后的理論是完美的。不幸地是，現實完全不同。雙重檢查鎖定的問題是：并不能保證它會在單處理器或多處理器計算機上順利運行。

雙重檢查鎖定失敗的問題并不歸咎于 JVM 中的實現 bug，而是歸咎于 Java 平臺內存模型。內存模型允許所謂的“無序寫入”，這也是這些習語失敗的一個主要原因。

無序寫入

為解釋該問題，需要重新考察上述清單 4 中的 //3 行。此行代碼創建了一個 Singleton 對象并初始化變量 instance 來引用此對象。這行代碼的問題是：在 Singleton 構造函數體執行之前，變量 instance 可能成為非 null 的。

什么？這一說法可能讓您始料未及，但事實確實如此。在解釋這個現象如何發生前，請先暫時接受這一事實，我們先來考察一下雙重檢查鎖定是如何被破壞的。假設清單 4 中代碼執行以下事件序列：

1. 線程 1 進入 getInstance() 方法。
   
   
2. 由于 instance 為 null，線程 1 在 //1 處進入 synchronized 塊。
   
   
3. 線程 1 前進到 //3 處，但在構造函數執行之前，使實例成為非 null。
   
   
4. 線程 1 被線程 2 預占。
   
   
5. 線程 2 檢查實例是否為 null。因為實例不為 null，線程 2 將 instance 引用返回給一個構造完整但部分初始化了的 Singleton 對象。
   
   
6. 線程 2 被線程 1 預占。
   
   
7. 線程 1 通過運行 Singleton 對象的構造函數并將引用返回給它，來完成對該對象的初始化。

此事件序列發生在線程 2 返回一個尚未執行構造函數的對象的時候。

為展示此事件的發生情況，假設為代碼行 instance =new Singleton(); 執行了下列偽代碼： instance =new Singleton();

mem = allocate();             //Allocate memory for Singleton object.
            instance = mem;               //Note that instance is now non-null, but
            //has not been initialized.
            ctorSingleton(instance);      //Invoke constructor for Singleton passing
            //instance.
            

這段偽代碼不僅是可能的，而且是一些 JIT 編譯器上真實發生的。執行的順序是顛倒的，但鑒于當前的內存模型，這也是允許發生的。JIT 編譯器的這一行為使雙重檢查鎖定的問題只不過是一次學術實踐而已。

為說明這一情況，假設有清單 5 中的代碼。它包含一個剝離版的 getInstance() 方法。我已經刪除了“雙重檢查性”以簡化我們對生成的匯編代碼（清單 6）的回顧。我們只關心 JIT 編譯器如何編譯 instance=new Singleton(); 代碼。此外，我提供了一個簡單的構造函數來明確說明匯編代碼中該構造函數的運行情況。

                        class Singleton
            {
            private static Singleton instance;
            private boolean inUse;
            private int val;
            private Singleton()
            {
            inUse = true;
            val = 5;
            }
            public static Singleton getInstance()
            {
            if (instance == null)
            instance = new Singleton();
            return instance;
            }
            }
            

清單 6 包含由 Sun JDK 1.2.1 JIT 編譯器為清單 5 中的 getInstance() 方法體生成的匯編代碼。

                        ;asm code generated for getInstance
            054D20B0   mov         eax,[049388C8]      ;load instance ref
            054D20B5   test        eax,eax             ;test for null
            054D20B7   jne         054D20D7
            054D20B9   mov         eax,14C0988h
            054D20BE   call        503EF8F0            ;allocate memory
            054D20C3   mov         [049388C8],eax      ;store pointer in
            ;instance ref. instance
            ;non-null and ctor
            ;has not run
            054D20C8   mov         ecx,dword ptr [eax]
            054D20CA   mov         dword ptr [ecx],1   ;inline ctor - inUse=true;
            054D20D0   mov         dword ptr [ecx+4],5 ;inline ctor - val=5;
            054D20D7   mov         ebx,dword ptr ds:[49388C8h]
            054D20DD   jmp         054D20B0
            

注: 為引用下列說明中的匯編代碼行，我將引用指令地址的最后兩個值，因為它們都以 054D20 開頭。例如，B5 代表 test eax,eax。

匯編代碼是通過運行一個在無限循環中調用 getInstance() 方法的測試程序來生成的。程序運行時，請運行 Microsoft Visual C++ 調試器并將其附到表示測試程序的 Java 進程中。然后，中斷執行并找到表示該無限循環的匯編代碼。

B0 和 B5 處的前兩行匯編代碼將 instance 引用從內存位置 049388C8 加載至 eax 中，并進行 null 檢查。這跟清單 5 中的 getInstance() 方法的第一行代碼相對應。第一次調用此方法時，instance 為 null，代碼執行到 B9。BE 處的代碼為 Singleton 對象從堆中分配內存，并將一個指向該塊內存的指針存儲到 eax 中。下一行代碼，C3，獲取 eax 中的指針并將其存儲回內存位置為 049388C8 的實例引用。結果是，instance 現在為非 null 并引用一個有效的 Singleton 對象。然而，此對象的構造函數尚未運行，這恰是破壞雙重檢查鎖定的情況。然后，在 C8 行處，instance 指針被解除引用并存儲到 ecx。CA 和 D0 行表示內聯的構造函數，該構造函數將值 true 和 5 存儲到 Singleton 對象。如果此代碼在執行 C3 行后且在完成該構造函數前被另一個線程中斷，則雙重檢查鎖定就會失敗。

不是所有的 JIT 編譯器都生成如上代碼。一些生成了代碼，從而只在構造函數執行后使 instance 成為非 null。針對 Java 技術的 IBM SDK 1.3 版和 Sun JDK 1.3 都生成這樣的代碼。然而，這并不意味著應該在這些實例中使用雙重檢查鎖定。該習語失敗還有一些其他原因。此外，您并不總能知道代碼會在哪些 JVM 上運行，而 JIT 編譯器總是會發生變化，從而生成破壞此習語的代碼。

雙重檢查鎖定：獲取兩個

考慮到當前的雙重檢查鎖定不起作用，我加入了另一個版本的代碼，如清單 7 所示，從而防止您剛才看到的無序寫入問題。

                        public static Singleton getInstance()
            {
            if (instance == null)
            {
            synchronized(Singleton.class) {      //1
            Singleton inst = instance;         //2
            if (inst == null)
            {
            synchronized(Singleton.class) {  //3
            inst = new Singleton();        //4
            }
            instance = inst;                 //5
            }
            }
            }
            return instance;
            }
            

看著清單 7 中的代碼，您應該意識到事情變得有點荒謬。請記住，創建雙重檢查鎖定是為了避免對簡單的三行 getInstance() 方法實現同步。清單 7 中的代碼變得難于控制。另外，該代碼沒有解決問題。仔細檢查可獲悉原因。

此代碼試圖避免無序寫入問題。它試圖通過引入局部變量 inst 和第二個 synchronized 塊來解決這一問題。該理論實現如下：

1. 線程 1 進入 getInstance() 方法。
   
   
2. 由于 instance 為 null，線程 1 在 //1 處進入第一個 synchronized 塊。
   
   
3. 局部變量 inst 獲取 instance 的值，該值在 //2 處為 null。
   
   
4. 由于 inst 為 null，線程 1 在 //3 處進入第二個 synchronized 塊。
   
   
5. 線程 1 然后開始執行 //4 處的代碼，同時使 inst 為非 null，但在 Singleton 的構造函數執行前。（這就是我們剛才看到的無序寫入問題。）
   
   
6. 線程 1 被線程 2 預占。
   
   
7. 線程 2 進入 getInstance() 方法。
   
   
8. 由于 instance 為 null，線程 2 試圖在 //1 處進入第一個 synchronized 塊。由于線程 1 目前持有此鎖，線程 2 被阻斷。
   
   
9. 線程 1 然后完成 //4 處的執行。
   
   
10. 線程 1 然后將一個構造完整的 Singleton 對象在 //5 處賦值給變量 instance，并退出這兩個 synchronized 塊。
    
    
11. 線程 1 返回 instance。
    
    
12. 然后執行線程 2 并在 //2 處將 instance 賦值給 inst。
    
    
13. 線程 2 發現 instance 為非 null，將其返回。

這里的關鍵行是 //5。此行應該確保 instance 只為 null 或引用一個構造完整的 Singleton 對象。該問題發生在理論和實際彼此背道而馳的情況下。

由于當前內存模型的定義，清單 7 中的代碼無效。Java 語言規范（Java Language Specification，JLS）要求不能將 synchronized 塊中的代碼移出來。但是，并沒有說不能將 synchronized 塊外面的代碼移入 synchronized 塊中。

JIT 編譯器會在這里看到一個優化的機會。此優化會刪除 //4 和 //5 處的代碼，組合并且生成清單 8 中所示的代碼。

                        public static Singleton getInstance()
            {
            if (instance == null)
            {
            synchronized(Singleton.class) {      //1
            Singleton inst = instance;         //2
            if (inst == null)
            {
            synchronized(Singleton.class) {  //3
            //inst = new Singleton();      //4
            instance = new Singleton();
            }
            //instance = inst;               //5
            }
            }
            }
            return instance;
            }
            

如果進行此項優化，您將同樣遇到我們之前討論過的無序寫入問題。

用 volatile 聲明每一個變量怎么樣？

另一個想法是針對變量 inst 以及 instance 使用關鍵字 volatile。根據 JLS（參見 參考資料），聲明成 volatile 的變量被認為是順序一致的，即，不是重新排序的。但是試圖使用 volatile 來修正雙重檢查鎖定的問題，會產生以下兩個問題：

• 這里的問題不是有關順序一致性的，而是代碼被移動了，不是重新排序。
  
  
• 即使考慮了順序一致性，大多數的 JVM 也沒有正確地實現 volatile。

第二點值得展開討論。假設有清單 9 中的代碼：

                        class test
            {
            private volatile boolean stop = false;
            private volatile int num = 0;
            public void foo()
            {
            num = 100;    //This can happen second
            stop = true;  //This can happen first
            //...
            }
            public void bar()
            {
            if (stop)
            num += num;  //num can == 0!
            }
            //...
            }
            

根據 JLS，由于 stop 和 num 被聲明為 volatile，它們應該順序一致。這意味著如果 stop 曾經是 true，num 一定曾被設置成 100。盡管如此，因為許多 JVM 沒有實現 volatile 的順序一致性功能，您就不能依賴此行為。因此，如果線程 1 調用 foo 并且線程 2 并發地調用 bar，則線程 1 可能在 num 被設置成為 100 之前將 stop 設置成 true。這將導致線程見到 stop 是 true，而 num 仍被設置成 0。使用 volatile 和 64 位變量的原子數還有另外一些問題，但這已超出了本文的討論范圍。有關此主題的更多信息，請參閱 參考資料。

解決方案

底線就是：無論以何種形式，都不應使用雙重檢查鎖定，因為您不能保證它在任何 JVM 實現上都能順利運行。JSR-133 是有關內存模型尋址問題的，盡管如此，新的內存模型也不會支持雙重檢查鎖定。因此，您有兩種選擇：

• 接受如清單 2 中所示的 getInstance() 方法的同步。
  
  
• 放棄同步，而使用一個 static 字段。

選擇項 2 如清單 10 中所示

                        class Singleton
            {
            private Vector v;
            private boolean inUse;
            private static Singleton instance = new Singleton();
            private Singleton()
            {
            v = new Vector();
            inUse = true;
            //...
            }
            public static Singleton getInstance()
            {
            return instance;
            }
            }
            

清單 10 的代碼沒有使用同步，并且確保調用 static getInstance() 方法時才創建 Singleton。如果您的目標是消除同步，則這將是一個很好的選擇。

String 不是不變的

鑒于無序寫入和引用在構造函數執行前變成非 null 的問題，您可能會考慮 String 類。假設有下列代碼：

private String str;
            //...
            str = new String("hello");
            

String 類應該是不變的。盡管如此，鑒于我們之前討論的無序寫入問題，那會在這里導致問題嗎？答案是肯定的。考慮兩個線程訪問 String str。一個線程能看見 str 引用一個 String 對象，在該對象中構造函數尚未運行。事實上，清單 11 包含展示這種情況發生的代碼。注意，這個代碼僅在我測試用的舊版 JVM 上會失敗。IBM 1.3 和 Sun 1.3 JVM 都會如期生成不變的 String。

                        class StringCreator extends Thread
            {
            MutableString ms;
            public StringCreator(MutableString muts)
            {
            ms = muts;
            }
            public void run()
            {
            while(true)
            ms.str = new String("hello");          //1
            }
            }
            class StringReader extends Thread
            {
            MutableString ms;
            public StringReader(MutableString muts)
            {
            ms = muts;
            }
            public void run()
            {
            while(true)
            {
            if (!(ms.str.equals("hello")))         //2
            {
            System.out.println("String is not immutable!");
            break;
            }
            }
            }
            }
            class MutableString
            {
            public String str;                         //3
            public static void main(String args[])
            {
            MutableString ms = new MutableString();  //4
            new StringCreator(ms).start();           //5
            new StringReader(ms).start();            //6
            }
            }
            

此代碼在 //4 處創建一個 MutableString 類，它包含了一個 String 引用，此引用由 //3 處的兩個線程共享。在行 //5 和 //6 處，在兩個分開的線程上創建了兩個對象 StringCreator 和 StringReader。傳入一個 MutableString 對象的引用。StringCreator 類進入到一個無限循環中并且使用值“hello”在 //1 處創建 String 對象。StringReader 也進入到一個無限循環中，并且在 //2 處檢查當前的 String 對象的值是不是 “hello”。如果不行，StringReader 線程打印出一條消息并停止。如果 String 類是不變的，則從此程序應當看不到任何輸出。如果發生了無序寫入問題，則使 StringReader 看到 str 引用的惟一方法絕不是值為“hello”的 String 對象。

在舊版的 JVM 如 Sun JDK 1.2.1 上運行此代碼會導致無序寫入問題。并因此導致一個非不變的 String。

結束語

為避免單例中代價高昂的同步，程序員非常聰明地發明了雙重檢查鎖定習語。不幸的是，鑒于當前的內存模型的原因，該習語尚未得到廣泛使用，就明顯成為了一種不安全的編程結構。重定義脆弱的內存模型這一領域的工作正在進行中。盡管如此，即使是在新提議的內存模型中，雙重檢查鎖定也是無效的。對此問題最佳的解決方案是接受同步或者使用一個 static field。

最近有Java解壓縮的需求，java.util.zip實在不好用，對中文支持也不行。所以選擇了強大的TrueZIP，使用時遇到了一個問題，做個記錄。
解壓縮代碼如下：

ArchiveDetector detector = new DefaultArchiveDetector(ArchiveDetector.ALL,

        new Object[] { "zip", new CheckedZip32Driver("GBK") } );

File zipFile = new File("zipFile", detector);

File dst = new File("dst");

// 解壓縮

zipFile.copyAllTo(dst);

代碼十分簡潔，注意這個File是

de.schlichtherle.io.File

不是

java.io.File

當處理完業務要刪除這個Zip File時，問題出現了：
這個文件刪不掉！！！
把自己的代碼檢查了好久，確認沒問題后，開始從TrueZIP下手，發現它有特殊的地方的，是提示過的：

File file = new File(“archive.zip”); // de.schlichtherle.io.File!
Please do not do this instead:
de.schlichtherle.io.File file = new de.schlichtherle.io.File(“archive.zip”);

This is for the following reasons:
1.Accidentally using java.io.File and de.schlichtherle.io.File instances referring to the same path concurrently will result in erroneous behaviour and may even cause loss of data! Please refer to the section “Third Party Access” in the package Javadoc of de.schlichtherle.io for for full details and workarounds.
2.A de.schlichtherle.io.File subclasses java.io.File and thanks to polymorphism can be used everywhere a java.io.File could be used.

原來兩個File不能交叉使用，搞清楚原因了，加這么一句代碼搞定。

zipFile.deleteAll();

目前的ANTLR支持的語法層的選項主要包括：

語言選項（Language）、

輸出選項（output）、

回溯選項（backtrack）、

記憶選項 （memorize）、

記號詞庫（tokenVocab）、

重寫選項（rewrite）、

超類選項（superClass）、

過濾選項（Filter）、

AST標簽類型（ASTLabelType）

K選項

/**

        //一些寫法















k=2;

        backtrack=true;

        memoize=true;

*/

1.   語言選項 language

語言選項指定了ANTLR將要產生的代碼的目標語言，默認情況下該選項設置為了Java。需要注意的是，ANTLR中的嵌入的動作必須要使用目標語言來寫。

grammar T;
options {
    language=Java;
}

ANTLR使用了特有的基于字串模板（StringTemplate-based）代碼生成器，構建一個新的目標語言顯得較為簡單，因此我們可以構建多種 語言，諸如Java，C，C++，C#，Python，Objective-C，Ruby等等。語言選項讓ANNTLR去模板目錄（例如 org/antlr/codegen/templates/Java or org/antlr/codegen/templates/C）下尋找合適的模板,并使用模板來構建語言。該目錄下包含大量的模板，我們可以向其中加入其 他的模板以滿足我們的需求。

2.   輸出選項 output

輸出選項控制了ANTLR輸出的數據結構，目前支持兩種輸出：抽象語法樹——AST（Abstract Syntax Trees）和字串模板（StringTemplates）——template。當output這個選項被設置后，所有的規則都被輸出成了AST或者 template。

grammar T;
options {
    output=AST;
}

3.   回溯選項backtrack

當回溯選項打開的時候，在執行一個LL(K)失敗的時候，ANTLR會返回至LL(K)開始而嘗試其他的規則。

4.   記憶選項 （memorize）

memoize選項打開以后，每條解析方法（Paser Method）開始之前，ANTLR會首先檢測以前的嘗試結果，并在該方法執行完成之后記錄該規則是否執行成功。但是注意，對于單條的規則打開此選項經常比在全局上打開該規則效率更高。

5.   記號詞庫（tokenVocab）

說白了就是output輸出目錄中的XX.tokens文件中的定義可以方便的給 大型工程中多個.g中的符號同步更新。

大型的工程中常常利用AST作為中間產物對輸入進行多次分析并最終生成代碼。對AST的遍歷時需要經常使用樹語法（tree grammar），而tree grammar中經常需要將符號與其他的文件中的符號進行同步或者更新。tokenVocab實現了這個功能。
例如我們定義了下面的一個語法文件：

grammar P;
options {
    output=AST;
}
expr: INT ('+' ^ INT)* ;
INT : '0'..'9' +;
WS : ' ' | '\r' | '\n' ;
利用該文件生成了一個標記：P.token，并生成了語法樹（AST）。這時我們需要一個用于遍歷該AST的tree grammar，并通過tree grammar 中的tokenVocab選項來向其中更新tokens:

tree grammar Dump;
options {
    tokenVocab=P;
    ASTLabelType=CommonTree;
}
expr: ^( '+' expr {System.out.print('+' );} expr )
    | INT {System.out.print($INT.text);}
    ;

編譯tree grammar的時候ANTLR默認會在當前目錄下尋找.token文件，我們可以通過-lib選項來設置用于尋找.token文件的目錄，例如：
java org.antlr.Tool -lib . Dump.g

6.   重寫選項（rewrite）

通過重寫選項可以改變ANTLR對輸入的默認處理規則，一般用在輸出為template的情況下。將該選項使能之后，ANTLR將一般的輸入直接拷貝至輸出，而將適于模板重寫規則的輸入做其他的處理。

7.   超類選項（superClass）

用于指定一個超類。

8.   過濾選項（Filter）

9.   AST標簽類型（ASTLabelType）

10.             K選項

   K選項用于限制對LL(K)進行語法分析的次數，從而提高了ANTLR的解析速度。K只能為*或者數字，默認為*。

屬性和動作

動作（Actions）實際上是用目標語言寫成的、嵌入到規則中的代碼（以花括號包裹）。它們通常直接操作輸入的標號，但是他們也可以用來調用相應的外部代碼。屬性，到目前為止我的理解還不多，感覺像是C++中類里面的成員，一會看完應該會更清楚一些。

1. 語法動作（Grammar Actions）
動作（Actions）是指嵌在語法中的、用目標語言寫成的代碼片段。ANTLR則把這些代碼（除了用$或%標記的以外）逐字地插入到生成的識別器中。
動作可以放到規則的外邊，也可以嵌入到某條規則當中。當動作位于規則之外時候，這些動作同城定義了一些全局的或者是類的成員（變量或者成員函數）；而當其嵌入規則之中時，則用于執行某些特定的命令，這些命令在識別器識別了其預訂的字符的時候就會開始執行。例如下面的例子：

parser grammar T;
@header {
    package p;
}
@members {
    int i;
    public TParser(TokenStream input, int foo) {
        this(input);
        i = foo;
    }
}
a[int x] returns [int y]
@init {int z=0;}
@after {System.out.println("after matching rule; before finally");}
: {《action1》} A {《action2 》}
;
catch[RecognitionException re] {
    System.err.println("error");
}
finally { 《do-this-no-matter-what 》 }

從中可以看出，前面的兩個動作，@head and @members是兩個處于規則之外的全局的動作，定義了一些變量和類；而后兩個則分別在a這個規則的前后執行（@init在前，@after在后，這個在前面提到過）。 這里針對兩種類型詳細敘述。

       在傳統的項目中，通常有一個人保護他們的代碼庫，直到代碼集成階段。但是在敏捷里面，我們持代碼集體所有制的觀點——所有的代碼屬于所有的開發人員，只要開發人員認為有必要，每個人都能不受約束地去改善代碼。在一段時間里面，我們的代碼庫開始出現奇怪的行為——解決辦法就是重構（感謝Martin Fowler在他的同名著作中把重構一詞推廣開來）。重構的本質歸結為修改代碼以改善代碼的結構和清晰度，但不改變代碼的功能。我們學到的一個重要教訓是在重構代碼之前使用單元測試作為安全網，我們曾經使用過的一些主要工具包括Eclipse、NetBeans、IntelliJ IDEA的和Visual Studio.NET。

在敏捷團隊之中工作所必備的行為特征

由于敏捷團隊不同于普通的團隊，并且非常倚賴于有效果和有效率的溝通和快速執行，敏捷團隊更需要使用軟技能。如果我們意識到這一點，并積極鼓勵使用這些特征和技能，我們可以使得敏捷團隊更有價值和富有成效。

自組織往往倚賴于諸如正反饋、負反饋、深度探索和廣度調研之間取得平衡以及多重互動的基本要素。根據我們的經驗，團隊可能由于許多文化和社會因素無法給予正確的反饋或者回避人與人之間的互動。

根據我個人的經驗，這仍然是一個“神話”。我們總是傾向于患有“可預測性綜合癥”——如果我們做更多的規劃，我們將更加功能預測。

團隊需要有良好的紀律、有能力承擔責任、盡忠盡責以及承擔職責和所有權。

團隊需要擁有的關鍵技能之一是有能力尋求幫助，并尋求他人的評價。在某些情形下，我們已經看到了“自我”因素表現為一個主要的障礙。

有些時候，承擔責任，盡忠盡責和協作精神是理所當然的，但是根據以往的經驗，為了這些能夠出現，我們有時需要外部干預。

有些我們常常傾向于忽視的關鍵技能是積極主動、在激烈的環境中享受工作和易于適應新的形勢和框架。

我們的大多數項目都是分布式的，這意味著在客戶和服務供應商之間將會共同使用Scrum。在這種情況下，諸如管理多樣化團隊、時間管理、外交技巧和領導力等技能是非常關鍵的。

敏捷團隊的成功“咒語”

對于任何一個希望成功和高效的敏捷項目，團隊需要對向同儕學習（不管資歷和專業知識）表現出更大的熱情和正確的態度。必須保證一個無畏表達的安全網，這樣才會展現出真正的友情，而這反過來會增強團隊成員對團隊目標的關注，而不是“哪些由我來做”？

結論

根據我個人的經驗和觀察，對于提高生產率所需的技能，敏捷項目與傳統項目有所不同。本文定義了團隊提高生產率所需的行為和技術技能。具有這些“delta” 特征的人應該具備了合適的行為和技術技能，這些技能使得他們在敏捷項目中的工作能夠富有成效。對于這些技能的總結請見下表。

技能表

作者簡介

Prasad，擁有10年的IT服務行業經驗，他第一次接觸敏捷項目是在2005年微軟的一個項目；從那時起，他為許多公司如GE、思科、可口可樂等，針對敏捷及其變體提供了解決方案開發、培訓、咨詢以及指導。目前他正在Symphony Services的敏捷實驗室擔任經理。Symphony40％的項目都是關于敏捷或其不同的形式，并且自2004年起就通過敏捷為客戶提供商務的關鍵價值。你可以通過pprabhak@symphonsysv.com與他聯系。

查看英文原文：Skills for Scrum Agile Teams

1. 任何程序一旦部署即顯陳舊。
2. 修改需求規范來適應程序比反過來做更容易。
3. 一個程序如果很有用，那它注定要被改掉。
4. 一個程序如果沒用，那它一定會有很好的文檔。
5. 任何程序里都僅僅只有10%的代碼會被執行到。
6. 軟件會一直膨脹到耗盡所有資源為止。
7. 任何一個有點價值的程序里都會有至少一個bug。
8. 原型完美的程度跟審視的人數成反比，反比值會隨著涉及的資金數增大。
9. 軟件直到被變成產品運行至少6個月后，它最嚴重的問題才會被發現。
10. 無法檢測到的錯誤的形式無限多樣，而能被檢測到的正好相反，被定義了的十分有限。
11. 修復一個錯誤所需要投入的努力會隨著時間成指數級增加。
12. 軟件的復雜度會一直增加，直到超出維護這個程序的人的承受能力。
13. 任何自己的程序，幾個月不看，形同其他人寫的。
14. 任何一個小程序里面都有一個巨大的程序蠢蠢欲出。
15. 編碼開始的越早，花費的時間越長。
16. 一個粗心的項目計劃會讓你多花3倍的時間去完成；一個細心的項目計劃只會讓你多花2倍的時間。
17. 往大型項目里添加人手會使項目更延遲。
18. 一個程序至少會完成90%，但永遠完成不了超過95%。
19. 如果你想麻煩被自動處理掉，你得到的是自動產生的麻煩。
20. 開發一個傻瓜都會使用的軟件，只有傻瓜愿意使用它。
21. 用戶不會真正的知道要在軟件里做些什么，除非使用過。

public class CheckQueryParams {

    private static interface Validation{
 void check(QueryInfo query);
    }
   
    private static List<Validation> validations = new ArrayList<Validation>();
   
    static {
 validations.add(new Validation() {
     public void check(QueryInfo query) {
  if(StringUtils.isEmpty(query.getStartKey()) && StringUtils.isEmpty(query.getEndKey()))
      throw new RuntimeException("Both keys can not be null or empty at the same time");
     }});
    }

    public static void check(QueryInfo query) {
 for(Validation validation : validations) {
     validation.check(query);
 }
    }
}

public class LRUCache<K,V> {

    final private int capacity;
    final private Map<K,Reference<V>> map;
    final private ReentrantLock lock = new ReentrantLock();
    final private ReferenceQueue<Reference<V>> queue = new ReferenceQueue<Reference<V>>();
   
    public LRUCache(int capacity) {
 this.capacity = capacity;
 map = new LinkedHashMap<K,Reference<V>>(capacity,1f,true){
     @Override
     protected boolean removeEldestEntry(Map.Entry<K,Reference<V>> eldest) {
         return this.size() > LRUCache.this.capacity;
     }
 };
    }
   
    public V put(K key,V value) {
 lock.lock();
 try {
  map.put(key, new SoftReference(value,queue));
  return value;
 }finally {
     lock.unlock();
 }
    }
   
    public V get(K key) {
 lock.lock();
 try {
     queue.poll();
     return map.get(key).get();
 }finally {
     lock.unlock();
 }
    }
 
    public void remove(K key) {
 lock.lock();
 try {
     map.remove(key);
 }finally {
     lock.unlock();
 }
    }

}

         java中的同步對象，實際上是對于reference所指的“對象地址”進行同步。
        需要注意的問題是，千萬不要對同步對象重新賦值。舉個例子。
            class A implements Runnable{
                Object lock = new Object();

                    void run(){
                        for(...){
                            synchronized(lock){
                                // do something
                                    ...
                                  lock = new Object();
                             }
                        }
                    }
            }

        run函數里面的這段同步代碼實際上是毫無意義的。因為每一次lock都給重新分配了新的對象的reference，每個線程都在新的reference同步。大家可能覺得奇怪，怎么會舉這么一個例子。因為我見過這樣的代碼，同步對象在其它的函數里被重新賦了新值。這種問題很難查出來。所以，一般應該把同步對象聲明為final。 final Object lock = new Object();

使用Singleton Pattern 設計模式來獲取同步對象，也是一種很好的選擇。

        實現線程，有兩種方法，一種是繼承Thread類，一種是實現Runnable接口。
        首先，把需要共享的數據放在一個實現Runnable接口的類里面，然后，把這個類的實例傳給多個Thread的構造方法。這樣，新創建的多個Thread，都共同擁有一個Runnable實例，共享同一份數據。如果采用繼承Thread類的方法，就只好使用static靜態成員了。如果共享的數據比較多，就需要大量的static靜態成員，令程序數據結構混亂，難以擴展。這種情況應該盡量避免。編寫一段多線程代碼，處理一個稍微復雜點的問題。兩種方法的優劣，一試便知。

        線程同步的粒度越小越好，即，線程同步的代碼塊越小越好。盡量避免用synchronized修飾符來聲明方法。盡量使用synchronized(anObject)的方式，如果不想引入新的同步對象，使用synchronized(this)的方式。而且，synchronized代碼塊越小越好。

        對于簡單的問題，可以把訪問共享資源的同步代碼都放在一個類里面。
        但是對于復雜的問題，我們需要把問題分為幾個部分來處理，需要幾個不同的類來處理問題。這時，就需要在不同的類中，共享同步對象。比如，在生產者和消費者之間共享同步對象，在讀者和寫者之間共享同步對象。
如何在不同的類中，共享同步對象。有幾種方法實現，
（1）前面講過的方法，使用static靜態成員，（或者使用Singleton Pattern.）
（2）用參數傳遞的方法，把同步對象傳遞給不同的類。
（3）利用字符串常量的“原子性”。
對于第三種方法，這里做一下解釋。一般來說，程序代碼中的字符串常量經過編譯之后，都具有唯一性，即，內存中不會存在兩份相同的字符串常量。
（通常情況下，C++，C語言程序編譯之后，也具有同樣的特性。）

    比如，我們有如下代碼。
        String A = “atom”;
        String B = “atom”;

    我們有理由認為，A和B指向同一個字符串常量。即，A==B。注意，聲明字符串變量的代碼，不符合上面的規則。
        String C= new String(“atom”);
        String D = new String(“atom”);
    這里的C和D的聲明是字符串變量的聲明，所以，C != D。

有了上述的認識，我們就可以使用字符串常量作為同步對象。比如我們在不同的類中，使用synchronized(“myLock”), “myLock”.wait(),“myLock”.notify(), 這樣的代碼，就能夠實現不同類之間的線程同步。本文并不強烈推薦這種用法，只是說明，有這樣一種方法存在。本文推薦第二種方法，（2）用參數傳遞的方法，把同步對象傳遞給不同的類。