Java框架入门篇——Spring

前言

  学习基础的时候大家应该都知道，最传统的Java Web应用程序是采用JSP、Servlet、Javabean来实现的，这种模式实现了最基本的MVC分层，使的程序结构有负责前台展示的 JSP、负责流程逻辑控制的Servlet以及负责数据封装的Javabean，但是这种结构存在问题如JSP页面中需要使用符号嵌入很多的 Java代码，造成页面结构混乱，Servlet和Javabean负责了大量的跳转和运算工作，耦合紧密，程序复用度低等。
  Spring框架的出现就解决了这个问题，通过IOC和AOP两大特性的加持，把所有类之间的这种依赖关系完全通过配置文件的方式替代了，同时将实体bean很好的管理到了容器中，使得耦合性大大降低，复用性大大提高。
  Spring的重要性：后端框架的老大，无论你在后端开发中使用什么样的技术栈，它一定（几乎100%）都和Spring这个框架相关，所以学习好这个框架才算是入门后端开发。

1、Spring是什么?

  Spring是一个轻量级控制反转(IoC)和面向切面(AOP)的容器框架。（这句话的每一个词都值得细细推敲）
轻量——从大小与开销两方面而言Spring都是轻量的。完整的Spring框架可以在一个大小只有1MB多的JAR文件里发布。并且Spring所需的处理开销也是微不足道的。此外，Spring是非侵入式的：典型地，Spring应用中的对象不依赖于Spring的特定类。
控制反转——Spring通过一种称作控制反转（IoC）的技术促进了松耦合。当应用了IoC，一个对象依赖的其它对象会通过被动的方式传递进来，而不是这个对象自己创建或者查找依赖对象。你可以认为IoC与JNDI相反——不是对象从容器中查找依赖，而是容器在对象初始化时不等对象请求就主动将依赖传递给它。
面向切面——Spring提供了面向切面编程的丰富支持，允许通过分离应用的业务逻辑与系统级服务（例如审计（auditing）和事务（transaction）管理）进行内聚性的开发。应用对象只实现它们应该做的——完成业务逻辑——仅此而已。它们并不负责（甚至是意识）其它的系统级关注点，例如日志或事务支持。
容器——Spring包含并管理应用对象的配置和生命周期，在这个意义上它是一种容器，你可以配置你的每个bean如何被创建——基于一个可配置原型（prototype），你的bean可以创建一个单独的实例或者每次需要时都生成一个新的实例——以及它们是如何相互关联的。然而，Spring不应该被混同于传统的重量级的EJB容器，它们经常是庞大与笨重的，难以使用。
框架——Spring可以将简单的组件配置、组合成为复杂的应用。在Spring中，应用对象被声明式地组合，典型地是在一个XML文件里。Spring也提供了很多基础功能（事务管理、持久化框架集成等等），将应用逻辑的开发留给了你。

  所有Spring的这些特征使你能够编写更干净、更可管理、并且更易于测试的代码。它们也为Spring中的各种模块提供了基础支持。

2、Spring 的优点？

1、非侵入式设计
  Spring是一种非侵入式（non-invasive）框架，它可以使应用程序代码对框架的依赖最小化。
   简单说一下我的理解吧。假设大家都想要把用户代码塞到一个框架里。侵入式的做法就是要求用户代码“知道”框架的代码，表现为用户代码需要继承框架提供的类。非侵入式则不需要用户代码引入框架代码的信息，从类的编写者角度来看，察觉不到框架的存在。 使用spring，编写一些业务类的时候不需要继承spring特定的类，通过配置完成依赖注入后就可以使用，此时，spring就没有侵入到我业务类的代码里。 侵入式让用户代码产生对框架的依赖，这些代码不能在框架外使用，不利于代码的复用。
   简单来说，非侵入式就是不继承框架提供的类，而是通过配置完成依赖注入后，就可以使用。
  优点：允许所开发出来的应用系统能够在不同的环境中自由移植，不需要修改应用系统中的核心功能实现的代码，利于代码的复用。
