Java最常用面试知识总结-持续更新中

古城微笑少年丶 2022-11-09 14:18 228阅读 0赞

# 框架： #

## 1. Spring ##

### 1.1 原理 ###

Spring是一个轻量级的控制反转(IoC)的容器和面向切面(AOP)的框架。

### 1.2 Spring IoC ###

控制反转，把对象创建的过程和对象之间的调用过程交给spring管理。

#### 1.2.1 底层原理 ####

xml解析，工厂模式，反射。

**单例模式**：单例模式要求某一类能够有返回对象一个引用(永远是同一个)和一个获得该实例的方法（必须是静态方法，通常使用getInstance这个名称）。  
![单例模式][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xhczcyMw_size_16_color_FFFFFF_t_70]

**工厂模式**：为创建对象提供过渡接口，以便将创建对象的具体过程（new 关键字和具体的构造器）隐藏起来。用一个工厂方法来替代，对外提供的只是一个工厂方法，达到提高灵活性的目的。在工厂方法模式中，核心的工厂类不再负责所有的产品的创建，而是将具体创建的工作交给子类去做。该核心类成为一个抽象工厂角色，仅负责给出具体工厂子类必须实现的接口，而不接触哪一个产品类应当被实例化这种细节。  
![工厂模式][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xhczcyMw_size_16_color_FFFFFF_t_70 1]

**反射**：JAVA反射机制是在运行状态中，对于任意一个类，都能够知道这个类的所有属性和方法；对于任意一个对象，都能够调用它的任意方法和属性；  
这种动态获取信息以及动态调用对象方法的功能称为java语言的反射机制。

**Bean管理**：spring创建对象，spring注入属性

#### 1.2.2 Spring的IOC有三种注入方式 ####

构造器注入、setter方法注入、根据注解注入。

### 1.3 Spring AOP ###

面向切面编程，不修改源码进行主干功能增强。

#### 1.3.1 底层原理 ####

AOP实现的关键在于 代理模式，AOP代理主要分为静态代理和动态代理。静态代理的代表为AspectJ；动态代理则以Spring AOP为代表。

*  Spring AOP 属于运行时增强，而 AspectJ 是编译时增强。 Spring AOP 基于代理(Proxying)，而 AspectJ 基于字节码操作(Bytecode Manipulation)。
 *  Spring AOP 已经集成了 AspectJ ，AspectJ 应该算的上是 Java 生态系统中最完整的 AOP 框架了。AspectJ 相比于 Spring AOP 功能更加强大，但是 Spring AOP 相对来说更简单，
 *  如果我们的切面比较少，那么两者性能差异不大。但是，当切面太多的话，最好选择 AspectJ ，它比Spring AOP 快很多。

动态代理的角色和静态代理的一样 ，动态代理的代理类是动态生成的 . 静态代理的代理类是我们提前写好的。  
Spring AOP中的动态代理主要有两种方式，（有接口的情况下）JDK动态代理和（没有接口的情况下）CGLIB动态代理。

##### 1）代理模式 #####

代理模式是23种设计模式的一种，他是指一个对象A通过持有另一个对象B，可以具有B同样的行为的模式。为了对外开放协议，B往往实现了一个接口，A也会去实现接口。但是B是“真正”实现类，A则比较“虚”，他借用了B的方法去实现接口的方法。A虽然是“伪军”，但它可以增强B，在调用B的方法前后都做些其他的事情。Spring AOP就是使用了动态代理完成了代码的动态“织入”。  
使用代理好处还不止这些，一个工程如果依赖另一个工程给的接口，但是另一个工程的接口不稳定，经常变更协议，就可以使用一个代理，接口变更时，只需要修改代理，不需要一一修改业务代码。从这个意义上说，所有调外界的接口，我们都可以这么做，不让外界的代码对我们的代码有侵入，这叫防御式编程。代理其他的应用可能还有很多。  
上述例子中，类A写死持有B，就是B的静态代理。如果A代理的对象是不确定的，就是动态代理。动态代理目前有两种常见的实现，jdk动态代理和cglib动态代理。

##### 2）JDK动态代理 #####

jdk动态代理是jre提供给我们的类库，可以直接使用，不依赖第三方。  
先看下jdk动态代理的使用代码，再理解原理。

首先有个“明星”接口类，有唱、跳两个功能：

package proxy;
     
    public interface Star
    { 
        String sing(String name);
        
        String dance(String name);
    }

再有个明星实现类“刘德华”：

package proxy;
     
    public class LiuDeHua implements Star
    {    
        @Override
        public String sing(String name)
        { 
             System.out.println("给我一杯忘情水");
     
            return "唱完" ;
        }
        
        @Override
        public String dance(String name)
        { 
            System.out.println("开心的马骝");
     
            return "跳完" ;
        }
    }

