局部内部类和非静态成员内部类

关于为什么局部内部类只能访问final变量和非静态成员内部类为什么不能定义static成员的问题，csdn的解答比较清楚，借鉴：

第一个问题：LLC必须访问方法内中final的变量或者参数归根到底是由于LLC所在方法中的局部变量的生命周期要短于LLC的生命周期。
描述：LLC定义在方法的内部，它可以访问方法中的变量和参数，当方法被调用时，局部变量和参数在栈内存中入栈，然后再在堆内存中创建一个内部类对象，方法调用结束后栈内存中的变量和参数就出栈消亡了，但是堆内存中的内部类对象是在没有对象变量引用它的时候才会被垃圾回收器给回收了，所以完全可能一个方法已调用结束（局部变量已死亡），但该局部类的对象仍然活着。即：局部类的对象生命期会超过局部变量。如果此时再调用LLC对象的方法，会由于局部变量不能访问发生编译错误，
解决办法：LLC对象可以访问同一个方法中被定义为final的局部变量。定义为final后，编译程序的实现方法：将所有的LLC对象要访问的final型局部变量，都拷贝成为该内部类对象中的一个数据成员。这样，即使栈中局部变量（含final）已死亡，但由于它是final,其值永不变，因而LLC对象在局部变量死亡后，照样可以访问final型局部变量。

第二个问题：这个跟编译器的内存处理有关系，静态成员变量需要在一开始就分配内存进行初始化，而一般的类成员只是在类实例化的时候才会为止分配内存初始化，从方面来说，假如允许非静态类中有静态成员变量，如下面所示：

    class A{ 
        public class B{ 
            static string var_a; 
        } 
    } 

那么在程序一开始就需要给A.B.var_a分配内存并初始化，假如这个成立了，那么A.B也应该会有相应的内存，但是由于B只是A的一个非静态成员变量，在类A还没有实例化的时候就以及有了相应的内存(也就是非静态成员变量只有在类的实例中才会有相应的内存位置)，这样跟原来的标准有冲突，假如JAVA编译器（或者JAVA虚拟机）支持这种做法（其实也是可以实现的），这有的后果会导致编译器混乱无序的，大大增加了编译器的难度和复杂性，每一种语言都有预先制定好的语言标准，相对应的编译器都是基于这种标准来实现的，假如随意突破这种标准，那只会导致灾难性的后果而已。

参考：
http://topic.csdn.net/u/20091003/18/c2d31cda-0e0f-4598-8f2e-becfb718c14b.html?17058