2、方便解耦、简化开发
  Spring就是一个大工厂，可以将所有对象的创建和依赖关系的维护工作都交给Spring容器的管理，大大的降低了组件之间的耦合性。
3、支持AOP
  Spring提供了对AOP的支持，它允许将一些通用任务，如安全、事物、日志等进行集中式处理，从而提高了程序的复用性。
4、支持声明式事务处理
  只需要通过配置就可以完成对事物的管理，而无须手动编程。
5、方便程序的测试
  Spring提供了对Junit4的支持，可以通过注解方便的测试Spring程序。
6、方便集成各种优秀框架
  Spring不排斥各种优秀的开源框架，其内部提供了对各种优秀框架（如SpringMVC、Struts、MyBatis、Hibernate等等）的直接支持。
7、降低Jave EE API的使用难度。
  Spring对Java EE开发中非常难用的一些API（如JDBC等），都提供了封装，使这些API应用难度大大降低。

3、Spring的IoC理解

  所谓控制反转就是指：由Spring框架来统一管理创建对象，（本来实例对象是由调用者来创建的，这样耦合性会太强）。只需要在Spring的配置文件中配置相应的bean对象以及相关的属性，让Spring容器来生成并管理类的实例对象。最直观的表达就是，IOC让对象的创建不用去new了，可以由spring自动生成，使用java的反射机制，根据配置文件，在运行时动态的去创建对象以及管理对象，并调用对象的方法。
  实现IOC需要DI技术支持。依赖注入（DI）有两种种方式：
  1.构造器依赖注入：构造器依赖注入通过容器触发一个类的构造器来实现的，该类有一系列参数，每个参数代表一个对其他类的依赖。
  2.Setter方法注入：Setter方法注入是容器通过调用无参构造器或无参static工厂方法实例化bean之后，调用该bean的setter方法，即实现了基于setter的依赖注入。
  最好的解决方案是用构造器参数实现强制依赖，setter方法实现可选依赖。

4、Spring的AOP理解

  OOP面向对象，允许开发者定义纵向的关系，但并不适用于定义横向的关系，导致了大量代码的重复，而不利于各个模块的重用。
  AOP，一般称为面向切面，作为面向对象的一种补充，用于将那些与业务无关，但却对多个对象产生影响的公共行为和逻辑，抽取并封装为一个可重用的模块，这个模块被命名为“切面”（Aspect），减少系统中的重复代码，降低了模块间的耦合度，同时提高了系统的可维护性。可用于权限认证、日志、事务处理。
  AOP实现的关键是实现代理模式，将通知通过配置注入目标对象实现动态代理的过程即为AOP。简单理解就是：Spring AOP能帮我们产生动态代理对象，所谓的动态代理就是说AOP框架不会去修改字节码，而是每次运行时在内存中临时为方法生成一个AOP对象，这个AOP对象包含了目标对象的全部方法，并且在特定的切点做了增强处理，并回调原对象的方法。
  Spring AOP中的动态代理主要有两种方式，JDK动态代理和CGLIB动态代理：
  ①JDK动态代理只提供接口的代理，不支持类的代理。核心InvocationHandler接口和Proxy类，InvocationHandler 通过invoke()方法反射来调用目标类中的代码，动态地将横切逻辑和业务编织在一起；接着，Proxy利用 InvocationHandler动态创建一个符合某一接口的的实例, 生成目标类的代理对象。
   ②如果代理类没有实现 InvocationHandler 接口，那么Spring AOP会选择使用CGLIB来实现动态代理目标类。CGLIB（Code Generation Library），是一个代码生成的类库，可以在运行时动态的生成指定类的一个子类对象，并覆盖其中特定方法并添加增强代码，从而实现AOP。CGLIB是通过继承的方式做的动态代理，因此如果某个类被标记为final，那么它是无法使用CGLIB做动态代理的。
  静态代理与动态代理区别在于生成AOP代理对象的时机不同，相对来说AspectJ的静态代理方式具有更好的性能，但是AspectJ需要特定的编译器进行处理，而Spring AOP则无需特定的编译器处理。
   InvocationHandler 的 invoke(Object proxy,Method method,Object[] args)：proxy是最终生成的代理实例; method 是被代理目标实例的某个具体方法; args 是被代理目标实例某个方法的具体入参, 在方法反射调用时使用。

