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差不多，很少使用。

5.name属性可以用,隔开指定多个名字，如<bean name="b1,b2,b3">,相当于多个别名，这时通过getBean("a1") getBean("a2") getBean("a3")返回的都是同一个实例（假设是singleton的情况）

6.如果id和name都没有指定，则用类全名作为name，如<bean class="com.stamen.BeanLifeCycleImpl">,则你可以通过
getBean("com.biao.GroupThreadImpl")返回该实例。

7.如果存在多个id和name都没有指定，且实例类都一样的<bean>，如:

 <bean class="com.biao.GroupThreadImpl"/>



<bean class="com.biao.GroupThreadImpl"/>



<bean class="com.biao.GroupThreadImpl"/>



则第一个bean通过getBean("com.biao.GroupThreadImpl")获得， 



第二个bean通过getBean("com.biao.GroupThreadImpl#1")获得， 



第三个bean通过getBean("com.biao.GroupThreadImpl#2")获得，以此类推。 

倒计时：

第六条 在改写equals的时候请遵守通用规定
  有一种“值类”可以不要求改写equals方法，类型安全枚举类型，因为类型安全枚举类型保证每一个值之多只存在一个对象，所有对于这样的类而言，Object的queals方法等同于逻辑意义上的equals方法。
 
  在改写equals方法的时候，要遵循的规范： 
        1，自反性。对任意的引用值x,x.equals(x)一定是true
        2，对称性。对于任意的引用值x和y,当且仅当y.equals(x)返回true时，x.equals(y)也一定返回true.
        3，传递性。对于任意的引用值x,y和z,如果x.equals(y)==true and y.equals(z)==true,so x.equals(z)==true.
        4，一致性。对于任意的引用值x和y,如果用于equals比较的对象信息没有被修改的话，那么，多次调用x.equals(y)要么一致地返回true,要么一致地返回false.
        5，非空性。对于任意的非空引用值x,x.equals(null)一定返回false.
        
  自反性：要求一个对象必须等于其自身。一个例子：你把该类的实例加入到一个集合中，则该集合的contains方法
将果断地告诉你，该集合不包含你刚刚加入的实例． 

  对称性：
  例如：
　　　　　public final class CaseInsensitiveString{
           private String s;
           public CaseInsensitiveString(String s){
              if(s==null)   throw new NullPointerException();
              this.s=s;
           }
           public boolean equals(Object o){
              if(o instanceof CaseInsensitiveString)
                 return s.equalsIgnoreCase(((CaseInsensitiveString)o).s);
              if(o instanceof String)
                 return s.equalsIgnoreCase((String)o);
               return false;
            }
          }
调用：
　　　CaseInsensitiveString cis=new CaseInsensitiveString("Polish");
       String s="polish";
正如我们期望的：cis.equals(s)==true but s.equals(cis)==false
这就违反了对称性的原则．为了解决这个问题，只需把企图与String互操作的这段代码从equals方法中去掉旧可以了．这样做之后，你可以重构代码，使他变成一条返回语句：
public boolean equals(Object o){
   return o instanceof CaseInsensitiveString && ((CaseInsensitiveString)o).s.equalsIgnoreCase(s);
}

传递性---即如果一个对象等于第二个对象，并且第二个对象又等于第三个对象，则第一个对象一定等于第三个对象。
例如：
       public class Point{
           private final int x;
           private final int y;
           public Point(int x,int y){
                this.x=x;
                this.y=y;
          }
          public boolean equals(Object o){
             if(!(o instanceof Point))
              return false;
             Point p=(Point)o;
             return p.x==x&&p.y==y;
          }
     }
现在我们来扩展这个类，为一个点增加颜色信息：
   public class ColorPoint extends Point{
      private Color color;
      public ColorPoint(int x,int y,Color color){
          super(x,y);
          this.color=color;
      }
   }
分析： equals方法会怎么样呢？如果你完全不提供equals方法，而是直接从Point继承过来，那么在equals座比较的时候颜色信息会被忽略掉。如果你编写一个equals方法，只有当实参是另一个有色点，并且具有同样的位置和颜色的时候，它才返回true:
       public boolean equals(Object o){
          if(!(o instanceof ColorPoint)) return false;
          ColorPoint cp=(ColorPoint)o;
          return super.equals(o) && cp.color==color;
       }
