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）用参数传递的方法，把同步对象传递给不同的类。

    一旦你把对象引用放到缓存中，它就很容易被遗忘掉，从而使得它不再有用之后很长一段时间内仍然留在缓存中。对于这个问题，有几种可能的解决方案。如果你正好要实现这样的缓存：只要在缓存之外存在对某个项的键的引用，该项就有意义，那么就可以用WeakHashMap代表缓存；当缓存中的项过期之后，它们就会自动被删除。记住只有当所要的缓存项的生命周期是由该键的外部引用而不是由值决定时，WeakHashMap才有用处。

更为常见的情形则是，"缓存项的生命周期是否有意义"并不是很容易确定，随着时间的推移，其中的项会变得越来越没有价值。在这种情况下，缓存应该时不时地清除掉没用的项。这项清除工作可以由一个后台线程（可能是Timer或者ScheduledThreadPoolExecutor）来完成，或者也可以在给缓存添加新条目的时候顺便进行清理。LinkedHashMap类利用它的removeEldestEntry方法可以很容易地实现后一种方案。对于更加复杂的缓存，必须直接使用java.lang.ref。

清空过期引用的另一个好处是，如果它们以后又被错误地解除引用，程序就会立即抛出NullPointerException异常，而不是悄悄地错误运行下去。尽快地检测出程序中的错误总是有益的。

        
        在Java中设置变量值的操作，除了long和double类型的变量外都是原子操作，也就是说，对于变量值的简单读写操作没有必要进行同步。

这在JVM 1.2之前，Java的内存模型实现总是从主存读取变量，是不需要进行特别的注意的。而随着JVM的成熟和优化，现在在多线程环境下volatile关键字的使用变得非常重要。

在当前的Java内存模型下，线程可以把变量保存在本地内存（比如机器的寄存器）中，而不是直接在主存中进行读写。这就可能造成一个线程在主存中修改了一个变量的值，而另外一个线程还继续使用它在寄存器中的变量值的拷贝，造成数据的不一致。

要解决这个问题，只需要像在本程序中的这样，把该变量声明为volatile（不稳定的）即可，这就指示JVM，这个变量是不稳定的，每次使用它都到主存中进行读取。一般说来，多任务环境下各任务间共享的标志都应该加volatile修饰。

Volatile修饰的成员变量在每次被线程访问时，都强迫从共享内存中重读该成员变量的值。而且，当成员变量发生变化时，强迫线程将变化值回写到共享内存。这样在任何时刻，两个不同的线程总是看到某个成员变量的同一个值。

Java语言规范中指出：为了获得最佳速度，允许线程保存共享成员变量的私有拷贝，而且只当线程进入或者离开同步代码块时才与共享成员变量的原始值对比。

这样当多个线程同时与某个对象交互时，就必须要注意到要让线程及时的得到共享成员变量的变化。

而volatile关键字就是提示VM：对于这个成员变量不能保存它的私有拷贝，而应直接与共享成员变量交互。

使用建议：在两个或者更多的线程访问的成员变量上使用volatile。当要访问的变量已在synchronized代码块中，或者为常量时，不必使用。

由于使用volatile屏蔽掉了VM中必要的代码优化，所以在效率上比较低，因此一定在必要时才使用此关键字。

文章出处：DIY部落(http://www.diybl.com/course/3_program/java/javaxl/20090302/156333.html)

同时查看下IBM中的详细解释：

         
       今天在熟悉我们的项目的时候，sql中看到FORCE INDEX，额，都不知道什么东东，有什么特别用处吗？ 查了下资料，原来是这样啊，发现一般不搞复杂sql，而且复杂sql DBA也不允许，但优化的sql 还是有必要了解下。（一般来说也不太会使用，总被DBA pk了）

        下面部分转：
        对于经常使用oracle的朋友可能知道，oracle的hint功能种类很多，对于优化sql语句提供了很多方法。同样，在mysql里，也有类似的hint功能。下面介绍一些常用的。

      1。强制索引 FORCE INDEX

SELECT * FROM TABLE1 FORCE INDEX (FIELD1) …

以上的SQL语句只使用建立在FIELD1上的索引，而不使用其它字段上的索引。

       2。忽略索引 IGNORE INDEX

SELECT * FROM TABLE1 IGNORE INDEX (FIELD1, FIELD2) …

在上面的SQL语句中，TABLE1表中FIELD1和FIELD2上的索引不被使用。

       3。关闭查询缓冲 SQL_NO_CACHE

SELECT SQL_NO_CACHE field1, field2 FROM TABLE1;

有一些SQL语句需要实时地查询数据，或者并不经常使用（可能一天就执行一两次）,这样就需要把缓冲关了,不管这条SQL语句是否被执行过，服务器都不会在缓冲区中查找，每次都会执行它。

      4。强制查询缓冲 SQL_CACHE

SELECT SQL_CALHE * FROM TABLE1;

如果在my.ini中的query_cache_type设成2，这样只有在使用了SQL_CACHE后，才使用查询缓冲。

     5。优先操作 HIGH_PRIORITY

HIGH_PRIORITY可以使用在select和insert操作中，让MYSQL知道，这个操作优先进行。

SELECT HIGH_PRIORITY * FROM TABLE1;

     6。滞后操作 LOW_PRIORITY

LOW_PRIORITY可以使用在insert和update操作中，让mysql知道，这个操作滞后。

update LOW_PRIORITY table1 set field1= where field1= …

    7。延时插入 INSERT DELAYED

INSERT DELAYED INTO table1 set field1= …

INSERT DELAYED INTO，是客户端提交数据给MySQL，MySQL返回OK状态给客户端。而这是并不是已经将数据插入表，而是存储在内存里面等待排队。当mysql有空余时，再插入。另一个重要的好处是，来自许多客户端的插入被集中在一起，并被编写入一个块。这比执行许多独立的插入要快很多。坏处是，不能返回自动递增的ID，以及系统崩溃时，MySQL还没有来得及插入数据的话，这些数据将会丢失。

     8 。强制连接顺序 STRAIGHT_JOIN

SELECT TABLE1.FIELD1, TABLE2.FIELD2 FROM TABLE1 STRAIGHT_JOIN TABLE2 WHERE …

由上面的SQL语句可知，通过STRAIGHT_JOIN强迫MySQL按TABLE1、TABLE2的顺序连接表。如果你认为按自己的顺序比MySQL推荐的顺序进行连接的效率高的话，就可以通过STRAIGHT_JOIN来确定连接顺序。

    9。强制使用临时表 SQL_BUFFER_RESULT

SELECT SQL_BUFFER_RESULT * FROM TABLE1 WHERE …

当我们查询的结果集中的数据比较多时，可以通过SQL_BUFFER_RESULT.选项强制将结果集放到临时表中，这样就可以很快地释放MySQL的表锁（这样其它的SQL语句就可以对这些记录进行查询了），并且可以长时间地为客户端提供大记录集。

   10。分组使用临时表 SQL_BIG_RESULT和SQL_SMALL_RESULT

SELECT SQL_BUFFER_RESULT FIELD1, COUNT(*) FROM TABLE1 GROUP BY FIELD1;

一般用于分组或DISTINCT关键字，这个选项通知MySQL，如果有必要，就将查询结果放到临时表中，甚至在临时表中进行排序。SQL_SMALL_RESULT比起SQL_BIG_RESULT差不多，很少使用。