5、BeanFactory和ApplicationContext有什么区别？

   BeanFactory和ApplicationContext是Spring的两大核心接口，都可以当做Spring的容器。其中ApplicationContext是BeanFactory的子接口。
（1）BeanFactory：是Spring里面最底层的接口，包含了各种Bean的定义，读取bean配置文档，管理bean的加载、实例化，控制bean的生命周期，维护bean之间的依赖关系。ApplicationContext接口作为BeanFactory的派生，除了提供BeanFactory所具有的功能外，还提供了更完整的框架功能：
  ①继承MessageSource，因此支持国际化。
  ②统一的资源文件访问方式。
  ③提供在监听器中注册bean的事件。
  ④同时加载多个配置文件。
  ⑤载入多个（有继承关系）上下文 ，使得每一个上下文都专注于一个特定的层次，比如应用的web层。
（2）①BeanFactroy采用的是延迟加载形式来注入Bean的，即只有在使用到某个Bean时(调用getBean())，才对该Bean进行加载实例化。这样，我们就不能发现一些存在的Spring的配置问题。如果Bean的某一个属性没有注入，BeanFacotry加载后，直至第一次使用调用getBean方法才会抛出异常。
   ②ApplicationContext，它是在容器启动时，一次性创建了所有的Bean。这样，在容器启动时，我们就可以发现Spring中存在的配置错误，这样有利于检查所依赖属性是否注入。 ApplicationContext启动后预载入所有的单实例Bean，通过预载入单实例bean ,确保当你需要的时候，你就不用等待，因为它们已经创建好了。
   ③相对于基本的BeanFactory，ApplicationContext 唯一的不足是占用内存空间。当应用程序配置Bean较多时，程序启动较慢。
（3）BeanFactory通常以编程的方式被创建，ApplicationContext还能以声明的方式创建，如使用ContextLoader。
（4）BeanFactory和ApplicationContext都支持BeanPostProcessor、BeanFactoryPostProcessor的使用，但两者之间的区别是：BeanFactory需要手动注册，而ApplicationContext则是自动注册。

6、什么是Spring Bean？请解释Spring Bean的生命周期？

  Spring beans 是那些形成Spring应用的主干的java对象。它们被Spring IOC容器初始化、装配、管理。这些beans通过容器中配置的元数据创建。比如，以XML文件中<bean/>的形式定义。一个Spring Bean 的定义包含容器必知的所有配置元数据，包括如何创建一个bean，它的各种属性、生命周期详情及它的依赖。
  这里有三种重要的方法给Spring 容器提供配置元（Bean）数据：
  1.XML配置文件。
  2.基于注解的配置。
  3.基于java的配置（是指允许你在少量的Java注解的帮助下，进行你的大部分Spring配置而非通过XML文件。）

  首先说一下Servlet的生命周期：实例化，初始init，接收请求service，销毁destroy；
Spring上下文中的Bean生命周期也类似，如下：
（1）实例化Bean：
  对于BeanFactory容器，当客户向容器请求一个尚未初始化的bean时，或初始化bean的时候需要注入另一个尚未初始化的依赖时，容器就会调用createBean进行实例化。对于ApplicationContext容器，当容器启动结束后，通过获取BeanDefinition对象中的信息，实例化所有的bean。
（2）设置对象属性（依赖注入）：
  实例化后的对象被封装在BeanWrapper对象中，紧接着，Spring根据BeanDefinition中的信息以及通过BeanWrapper提供的设置属性的接口完成依赖注入。
（3）处理Aware接口：
  接着，Spring会检测该对象是否实现了xxxAware接口，并将相关的xxxAware实例注入给Bean：