分析：这个方法的问题在于，我们在比较一个普通点和一个有色点，以及反过来的情形的时候，可能会得到不同的结果。前一种比较忽略了颜色信息，而后一种比较总是返回false,因为实参的类型不正确。例如：
     Point p=new Point(1,2);
     ColorPoint cp=new ColorPoint(1,2,Color.RED);
然后：p.equals(cp)==true but cp.equals(p)==false

修正：让ColorPoint.equals在进行“混合比较”的时候忽略颜色信息：
   public boolean equals(Object o){
       if(!(o instanceof Point)) return false;
       if(!(o instanceof ColorPoint)) return o.equals(this);
       ColorPoint cp=(ColorPoint)o;
       return super.equals(o) && cp.color==color;
   }
这种方法确实提供了对称性,但是却牺牲了传递性:
   ColorPoint p1=new ColorPoint(1,2,Color.RED);
   Point p2=new Point(1,2);
   ColorPoint p3=new ColorPoint(1,2,Color.BLUE);
此时：p1.equals(p2)==true and p2.equals(p3)==true but p1.equals(p3)==false很显然违反了传递性。前两个比较不考虑颜色信息，而第三个比较考虑了颜色信息。

结论：要想在扩展一个可实例华的类的同时，既要增加新的特征，同时还要保留equals约定，没有一个简单的办法可以做到这一点。根据"复合优于继承"，这个问题还是有好的解决办法：我们不让ColorPoint扩展Point，而是在ColorPoint中加入一个私有的Point域，以及一个公有的视图方法，此方法返回一个与该有色 点在同一位置上的普通Point对象：
    public class ColorPoint{
       private Point point;
       private Color color;
       public ColorPoint(int x,int y,Color color){
         point=new Point(x,y);
         this.color=color;
       }
       public Point asPoint(){
           return point;
       }
     
       public boolean equals(Object o){
           if(!(o instanceof ColorPoint)) return false;
           ColorPoint cp=(ColorPoint)o;
           return cp.point.equals.(point) && cp.color.equals(color);
       }
    }
   
注意，你可以在一个抽象类的子类中增加新的特征，而不会违反equals约定。

一致性:
 如果两个对象相等的话，那么它们必须始终保持相等，除非有一个对象被修改了。由于可变对象在不同的时候可以与不同的对象相等，而非可变对象不会这样，这个约定没有严格界定。
 

非空性:没什么好说的。

1，使用==操作符检查“实参是否为指向对象的一个应用”。如果是的话，则返回true。
       2，使用instanceof操作符检查“实参是否为正确的类型”。如果不是的话，则返回false。
       3，把实参转换到正确的类型。
       4，对于该类中每一个“关键（significant）”域，检查实参中的域与当前对象中对应的域值是否匹配
     if (!(this.field == null ? o.field == null : this.equals(o.field)))
     //或者写成 if(!(this.field == o.field || (this.field != null && this.field.equals(o.field)))) 对于this.field和o.field通常是相同的对象引用，会更快一些。
       return false;
     //比较下一个field
     //都比较完了
     return true;
     
5.最后还要确认以下事情
   5.1）改写equals的同时，总是（必须）要改写hashCode方法（见【第8条】），这是极容易被忽略的，有极为重要的
   5.2）不要企图让equals方法过于聪明
   5.3）不要使用不可靠的资源。如依赖网络连接
   5.4）不要将equals声明中的Object对象替换为其他类型。
         public boolean equals(MyClass) 这样的声明并不鲜见，往外使程序员数小时搞不清楚为什么不能正常工作
         原因是这里是重载（overload）而并不是改写（override）（或称为覆盖、重写）
         相当于给equals又增加了一个实参类型为MyClass的重载，而实参为Object的那个equals并没有被改写，依然还是从Object继承来的最初的那个equals，所总是看不到程序员想要的效果。因为类库或其他人写的代码都是调用实参为Object型的那个equals方法的（别人又如何在事前知晓你今天写的MyClass呢？）

ExtJS可以用来开发RIA也即富客户端的AJAX应用，是一个用javascript写 的，主要用于创建前端用户界面，是一个与后台技术无关的前端ajax框架。因此，可以把ExtJS用在.Net、Java、Php等各种开发语言开发的应 用中。

ExtJs最开始基于YUI技术，由开发人员Jack Slocum开发，通过参考Java Swing等机制来组织可视化组件，无论从UI界面上CSS样式的应用，到数据解析上的异常处理，都可算是一款不可多得的JavaScript客户端技术 的精品。

