内部类

什么是 内部类 外部类？

外部类：

只能定义一个类名与文件名完全 致的公开类，使用public class 关键字来修饰。

内部类：

任何一个类都可以在内部定义另外一个或多个类

内部类本身就是 类的一个属性

 

属性字段 private static String str

由访问控制符、是否静态、类型、变量名

内部类 private static class Inner{}，

类型可以为 class、 enum，甚至是 interface，当然在内部类中定义接口是不推荐的。

内部类分为如下四种：

·静态内部类，如 static class StaticinnerC!ass {} ;

·成员内部类，如: private class InstancelnnerClass {} ;

·局部内部类，定义在方法或者表达式内部，
·匿名内部类，如: (new Thread(){} ).start()。

无论是什么类型的内部类，都会编译成一个独立的 .class 文件

外部类与内部类之间使用 $ 符号分隔 ，

匿名内部类使用数字进行编号 ， 而

方法内部类，在类名前还有一个编号来标识是哪个方法。

 

静态内部类是最常用的内部表现形式 ， 外部可以使用 OuterClass.StaticinnerClass 直接访问， 类加载与外部类在同一个阶段进行

好处：

( I )作用域不会扩散到包外。
( 2 )可以通过”外部类 . 内部类”的方式直接访问。
( 3 )内部类可以访问外部类中的所有静态属性和方法。

 

源码是在 ConcurrentHashMap 中定义的 Node 静态内部类 ， 用于表示一个节点数据， 属于包内可见，包内其他集合要用到这个 Node肘， 直接使用ConcurrentHashMap.Node

Node 的 父类 Entry 是 Map 的静态 内 部类 ， 之所以可以被 Node 成功继承 ， 是因为两个外部类同属一个包

 

内部类封装某种属性和操作的方式比较常见，比如

应用类加载器 Launcher 的 AppClassLoader, ReentrantLock 中继承自 AbstractQueuedSynchronizer的内部类 Sync, ArrayList中的私有静态内部类SubList

 

访问权限:

public:可以修饰外部类、属性、方法，表示公开的、无限制的，是访问限制最松的 一 级，被其修饰的类、属性和方法不仅可以被包内访问，还可以跨类、
跨包访问，甚至允许跨工程访问。

protected: 只能修饰属性和方法，表示受保护的、有限制的，被其修饰的属性和方法能被包内及包外子类访问。注意，即使并非继承关系， protected 属
性和方法在同一包内也是可见的。

无·即无任何访问权限控制符，如示例中的 noneMethod 方法，没有任何修饰符。千万不要说成 default， 它并非访问权限控制符的关键字 ，另外，在JDK8 接口中引入 default默认方法实现 ， 更加容易混淆两者释义。无访问权限控制符仅对包内可见。虽然无访问权限控制符还可以修饰外部类，但是定义外部类极少使用无控制符的方式，要么定义为内部类，功能内聚，要么定义公开类，即 public class，包外也可以实例化。

private 只能修饰 属性、方法、内部类。表示 私有的 权限最严格的一级，被其修饰的属性或方法只能在该类内部访问子类、包内均不能访问 ， 更不允许跨包访问。

 

定义类时，推荐访问控制级别从严处理：

( I )如果不允许外部直接通过 new 创建对象 ， 构造方法必须是 pnvale。

( 2 )工具类不允许有 public 或 default 构造方法。
( 3 )类非 static 成员变量并且与子类共享 ， 必须是 protected。
( 4 )类非 static 成员变量并且仅在本类使用 ， 必须是 private。

( 5 )类 static 成员变量如果仅在本类使用 ， 必须是 private

( 6 )若是 static 成员变量 ， 必须考虑是否为 final。
( 7 )类成员方法只供类内部调用 ， 必须是 private。
( 8 )类成员方法只对继承类公开 ， 那么限制为 protected。

 

对象实例化时，至少有 条从本类出发抵达 Object 的通路 ， 而打通这条路的两
个主要工兵就是 this 和 super，逢山开路 ， 遇水搭桥。但是 this和 super往往是默默无
闻的，在很多情况下可以省略，比如 .

· 本类方法调用本类属性。
· 本类方法调用另一个本类方法。

· 子类构造方法隐含调用 super()。

 

this与 super

 

类关系

·[ 继承 ] extends (is-a)。
·[ 实现 ] implements (can-do)。
·[ 组合 ] 类是成员变量 (contains-a)。

·{ 聚合 } 类是成员变量(has-a)。

·[依赖] import类(use-a)。

 

而类关系中的组合是一种完全绑定的关系，所有成员共同完成一件
使命 ， 它们的生命周期是一样的。组合体现的是非常强的整体与部分的关系， 同生共
死 ， 部分不能在整体之间共享。

 