①如果这个Bean已经实现了BeanNameAware接口，会调用它实现的setBeanName(String beanId)方法，此处传递的就是Spring配置文件中Bean的id值；
②如果这个Bean已经实现了BeanFactoryAware接口，会调用它实现的setBeanFactory()方法，传递的是Spring工厂自身。
③如果这个Bean已经实现了ApplicationContextAware接口，会调用setApplicationContext(ApplicationContext)方法，传入Spring上下文。
（4）BeanPostProcessor：
  如果想对Bean进行一些自定义的处理，那么可以让Bean实现了BeanPostProcessor接口，那将会调用postProcessBeforeInitialization(Object obj, String s)方法。由于这个方法是在Bean初始化结束时调用的，所以可以被应用于内存或缓存技术；
（5）InitializingBean 与 init-method：
  如果Bean在Spring配置文件中配置了 init-method 属性，则会自动调用其配置的初始化方法。
（6）如果这个Bean实现了BeanPostProcessor接口，将会调用postProcessAfterInitialization(Object obj, String s)方法；
以上几个步骤完成后，Bean就已经被正确创建了，之后就可以使用这个Bean了。
（7）DisposableBean：
  当Bean不再需要时，会经过清理阶段，如果Bean实现了DisposableBean这个接口，会调用其实现的destroy()方法；
（8）destroy-method：
  最后，如果这个Bean的Spring配置中配置了destroy-method属性，会自动调用其配置的销毁方法。

7、什么是基于注解的容器配置? 如何开启注解？有哪几种注解？

  相对于XML文件，注解型的配置依赖于通过字节码元数据装配组件，而非尖括号的声明。开发者通过在相应的类，方法或属性上使用注解的方式，直接组件类中进行配置，而不是使用xml表述bean的装配关系。注解装配在默认情况下是不开启的，为了使用注解装配，我们必须在Spring配置文件中配置 <context:annotation-config/>元素。
  @Required 表明bean的属性必须在配置的时候设置，通过一个bean定义的显式的属性值或通过自动装配，若@Required注解的bean属性未被设置，容器将抛出BeanInitializationException。
  @Autowired 注解提供了更细粒度的控制，包括在何处以及如何完成自动装配。它的用法和@Required一样，修饰setter方法、构造器、属性或者具有任意名称或多个参数的PN方法。
  @Qualifier 当有多个相同类型的bean却只有一个需要自动装配时，将@Qualifier 注解和@Autowire 注解结合使用以消除这种混淆，指定需要装配的确切的bean。

基于注解的方式：
  使用@Autowired注解来自动装配指定的bean。在使用@Autowired注解之前需要在Spring配置文件进行配置，<context:annotation-config />。在启动spring IoC时，容器自动装载了一个AutowiredAnnotationBeanPostProcessor后置处理器，当容器扫描到@Autowied、@Resource或@Inject时，就会在IoC容器自动查找需要的bean，并装配给该对象的属性。在使用@Autowired时，首先在容器中查询对应类型的bean：
如果查询结果刚好为一个，就将该bean装配给@Autowired指定的数据；
如果查询的结果不止一个，那么@Autowired会根据名称来查找；
如果上述查找的结果为空，那么会抛出异常。解决方法时，使用required=false。
@Autowired可用于：构造函数、成员变量、Setter方法
注：@Autowired和@Resource之间的区别
(1) @Autowired默认是按照类型装配注入的，默认情况下它要求依赖对象必须存在（可以设置它required属性为false）。
(2) @Resource默认是按照名称来装配注入的，只有当找不到与名称匹配的bean才会按照类型来装配注入。

8、注解@Resource与@Autowired的区别

@Autowired
@Autowired只有一个属性required，默认值为true，为true时，找不到就抛异常，为false时，找不到就赋值为null
@Autowired按类型查找，如果该类型的bean不唯一，则抛出异常；可通过组合注解解决@Autowired()@Qualifier("baseDao")，指定需要装配的确切的bean，即baseDao。

@Resource
@Resource有两个常用属性name、type，所以分4种情况
1、指定name和type：通过name找到唯一的bean，找不到抛出异常；如果type和字段类型不一致，也会抛出异常
2、指定name：通过name找到唯一的bean，找不到抛出异常
3、指定type：通过tpye找到唯一的bean，如果不唯一，则抛出异常：NoUniqueBeanDefinitionException
4、都不指定：通过字段名作为key去查找，找到则赋值；找不到则再通过字段类型去查找，如果不唯一，则抛出异常：NoUniqueBeanDefinitionException