ExtJS:    http://www.spket.com/demos/js.html spket插件(eclipse)

一个简单的例子：

http://extjs.org.cn/node/83

Java文件注释头

类中开头处插入如下 注释

/******************************************************************

 *该类功能及特点的描述(例如:该类是用来.....)

 *

 *

     *该类未被编译测试过。

     *

     *@see(与该类相关联的类):(AnotherClass.java)

     *

     *

 *

 *开发公司或单位:XXX软件有限公司研发中心

 *

 *版权:本文件版权归属XXX公司研发中心

 *

 *

       *@author(作者):XXX

       *

       *@since(该文件所支持的JDK版本):Jdk1.3或Jdk1.4

       *

       *@version(版本):1.0

       *

 *

 *@date(开发日期):      1999-01-29

 *

 *最后更改日期:        2003-01-02

 *

 *

 *修改人:    XXXX

 *

 *复审人:    张三李四 王五

 *

 */

伊甸园用来保存新的对象，它就像一个堆栈，新的对象被创建，就像指向该栈的指针在不断的增长一样，当伊甸园区域中的对象满了之后，JVM系统将要做可到达性测试，主要任务是检测有哪些对象由根集合出发是不可到达的，这些对象就可以被JVM回收，并且将所有的活动对象从伊甸园区域拷到TO区域，此时一些对象将发生状态交换，有的对象就从TO区域被转移到From区域，此时From区域就有了对象,这个过程都是JVM控制完成的。

Java 中的析构方法 finalize

 对象是使用完了 尽量都赋 为 null

共享静态变量存储空间

不要提前创建对象

    ........

    void f(){

       int i;

       A a = new A();

       //类A的对象a被创建

       //在判断语句之中没有

       //应用过a对象

       .....

       if(....){

           //类A的对象a仅在此处被应用

           a.showMessage();

           ....

       }

       .....

    }

    ..........

    正确的书写方式为：

    void f(){

       int i;

       .....

       if(...){

           A a = new A();

           //类A的对象a被创建

           //应用过a对象

           a.showMessage();

       }

       ......

    }

JVM内存参数调优

非静态方法中可引用静态变量

静态方法不可以引用非静态变量

静态方法中可 创建 非静态变量

调用父类的构造方法必须将其放置子类构造方法的第一行

线程同步：Vector Hashtable

非线程同步: ArrayList HashMap

字符串累加 尽量使用 StringBuffer  += 

方法length() 和 length属性  区别

IO缓存，读写文件优化。

       内部类（Inner Class）是Java语言中特有的类型，内部类只能被主类以外的其他内部类继承，主类是不能继承其内部类的，因为这样就引起了类循环继承的错误，下面的代码就是错误的。

       public class A extends x {

              public A(){}

              ……

           Classs x{

                     …..

}

}

上面的代码将引发类循环继承的错误，这种错误在编译时就会被发现，比较容易发现和排除。

但是下面例子中的内部类的继承方式却是正确的：

class A{

       ….

       public  A(){}

       ……

       class  X  extends Y  {

       ……….

}

       calss  Y {

       ……

}

}

什么时候使用继承，什么样的继承是合理的：

1.       现实世界的事物继承关系，可以作为软件系统中类继承关系的依据。

2.       包含关系的类之间不存在继承关系。如：主机，外设 ，电脑。 把主机类和外设类作为电脑类的成员就可以了。

3.       如果在逻辑上类B是类A的一种，并且类的所有属性和行为对类而言都有意义，则允许B继承A的行为和属性（私有属性与行为除外）。

本来我想把这篇文章的名字命名为: <怎样成为一个优秀的Java程序员>的, 但是自己还不够优秀, 而本篇所涉及的都是自己学习和工作中的一些经验, 后来一想, 叫<怎样进阶Java>可能更为合适吧. 能给初学Java的人一个参考, 也就是我本来的心愿. 如果有大牛看到不妥之处, 敬请指正. 我一定会修正的 :).

Java目前是最流行的语言之一,  是很多公司和程序员喜爱的一门程序语言. 而且, Java的入门比C++相对来说要简单一些, 所以有很大一部分程序员都选择Java作为自己的开发语言. 我也是其中之一, 就是因为觉得学C++太难, 当初在学校学了将近一个学期的C++, 啥进步都没有, 哈哈, 天资太差, 所以才选择自学Java(当时学校并没有开设Java的课程), 才走上了程序开发这条路.