明星演出前需要有人收钱，由于要准备演出，自己不做这个工作，一般交给一个经纪人。便于理解，它的名字以Proxy结尾，但他不是代理类，原因是它没有实现我们的明星接口，无法对外服务，它仅仅是一个wrapper。

package proxy;
     
    import java.lang.reflect.InvocationHandler;
    import java.lang.reflect.Method;
    import java.lang.reflect.Proxy;
     
    public class StarProxy implements InvocationHandler
    { 
        // 目标类，也就是被代理对象
        private Object target;
        
        public void setTarget(Object target)
        { 
            this.target = target;
        }
        
        @Override
        public Object invoke(Object proxy, Method method, Object[] args) throws Throwable
        { 
            // 这里可以做增强
            System.out.println("收钱");
            
            Object result = method.invoke(target, args);
            
            return result;
        }
        
        // 生成代理类
        public Object CreatProxyedObj()
        { 
            return Proxy.newProxyInstance(target.getClass().getClassLoader(), target.getClass().getInterfaces(), this);
        }  
       
    }

上述例子中，方法CreatProxyedObj返回的对象才是我们的代理类，它需要三个参数，前两个参数的意思是在同一个classloader下通过接口创建出一个对象，该对象需要一个属性，也就是第三个参数，它是一个InvocationHandler。需要注意的是这个CreatProxyedObj方法不一定非得在我们的StarProxy类中，往往放在一个工厂类中。上述代理的代码使用过程一般如下：

1、new一个目标对象  
2、new一个InvocationHandler，将目标对象set进去  
3、通过CreatProxyedObj创建代理对象，强转为目标对象的接口类型即可使用，实际上生成的代理对象实现了目标接口。

Star ldh = new LiuDeHua();
     
            StarProxy proxy = new StarProxy();
     
            proxy.setTarget(ldh); 
      
            Object obj = proxy.CreatProxyedObj();
            
            Star star = (Star)obj;

Proxy（jdk类库提供）根据B的接口生成一个实现类，我们成为C，它就是动态代理类（该类型是 $Proxy+数字 的“新的类型”）。生成过程是：由于拿到了接口，便可以获知接口的所有信息（主要是方法的定义），也就能声明一个新的类型去实现该接口的所有方法，这些方法显然都是“虚”的，它调用另一个对象的方法。当然这个被调用的对象不能是对象B，如果是对象B，我们就没法增强了，等于饶了一圈又回来了。

所以它调用的是B的包装类，这个包装类需要我们来实现，但是jdk给出了约束，它必须实现InvocationHandler，上述例子中就是StarProxy， 这个接口里面有个方法，它是所有Target的所有方法的调用入口（invoke），调用之前我们可以加自己的代码增强。

看下我们的实现，我们在InvocationHandler里调用了对象B（target）的方法，调用之前增强了B的方法。

@Override
        public Object invoke(Object proxy, Method method, Object[] args) throws Throwable
        { 
            // 这里增强
            System.out.println("收钱");
            
            Object result = method.invoke(target, args);
            
            return result;
        }

所以可以这么认为C代理了InvocationHandler，InvocationHandler代理了我们的类B，两级代理。

> 整个JDK动态代理的秘密也就这些，简单一句话，动态代理就是要生成一个包装类对象，由于代理的对象是动态的，所以叫动态代理。由于我们需要增强，这个增强是需要留给开发人员开发代码的，因此代理类不能直接包含被代理对象，而是一个InvocationHandler，该InvocationHandler包含被代理对象，并负责分发请求给被代理对象，分发前后均可以做增强。从原理可以看出，JDK动态代理是“对象”的代理。

下面看下动态代理类到底如何调用的InvocationHandler的，为什么InvocationHandler的一个invoke方法能为分发target的所有方法。C中的部分代码示例如下，通过反编译生成后的代码查看，摘自[链接地址][Link 1]。Proxy创造的C是自己（Proxy）的子类，且实现了B的接口，一般都是这么修饰的：

public final class XXX extends Proxy implements XXX

一个方法代码如下：