相同点
1、Spring都支持
2、都可以作用在字段和setter方法上
不同点
1、Resource是JDK提供的，而Autowired是Spring提供的。
2、Resource不允许找不到bean的情况，而Autowired允许（@Autowired(required = false)）
3、指定name的方式不一样，@Resource(name = "baseDao"),@Autowired()@Qualifier("baseDao")
4、Autowired默认通过type查找，而Resource默认通过name查找

9、 什么是bean装配? bean的自动装配？有哪些自动装配？以及自动装配的局限性？解释Spring支持的几种bean的作用域。spring的bean的创建时机？依赖注入的时机？

  bean装配是指在Spring 容器中把bean与bean组装到一起，前提是容器需要知道bean的依赖关系，如何通过依赖注入来把它们装配到一起。
  Bean 的自动装配是指Spring容器能够自动装配相互合作的bean，这意味着容器不需要<constructor-arg>和<property>配置，能通过Bean工厂自动处理bean之间的协作。
  有五种自动装配的方式，可以用来指导Spring容器用自动装配方式来进行依赖注入。
1、no：默认的方式是不进行自动装配，通过显式设置ref属性来进行装配。
2、byName：通过参数名 自动装配，Spring容器在配置文件中发现bean的autowire属性被设置成byname，之后容器试图匹配、装配和该bean的属性具有相同名字的bean。
3、byType：通过参数类型自动装配，Spring容器在配置文件中发现bean的autowire属性被设置成byType，之后容器试图匹配、装配和该bean的属性具有相同类型的bean。如果有多个bean符合条件，则抛出错误。
4、constructor：这个方式类似于byType， 但是要提供给构造器参数，如果没有确定的带参数的构造器参数类型，将会抛出异常。
5、autodetect：先尝试使用constructor来自动装配，如果无法工作，则使用byType方式。

自动装配的局限性是：
重写：你仍需用 <constructor-arg>和 <property> 配置来定义依赖，意味着总要重写自动装配。
基本数据类型：你不能自动装配简单的属性，如基本数据类型，String字符串，和类。
模糊特性：自动装配不如显式装配精确，如果有可能，建议使用显式装配。

Spring容器中的bean可以分为5个范围：
（1）singleton：默认，每个容器中只有一个bean的实例，单例的模式由BeanFactory自身来维护。
（2）prototype：为每一个bean请求提供一个实例。
（3）request：为每一个网络请求创建一个实例，在请求完成以后，bean会失效并被垃圾回收器回收。
（4）session：与request范围类似，确保每个session中有一个bean的实例，在session过期后，bean会随之失效。
（5）global-session：全局作用域，global-session和Portlet应用相关。当你的应用部署在Portlet容器中工作时，它包含很多portlet。如果你想要声明让所有的portlet共用全局的存储变量的话，那么这全局变量需要存储在global-session中。全局作用域与Servlet中的session作用域效果相同。

10、Spring框架中的单例Beans是线程安全的么？Spring如何处理线程并发问题？

  Spring框架并没有对单例bean进行任何多线程的封装处理。关于单例bean的线程安全和并发问题需要开发者自行去搞定。但实际上，大部分的Spring bean并没有可变的状态(比如Service类和DAO类)，所以在某种程度上说Spring的单例bean是线程安全的。如果你的bean有多种状态的话（比如 View和Model 对象），就需要自行保证线程安全。最浅显的解决办法就是将多态bean的作用域由“singleton”变更为“prototype”。
  在一般情况下，只有无状态的Bean才可以在多线程环境下共享，在Spring中，绝大部分Bean都可以声明为singleton作用域，因为Spring对一些Bean中非线程安全状态采用ThreadLocal进行处理，以解决线程安全问题。
  ThreadLocal和线程同步机制都是为了解决多线程中相同变量的访问冲突问题。线程同步机制采用了“时间换空间”的方式，仅提供一份变量，不同的线程在访问前需要获取锁，没获得锁的线程则需要排队。而ThreadLocal采用了“空间换时间”的方式，它会为每一个线程提供一个独立的变量副本，从而隔离了多个线程对数据的访问冲突。因为每一个线程都拥有自己的变量副本，从而也就没有必要对该变量进行同步了。ThreadLocal提供了线程安全的共享对象，在编写多线程代码时，可以把不安全的变量封装进ThreadLocal。