Java虽然入门要容易, 然而要精通它, 要成为专家却很难. 主要原因是Java所涉及的技术面比较宽, 人的精力总是有限的. 有些Java方面的技术是必须要要掌握的, 钻研得越深入越好, 比如多线程技术.

1. 基础阶段

基础阶段, 可能需要经历1-2年吧. 这个时段, 应该多写一些基础的小程序(自己动手写的越多越好). 计算机是一门实践性很强的学科, 自己动手的东西, 记忆非常深刻, 效果要胜过读好多书. 当然, 学Java基础的时候, 书籍的选择也非常重要, 好的书籍事半功倍, 能让你打个非常好的基础. 而差的书籍, 很容易将你带入歧途, 多走很多弯路. 书籍不在多, 而在乎读得精(有些书, 你读十遍都不为过). 我记得我学Java的第一本书是<Thinking in Java>的中文版, 网上有很多人都建议不要把这本书作为第一本的入门教程来看, 太难. 我却想在此极力推荐它, 这本书确实是本经典之作. 而且书中确实讲的也是Java中的一些基础技术, 没有什么太难的东西, 只不过比较厚, 学习周期比较长, 所以很多人中途会选择放弃. 其实, 这本书是一本难得的入门教程, 对Java一些基础的东西, 讲得很全, 而且也很清晰, 更重要的是, 这本书能让你养成很多好的编程习惯, 例子也很多. 建议你把大部分的例子自己去实现一遍.  我的亲身经历, 我记得当时认真的看了2遍, 花了大概7个月的时间, 不过真的有很好的效果. 另外一个教程, 就是<Java核心技术>卷一, 卷二的话可以不必要买. 卷一看完, 自己再钻研一下, 就已经能达到卷二的高度了:). 到那时, 你就会觉得看卷二没啥意思, 感觉浪费钱了. 还有一个, 就是张孝祥的Java视频, 看视频有个好处, 就是比看书的记忆要深刻, 还有很多你可以跟着视频的演示同步操作. 张孝祥的Java视频对初学者来说, 确实很有作用. 总结起来: 看这些资料的时候, 一定要多写例子, 写的越多越好!

2. 中级阶段

中级阶段, 是一个更漫长的时期, 能否突破此阶段, 跟个人的努力和天资有着很大的关系. 你不得不承认, 同样一门新技术, 有些人一个月领悟到的东西, 比你一年的都多. 这就是天资, 程序员是一个需要天才的工作. 我想, 很多人听说李一男吧, 此君就是这样的人物, 三个月的时间就能解决好大一帮人几年解决不了的问题, 给华为某部门带来了很多的收益. 哦, 这是题外话了, 与此篇的主题无关, 只是本人偶尔的感慨而已:).  这个阶段, 就需要研究很多专题性的东西了, 比如: IO的实现原理, 多线程和Java的线程模型, 网络编程, swing, RMI, reflect, EJB, JDBC等等很多很多的专题技术, 钻研得越深越好. 为了更好的提高, 研究的更深入, 你需要经常到网络上搜索资料, 这个时候往往一本书起不来很大的作用. 选一个JDK版本吧, 目前建议选用1.6, 多多研究它, 尤其是源代码(尽量! 就是尽自己最大的努力, 虽然研究透是不可能滴). 比如说: util, collection, io, nio, concurrent等等包. 可能有人会反对我说, 不是有API文档吗, 为什么还要研究这么多的源代码? 错了, 有API文档, 你仅仅只是知道怎么用而已, 而认真仔细的研读这些大牛的源码, 你就会深入更高的一个阶层, 自己的编码, 设计都会有很大的提高. 如果有能力和精力, 我建议你把JDK的每一行代码都熟悉一遍, 绝对只有好处, 没有坏处! 而且你会有些意外的收获, 比如, 当你仔细地读完concurrent包的时候(不多, 好像总共是86个类吧), 你就会对Doug Lea佩服得五体投地. 这个时候最忌碰到难题就去寻找帮助, 去网上找答案! 先把自己的脑袋想破吧, 或者等你的老板拿着砍刀冲过来要把你杀了, 再去寻求帮助吧. 对于专题的学习, 英文原版的阅读是非常必要的, 看的越多越好, 多上上IBM的developer, SUN的网站吧, 当然Javaeye也很不错:), 有很多大牛, 呵呵.

