java常见面试题（4）

接口和抽象类的区别？

接口和抽象类是java面向对象的两个基础机制。

接口是对行为的抽象，它是抽象方法的集合，利用接口可以达到API定义和实现分离的目的。接口，不能实例化；不能包含任何非常量成员，任何field都是隐含着public static final的意义；没有非静态方法实现，也就是要么是抽象方法，要么是静态方法。

抽象类是不能实例化的类，用关键字abstract修饰，其目的是代码重用。可以有一个或多个抽象方法，也可以没有抽象方法。抽象类大多用于抽取相关java类的公用方法或者共用成员变量，然后通过继承的方式打到代码复用的目的。

面向对象

基本要素：封装、继承、多态。

• 封装：隐藏事物内部的实现细节，以便提高安全性和简化编程。
• 继承：是代码复用的基础机制，继承可以看做是非常紧耦合的一种关系，父类代码修改，子类行为也会变动。在实践中，过度滥用继承，可能会起到反效果。
• 多态：提到多态可能会立马想到重写和重载。重写是父子类中相同名字和参数的方法，不同的实现；重载则是相同名字的方法，参数不同。注意方法名和参数相同，返回值不同在Java里不算有效的重载。

基本设计原则：

• 单一职责：类或者对象最好是单一职责，在程序设计中，如果发现某各类承担多个义务，最好进行拆分。
• 开关原则：设计要对扩展开放，对修改关闭。换句话说，程序设计应该保持平滑的扩展性，尽量避免新增同类功能而修改已有实现。
• 里氏替换：进行继承抽象关系时，凡是可以用父类或者基类的地方，都可以用子类替换。
• 接口分离：我们在进行类和接口设计时，如果在一个接口中定义太多的方法，其子类可能面临两难，就是只有部分方法对它是有意义的，这就破坏了程序的内聚性。这种情况我们可以通过拆分成功能单一的多个接口，将行为进行解耦。
• 依赖反转：实体应该依赖于抽象而不是实现。也就是说高层次模块不应该依赖于低层次模块，而是应该基于抽象。

注意：在java 10中引入了方法类型推断和var类型。看下面代码：

List<String> list = new ArrayList<>();

如果使用var类型：

var list = new ArrayList<>();

但是，list会被推断为new ArrayList<>(String);
理论上，这种语法上的便利增强了程序对实现的依赖，但是微小的类型泄露却带来了书写的便利和代码可读性的提高，所以实践中还是要按照得失利弊进行选择，而不是一味地遵循原则。

下面截取别人的代码：

public class VIPCenter {
  void serviceVIP(T extend User user>) {
     if (user instanceof SlumDogVIP) {
        // 穷 X VIP，活动抢的那种
        // do somthing
      } else if(user instanceof RealVIP) {
        // do somthing
      }
      // ...
  }

代码中存在的问题：业务逻辑集中在一起，当出现新的用户类型时，就需要直接去修改服务方法代码实现，这可能会影响到不相关的某个用户类型逻辑。

利用开关原则修改：

public class VIPCenter {
   private Map<User.TYPE, ServiceProvider> providers;
   void serviceVIP(T extend User user） {
      providers.get(user.getType()).service(user);
   }
 }
 interface ServiceProvider{
   void service(T extend User user) ;
 }
 class SlumDogVIPServiceProvider implements ServiceProvider{
   void service(T extend User user){
     // do somthing
   }
 }
 class RealVIPServiceProvider implements ServiceProvider{
   void service(T extend User user) {
     // do something
   }
 }

类加载过程，双亲委派模型

一般来说，java类加载过程分为三个主要步骤：加载、链接、初始化。

首先是加载阶段，它是将字节码数据从不同的数据源读取到JVM中，并映射为JVM认可的数据结构。加载阶段是用户参与的阶段，我们可以自定义类加载器，去实现自己的类加载过程。

第二阶段是链接，这是核心的步骤，简单说是把原始的类定义信息平滑的转化入JVM运行的过程中。这里可进一步细分为三个步骤：

• 验证：这是虚拟机安全的重要保障，JVM需要核验字节信息是符合Java虚拟机规范的，否则就被认为是VerifyError，这样就防止了恶意信息或者不合规的信息危害JVM的运行，验证阶段可能会出发更多class加载。
• 准备：创建类或接口中静态变量，并初始化静态变量的初始值。单这里“初始化”和下面的显式初始化阶段是有区别的，则重点在于分配所需要的内存空间，不会去执行更进一步的JVM指令。
• 解析：这一步会将常量池中的符号引用替换为直接引用。

最后是初始化阶段，这一步真正去执行类初始化的代码逻辑，包括静态字段赋值的操作，以及执行类定义中静态初始化块内的逻辑，编译器在编译阶段就会把这部分逻辑整理好，父类型的初始化逻辑优先于当前类型的逻辑。

双亲委派模型，简单说就是当类加载器试图加载某个类型的时候，除非父加载器找不到相应的类型，否则尽量将这个任务代理给当前加载器的父加载器去做。使用委派模型的目的就是避免重复加载java类型。

常量和不同的静态变量的区别：
定义如下类型，分别提供普通静态变量、静态常量，常量又考虑到原始数据类型和引用数据类型。

public class CLPreparation {
    public static int a = 100;
    public static final int INT_CONSTANT = 1000;
    public static final Integer INTEGER_CONSTANT = Integer.valueOf(10000);
}

编译并反编译一下：

Javac CLPreparation.java
Javap –v CLPreparation.class

可以在字节码中看到这样的额外初始化逻辑：

0: bipush        100
2: putstatic     #2                  // Field a:I
5: sipush        10000
8: invokestatic  #3            //Methodjava/lang/Integer.valueOf(I)Ljava/lang/Integer;
11: putstatic     #4                  // Field INTEGER_CONSTANT:Ljava/lang/Integer;

这让我们更加清楚，普通原始类型静态变量和引用类型，是需要额外调用putstatic等JVM指令的，这些是在显式初始化阶段执行的，而不是准备阶段调用；而原始类型常量不需要这样的步骤。

类加载器

• 启动类加载器(Bootstrap Class-Loader)，加载jre/lib下面jar文件。即使在开启了Security Manager的时候，JDK仍赋予了它加载的程序AllPermission。
• 扩展类加载器(Application or App Class-Loader)，加载我们最熟悉的classpath的内容。这里有一个容易混淆的概念，系统（System）类加载器，通常来说，其默认就是JDK内建的应用类加载器，但是它同样是可能修改的。
  

类加载机制的三个基本特征：

• 双亲委派模型。但不是所有类加载都遵守这个模型，有的时候，启动类加载器所加载的类型是可能加载用户代码的，比如JDK内部的ServiceProvider/ServiceLoader机制，用户可以在标准的API框架上提供自己的实现，JDK也需要提供些默认的参考实现 。例如，Java中JNDI、JDBC、文件系统、Cipher等很多方面，都是利用这种机制，不会用双亲委派模型去加载，而是利用所谓的上下文加载器。
• 可见性。子类加载器可以访问父类加载器的类型，但是反过来是不允许的，不然，因为缺少必要的隔离，我们就没有办法利用类加载器去实现容器的逻辑。
• 单一性。由于父加载器的类型对子加载器是可见的，所以父加载器中加载过的类型，就不会在爱加载器中重复加载。

JDK 9后，结合Layer，目前JVM内部结构变成了下面的层次：