11、Spring 框架中都用到了哪些设计模式？

（1）工厂模式：BeanFactory就是简单工厂模式的体现，用来创建对象的实例；
（2）单例模式：Bean默认为单例模式。
（3）代理模式：Spring的AOP功能用到了JDK的动态代理和CGLIB字节码生成技术；
（4）模板方法：用来解决代码重复的问题。比如:RestTemplate, JmsTemplate, JpaTemplate。
（5）观察者模式：定义对象键一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都会得到通知被制动更新，如Spring中listener的实现–ApplicationListener。

12、Spring事务的实现方式和实现原理：

  Spring事务的本质其实就是数据库对事务的支持，没有数据库的事务支持，spring是无法提供事务功能的。真正的数据库层的事务提交和回滚是通过binlog或者redolog实现的。
（1）Spring事务的种类：
  spring支持编程式事务管理和声明式事务管理两种方式：
①编程式事务管理使用TransactionTemplate。
②声明式事务管理建立在AOP之上的。其本质是通过AOP功能，对方法前后进行拦截，将事务处理的功能编织到拦截的方法中，也就是在目标方法开始之前加入一个事务，在执行完目标方法之后根据执行情况提交或者回滚事务。
  声明式事务最大的优点就是不需要在业务逻辑代码中掺杂事务管理的代码，只需在配置文件中做相关的事务规则声明或通过@Transactional注解的方式，便可以将事务规则应用到业务逻辑中。
  声明式事务管理要优于编程式事务管理，这正是spring倡导的非侵入式的开发方式，使业务代码不受污染，只要加上注解就可以获得完全的事务支持。唯一不足地方是，最细粒度只能作用到方法级别，无法做到像编程式事务那样可以作用到代码块级别。
（2）spring的事务传播行为：
  spring事务的传播行为说的是，当多个事务同时存在的时候，spring如何处理这些事务的行为。
① PROPAGATION_REQUIRED：如果当前没有事务，就创建一个新事务，如果当前存在事务，就加入该事务，该设置是最常用的设置。
② PROPAGATION_SUPPORTS：支持当前事务，如果当前存在事务，就加入该事务，如果当前不存在事务，就以非事务执行。‘
③ PROPAGATION_MANDATORY：支持当前事务，如果当前存在事务，就加入该事务，如果当前不存在事务，就抛出异常。
④ PROPAGATION_REQUIRES_NEW：创建新事务，无论当前存不存在事务，都创建新事务。
⑤ PROPAGATION_NOT_SUPPORTED：以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。
⑥ PROPAGATION_NEVER：以非事务方式执行，如果当前存在事务，则抛出异常。
⑦ PROPAGATION_NESTED：如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则按REQUIRED属性执行。
（3）Spring中的隔离级别：
① ISOLATION_DEFAULT：这是个 PlatfromTransactionManager 默认的隔离级别，使用数据库默认的事务隔离级别。
② ISOLATION_READ_UNCOMMITTED：读未提交，允许另外一个事务可以看到这个事务未提交的数据。
③ ISOLATION_READ_COMMITTED：读已提交，保证一个事务修改的数据提交后才能被另一事务读取，而且能看到该事务对已有记录的更新。
④ ISOLATION_REPEATABLE_READ：可重复读，保证一个事务修改的数据提交后才能被另一事务读取，但是不能看到该事务对已有记录的更新。
⑤ ISOLATION_SERIALIZABLE：可串行化，一个事务在执行的过程中完全看不到其他事务对数据库所做的更新。

13、spring的事务传播行为？事务特性？事务隔离问题与隔离级别？

  spring事务的传播行为说的是，当多个事务同时存在的时候，spring如何处理这些事务的行为。最常用的是：PROPAGATION_REQUIRED：如果当前没有事务，就创建一个新事务，如果当前存在事务，就加入该事务，该设置是最常用的设置。