这个时候, 你应该建立自己的代码库了, 你应该自己去研究很多有意思的东西了. 从一个200多M的文件中寻找一个字段, 最坏情况(在文件的末尾咯)也只需要1秒左右的时间, 你知道吗?  这个阶段, 有很多很多类似的有趣的东西可以供你去研究, 你需要更多地关注性能, 规范性, 多解决一些疑难问题. 需要学会所有的调试技术, 运用各种性能工具, 还有JDK附带的很多工具, 这些你都要熟练得跟屠夫操刀一样. 也可以看看<Effective Java>, 这本书总结的也不错, 对写高效稳定的Java程序有些帮助. 也可以看看模式方面的东西, 但是我建议模式不要滥用, 非得要用的时候才用, 模式往往会把问题搞复杂:). 总结起来: 这个阶段是一个由点延伸到面的过程, 经过不断的学习, 演变成全面的深入! Java技术中你没什么盲点了, 还能解决很多性能问题和疑难问题, 你就成了一个合格的程序员了! :)  [要想成为优秀程序员, 还得对数据库和操作系统很精通.]

3. 高级阶段

高级阶段, 我就不敢妄言了. 呵呵, 我感觉自己也是处于中级阶段吧. 也是根据自己的一些经验, 谈谈自己的理解吧:

这个阶段, 需要研究各种框架, Spring, struts, Junit, Hibernate, iBatis, Jboss, Tomcat, snmp4j等等, 我觉得这个时候, 只要是用Java实现的经典框架, 你都可以去研究. ------在此申明一下, 我的意思不是说会用. 光会用其实是远远不够的, 你可以选择自己喜欢钻研的框架, 去好好研究一下, 兴趣是最好的老师嘛.(2009.07.21)

建议开始的时候, 研究Junit和Struts吧, 小一点, 里面都采用了很多的模式, 呵呵, 可以熟悉一下, 尽量想想人家为什么这么做. 我建议主要的精力可以花在spring和jboss上, 尤其是jboss,  经典中的经典, 设计, 性能, 多线程, 资源管理等等, 你从中可以学到的东西简直是太多了. 而且它还有一本写得很好的参考书, 叫<Jboss管理与开发核心技术>, 英文方面的资料也是非常的多. 在工作中如果有机会参与架构的设计, 业务问题的讨论, 一定想方设法杀进去! 这对自己的设计能力, 以及对设计如何运用在业务上有很大的帮助. 毕竟, 程序都是为了更好地实现用户的业务的. 这个时候, 需要更多看看软件工程和UML方面的资料, 或者自己主持一个项目玩玩, 不一定非得出去拉项目赚钱(能赚钱当然更好), 不管成功或失败, 都是很宝贵的经验, 都能提高很多!  

  最近在翻《首先，打破一切常规》,书不只翻一遍了,每次都会有一些新的收获.书中经常提到的6个问题越想越觉得有道理,列出跟大家分享:

1.你知道对你工作的要求吗?

第一优先级的问题,如果不知道对你的工作要求,那么你如何衡量你工作的好坏?其他人如何衡量你的工作成果?首当其冲需要考虑的问题.

2.你有做好你当前工作的材料和设备或者资源吗?

当然明确工作要求的时候需要明确你达到你目标的途径,此时需要衡量你能掌控的资源,或者你能够使用到的潜在资源.

3.在工作中你每天都有机会做你最擅长的事情吗?

是否能够发挥自己的潜力,是否是自己的兴趣爱好,是否能做的更好.

4.过去的7天内,你有因你的工作出色而受到表扬吗?

周围同事或者你的主管关注你的个人价值,为什么会受到表扬?是否可以在这件工作上受到一贯的认可.

5.你觉得你的主管或者同事关心你的个人情况吗?

恒定自己在团队中的作用,如果不关心,为什么?你是否了解过其他人的感受?如果关心?关心那点?如何满足期望.

6.工作单位里面有人会鼓励你的发展吗?

职业发展的考虑,企业是否值得呆下去,是否能够共同进步.

定期拿这些问题进行自勉,会有很多收获.包括你的同事,你的主管,你的合作伙伴,甚至会改变你的人生.

问题：

下面一个简单的类：

public class MyTest {
 private static String className = String.class.getName(); //红色部分是下面问题的关键
 public static void main(String[] args){
  System.out.println(className);   
 }
}

经eclipse3.1.1编译后(指定类兼容性版本为1.4)，再反编译的结果是：

public class MyTest
{

    public MyTest()
    {
    }

