AOP：面向切面编程。
即在一个功能模块中新增其他功能，比方说你要下楼取个快递，你同事对你说帮我也取一下呗，你就顺道取了。在工作中如果系统中有些包和类中没有使用AOP，例如日志，事务和异常处理，那么就必须在每个类和方法中去实现它们。 代码纠缠每个类和方法中都包含日志，事务以及异常处理甚至是业务逻辑。在一个这样的方法中，很难分清代码中实际做的是什么处理。AOP 所做的就是将所有散落各处的事务代码集中到一个事务切面中。
场景
比方说我现在要弄一个日志，记录某些个接口调用的方法时间。使用Aop我可以在这个接口前插入一段代码去记录开始时间，在这个接口后面去插入一段代码记录结束时间。
又或者你去访问数据库，而你不想管事务（太烦），所以，Spring在你访问数据库之前，自动帮你开启事务，当你访问数据库结束之后，自动帮你提交/回滚事务！
异常处理你可以开启环绕通知，一旦运行接口报错，环绕通知捕获异常跳转异常处理页面。
动态代理
Spring AOP使用的动态代理，所谓的动态代理就是说AOP框架不会去修改字节码，而是在内存中临时为方法生成一个AOP对象，这个AOP对象包含了目标对象的全部方法，并且在特定的切点做了增强处理，并回调原对象的方法。它的动态代理主要有两种方式，JDK动态代理和CGLIB动态代理。JDK动态代理通过反射来接收被代理的类，并且要求被代理的类必须实现一个接口。JDK动态代理的核心是InvocationHandler接口和Proxy类。如果目标类没有实现接口，那么Spring AOP会选择使用CGLIB来动态代理目标类。CGLIB是一个代码生成的类库，可以在运行时动态的生成某个类的子类，注意，CGLIB是通过继承的方式做的动态代理，因此如果某个类被标记为final，那么它是无法使用CGLIB做动态代理的。
IOC：依赖注入或者叫做控制反转。
正常情况下我们使用一个对象时都是需要new Object()的。而ioc是把需要使用的对象提前创建好，放到spring的容器里面。
所有需要使用的类都会在spring容器中登记，告诉spring你是个什么东西，你需要什么东西，然后spring会在系统运行到适当的时候，把你要的东西主动给你，同时也把你交给其他需要你的东西。所有的类的创建、销毁都由 spring来控制，也就是说控制对象生存周期的不再是引用它的对象，而是spring。DI(依赖注入)其实就是IOC的另外一种说法，其实它们是同一个概念的不同角度描述。
场景：
正常情况下我们使用一个对象时都是需要new Object() 的。而ioc是把需要使用的对象提前创建好，放到spring的容器里面。需要使用的时候直接使用就行，而且可以设置单例或多例，非常灵活。
我们在service层想调用另外一个service的方法，不需要去new了，直接把它交给spring管理，然后用注解的方式引入就能使用。
IOC三种注入方式
（1）XML：Bean实现类来自第三方类库，例如DataSource等。需要命名空间等配置，例如：context，aop，mvc。
（2）注解：在开发的类使用@Controller，@Service等注解
（3）Java配置类：通过代码控制对象创建逻辑的场景。例如：自定义修改依赖类库。
什么是事务？
事务是访问并可能更新数据库中各种数据项的一个程序执行单元。
Spring事务与数据库事务关系？
Spring的事务是对数据库的事务的封装，最后本质的实现还是在数据库，假如数据库不支持事务的话，Spring的事务是没有作用的。所以说Spring事务的底层依赖MySQL的事务，Spring是在代码层面利用AOP实现，执行事务的时候使用TransactionInceptor进行拦截，然后处理。本质是对方法前后进行拦截，然后在目标方法开始之前创建或者加入一个事务，执行完目标方法之后根据执行的情况提交或者回滚。
属性（特性）
A(原子性)：要么全部完成，要么完全不起作用
C(一致性)：一旦事务完成（不管成功还是失败），业务处于一致的状态，而不会是部分完成，部分失败。
I(隔离性)：多事务会同时处理相同的数据，因此每个事务都应该与其他事务隔离开来，防止数据损坏。
D(持久性)：一旦事务完成，无论发生什么系统错误，它的结果都不应该受到影响，事务的结果被写到持久化存储器中。
什么叫事务传播行为？
传播，至少有两个东西，才可以发生传播。单体不存在传播这个行为。事务传播行为就是当一个事务方法被另一个事务方法调用时，这个事务方法应该如何进行。
Spring支持7中事务传播行为
propagation_required（需要传播）：当前没有事务则新建事务，有则加入当前事务
propagation_supports（支持传播）：支持当前事务，如果当前没有事务则以非事务方式执行
propagation_mandatory（强制传播）：使用当前事务，如果没有则抛出异常
propagation_nested（嵌套传播）：如果当前存在事务，则在嵌套事务内执行，如果当前没有事务，则执行需要传播行为。
propagation_never（绝不传播）：以非事务的方式执行，如果当前有事务则抛出异常
propagation_requires_new（传播需要新的）：新建事务，如果当前有事务则把当前事务挂起
propagation_not_supported（不支持传播）：以非事务的方式执行，如果当前有事务则把当前事务挂起
关于事务的传播行为，个人觉得这篇写的非常好，这里给上链接：https://www.cnblogs.com/haha12/p/11855001.html
数据库事务的隔离级别
数据库事务的隔离级别有4个，由低到高依次为Read uncommitted、Read committed、Repeatable read、Serializable，这四个级别可以逐个解决脏读、不可重复读、幻读这几类问题。
√: 可能出现 ×: 不会出现
| 说明 | 脏读 | 不可重复读 | 幻读 |
| Read uncommitted | √ | √ | √ |
| Read committed | × | √ | √ |
| Repeatable read | × | × | √ |
| Serializable | × | × | × |
注意：我们讨论隔离级别的场景，主要是在多个事务并发的情况下，因此，接下来的讲解都围绕事务并发。
Read uncommitted 读未提交
公司发工资了，领导把20000元打到廖志伟的账号上，但是该事务并未提交，而廖志伟正好去查看账户，发现工资已经到账，是20000元整，非常高兴。可是不幸的是，领导发现发给廖志伟的工资金额不对，是16000元，于是迅速回滚了事务，修改金额后，将事务提交，最后廖志伟实际的工资只有16000元，廖志伟空欢喜一场。
出现上述情况，即我们所说的脏读，两个并发的事务，“事务A：领导给廖志伟发工资”、“事务B：廖志伟查询工资账户”，事务B读取了事务A尚未提交的数据。当隔离级别设置为Read uncommitted时，就可能出现脏读，如何避免脏读，请看下一个隔离级别。
Read committed 读提交
廖志伟拿着工资卡去消费，系统读取到卡里确实有2000元，而此时她的老婆也正好在网上转账，把廖志伟工资卡的2000元转到另一账户，并在廖志伟之前提交了事务，当廖志伟扣款时，系统检查到廖志伟的工资卡已经没有钱，扣款失败，廖志伟十分纳闷，明明卡里有钱，为何…
出现上述情况，即我们所说的不可重复读，两个并发的事务，“事务A：廖志伟消费”、“事务B：廖志伟的老婆网上转账”，事务A事先读取了数据，事务B紧接了更新了数据，并提交了事务，而事务A再次读取该数据时，数据已经发生了改变。当隔离级别设置为Read committed时，避免了脏读，但是可能会造成不可重复读。大多数数据库的默认级别就是Read committed，比如Sql Server , Oracle。如何解决不可重复读这一问题，请看下一个隔离级别。
Repeatable read 重复读
当廖志伟拿着工资卡去消费时，一旦系统开始读取工资卡信息（即事务开始），廖志伟的老婆就不可能对该记录进行修改，也就是廖志伟的老婆不能在此时转账。这就避免了不可重复读。廖志伟的老婆工作在银行部门，她时常通过银行内部系统查看廖志伟的信用卡消费记录。有一天，她正在查询到廖志伟当月信用卡的总消费金额（select sum(amount) from transaction where month = 本月）为80元，而廖志伟此时正好在外面胡吃海喝后在收银台买单，消费1000元，即新增了一条1000元的消费记录（insert transaction … ），并提交了事务，随后廖志伟的老婆将廖志伟当月信用卡消费的明细打印到A4纸上，却发现消费总额为1080元，廖志伟的老婆很诧异，以为出现了幻觉，幻读就这样产生了。当隔离级别设置为Repeatable read时，可以避免不可重复读，但会出现幻读。注：MySQL的默认隔离级别就是Repeatable read。
Serializable 序列化
Serializable是最高的事务隔离级别，同时代价也花费最高，性能很低，一般很少使用，在该级别下，事务顺序执行，不仅可以避免脏读、不可重复读，还避免了幻像读。