事务的特性：ACID特性。
原子性（Atomicity）：要么都执行，要么都不执行；（整体）
一致性（Consistency）：事务完成后，所有的数据必须保持一致；（完整）
隔离性（Isolation）：并发事务中一个事务的影响在该事务提交前对其它事务不可见；（并发）
持久性（Durability）：事务完成后，它对系统的影响是永久的。（结果）

事务中的隔离问题：1.脏读；2.不可重复读；3.幻读。
事务中的隔离级别：1.读未提交；2.读已提交；3.可重复读；4.串行化。

14、解释一下Spring AOP里面的几个名词：

（1）切面（Aspect）：被抽取的公共模块，可能会横切多个对象。 在Spring AOP中，切面可以使用通用类（基于模式的风格） 或者在普通类中以 @AspectJ 注解来实现。
（2）连接点（Join point）：指方法，在Spring AOP中，一个连接点 总是 代表一个方法的执行。
（3）通知（Advice）：在切面的某个特定的连接点（Join point）上执行的动作。通知有各种类型，其中包括“around”、“before”和“after”等通知。许多AOP框架，包括Spring，都是以拦截器做通知模型， 并维护一个以连接点为中心的拦截器链。
（4）切入点（Pointcut）：切入点是指 我们要对哪些Join point进行拦截的定义。通过切入点表达式，指定拦截的方法，比如指定拦截add*、search*。
（5）引入（Introduction）：（也被称为内部类型声明（inter-type declaration））。声明额外的方法或者某个类型的字段。Spring允许引入新的接口（以及一个对应的实现）到任何被代理的对象。例如，你可以使用一个引入来使bean实现 IsModified 接口，以便简化缓存机制。
（6）目标对象（Target Object）： 被一个或者多个切面（aspect）所通知（advise）的对象。也有人把它叫做 被通知（adviced） 对象。 既然Spring AOP是通过运行时代理实现的，这个对象永远是一个 被代理（proxied） 对象。
（7）织入（Weaving）：指把增强应用到目标对象来创建新的代理对象的过程。Spring是在运行时完成织入。
  切入点（pointcut）和连接点（join point）匹配的概念是AOP的关键，这使得AOP不同于其它仅仅提供拦截功能的旧技术。 切入点使得定位通知（advice）可独立于OO层次。 例如，一个提供声明式事务管理的around通知可以被应用到一组横跨多个对象中的方法上（例如服务层的所有业务操作）。

15、Spring通知有哪些类型？

（1）前置通知（Before advice）：在某连接点（join point）之前执行的通知，但这个通知不能阻止连接点前的执行（除非它抛出一个异常）。
（2）返回后通知（After returning advice）：在某连接点（join point）正常完成后执行的通知：例如，一个方法没有抛出任何异常，正常返回。
（3）抛出异常后通知（After throwing advice）：在方法抛出异常退出时执行的通知。
（4）后通知（After (finally) advice）：当某连接点退出的时候执行的通知（不论是正常返回还是异常退出）。
（5）环绕通知（Around Advice）：包围一个连接点（join point）的通知，如方法调用。这是最强大的一种通知类型。 环绕通知可以在方法调用前后完成自定义的行为。它也会选择是否继续执行连接点或直接返回它们自己的返回值或抛出异常来结束执行。 环绕通知是最常用的一种通知类型。大部分基于拦截的AOP框架，例如Nanning和JBoss4，都只提供环绕通知。
  同一个切面（aspect），不同通知（advice）的执行顺序：
①没有异常情况下的执行顺序： ②有异常情况下的执行顺序：
around before advice        around before advice
before advice             before advice
target method 执行           target method 执行
around after advice           around after advice
after advice                 after advice
afterReturning               afterThrowing:异常发生
                       java.lang.RuntimeException: 异常发生