public final String SayHello(String paramString)
      { 
        try
        { 
          return (String)this.h.invoke(this, m4, new Object[] {  paramString });
        }
        catch (Error|RuntimeException localError)
        { 
          throw localError;
        }
        catch (Throwable localThrowable)
        { 
          throw new UndeclaredThrowableException(localThrowable);
        }

可以看到，C中的方法全部通过调用h实现，其中h就是InvocationHandler，是我们在生成C时传递的第三个参数。这里还有个关键就是SayHello方法（业务方法）跟调用invoke方法时传递的参数m4一定要是一一对应的，但是这些对我们来说都是透明的，由Proxy在newProxyInstance时保证的。留心看到C在invoke时把自己this传递了过去，InvocationHandler的invoke的第一个方法也就是我们的动态代理实例类，业务上有需要就可以使用它。（所以千万不要在invoke方法里把请求分发给第一个参数，否则很明显就死循环了）

C类中有B中所有方法的成员变量

private static Method m1;
      private static Method m3;
      private static Method m4;
      private static Method m2;
      private static Method m0;

这些变量在static静态代码块初始化，这些变量是在调用invocationhander时必要的入参，也让我们依稀看到Proxy在生成C时留下的痕迹。

static
      { 
        try
        { 
          m1 = Class.forName("java.lang.Object").getMethod("equals", new Class[] {  Class.forName("java.lang.Object") });
          m3 = Class.forName("jiankunking.Subject").getMethod("SayGoodBye", new Class[0]);
          m4 = Class.forName("jiankunking.Subject").getMethod("SayHello", new Class[] {  Class.forName("java.lang.String") });
          m2 = Class.forName("java.lang.Object").getMethod("toString", new Class[0]);
          m0 = Class.forName("java.lang.Object").getMethod("hashCode", new Class[0]);
          return;
        }
        catch (NoSuchMethodException localNoSuchMethodException)
        { 
          throw new NoSuchMethodError(localNoSuchMethodException.getMessage());
        }
        catch (ClassNotFoundException localClassNotFoundException)
        { 
          throw new NoClassDefFoundError(localClassNotFoundException.getMessage());
        }
      }

从以上分析来看，要想彻底理解一个东西，再多的理论不如看源码，底层的原理非常重要。

**jdk动态代理类图如下**  
![jdk动态代理][jdk]

##### 3）CGLIB动态代理 #####

我们先通过一个demo看一下Cglib是如何实现动态代理的。

首先定义个服务类，有两个方法并且其中一个方法用final来修饰。

public class PersonService { 
        public PersonService() { 
            System.out.println("PersonService构造");
        }
        //该方法不能被子类覆盖
        final public Person getPerson(String code) { 
            System.out.println("PersonService:getPerson>>"+code);
            return null;
        }
    
        public void setPerson() { 
            System.out.println("PersonService:setPerson");
        }
    }

Cglib是无法代理final修饰的方法的，具体原因我们一会通过源码来分析。

然后，定义一个自定义MethodInterceptor。

public class CglibProxyIntercepter implements MethodInterceptor { 
        @Override
        public Object intercept(Object sub, Method method, Object[] objects, MethodProxy methodProxy) throws Throwable { 
            System.out.println("执行前...");
            Object object = methodProxy.invokeSuper(sub, objects);
            System.out.println("执行后...");
            return object;
        }
    }

我们看一下intercept方法入参，sub：cglib生成的代理对象，method：被代理对象方法，objects：方法入参，methodProxy:代理方法

最后，我们写个例子调用一下，并将Cglib生成的代理类class文件输出磁盘方便我们反编译查看源码。

public class Test { 
        public static void main(String[] args) { 
            //代理类class文件存入本地磁盘
            System.setProperty(DebuggingClassWriter.DEBUG_LOCATION_PROPERTY, "D:\\code");
            Enhancer enhancer = new Enhancer();
            enhancer.setSuperclass(PersonService.class);
            enhancer.setCallback(new CglibProxyIntercepter());
            PersonService proxy= (PersonService)  enhancer.create();
            proxy.setPerson();
            proxy.getPerson("1"); 
        } }
    }

我们执行一下会发现getPerson因为加final修饰并没有被代理，下面我们通过源码分析一下。

执行前...
    PersonService:setPerson
    执行后...
    PersonService:getPerson>>1

**生成代理类**  
执行Test测试类可以得到Cglib生成的class文件，一共有三个class文件我们反编译以后逐个说一下他们的作用。

`PersonService$$EnhancerByCGLIB$$eaaaed75`就是cglib生成的代理类，它继承了PersonService类。

