死锁：
指两个事务或者多个事务在同一资源上相互占用，并请求对方所占用的资源，从而造成恶性循环的现象。
出现死锁的原因：
系统资源不足；
进程运行推进的顺序不当；
资源分配不当。
产生死锁的四个必要条件：
互斥条件： 一个资源只能被一个进程使用；
请求和保持条件：进行获得一定资源，又对其他资源发起了请求，但是其他资源被其他线程占用，请求阻塞，但是也不会释放自己占用的资源；
不可剥夺条件： 指进程所获得的资源，不可能被其他进程剥夺，只能自己释放；
环路等待条件： 进程发生死锁，必然存在着进程-资源之间的环形链。
数据库也会发生死锁的现象，数据库系统实现了各种死锁检测和死锁超时机制来解除死锁，锁监视器进行死锁检测，MySQL的InnoDB处理死锁的方式是将持有最少行级排它锁的事务进行回滚。
常见的三种避免死锁的方法：
如果不同程序会并发存取多个表，尽量约定以相同的顺序访问表，可以大大降低死锁机会；
在同一个事务中，尽可能做到一次锁定所需要的所有资源，减少死锁产生概率；
对于非常容易产生死锁的业务部分，可以尝试使用升级锁定颗粒度，通过表级锁定来减少死锁产生的概率。
乐观锁和悲观锁都是为了解决并发控制问题， 乐观锁可以认为是一种在最后提交的时候检测冲突的手段，而悲观锁则是一种避免冲突的手段。
乐观锁：
乐观锁应用系统层面和数据的业务逻辑层次上的（实际上并没有加锁，只不过大家一直这样叫而已），利用程序处理并发， 它假定当某一个用户去读取某一个数据的时候，其他的用户不会来访问修改这个数据，但是在最后进行事务的提交的时候会进行版本的检查，以判断在该用户的操作过程中，没有其他用户修改了这个数据。
乐观锁不是数据库自带的，需要我们自己去实现。乐观锁的实现大部分都是基于版本控制实现的，级别高低是：脏读 < 不可重复读 < 幻读（级别介绍详细见数据库的事务隔离级别）。 除此之外，还可以通过时间戳的方式，通过提前读取，事后对比的方式实现。
悲观锁：
每次拿数据的时候都认为别的线程会修改数据，所以在每次拿的时候都会给数据上锁。上锁之后，当别的线程想要拿数据时，就会阻塞，直到给数据上锁的线程将事务提交或者回滚。传统的关系型数据库里就用到了很多这种锁机制，比如行锁，表锁，共享锁，排他锁等，都是在做操作之前先上锁。与乐观锁相对应的，悲观锁是由数据库自己实现，要用的时候，我们直接调用数据库的相关语句就可以。
共享锁和排它锁是悲观锁的不同的实现，它俩都属于悲观锁的范畴。
共享锁：
共享锁又称为读锁，简称S锁，共享锁就是多个事务对于同一数据可以共享一把锁，都能访问到数据，但是只能读不能修改。
比如事务T对数据对象A加上S锁，则事务T只能读A；其他事务只能再对A加S锁，而不能加X锁，直到T释放A上的S锁。这就保证了其他事务可以读A，但在T释放A上的S锁之前不能对A做任何修改。
排他锁：
排他锁又称为写锁，简称X锁，排他锁就是不能与其他所并存，如一个事务获取了一个数据行的排他锁，其他事务就不能再获取该行的其他锁，包括共享锁和排他锁，但是获取排他锁的事务是可以对数据就行读取和修改。
比如事物T对数据对象A加上X锁，则只允许T读取和修改A，其它任何事务都不能再对A加任何类型的锁，直到T释放A上的锁。它防止任何其它事务获取资源上的锁，直到在事务的末尾将资源上的原始锁释放为止。
注意：
mysql InnoDB引擎默认的修改数据语句，update,delete,insert都会自动给涉及到的数据加上排他锁，select语句默认不会加任何锁类型，如果加排他锁可以使用select ...for update语句，加共享锁可以使用select ... lock in share mode语句。所以加过排他锁的数据行在其他事务种是不能修改数据的，也不能通过for update和lock in share mode锁的方式查询数据，但可以直接通过select ...from...查询数据，因为普通查询没有任何锁机制。
---------------------
作者：一骑走烟尘
来源：CSDN
原文：https://blog.csdn.net/zgcr654321/article/details/82345087
版权声明：本文为博主原创文章，转载请附上博文链接！