事务的本质和死锁的原理

仅以MySQL和Spring为例，本文不介绍事务和锁的概念。
本文使用伪代码表示方法代码，仅仅表达方法的意义及事务注解。

事务的形状

在我心中，事务一直是这个样子的

x轴是上锁的资源，y轴是消耗的时间，
事务方块随着时间的流逝向下移动，
当碰触x轴时资源加锁，越过x轴时资源解锁
上图是对于方法a的事务形状，我起名【 事务方块】。

@Transactional
function a(){
    对A表修改，耗时五秒
}

一、多事务

当一个方法调用多个被事务注解的子方法时情况是

上图是对于方法abc调用时，a方法、b方法、c方法的事务形状

function abc(){
    this.a(){}
    this.c(){}
}
@Transactional
function a(){
    对A表修改，耗时五秒
}
@Transactional
function b(){
    对B表修改，耗时五秒
}
@Transactional
function c(){
    对C表修改，耗时五秒
}

其中abc方法开始执行时，执行到a方法，锁定a表，当a方法结束b方法开始时，a表解锁，b表锁定，当b方法结束c方法开始时，b表解锁c表锁定。
相当于下图的三个事务方块联合且相对位置锁定一起下落，总运行时间15秒

如果并发请求两次abc方法则事务方块如下图

其中a表会先被请求1锁定5秒后解锁，再被请求2锁定5秒，
其中b表也会先被请求1锁定5秒后解锁，再被请求2锁定5秒，
其中c表也会先被请求1锁定5秒后解锁，再被请求2锁定5秒，
而请求1在解锁表a后紧接着又锁定了表b五秒，同时表a再被请求2锁定5秒
依次类推，请求2都在请求1解锁对应的表之后，锁定该表，
那么总运行时间20秒。

二、大事务

@Transactional
function abc(){
    this.a(){}
    this.b(){}
    this.c(){}
}
function a(){
    对A表修改，耗时五秒
}
function b(){
    对B表修改，耗时五秒
}
function c(){
    对C表修改，耗时五秒
}

其中abc方法上有事务注解，而子方法a、b、c上没有事务注解，事务方块形状如下图

a、b、c三个颜色的方块是结合在一起的只能一起执行，那么a表被锁定15秒，b表被锁定10秒，c表被锁定5秒
如果也并发请求两次abc方法则总耗时30秒，显而易见事务方块越大，耗时越长。

在这个abc方法中，事务锁定表是懒锁定的方式，就是说
当abc中a方法开始执行时，只锁定了a表，执行完a方法后，
开始执行b方法锁定b表，此时a表不解锁，当b方法执行完后，
开始执行c方法锁定c表，此时a、b两个表都不解锁，当c方法执行完后，a、b、c三个表一起解锁。
这就造成了以下情况。

三、死锁

有如下两个方法ab和ba

@Transactional
function ab(){
    this.a(){}
    this.b(){}
}
@Transactional
function ba(){
    this.b(){}
    this.a(){}
}

当ab和ba方法同时被执行时，事务方块类似下图，但不完全

当ab和ba方法同时被执行时，ab锁定a表，ba锁定b表，
当ab执行完a方法请求锁定b表时，ba也执行完了b方法请求锁定a表，
但ab没有解开对a表的锁定，ba也没有解开对b表的锁定，那么相互等待对方解锁，这就是死锁。

所以减少死锁出现的几率的办法是减小事务方块的大小，即减小事务方块消耗的时间或减小事务方块锁定的资源【表或行】
所以行级锁不易出现死锁，表级锁易出现死锁，是因为行级锁事务方块小，但消耗时间不一定，还是需要参考事务消耗时间。
如果主键是int类型自增id，则相当于把事务可锁定资源从一个表分成了21亿份的行，可见使用行级锁时事务方块明显变小。

四、名称来历

事务方块的名字来历是因为联想到俄罗斯方块，俄罗斯方块是为了给方块找一个位置放置，而事务方块是为了给方块找一个时间间隙执行通过，两者目的不同。

很抱歉我不会做动图，请自行联想俄罗斯方块下落的情况。

也可以类比成要过桥的车辆，桥宽度固定，有的车占用一车道，有的车占用两车道，有的车占用半车道，
车的形状多种多样，如老式武装三轮摩托车像ab方法的小车，大客车就是一车道的长车，自行车是半车道的小车。类似的情形很多，可自行联想。