本文共 9157 字，大约阅读时间需要 30 分钟。
昨天有一个比较爱思考的同事和我提起一个问题：为什么匿名内部类使用的局部变量和参数需要final修饰，而外部类的成员变量则不用？对这个问题我一直作为默认的语法了，木有仔细想过为什么（在分析完后有点印象在哪本书上看到过，但是就是没有找到，难道是我的幻觉？呵呵）。虽然没有想过，但是还是借着之前研究过字节码的基础上，分析了一些，感觉上是找到了一些答案，分享一下；也希望有大牛给指出一些不足的地方。 假如我们有以下的代码：
这里因为param要在匿名内部类的print()方法中使用，因而它要用final修饰；local/local2是局部变量，因而也需要final修饰；而field是外部类MyApplication的字段，因而不需要final修饰。这种设计是基于什么理由呢？
我想这个问题应该从Java是如何实现匿名内部类的。其中有两点：
1. 匿名内部类可以使用外部类的变量（局部或成员变来那个）2. 匿名内部类中不同的方法可以共享这些变量
根据这两点信息我们就可以分析，可能这些变量会在匿名内部类的字段中保存着，并且在构造的时候将他们的值/引用传入内部类。这样就可以保证同时实现上述两点了。
事实上，Java就是这样设计的，并且所谓匿名类，其实并不是匿名的，只是编译器帮我们命名了而已。这点我们可以通过这两个类编译出来的字节码看出来：
从这两段字节码中可以看出，编译器为我们的匿名类起了一个叫MyApplication$1的名字，它包含了三个final字段（这里synthetic修饰符是指这些字段是由编译器生成的，它们并不存在于源代码中）：
MyApplication的应用this$0
long值val$local2
Integer引用val$param
这些字段在构造函数中赋值，而构造函数则是在MyApplication.print()方法中调用。
由此，我们可以得出一个结论：Java对匿名内部类的实现是通过编译器来支持的，即通过编译器帮我们产生一个匿名类的类名，将所有在匿名类中用到的局部变量和参数做为内部类的final字段，同是内部类还会引用外部类的实例。其实这里少了local的变量，这是因为local是编译器常量，编译器对它做了替换的优化。
其实Java中很多语法都是通过编译器来支持的，而在虚拟机/字节码上并没有什么区别，比如这里的final关键字，其实细心的人会发现在字节码中，param参数并没有final修饰，而final本身的很多实现就是由编译器支持的。类似的还有Java中得泛型和逆变、协变等。这是题外话。
有了这个基础后，我们就可以来分析为什么有些要用final修饰，有些却不用的问题。
首先我们来分析local2变量，在”匿名类”中，它是通过构造函数传入到”匿名类”字段中的，因为它是基本类型，因而在够着函数中赋值时（撇开对函数参数传递不同虚拟机的不同实现而产生的不同效果），它事实上只是值的拷贝；因而加入我们可以在”匿名类”中得print()方法中对它赋值，那么这个赋值对外部类中得local2变量不会有影响，而程序员在读代码中，是从上往下读的，所以很容易误认为这段代码赋值会对外部类中得local2变量本身产生影响，何况在源码中他们的名字都是一样的，所以我认为了避免这种confuse导致的一些问题，Java设计者才设计出了这样的语法。
对引用类型，其实也是一样的，因为引用的传递事实上也只是传递引用的数值（简单的可以理解成为地址），因而对param，如果可以在”匿名类”中赋值，也不会在外部类的print()后续方法产生影响。虽然这样，我们还是可以在内部类中改变引用内部的值的，如果引用类型不是只读类型的话；在这里Integer是只读类型，因而我们没法这样做。（如果学过C++的童鞋可以想想常量指针和指针常量的区别）。
现在还剩下最后一个问题：为什么引用外部类的字段却是可以不用final修饰的呢？细心的童鞋可能也已经发现答案了，因为内部类保存了外部类的引用，因而内部类中对任何字段的修改都回真实的反应到外部类实例本身上，所以不需要用final来修饰它。
这个问题基本上就分析到这里了，不知道我有没有表达清楚了。
加点题外话吧。
首先是，对这里的字节码，其实还有一点可以借鉴的地方，就是内部类在使用外部类的字段时不是直接取值，而是通过编译器在外部类中生成的静态的access$0()方法来取值，我的理解，这里Java设计者想尽量避免其他类直接访问一个类的数据成员，同时生成的access$0()方法还可以被其他类所使用，这遵循了面向对象设计中的两个重要原则：封装和复用。
另外，对这个问题也让我意识到了即使是语言语法层面上的设计都是有原因可循的，我们要善于多问一些为什么，理解这些设计的原因和局限，记得曾听到过一句话：知道一门技术的局限，我们才能很好的理解这门技术可以用来做什么。也只有这样我们才能不断的提高自己。在解决了这个问题后，我突然冒出了一句说Java这样设计也是合理的。是啊，语法其实就一帮人创建的一种解决某些问题的方案，当然有合理和不合理之分，我们其实不用对它视若神圣。
之前有进过某著名高校的研究生群，即使在那里，码农论也是甚嚣尘上，其实码农不码农并不是因为程序员这个职位引起的，而是个人引起的，我们要不断理解代码内部的本质才能避免一直做码农的命运那。个人愚见而已，呵呵。
转载地址：http://qbjix.baihongyu.com/