聚合是一种可以拆分的整体与部分的关系 ， 是非常松散的暂时组合 ， 部分可以被
拆出来给另一个整体。

 

依赖是除组合和聚合外的类与类之间的关系 ， 这个类只要 import， 那就是依赖关系

在业务重构过程中，往往会把原来强组合的关系拆开来，供其他模块调用，这就是类图的一种演变。

 

 

方法：

方法签名： 1名称 2 参数列表

 

可变参数 适用于 参数个数不确定的场景

但是严重影响代码可读性以及可维护性 尽量不要使用 更不应该使用Object作为可变参数

入参保护：

限制入参个数 以及哪些参数必传

参数校验：

1 防御式编程 方法内进行参数校验

2 重复代码校验 影响性能

根据方法场景进行判断是否应该使用：

需要重复校验场景

·调用 频度低的方法。

·执行时 间开销很大的方法。此情形中 ， 参数校验时间几乎可以忽略不计 ， 但如果因为参数错误导致中间执行回退或者错误，贝 lj得不偿失。

·需要极高稳定性和可用性的方法。

· 对外提供的开放接口。
· 敏感权限入口。

 

不需要进行参数校验的场景

· 极有可能被循环调用的方法。但在方法说明里必须注明外部参数检查。

·底层 调用频度较高的方法。参数错误不太可能到底层才会暴露问题。一般DAO 层与 Service 层都在同 个应用中，部署在同 一台服务器中，所以可以省略 DAO 的参数校验。

·声明成 private 只会被自己代码调用的方法。如果能够确定调用方法的代码传入参数已经做过检查或者肯定不会有问题，此时可以不校验参数。

 

构造方法
构造方法( Constructor )是方法名与类名相同的特殊方法，在新建对象时调用，

可以通过不同的构造方法实现不同方式的对象初始化 ， 它有如下特征 ，

(I )构造方法名必须与类名相同。

( 2 )构造方法不能有返回类型 包括void，其返回对象的地址，并返回给引用变量

(3) 构造方法 不能被继承、覆写、直接调用。 调用方式： 1 通过new 关键字、2通过super调用父类构造方法 3 通过反射获取构造方法 并调用

( 4 )类定义时提供了默认的 无参数构造方法 但是如果显式定义了有参构造方法 ，则此无参构造方法就会被覆盖，如果依然想拥有，就需要进行显式定义。

( 5 )构造方法可以私有，外部无法使用私有构造方法创建对象，常用于单例模式的实现。

 

一个类可以有多个参数不同的构造方法，称为构造方法的重载

类中的其他同名方法应该被放置在一起

单一职责 ， 对于构造方法同样适用 ，构造方 法的使命就是在构造对象时进行传参操作，所以不应该在构造方法中引入业务逻辑。

 

类中的 static {...}代码被称为类的静态代码块，在类初始化时执行，优先级很高。

类加载过程：加载、验证、准备、解析、初始化五个阶段

加载：

    1、通过一个类的全限定名来获取其定义的二进制字节流。

    2、将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。

    3、在Java堆中生成一个代表这个类的java.lang.Class对象，作为对方法区中这些数据的访问入口。

 

类加载器：

站在Java虚拟机的角度来讲，只存在两种不同的类加载器：

启动类加载器：它使用C++实现（这里仅限于Hotspot，也就是JDK1.5之后默认的虚拟机，有很多其他的虚拟机是用Java语言实现的），是虚拟机自身的一部分。

所有其他的类加载器：这些类加载器都由Java语言实现，独立于虚拟机之外，并且全部继承自抽象类java.lang.ClassLoader，这些类加载器需要由启动类加载器加载到内存中之后才能去加载其他的类。

 

站在Java开发人员的角度来看，类加载器可以大致划分为以下三类：

1 启动类加载器：Bootstrap ClassLoader，跟上面相同。它负责加载存放在JDK\jre\lib(JDK代表JDK的安装目录，下同)下，或被-Xbootclasspath参数指定的路径中的，并且能被虚拟机识别的类库（如rt.jar，所有的java.*开头的类均被Bootstrap ClassLoader加载）。启动类加载器是无法被Java程序直接引用的。

2 扩展类加载器：Extension ClassLoader，该加载器由sun.misc.Launcher$ExtClassLoader实现，它负责加载JDK\jre\lib\ext目录中，或者由java.ext.dirs系统变量指定的路径中的所有类库（如javax.*开头的类），开发者可以直接使用扩展类加载器。

3 应用程序类加载器：Application ClassLoader，该类加载器由sun.misc.Launcher$AppClassLoader来实现，它负责加载用户类路径（ClassPath）所指定的类，开发者可以直接使用该类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

4 自定义类加载器

每一层上面的类加载器叫做当前层类加载器的父加载器

