PS：文章内容涉及源码，请耐心阅读。

理论实践，相辅相成

伟大领袖毛主席告诉我们实践出真知。这是无比正确的。但是也会很辛苦。

就像淘金一样，从大量沙子中淘出金子一定是一个无比艰辛的过程。但如果真能淘出来，也一定是像金子一样宝贵的东西。

他老人家还说过，当真知上升为理论的时候，就可以反过来指导实践了。

在当下这个时代，前辈们已经发现和整理了很多理论，我们直接拿来使用就行了。“拿来主义”不全是不好的。

如果说阅读源码算一种实践的话，那我们拿什么“理论”来指导它呢？

兵马未动，粮草先行

答案自然是官方文档。官方文档就是前辈们总结出来的“理论”，一般来说包含三方面的内容：

a）哲学方面：一些设计思想，比如初衷啊、灵感来源啊这些。一些取舍的选择，比如主要是为了克服什么痛点、解决什么问题。

b）详细解说：把整体内容一点一点的讲清楚，包括很多名字解释，很多设计原理，还有很多注意事项等。

c）入门示例：一些简单的常规使用例子。

下面我们就来熟悉下这些“理论”的关键部分：

事务的执行是和线程相关的，那是不是就要使用ThreadLocal来存储一些相关东西，究竟会存储哪些东西呢。

物理事务就是到数据库的一个物理链接，这个链接一开始是如何建立，建立好后又是如何保存起来呢。

逻辑事务就是一个带有事务注解的方法，它需要关联到一个物理事务上。那它是不是先从当前上下文寻找物理事务，找到就用，否则就新开一个物理事务呢。

多个逻辑事务可以映射到一个物理事务上，逻辑事务是各自提交的，如何处理逻辑事务提交和物理事务提交间的关系呢，至少所有的逻辑事务都提交了才可以提交物理事务。

获取事务时的参数叫事务定义，是一个接口，那它的实现类是哪个，都会包含哪些内容呀，至少要包含事务注解里指定的内容吧。

获取事务时的结果叫事务状态，是一个接口，那它的实现类是哪个，都会包含哪些内容呀。

获取事务这个方法是非常核心的方法，入参和出参分别是事务定义和事务状态。你会不会感到有些奇怪，获取事务的结果不应该是一个事务吗，为啥却是一个事务状态呢？到底有没有一个类和事务这两个字对应呢？

多个逻辑事务也可以映射到多个物理事务上，此时就会遇到在当下已存在物理事务的时候再开启新的物理事务。那么就需要将当下事务挂起，具体的挂起会执行哪些操作呢。

挂起的事务会存到那里呢，在新的物理事务提交完毕后又如何将挂起的事务恢复呢。