16、静态代理和动态代理的区别？动态代理是怎么实现的？

  静态代理： 就是自己编写一个代理类来代理一个具体的类，使使用这个类的客户端不需要知道实现类是什么，怎么做的，而客户端只需知道和使用代理即可，也就是把客户端和具体类进行了解耦合。（典型的代理模式通常有三个角色，这里称之为代理三要素：共同接口：Action，真实对象：RealObject（又称作委托类），代理实例：Proxy）
  传统的方式是客户端直接调用真实对象（类）来使用，如果想改变真实对象的属性，必须要在具体的真实对象（类）中进行修改，这样使得客户端和具体类耦合度变高。通过静态代理的方式，可以直接在代理对象中进行修改，使得客户端和具体类的耦合度降低。
虽然静态代理满足了解耦合的需要，但是也有一些缺点。第一，代理类和委托类实现了相同的接口，代理类通过委托类实现了相同的方法。这样就出现了大量的代码重复。如果接口增加一个方法，除了所有实现类需要实现这个方法外，所有代理类也需要实现此方法。增加了代码维护的复杂度。第二，代理对象只服务于一种类型的对象，如果要服务多类型的对象。势必要为每一种对象都进行代理，静态代理在程序规模稍大时就无法胜任了。
而且静态代理是由程序员创建代理类或特定工具自动生成源代码再对其编译。在程序运行前代理类的.class文件就已经存在了。
  要解决静态代理的不足，出现了动态代理。（动态生成+代理模式，也就是动态代理。）
  通过使用动态代理，我们可以通过在运行时，动态生成一个持有RealObject、并实现代理接口的Proxy，同时注入我们相同的扩展逻辑。哪怕你要代理的RealObject是不同的对象，甚至代理不同的方法，都可以动过动态代理，来扩展功能。（使用动态代理，需要将要扩展的功能写在一个InvocationHandler 实现类，在这个Handler中的invoke方法中实现了代理类要扩展的公共功能。）

public class DynamicProxy implements InvocationHandler{
	private Object targetObject;
	public Object newProxyInstance(Object targetObject){
		this.targetObject = targetObject;  //输入 targetObject（真实对象）、Action（接口），返回一个Proxy，即代理模式。
		return Proxy.newProxyInstance(targetObject.getClass().getClassLoader(),targetObject.getClass().getInterfaces(),this); }
	@Override
	public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
		System.out.println("开始代理");
		result = method.invoke(targetObject, args);
		System.out.println("结束代理");
		return null;	
		}
    }

被代理对象targetObject通过参数传递进来，我们通过targetObject.getClass().getClassLoader()获取ClassLoader对象，然后通过targetObject.getClass().getInterfaces()获取它实现的所有接口，然后将targetObject包装到实现了InvocationHandler接口的DynamicProxy对象中。通过newProxyInstance函数我们就获得了一个动态代理对象。
  可以看到，我们可以通过DynamicProxy代理不同类型的对象，如果我们把对外的接口都通过动态代理来实现，那么所有的函数调用最终都会经过invoke函数的转发，因此我们就可以在这里做一些自己想做的操作，比如日志系统、事务、拦截器、权限控制等。这也就是AOP(面向切面编程)的基本原理。
  动态代理类dynamicproxy中的代码几乎都是通用的，对象只有在main方法中传递真实对象类时才会生成，也就是说只有在程序运行起来后对象才会动态生成。而且也可以生成其他类型的类的实例，提高了代码重用性和解耦合。
  动态代理与静态代理相比较，最大的好处是接口中声明的所有方法都被转移到调用处理器一个集中的方法中处理（InvocationHandler.invoke）。这样，在接口方法数量比较多的时候，我们可以进行灵活处理，而不需要像静态代理那样每一个方法进行中转。而且动态代理的应用使我们的类职责更加单一，复用性更强。并且动态代理类的字节码在程序运行时由Java反射机制动态生成，无需程序员手工编写它的源代码。动态代理类不仅简化了编程工作，而且提高了软件系统的可扩展性，因为Java 反射机制可以生成任意类型的动态代理类。java.lang.reflect 包中的Proxy类和InvocationHandler 接口提供了生成动态代理类的能力。

Spring框架——IOC与AOP：https://blog.csdn.net/qq_41822345/article/details/104983468