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