MySQL事物本质_事务的本质和死锁的原理・改

由于一些错误操作和被爬的原因，我重新整理了上一篇文章事务的本质和死锁的原理-一剑破万法 - 博客园

前言、事务方块

在我的理解，事务是这个形状的

x轴是可以锁定的资源，y轴是函数执行时间， 事务随着时间的流逝向下降落， 当恰好与x轴接触时资源被锁定，当恰好不再与x轴接触时资源解除锁定，这里的耗时五秒是夸张的写法，通常情况下单位是毫秒级甚至微妙级，这里使用秒作为单位是为了凸显现象 上图是函数a的事务形状，命名【 事务方块】，

@Transactional

public void a(){

//对A表增删改，耗时5秒 }

一、多事务

当一个函数调用多个子函数且都是被事务注解的函数时情况是

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

public void abc(){

this.a(){}

this.b(){}

this.c(){}

}

@Transactional

public void a(){

//对A表修改，耗时五秒}

@Transactional

public void b(){

//对B表修改，耗时五秒}

@Transactional

public void c(){

//对C表修改，耗时五秒}

当abc函数开始执行时，先调用a函数，先锁定a表， 当a函数结束执行，a表解锁，同时b函数开始执行，b表锁定， 当b函数结束执行，b表解锁，同时c函数开始执行，c表锁定。 相当于下图的三个事务方块联合且相对位置固定一起下落，总耗时十五秒

如果并发请求两次abc函数，事务方块如图

其中a表先被请求一锁定五秒后解锁，再马上被请求二锁定五秒， 其中b表也先被请求一锁定五秒后解锁，再马上被请求二锁定五秒， 其中c表也先被请求一锁定五秒后解锁，再马上被请求二锁定五秒， 而请求一在解锁表a后紧接着又锁定了表b五秒，同时表a再被请求二锁定五秒 依此类推，请求二都在请求一解锁对应的表后锁定该表， 那么总运行时间二十秒

二、大事务

@Transactional

function abc(){

this.a(){}

this.b(){}

this.c(){}

}

public void a(){

//对A表修改，耗时五秒}

public void b(){

//对B表修改，耗时五秒}

public void c(){

//对C表修改，耗时五秒}

其中abc函数有注解，而子函数a、b、c没有注解，事务形状如图

a、b、c三个颜色的方块是结合在一起的,必须一起执行，实际上就是事务原子性的表象，那么a表被锁定十五秒，b表被锁定十秒，c表被锁定五秒 若也同时并发两次abc函数则总耗时三十秒，容易发现事务越大，耗时越长；本来在多事务时被锁定五秒的a表，被锁定了十五秒。 在这个abc函数中，事务对表的锁定是懒锁定的情况， 就是说，当abc函数中 a函数开始执行时，只锁定了a表，当a函数执行完成， b函数开始执行锁定b表，此时不解锁a表，当b函数执行完成， c函数开始执行锁定c表，此时不解锁a、b两个表，当c函数执行完成，同时解锁a、b、c三个表。 这就导致了死锁的出现

三、死锁

有如下两个函数ab和ba

@Transactional

public void ab(){

this.a(){}

this.b(){}

}

@Transactional

public void ba(){

this.b(){}

this.a(){}

}

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

当ab和ba函数同时被执行时，ab锁定a表，ba锁定b表， 当ab执行完a函数请求锁定b表时，ba也执行完了b函数请求锁定a表， 但ab没有解开对a表的锁定，ba也没有解开对b表的锁定，那么相互等待对方解锁，这就是死锁。 所以减少死锁出现的几率的办法是减小事务方块的大小，即减小事务方块消耗的时间或减小事务方块锁定的资源【表或行】 所以行级锁不易出现死锁，表级锁易出现死锁，是因为行级锁事务方块小，但消耗时间不一定，还是需要参考事务消耗时间。 当表的主键是整型的自增ID时，则相当于把事务可锁定资源从一个资源【表】分割成了2147483647份的资源【行】，可见使用行级锁时事务方块明显变小。

四、名称来历

事务方块的名字来历是一次研究死锁时联想到俄罗斯方块，俄罗斯方块是为了找一个位置放置方块，而事务方块是为了找一个时空缝隙让方块执行通过，目的不同。

【网络图片侵删】