众所周知，我们的 C++ 程序语言是多继承制的，而多继承明显的好处就是，相对而言只需要写较少的代码即可完成一个类的定义，因为我们可以通过继承其它类来获取别人的实现。
但是，它也有一个致命性的缺陷，容易出现「钻石继承结构」，例如：
C 和 D 继承自 A，并得到 A 的 name 属性，那么如果有一个类 B 多继承自 C 和 D，请问 D 该如何取舍这两个相同的属性字段？
一般这种情况下，编译器会提示错误，以警示程序员修改代码。当然，C++ 通过 virtual 关键字以虚拟继承的方式解决了这个问题，具体细节大家可以自行参照 C++ 的语法进行了解。
但是，Java 从一开始就觉得 C++ 的多继承会是一个「麻烦」，所以 Java 是单根继承机制，不允许多继承。网上看到有人用一个词评论了 sun 公司的这种做法，觉得挺贴切的，叫「矫枉过正」，多继承也不是一无是处，在一些需要大量复用代码的情境下，也不失为一个好的解决方式。
所以，jdk 推出了「内部类」的概念，当然，内部类不仅仅弥补了 Java 不能多继承的一个不足，通过将一个类定义在另一个类的内部，也可以有效的隐藏该类的可见性，等等。
接口 + 内部类 = 多继承
在这之前，Java 的继承机制主要由接口和单根继承实现，通过实现多个接口里的方法，看似能够实现多继承，但是并不总是高效的，因为一旦我们继承了一个接口就必然要实现它内部定义的所有方法。
现在我们可以通过内部类多次继承某个具体类或者接口，省去一些不必要的实现动作。只能说 Java 的内部类完善了它的多继承机制，而不是主要实现，因为内部类终究是一种破坏封装性的设计，除非有很强的把控能力，否则还是越少用越好。
我们看一段代码：
public class Father {
public String powerFul = "市长";
}
public class Mother {
public String wealthy = "一百万";
}
public class Son {
class Extends_Father extends Father{
}
class Extends_Mother extends Mother{
}
public void sayHello(){
String father = new Extends_Father().powerFul;
String mother = new Extends_Mother().wealthy;
}
}
显然，我们的 Son 类是不可能同时继承 Father 和 Mother 的，但是我们却可以通过在其内部定义内部类继承了 Father 和 Mother，必要的情况下，我们还能够重写继承而来的各个类的属性或者方法。
这就是典型的一种通过内部类实现多继承的实现方式，但是同时你也会发现，单单从 Son 来外表看，你根本不知道它内部多继承了 Father 和 Mother，从而往往会给我们带来一些错觉。所以你看，内部类并不绝对是一个好东西，它破坏了封装性，用的不好反而会适得其反，让你的程序一团糟，所以谨慎！
当然，并不是贬低它的价值，有些情况下它也能给你一种「四两拨千斤」的感觉，省去很多麻烦。下面我们看看几种不同的内部类类型。
静态内部类
静态内部类通过对定义在外部类内部的类加上关键字「static」进行修饰，以标示一个静态内部类，例如：
public class OuterClass {
private static String name = "hello world";
private int age = 23;
public static class MyInnerClass{
private static String myName = "single";
private int myAge = 23;
public void sayHello(){
//编译器报错提示：不可访问的字段 age
}
}
}
首先，MyInnnerClass 作为一个内部类，它可以定义自己的静态属性，静态方法，实例属性，实例方法，和普通类一样。
此外，由于 MyInnerClass 作为一个内部类，它对于外部类 OuterClass 中部分成员也是可见的，但并全部可见，不同类型的内部类可见的外部类成员不尽相同，例如我们的静态内部类对于外部类的以下成员时可见的：
静态属性
静态方法
所以，我们上述的例子中，外部类 OuterClass 的实例属性 age 对于静态内部类 MyInnerClass 是不可见的。
那么 Java 是如何做到在一个类的内部定义另一个类的呢？
实际上编译器在编译我们的外部类的时候，会扫描其内部是否还存在其他类型的定义，如果有那么会「搜集」这些类的代码，并按照某种特殊名称规则单独编译这些类。正如我们上述的 MyInnerClass 内部类会被单独编译成 OuterClass$MyInnerClass.class 文件。
当然，这里的特殊命名规则其实就是：外部类名 + $ + 内部类名。
那么，既然内部类会被单独编译出来，那它如何保持与外部类的联系呢，我们反编译一下字节码文件。
由于静态内部类内部只能访问它的外部内的静态成员，而对于访问权限可见的情况下，这两个类本质上毫无关联，但如果像我们此例中的外部类属性 name 而言，它本身被修饰为 private，不可见于外部的任何类。
但是对于某个外部类的内部类而言，即便是被修饰为 private 的成员，它应当也是可见于内部类的任意位置的。
所以我们的编译器「偷偷的」做了一件事情，为被修饰为 private 的静态字段 name 提供一个包范围可见的静态方法，返回对 name 的引用，正如我们这里的方法：access$000一样。
你当然也可以猜测出，如果是修改 name 值的操作，想必也会对应一个这样的方法用于设置私有成员的属性值。
如果你想要在外部直接创建一个静态内部类的实例，也是被允许的。例如：
public static void main(String[] args){
//创建静态内部类实例
OuterClass.MyInnerClass innerClass = new OuterClass.MyInnerClass();
innerClass.sayHello();
}
当然，这样的操作一般也不被推荐，因为一个内部类既然被定义在某个外围类的内部，那它一定是为这个外围类服务的，而你从外部越过外围类而单独创建内部类的实现显然是不符合面向对象设计思想的。
静态内部类的应用场景其实还是很多的，但有一个基本的设计准则是，静态内部类不需要依赖外围类的实例，独立于外围类，为外围类提供服务。
例如我们 Integer 类中的 IntegerCache 就是一个静态的内部类，它不需要访问外围类中任何成员，却通过内部定义的一些属性和方法为外围类提供缓存服务。
成员内部类
成员内部类不使用「static」关键字修饰，但却与「静态内部类」有着截然不同的特性。例如：
public class OuterClass {
private int age = 23;
public class MyInnerClass{
//编译不通过，非静态的内部类是不允许拥有静态的属性和方法的
private static String name;
private String name2 = "hello";
public void sayHello(){
}
}
}
成员内部类的实例创建需要依赖外围类，也就是没有外围类实例就不会有内部类实例，外围类的静态或非静态成员对于成员内部类而言全部可见。
但是成员内部类之中不允许定义静态成员，原因也很简单，假如允许定义静态成员，那么我们下面这条语句必然是可行的。
但是我们说，既然成员内部类必须关联一个外围类实例，那么这种不需要依赖外围类实例即可操作内部类的方式是不是有点违背设计了呢？
于是 Java 干脆不允许成员内部类中定义静态的成员。
当然，如果你想要从外部直接创建一个成员内部类的实例，你可以这样做：
public static void main(String[] args){
OuterClass outerClass = new OuterClass();
OuterClass.MyInnerClass myInnerClass = outerClass.new MyInnerClass();
myInnerClass.sayHello();
}
同样的，Java 并不推荐这样使用内部类，内部类更适合作为一种工具提供给它的外围类。
接着，我们看看成员内部类的实现原理：
内部类：
我们先看内部类的构造器，实际上每当实例化一个内部类实例的时候，都会传入一个外围类实例引用作为构造参数，内部类保存这个实例引用并通过它访问该引用所对应的外围类成员属性。
成员内部类与静态内部类最大的不同点就在于，成员内部类高度依赖一个外围类实例，并且不允许定义任何静态成员，而静态内部类与外围类趋于独立。
局部内部类
局部内部类就是在代码块中定义一个类，最典型的应用是在方法中定义一个类。例如：
public class Method {
private static String name;
private int age;
public void hello(){
class MyInnerClass{
public void sayHello(){
}
}
}
}
局部内部类中是可以访问外围类的相关属性或者方法的，但是往往限制于外围的方法。如果方法是实例方法，那么方法内的内部类可以访问外围类的任意成员，如果方法是静态方法，那么方法内部的内部类只能访问外围类的静态成员。
考虑另一种情况，当方法具有参数或方法内定义了局部变量，那么我们的局部内部类还能够访问到它们吗？
public class Method2 {
public void hello(String name){
int age = 23;
class MyInnerClass{
public void sayHello(){
}
}
}
}
答案是能的，我们看一下它的反编译代码：
同样的套路，通过构造器传入外围类实例以实现内部类对外围类成员的访问。除此之外，如果外围类的方法中有参数或者定义了局部变量，编译器会搜集并在构建局部内部类实例的时候全部传入。
但是，这里有一个坑大家需要注意一下。虽然这里的 name 和 age 并没有被声明为 final，但是程序是不允许你修改它们的值的。也就是说，它们被默认添加了 final 修饰符。
为什么这么做？
从我们反编译的结果来看，局部内部类中只保存的这些变量的数值，而不是内存地址，并且也不允许更改，那么如果外部的这些变量可更改，将直接导致每个新建内部类的实例具有不同的属性值，所以直接给声明为 final，不允许你修改。
（这个特性以前貌似是需要程序员手动添加 final 进行修饰的，现在好像是默认的，害我还郁闷了半天，为什么不加 final 也能通过编译。。后来手动改它的值，发现不能改）
匿名内部类
匿名内部类，顾名思义，是没有名字的类，那么既然它没有名字，自然也就无法显式的创建出其实例对象了，所以匿名内部类适合那种只使用一次的情境，例如：
这就是一个典型的匿名内部类的使用，它等效于下面的代码：
public class MyObj extends Object{
@Override
public String toString(){
return "hello world";
}
}
public static void main(String[] args){
Object obj = new MyObj();
}
为了一个只使用一次的类而单独创建一个 .java 文件，是否有些浪费和繁琐？
在我看来，匿名内部类最大的好处就在于能够简化代码块。
匿名类的基本使用语法格式如下：
new 父类/接口{
//匿名类的实现
}
匿名内部类往往是对某个父类或者接口的继承与实现，我们再看一段代码：
public static void main(String[] args){
Date date = new Date(123313){
@Override
public String toString(){
return "hello";
}
};
}
我们这里定义了一个匿名内部类，实现了父类 Date，并重写了其 toString 方法。我们反编译一下：
显然，我们匿名内部类的构造器会调用相对应的父类构造器进行父类成员的初始化动作。而匿名内部类的本质也就这样，只是你看不到名字而已，其实编译器还是会为它生成单独的一份 Class 文件并拥有唯一的类名的。
其实你从编译器的层面上看，匿名内部类和一个实际的类型相差无几，它也能继承某个类并重写其中方法，实现某个接口的所有方法等。最吸引人的可能就是它无需单独创建类文件的简便性。
说句实话，内部类在实际的开发中并不常见，甚至被某些公司抵制使用，因为一旦你使用的不好很可能导致整个项目代码混乱不堪，不易于排查错误。但是如果你用的好的话，往往会给你有一种「巧劲」，你就比如我们的 jdk 源码，几乎每个类中都定义有一至多个内部类，并且相互之间不存在问题，很高效。
所以，内部类的使用还是适情况，适人而定，但是看的懂内部类却是你应当具有的能力，这也是本篇文章的目标。
还没有评论，来说两句吧...