双亲委派模型的工作流程是：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把请求委托给父加载器去完成，依次向上，因此，所有的类加载请求最终都应该被传递到顶层的启动类加载器中，只有当父加载器在它的搜索范围中没有找到所需的类时，即无法完成该加载，子加载器才会尝试自己去加载该类。

    使用双亲委派模型来组织类加载器之间的关系，有一个很明显的好处，就是Java类随着它的类加载器（说白了，就是它所在的目录）一起具备了一种带有优先级的层次关系，这对于保证Java程序的稳定运作很重要。例如，类java.lang.Object类存放在JDK\jre\lib下的rt.jar之中，因此无论是哪个类加载器要加载此类，最终都会委派给启动类加载器进行加载，这边保证了Object类在程序中的各种类加载器中都是同一个类。

 

 验证

文件格式的验证、元数据的验证、字节码验证和符号引用验证。

文件格式的验证：验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理，该验证的主要目的是保证输入的字节流能正确地解析并存储于方法区之内。经过该阶段的验证后，字节流才会进入内存的方法区中进行存储，后面的三个验证都是基于方法区的存储结构进行的。

元数据验证：对类的元数据信息进行语义校验（其实就是对类中的各数据类型进行语法校验），保证不存在不符合Java语法规范的元数据信息。

字节码验证：该阶段验证的主要工作是进行数据流和控制流分析，对类的方法体进行校验分析，以保证被校验的类的方法在运行时不会做出危害虚拟机安全的行为。

符号引用验证：这是最后一个阶段的验证，它发生在虚拟机将符号引用转化为直接引用的时候（解析阶段中发生该转化，后面会有讲解），主要是对类自身以外的信息（常量池中的各种符号引用）进行匹配性的校验。

 

准备

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些内存都将在方法区中分配。对于该阶段有以下几点需要注意：

 1、这时候进行内存分配的仅包括类变量（static），而不包括实例变量，实例变量会在对象实例化时随着对象一块分配在Java堆中。

 2、这里所设置的初始值通常情况下是数据类型默认的零值（如0、0L、null、false等），而不是被在Java代码中被显式地赋予的值。

 

 解析

解析动作主要针对类或接口、字段、类方法、接口方法四类符号引用进行，分别对应于常量池中的CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info、CONSTANT_InterfaceMethodref_info四种常量类型。

    1、类或接口的解析：判断所要转化成的直接引用是对数组类型，还是普通的对象类型的引用，从而进行不同的解析。

    2、字段解析：对字段进行解析时，会先在本类中查找是否包含有简单名称和字段描述符都与目标相匹配的字段，如果有，则查找结束；如果没有，则会按照继承关系从上往下递归搜索该类所实现的各个接口和它们的父接口，还没有，则按照继承关系从上往下递归搜索其父类，直至查找结束，查找流程如下图所示：

3、类方法解析：对类方法的解析与对字段解析的搜索步骤差不多，只是多了判断该方法所处的是类还是接口的步骤，而且对类方法的匹配搜索，是先搜索父类，再搜索接口。

4、接口方法解析：与类方法解析步骤类似，知识接口不会有父类，因此，只递归向上搜索父接口就行了。

初始化

初始化阶段，则是根据程序员通过程序指定的主观计划去初始化类变量和其他资源，或者可以从另一个角度来表达：初始化阶段是执行类构造器<clinit>()方法的过程。

   这里简单说明下<clinit>（）方法的执行规则:

    1、<clinit>（）方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序所决定的，静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句中可以赋值，但是不能访问。

    2、<clinit>（）方法与实例构造器<init>（）方法（类的构造函数）不同，它不需要显式地调用父类构造器，虚拟机会保证在子类的<clinit>（）方法执行之前，父类的<clinit>（）方法已经执行完毕。因此，在虚拟机中第一个被执行的<clinit>（）方法的类肯定是java.lang.Object。

    3、<clinit>（）方法对于类或接口来说并不是必须的，如果一个类中没有静态语句块，也没有对类变量的赋值操作，那么编译器可以不为这个类生成<clinit>（）方法。

    4、接口中不能使用静态语句块，但仍然有类变量（final static）初始化的赋值操作，因此接口与类一样会生成<clinit>（）方法。但是接口鱼类不同的是：执行接口的<clinit>（）方法不需要先执行父接口的<clinit>（）方法，只有当父接口中定义的变量被使用时，父接口才会被初始化。另外，接口的实现类在初始化时也一样不会执行接口的<clinit>（）方法。

    5、虚拟机会保证一个类的<clinit>（）方法在多线程环境中被正确地加锁和同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的<clinit>（）方法，其他线程都需要阻塞等待，直到活动线程执行<clinit>（）方法完毕。如果在一个类的<clinit>（）方法中有耗时很长的操作，那就可能造成多个线程阻塞，在实际应用中这种阻塞往往是很隐蔽的。