public class PersonService$$EnhancerByCGLIB$$eaaaed75
      extends PersonService
      implements Factory
    { 
      private boolean CGLIB$BOUND;
      private static final ThreadLocal CGLIB$THREAD_CALLBACKS;
      private static final Callback[] CGLIB$STATIC_CALLBACKS;
      private MethodInterceptor CGLIB$CALLBACK_0;//拦截器
      private static final Method CGLIB$setPerson$0$Method;//被代理方法
      private static final MethodProxy CGLIB$setPerson$0$Proxy;//代理方法
      private static final Object[] CGLIB$emptyArgs;
      private static final Method CGLIB$finalize$1$Method;
      private static final MethodProxy CGLIB$finalize$1$Proxy;
      private static final Method CGLIB$equals$2$Method;
      private static final MethodProxy CGLIB$equals$2$Proxy;
      private static final Method CGLIB$toString$3$Method;
      private static final MethodProxy CGLIB$toString$3$Proxy;
      private static final Method CGLIB$hashCode$4$Method;
      private static final MethodProxy CGLIB$hashCode$4$Proxy;
      private static final Method CGLIB$clone$5$Method;
      private static final MethodProxy CGLIB$clone$5$Proxy;
      
      static void CGLIB$STATICHOOK1()
      { 
        CGLIB$THREAD_CALLBACKS = new ThreadLocal();
        CGLIB$emptyArgs = new Object[0];
        Class localClass1 = Class.forName("com.demo.proxy.cglib.PersonService$$EnhancerByCGLIB$$eaaaed75");//代理类
        Class localClass2;//被代理类PersionService
        Method[] tmp95_92 = ReflectUtils.findMethods(new String[] {  "finalize", "()V", "equals", "(Ljava/lang/Object;)Z", "toString", "()Ljava/lang/String;", "hashCode", "()I", "clone", "()Ljava/lang/Object;" }, (localClass2 = Class.forName("java.lang.Object")).getDeclaredMethods());
        CGLIB$finalize$1$Method = tmp95_92[0];
        CGLIB$finalize$1$Proxy = MethodProxy.create(localClass2, localClass1, "()V", "finalize", "CGLIB$finalize$1");
        Method[] tmp115_95 = tmp95_92;
        CGLIB$equals$2$Method = tmp115_95[1];
        CGLIB$equals$2$Proxy = MethodProxy.create(localClass2, localClass1, "(Ljava/lang/Object;)Z", "equals", "CGLIB$equals$2");
        Method[] tmp135_115 = tmp115_95;
        CGLIB$toString$3$Method = tmp135_115[2];
        CGLIB$toString$3$Proxy = MethodProxy.create(localClass2, localClass1, "()Ljava/lang/String;", "toString", "CGLIB$toString$3");
        Method[] tmp155_135 = tmp135_115;
        CGLIB$hashCode$4$Method = tmp155_135[3];
        CGLIB$hashCode$4$Proxy = MethodProxy.create(localClass2, localClass1, "()I", "hashCode", "CGLIB$hashCode$4");
        Method[] tmp175_155 = tmp155_135;
        CGLIB$clone$5$Method = tmp175_155[4];
        CGLIB$clone$5$Proxy = MethodProxy.create(localClass2, localClass1, "()Ljava/lang/Object;", "clone", "CGLIB$clone$5");
        tmp175_155;
        Method[] tmp223_220 = ReflectUtils.findMethods(new String[] {  "setPerson", "()V" }, (localClass2 = Class.forName("com.demo.proxy.cglib.PersonService")).getDeclaredMethods());
        CGLIB$setPerson$0$Method = tmp223_220[0];
        CGLIB$setPerson$0$Proxy = MethodProxy.create(localClass2, localClass1, "()V", "setPerson", "CGLIB$setPerson$0");
        tmp223_220;
        return;
      }

我们通过代理类的源码可以看到，代理类会获得所有在父类继承来的方法，并且会有MethodProxy与之对应，`比如 Method CGLIB$setPerson$0$Method、MethodProxy CGLIB$setPerson$0$Proxy;`

方法的调用

//代理方法（methodProxy.invokeSuper会调用）
       final void CGLIB$setPerson$0() { 
          super.setPerson();
       }
       //被代理方法(methodProxy.invoke会调用，这就是为什么在拦截器中调用methodProxy.invoke会死循环，一直在调用拦截器)
       public final void setPerson() { 
          MethodInterceptor var10000 = this.CGLIB$CALLBACK_0;
          if(this.CGLIB$CALLBACK_0 == null) { 
             CGLIB$BIND_CALLBACKS(this);
             var10000 = this.CGLIB$CALLBACK_0;
          }
    
          if(var10000 != null) { 
             //调用拦截器
             var10000.intercept(this, CGLIB$setPerson$0$Method, CGLIB$emptyArgs, CGLIB$setPerson$0$Proxy);
          } else { 
             super.setPerson();
          }
       }

调用过程：代理对象调用this.setPerson方法->调用拦截器->methodProxy.invokeSuper->CGLIB$setPerson$0->被代理对象setPerson方法

**MethodProxy**  
拦截器MethodInterceptor中就是由MethodProxy的invokeSuper方法调用代理方法的，MethodProxy非常关键，我们分析一下它具体做了什么。

*  创建MethodProxy

public class MethodProxy { 
        private Signature sig1;
        private Signature sig2;
        private MethodProxy.CreateInfo createInfo;
        private final Object initLock = new Object();
        private volatile MethodProxy.FastClassInfo fastClassInfo;
        //c1:被代理对象Class
        //c2:代理对象Class
        //desc：入参类型
        //name1:被代理方法名
        //name2:代理方法名
        public static MethodProxy create(Class c1, Class c2, String desc, String name1, String name2) { 
            MethodProxy proxy = new MethodProxy();
            proxy.sig1 = new Signature(name1, desc);//被代理方法签名
            proxy.sig2 = new Signature(name2, desc);//代理方法签名
            proxy.createInfo = new MethodProxy.CreateInfo(c1, c2);
            return proxy;
        }
    private static class CreateInfo { 
        Class c1;
        Class c2;
        NamingPolicy namingPolicy;
        GeneratorStrategy strategy;
        boolean attemptLoad;
    
        public CreateInfo(Class c1, Class c2) { 
            this.c1 = c1;
            this.c2 = c2;
            AbstractClassGenerator fromEnhancer = AbstractClassGenerator.getCurrent();
            if(fromEnhancer != null) { 
                this.namingPolicy = fromEnhancer.getNamingPolicy();
                this.strategy = fromEnhancer.getStrategy();
                this.attemptLoad = fromEnhancer.getAttemptLoad();
            }
    
        }
    }

*  invokeSuper调用

public Object invokeSuper(Object obj, Object[] args) throws Throwable { 
            try { 
                this.init();
                MethodProxy.FastClassInfo fci = this.fastClassInfo;
                return fci.f2.invoke(fci.i2, obj, args);
            } catch (InvocationTargetException var4) { 
                throw var4.getTargetException();
            }
        }
    private static class FastClassInfo { 
        FastClass f1;//被代理类FastClass
        FastClass f2;//代理类FastClass
        int i1; //被代理类的方法签名(index)
        int i2;//代理类的方法签名
    
        private FastClassInfo() { 
        }
    }

上面代码调用过程就是获取到代理类对应的FastClass，并执行了代理方法。还记得之前生成三个class文件吗？`PersonService$$EnhancerByCGLIB$$eaaaed75$$FastClassByCGLIB$$355cb7ea.class`就是代理类的FastClass，  
`PersonService$$FastClassByCGLIB$$a076b035.class`就是被代理类的FastClass。

**FastClass机制**  
Cglib动态代理执行代理方法效率之所以比JDK的高是因为Cglib采用了FastClass机制，它的原理简单来说就是：为代理类和被代理类各生成一个Class，这个Class会为代理类或被代理类的方法分配一个index(int类型)。  
这个index当做一个入参，FastClass就可以直接定位要调用的方法直接进行调用，这样省去了反射调用，所以调用效率比JDK动态代理通过反射调用高。下面我们反编译一个FastClass看看：

//根据方法签名获取index
     public int getIndex(Signature var1) { 
          String var10000 = var1.toString();
          switch(var10000.hashCode()) { 
          case -2077043409:
             if(var10000.equals("getPerson(Ljava/lang/String;)Lcom/demo/pojo/Person;")) { 
                return 21;
             }
             break;
          case -2055565910:
             if(var10000.equals("CGLIB$SET_THREAD_CALLBACKS([Lnet/sf/cglib/proxy/Callback;)V")) { 
                return 12;
             }
             break;
          case -1902447170:
             if(var10000.equals("setPerson()V")) { 
                return 7;
             }
             break;
       //省略部分代码.....
    　
     //根据index直接定位执行方法
     public Object invoke(int var1, Object var2, Object[] var3) throws InvocationTargetException { 
          eaaaed75 var10000 = (eaaaed75)var2;
          int var10001 = var1;
    
          try { 
             switch(var10001) { 
             case 0:
                return new Boolean(var10000.equals(var3[0]));
             case 1:
                return var10000.toString();
             case 2:
                return new Integer(var10000.hashCode());
             case 3:
                return var10000.newInstance((Class[])var3[0], (Object[])var3[1], (Callback[])var3[2]);
             case 4:
                return var10000.newInstance((Callback)var3[0]);
             case 5:
                return var10000.newInstance((Callback[])var3[0]);
             case 6:
                var10000.setCallback(((Number)var3[0]).intValue(), (Callback)var3[1]);
                return null;
             case 7:
                var10000.setPerson();
                return null;
             case 8:
                var10000.setCallbacks((Callback[])var3[0]);
                return null;
             case 9:
                return var10000.getCallback(((Number)var3[0]).intValue());
             case 10:
                return var10000.getCallbacks();
             case 11:
                eaaaed75.CGLIB$SET_STATIC_CALLBACKS((Callback[])var3[0]);
                return null;
             case 12:
                eaaaed75.CGLIB$SET_THREAD_CALLBACKS((Callback[])var3[0]);
                return null;
             case 13:
                return eaaaed75.CGLIB$findMethodProxy((Signature)var3[0]);
             case 14:
                return var10000.CGLIB$toString$3();
             case 15:
                return new Boolean(var10000.CGLIB$equals$2(var3[0]));
             case 16:
                return var10000.CGLIB$clone$5();
             case 17:
                return new Integer(var10000.CGLIB$hashCode$4());
             case 18:
                var10000.CGLIB$finalize$1();
                return null;
             case 19:
                var10000.CGLIB$setPerson$0();
                return null;
            //省略部分代码....
          } catch (Throwable var4) { 
             throw new InvocationTargetException(var4);
          }
    
          throw new IllegalArgumentException("Cannot find matching method/constructor");
       }

FastClass并不是跟代理类一块生成的，而是在第一次执行MethodProxy invoke/invokeSuper时生成的并放在了缓存中。

//MethodProxy invoke/invokeSuper都调用了init()
    private void init() { 
            if(this.fastClassInfo == null) { 
                Object var1 = this.initLock;
                synchronized(this.initLock) { 
                    if(this.fastClassInfo == null) { 
                        MethodProxy.CreateInfo ci = this.createInfo;
                        MethodProxy.FastClassInfo fci = new MethodProxy.FastClassInfo();
                        fci.f1 = helper(ci, ci.c1);//如果缓存中就取出，没有就生成新的FastClass
                        fci.f2 = helper(ci, ci.c2);
                        fci.i1 = fci.f1.getIndex(this.sig1);//获取方法的index
                        fci.i2 = fci.f2.getIndex(this.sig2);
                        this.fastClassInfo = fci;
                        this.createInfo = null;
                    }
                }
            }
    
        }

至此，Cglib动态代理的原理我们就基本搞清楚了，代码细节有兴趣可以再研究下。

##### 4）JDK动态代理和Gglib动态代理的区别： #####

> 1.JDK动态代理是实现了被代理对象的接口，Cglib是继承了被代理对象。  
> 2.JDK和Cglib都是在运行期生成字节码，JDK是直接写Class字节码，Cglib使用ASM框架写Class字节码，Cglib代理实现更复杂，生成代理类比JDK效率低。  
> 3.JDK调用代理方法，是通过反射机制调用，Cglib是通过FastClass机制直接调用方法，Cglib执行效率更高。

> JDK: java动态代理是利用反射机制生成一个实现代理接口的匿名类，在调用具体方法前调用InvokeHandler来处理。  
> CGKIB: cglib动态代理是利用asm开源包，对代理对象类的class文件加载进来，通过修改其字节码生成子类来处理，主要是对指定的类生成一个子类，覆盖其中的方法（继承）。  
> 1、如果目标对象实现了接口，默认情况下会采用JDK的动态代理实现AOP  
> 2、如果目标对象实现了接口，可以强制使用CGLIB实现AOP  
> 3、如果目标对象没有实现了接口，必须采用CGLIB库，spring会自动在JDK动态代理和CGLIB之间转换  
> 如何强制使用CGLIB实现AOP？  
> （1）添加CGLIB库，SPRING\_HOME/cglib/\*.jar  
> （2）在spring配置文件中加入<aop:aspectj-autoproxy proxy-target-class=“true”/>  
> JDK动态代理和CGLIB字节码生成的区别？  
> （1）JDK动态代理只能对实现了接口的类生成代理，而不能针对类  
> （2）CGLIB是针对类实现代理，主要是对指定的类生成一个子类，覆盖其中的方法, 因为是继承，所以该类或方法最好不要声明成final

#### 1.3.2 AOP名词解释 ####

![spring AOP][]

### 1.4 Spring Bean的生命周期？ ###

实例化bean对象、注入bean初始化init、接收请求service、容器关闭销毁调用destroy方法

> 1.Bean容器找到配置文件中Spring Bean的定义。  
> 2.Bean容器利用Java Reflection API创建一个Bean的实例。  
> 3.如果涉及到一些属性值，利用set()方法设置一些属性值。  
> 4.如果Bean实现了BeanNameAware接口，调用setBeanName()方法，传入Bean的名字。  
> 5.如果Bean实现了BeanClassLoaderAware接口，调用setBeanClassLoader()方法，传入ClassLoader对象的实例。  
> 6.如果Bean实现了BeanFactoryAware接口，调用setBeanClassFacotory()方法，传入ClassLoader对象的实例。  
> 7.与上面的类似，如果实现了其他\*Aware接口，就调用相应的方法。  
> 8.如果有和加载这个Bean的Spring容器相关的BeanPostProcessor对象，执行postProcessBeforeInitialization()方法。  
> 9.如果Bean实现了InitializingBean接口，执行afeterPropertiesSet()方法。  
> 10.如果Bean在配置文件中的定义包含init-method属性，执行指定的方法。  
> 11.如果有和加载这个Bean的Spring容器相关的BeanPostProcess对象，执行postProcessAfterInitialization()方法。  
> 12.当要销毁Bean的时候，如果Bean实现了DisposableBean接口，执行destroy()方法。  
> 13.当要销毁Bean的时候，如果Bean在配置文件中的定义包含destroy-method属性，执行指定的方法。

![spring bean生命周期][spring bean]

### 1.5 Spring中bean的作用域： ###

> 1.**singleton**：Spring中的bean默认都是单例的，这种范围确保不管接受到多个请求，每个容器中有一个bean的实例，单利模式由bean factory自身来维护。  
> 2.**prototype**：与单例范围相反，为每一个bean请求提供一个实例。  
> 3.**request**：每一次HTTP请求都会产生一个新的bean，该bean仅在当前HTTP request内有效，在请求完成之后，bean会失效并被垃圾回收器回收。  
> 4.**session**：同一个HttpSession共享同一个Bean，不同的HttpSession使用不同的Bean，该bean仅在当前HTTP session内有效，在session过期后bean会随之消失。  
> 5.**global-session**：同一个全局Session共享一个Bean，仅仅在基于Portlet的Web应用中才有意义，Spring5中已经没有了。Portlet是能够生成语义代码（例如HTML）片段的小型Java Web插件。它们基于Portlet容器，可以像Servlet一样处理HTTP请求。但是与Servlet不同，每个Portlet都有不同的会话。

### 1.6 Spring框架中的Bean是线程安全的么？如果线程不安全，那么如何处理？ ###

Spring容器本身并没有提供Bean的线程安全策略，因此可以说Spring容器中的Bean本身不具备线程安全的特性，但是具体情况还是要结合Bean的作用域来讨论。  
（1）对于prototype作用域的Bean，每次都创建一个新对象，也就是线程之间不存在Bean共享，因此不会有线程安全问题。  
（2）对于singleton作用域的Bean，所有的线程都共享一个单例实例的Bean，因此是存在线程安全问题的。但是如果单例Bean是一个无状态Bean，也就是线程中的操作不会对Bean的成员执行查询以外的操作，那么这个单例Bean是线程安全的。比如Controller类、Service类和Dao等，这些Bean大多是无状态的，只关注于方法本身。  
对于有状态的bean（比如Model和View），就需要自行保证线程安全，最浅显的解决办法就是将有状态的bean的作用域由“singleton”改为“prototype”。  
也可以采用ThreadLocal解决线程安全问题，为每个线程提供一个独立的变量副本，不同线程只操作自己线程的副本变量。

### 1.7 Spring的自动装配： ###

#### 1）在Spring框架xml配置中共有5种自动装配： ####

no：默认的方式是不进行自动装配的，通过手工设置ref属性来进行装配bean。  
byName：通过bean的名称进行自动装配，如果一个bean的 property 与另一bean 的name 相同，就进行自动装配。  
byType：通过参数的数据类型进行自动装配。  
constructor：利用构造函数进行装配，并且构造函数的参数通过byType进行装配。  
autodetect：自动探测，如果有构造方法，通过 construct的方式自动装配，否则使用 byType的方式自动装配。

#### 2）基于注解的自动装配方式： ####

使用@Autowired、@Resource注解来自动装配指定的bean。在使用@Autowired注解之前需要在Spring配置文件进行配置，<context:annotation-config />。在启动spring IoC时，容器自动装载了一个AutowiredAnnotationBeanPostProcessor后置处理器，当容器扫描到@Autowied、@Resource或@Inject时，就会在IoC容器自动查找需要的bean，并装配给该对象的属性。在使用@Autowired时，首先在容器中查询对应类型的bean：  
![@Autowired @Resource][Autowired _Resource]

### 1.8 Spring事务管理的方式有几种？ ###

> 1.编程式事务：在代码中硬编码（不推荐使用）。  
> 2.声明式事务：在配置文件中配置（推荐使用），分为基于XML的声明式事务和基于注解的声明式事务。

### 1.9 Spring事务中的隔离级别有哪几种？ ###

在TransactionDefinition接口中定义了五个表示隔离级别的常量：

> ISOLATION\_DEFAULT：使用后端数据库默认的隔离级别，Mysql默认采用的REPEATABLE\_READ隔离级别；Oracle默认采用的READ\_COMMITTED隔离级别。  
> ISOLATION\_READ\_UNCOMMITTED：最低的隔离级别，允许读取尚未提交的数据变更，可能会导致脏读、幻读或不可重复读。  
> ISOLATION\_READ\_COMMITTED：允许读取并发事务已经提交的数据，可以阻止脏读，但是幻读或不可重复读仍有可能发生  
> ISOLATION\_REPEATABLE\_READ：对同一字段的多次读取结果都是一致的，除非数据是被本身事务自己所修改，可以阻止脏读和不可重复读，但幻读仍有可能发生。  
> ISOLATION\_SERIALIZABLE：最高的隔离级别，完全服从ACID的隔离级别。所有的事务依次逐个执行，这样事务之间就完全不可能产生干扰，也就是说，该级别可以防止脏读、不可重复读以及幻读。但是这将严重影响程序的性能。通常情况下也不会用到该级别。

### 1.10 Spring事务中有哪几种事务传播行为？ ###

在TransactionDefinition接口中定义了八个表示事务传播行为的常量。

> **1）支持当前事务的情况**：  
> PROPAGATION\_REQUIRED：如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务。  
> PROPAGATION\_SUPPORTS： 如果当前存在事务，则加入该事务；如果当前没有事务，则以非事务的方式继续运行。  
> PROPAGATION\_MANDATORY： 如果当前存在事务，则加入该事务；如果当前没有事务，则抛出异常。（mandatory：强制性）。  
> **2）不支持当前事务的情况**：  
> PROPAGATION\_REQUIRES\_NEW： 创建一个新的事务，如果当前存在事务，则把当前事务挂起。  
> PROPAGATION\_NOT\_SUPPORTED： 以非事务方式运行，如果当前存在事务，则把当前事务挂起。  
> PROPAGATION\_NEVER： 以非事务方式运行，如果当前存在事务，则抛出异常。  
> **3）其他情况**：  
> PROPAGATION\_NESTED： 如果当前存在事务，则创建一个事务作为当前事务的嵌套事务来运行；如果当前没有事务，则该取值等价于PROPAGATION\_REQUIRED。

### 1.11 Spring框架中用到了哪些设计模式 ###

> 1.工厂设计模式：Spring使用工厂模式通过BeanFactory和ApplicationContext创建bean对象。  
> 2.代理设计模式：Spring AOP功能的实现。  
> 3.单例设计模式：Spring中的bean默认都是单例的。  
> 4.模板方法模式：Spring中的jdbcTemplate、hibernateTemplate等以Template结尾的对数据库操作的类，它们就使用到了模板模式。  
> 5.包装器设计模式：我们的项目需要连接多个数据库，而且不同的客户在每次访问中根据需要会去访问不同的数据库。这种模式让我们可以根据客户的需求能够动态切换不同的数据源。  
> 6.观察者模式：Spring事件驱动模型就是观察者模式很经典的一个应用。  
> 7.适配器模式：Spring AOP的增强或通知（Advice）使用到了适配器模式、Spring MVC中也是用到了适配器模式适配Controller。  
> 。。。

### 1.12 Spring MVC的了解？ ###

MVC是一种设计模式，Spring MVC是一款很优秀的MVC框架。Spring MVC可以帮助我们进行更简洁的Web层的开发，并且它天生与Spring框架集成。Spring MVC下我们一般把后端项目分为Service层（处理业务）、Dao层（数据库操作）、Entity层（实体类）、Controller层（控制层，返回数据给前台页面）。

**Spring MVC的原理**图如下：  
![Spring MVC原理][Spring MVC]

**流程说明**：  
1.客户端（浏览器）发送请求，直接请求到DispatcherServlet。  
2.DispatcherServlet根据请求信息调用HandlerMapping，解析请求对应的Handler。  
3.解析到对应的Handler（也就是我们平常说的Controller控制器）。  
4.HandlerAdapter会根据Handler来调用真正的处理器来处理请求和执行相对应的业务逻辑。  
5.处理器处理完业务后，会返回一个ModelAndView对象，Model是返回的数据对象，View是逻辑上的View。  
6.ViewResolver会根据逻辑View去查找实际的View。  
7.DispatcherServlet把返回的Model传给View（视图渲染）。  
8.把View返回给请求者（浏览器）。

## 2. hibernate ##

## 3. mybatis ##

## 4. spring boot ##

# 微服务架构： #

## 1. spring cloud ##

## 2. dubbo ##

# 数据库： #

## 1. MySQL ##

## 2. mongoDB ##

# 缓存： #

## 1. redis ##

## 2. memcached ##

# 容器组件： #

## 1. Tomcat ##

## 2. Jetty ##

## 3. Nginx ##

# 消息组件： #

## 1. rabbitMQ ##

## 2. kafka ##

# java知识： #

## 1. jvm ##

## 2. 并发 ##

## 3. 多线程 ##

# 数据结构： #

## 1. 队列 ##

## 2. 集合 ##

## 3. 链表、数组 ##

## 4. 栈 ##

## 5. 树 ##

## 6. BitSet ##

# 算法： #

## 1. 选择排序 ##

## 2. 冒泡排序 ##

## 3. 快速排序 ##

## 4. 二分查找 ##

## 5. 布隆过滤器 ##

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xhczcyMw_size_16_color_FFFFFF_t_70]: /images/20221023/9c3fdd4f95a942ada75aa95479c9bcff.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xhczcyMw_size_16_color_FFFFFF_t_70 1]: /images/20221023/b84f7526824b4bbb8d2bea48dbadf3d0.png
[Link 1]: https://blog.csdn.net/jiankunking/article/details/52143504
[jdk]: /images/20221023/85f37e8f5b5045488b6b9e780c4f2d62.png
[spring AOP]: /images/20221023/3e8e031df34d429894f9ef193082eb16.png
[spring bean]: /images/20221023/eb1ca6a7cbfa463582fdb914e72088cf.png
[Autowired _Resource]: /images/20221023/d39f70ad5ef44fafa1bb5f91c605a823.png
[Spring MVC]: /images/20221023/5b824ad275df49b1b2c7c0d2ec208e32.png