    public static void main(String args[])
    {
        System.out.println(className);
    }

    private static String className;

    static
    {
        className = java.lang.String.class.getName();
    }
}

而经过sun javac(或者ant, antx)编译后(JDK版本1.4，或者JDK1.5，但是编译结果指定版本为1.4)，再反编译的结果是：

public class MyTest
{

    public MyTest()
    {
    }

    public static void main(String args[])
    {
        System.out.println(className);
    }

    static Class _mthclass$(String x0)
    {
        return Class.forName(x0);
        ClassNotFoundException x1;
        x1;
        throw (new NoClassDefFoundError()).initCause(x1);
    }

    private static String className;

    static
    {
        className = (java.lang.String.class).getName();
    }
}

也就是说sun javac编译出来的结果里面多了一个_mthclass$方法，这个通常不会有什么问题，不过在使用hot swap技术(例如Antx eclipse plugin中的快速部署插件利用hot swap来实现类的热替换，或者某些类序列化的地方，这个就成为问题了。

用_mthclass$在google上搜一把，结果不多，比较有价值的是这一篇：http://coding.derkeiler.com/Archive/Java/comp.lang.java.softwaretools/2004-01/0138.html

按照这个说法，这个问题是由于Sun本身没有遵循规范，而eclipse compiler遵循规范导致的，而且eclipse compiler是没有办法替换的。

尝试将JDK版本换成1.5，sun javac生成出来的_mthclass$是不见了，不过，这回奇怪的是eclipse的编译结果中多了一个成员变量class$0，
下面是经eclipse3.1.1编译后(指定类兼容性版本为5.0)，再反编译的结果：
public class MyTest
{

    public MyTest()
    {
    }

    public static void main(String args[])
    {
        System.out.println(className);
    }

    private static String className = java/lang/String.getName();
    static Class class$0;

}
而经过sun javac(或者ant, antx)编译后(JDK版本1.5)，再反编译的结果是：
public class MyTest
{

    public MyTest()
    {
    }

    public static void main(String args[])
    {
        System.out.println(className);
    }

    private static String className = java/lang/String.getName();

}

再在goole上搜了一把，发现了Eclipse3.2有两个比较重要的特征：
1.与javac的兼容性更好。
2.提供了单独的编译器，可以在eclipse外部使用，包括ant中使用。

于是下载eclipse3.2版本，首先验证一下其与sun javac的兼容性如何，
使用JDK1.4版本的时候，还是老样子，sun javac编译出来的_mthclass$方法在eclipse3.2的编译结果中还是不存在，所以还是不兼容的。
不过使用JDK1.5版本的时候，这会eclipse 3.2的编译结果总算和sun javac一致了。

虽然，用JDK1.5加上eclipse 3.2已经保证了这个类在两种编译器下的兼容性，不过总觉得不踏实：
1.谁知道这两个编译器还有没有其它不兼容的地方呢？
2.版本要求太严格，很多由于各种原因没有使用这些版本的很麻烦。

因此，还是从根本上解决这个问题比较合适：根本上解决最好就是不要使用两种不同的编译器，而使用同一种。
由于eclipse环境下的编译器是不可替换的，所以企图都使用sun javac的方式不太可行，那么统一使用eclipse自带的编译器如何呢？
刚才提到的eclipse3.2的第二个比较重要的特性就派上用场了。
独立的eclipse编译器(1M大小而已)可以在如下地址下载：http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/drops/R-3.2-200606291905/ecj.jar
这个独立的编译器在antx下的使用也很简单：(关于该编译器的独立使用或者ant下面的使用可以参看this help section: JDT Plug-in Developer Guide>Programmer's Guide>JDT Core>Compiling Java code)
1.将下载下来的编译器放在ANTX_HOME/lib目录下面。
2.在总控项目文件的project.xml增加这么一行即可：<property name="build.compiler" value="org.eclipse.jdt.core.JDTCompilerAdapter"/>
这样就保证了通过antx打包的类也是用eclipse的编译器编译出来的，当然就不应该存在类不兼容的情况了。

实际上，eclipse3.1.1版本也已经提供了独立的eclipse编译器，不过当时并没有单独提供独立的包下载，如果希望使用3.1.1版本的eclipse编译器，可以使用org.eclipse.jdt.core_3.1.1.jar以及其中包含的jdtCompilerAdapter.jar。（eclipse3.1.1环境的编译器我没有独立验证过）