锁定锁是网络数据库中一个非常重要的概念，当多个用户同时操作数据库时，会发生数据不一致。 因此，锁主要用于在多用户环境中保证数据库的完整性和完整性。
帮助理解:以商场试衣间为例，由于每个试衣间可供多个消费者使用，因此可能需要多个消费者同时使用试衣间进行试穿。 为了避免碰撞，试衣间里安装了钥匙。 一个试衣间的人在试衣间锁上钥匙，其他客人就不能从外面打开了。 里面的客人只能试衣服，然后从里面打开锁，等外面的人进来。
数据库锁定的目的：处理并发问题
并发控制的主要采用的技术手段:乐观锁定、悲观锁定和时间戳。
从数据库系统的角度来看，锁的分类可以分为排他锁、共享锁和更新锁三种。
从程序员的角度来看，可以分为悲观锁定和乐观锁定两种。
悲观锁定个性小蚂蚁比较悲观，每次去取数据都认为别人会修改，所以每次取数据都要锁定，直到别人拿着这个数据去锁定。
悲观锁定(Pessimistic Lock )顾名思义，具有较强的垄断和排他特性。 这意味着在数据处理过程中数据被锁定，因为它对本系统当前的其他事务和外部数据更改(包括来自外部系统的事务)保持保守。 悲观锁定的实现往往取决于数据库提供的锁定机制。 此外，只有数据库层提供的锁定机制才能真正保证数据访问的排他性。 否则，在本系统中实现锁定机制并不能保证外部系统不会修改数据。
传统的关系数据库经常使用这种锁定机制，包括行锁、表锁、读锁和写锁。
悲观锁定根据使用性质分为“共享锁定”(Share Lock ) s锁定，也称为用于所有只读数据操作的读锁定。 共享锁不是独占的，并且多个并发事务可以读取锁定的资源。性质
1 .多个事务可以阻止同一共享页
2 .任何事务不得修改本页面；
3 .通常会读取此页面，并立即释放s锁。
默认情况下，SQL Server在读取数据时立即解除共享锁定。
例如，如果执行查询语句" SELECT * FROM my_table "，则首先锁定第一页，读取后解锁第一页，然后锁定第二页。 这样可以修改在读取操作过程中未锁定的第一页。
例如，在语句“SELECT * FROM my_table HOLDLOCK”中，在查询完成之前，必须在查询运行期间保持对表的锁定。
“独占锁定”(Exclusive Lock ) x锁定也称为写入锁定，表示对数据的写入操作。 如果一个事务对对象进行了独占锁定，则其他事务将无法对其进行锁定。 (有个客人把试衣间从里面反锁了。 如果其他客人想要使用这个试衣间，只能等待锁从里面打开。 (性质
1 .只能阻止此页面的一个事务处理
2 .在解除x锁定之前，其他事务处理无法访问此页面。
3. X锁在事务结束之前不会释放。
生成排他锁定的SQL语句如下： 选择* from ad _ plan for update；
更新锁定u锁定用于锁定在更改操作初始化阶段可能更改的资源，从而避免使用共享锁定导致的死锁。
因为使用共享锁时，修改数据的操作分为两个步骤。
1 .首先获取共享锁，读取数据，
2 .然后将共享锁升级为独占锁并执行更改操作。
这样，如果两个或多个事务同时为一个事务申请共享锁，则在更改数据时，这些事务必须将共享锁升级为独占锁。 在这种情况下，这些事务不会释放共享锁定，而是继续等待对方释放，从而导致死锁。
通过在数据更改之前直接申请更新锁定，并在数据更改时升级到独占锁定，可以避免死锁。
性质
1 .计划对此页面进行x锁定，允许读取其他事务，但不允许u锁定或x锁定。
2 .如果读取的页面更新，则升级到x锁定；
3. U型锁在事务结束之前不会释放。
悲观锁定根据作用范围分为行锁定、表锁定。 (本部分摘自https://www.Jian Shu.com/p/eb41 df 600775 )行锁的作用范围为低电平。
表锁的作用范围是整个表。
数据库可以决定在需要锁定行时使用行锁，在不知道影响哪一行时使用表锁。
例如，具有主键id和用户生日birthday的用户表user。
舒适的咖啡豆加上更新…where id=？ 对于这些语句，数据库清楚地知道影响哪些行，并使用行锁定
舒适的咖啡豆加上update … where birthday=？ 对于这样的语句，由于事先不知道会影响哪一行，所以可能会使用表锁。
乐观锁定个性的蚂蚁很乐观，每次去取数据都认为别人不会修改，所以不会锁定。 但是，在更新时，判断在此期间其他人是否更新该数据，可以使用版本号等结构。
>乐观锁（ Optimistic Locking ）： 相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。
悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。而乐观锁机制在一定程度上解决了这个问题。
乐观锁，大多是基于数据版本（ Version ）记录机制实现。
数据版本：为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。
乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁。
乐观锁的实现方式（这部分摘自https://www.jianshu.com/p/eb41df600775 ） 版本号（version）版本号（记为version）：就是给数据增加一个版本标识，在数据库上就是表中增加一个version字段，每次更新把这个字段加1，读取数据的时候把version读出来，更新的时候比较version，如果还是开始读取的version就可以更新了，如果现在的version比老的version大，说明有其他事务更新了该数据，并增加了版本号，这时候得到一个无法更新的通知，用户自行根据这个通知来决定怎么处理，比如重新开始一遍。这里的关键是判断version和更新两个动作需要作为一个原子单元执行，否则在你判断可以更新以后正式更新之前有别的事务修改了version，这个时候你再去更新就可能会覆盖前一个事务做的更新，造成第二类丢失更新，所以你可以使用update … where … and version=”old version”这样的语句，根据返回结果是0还是非0来得到通知，如果是0说明更新没有成功，因为version被改了，如果返回非0说明更新成功。
时间戳（使用数据库服务器的时间戳）
时间戳（timestamp）：和版本号基本一样，只是通过时间戳来判断而已，注意时间戳要使用数据库服务器的时间戳不能是业务系统的时间。
待更新字段
待更新字段：和版本号方式相似，只是不增加额外字段，直接使用有效数据字段做版本控制信息，因为有时候我们可能无法改变旧系统的数据库表结构。假设有个待更新字段叫count,先去读取这个count,更新的时候去比较数据库中count的值是不是我期望的值（即开始读的值），如果是就把我修改的count的值更新到该字段，否则更新失败。java的基本类型的原子类型对象如AtomicInteger就是这种思想。
所有字段所有字段：和待更新字段类似，只是使用所有字段做版本控制信息，只有所有字段都没变化才会执行更新。 乐观锁几种方式的区别（这部分摘自https://www.jianshu.com/p/eb41df600775 ） 新系统设计可以使用version方式和timestamp方式，需要增加字段，应用范围是整条数据，不论那个字段修改都会更新version,也就是说两个事务更新同一条记录的两个不相关字段也是互斥的，不能同步进行。旧系统不能修改数据库表结构的时候使用数据字段作为版本控制信息，不需要新增字段，待更新字段方式只要其他事务修改的字段和当前事务修改的字段没有重叠就可以同步进行，并发性更高。 并发控制会造成两种锁（这部分摘自https://www.cnblogs.com/ismallboy/p/5574006.html） 活锁死锁
并发控制会造成活锁和死锁，就像操作系统那样，会因为互相等待而导致。
活锁定义：指的是T1封锁了数据R，T2同时也请求封锁数据R，T3也请求封锁数据R，当T1释放了锁之后，T3会锁住R，T4也请求封锁R，则T2就会一直等待下去。
解决方法：采用“先来先服务”策略可以避免。
定义：就是我等你，你又等我，双方就会一直等待下去。比如：T1封锁了数据R1，正请求对R2封锁，而T2封住了R2,正请求封锁R1，这样就会导致死锁，死锁这种没有完全解决的方法，只能尽量预防。
预防方法：
1. 一次封锁法，指的是一次性把所需要的数据全部封锁住，但是这样会扩大了封锁的范围，降低系统的并发度；
2. 顺序封锁法，指的是事先对数据对象指定一个封锁顺序，要对数据进行封锁，只能按照规定的顺序来封锁，但是这个一般不大可能的。
系统判定死锁的方法：
超时法：如果某个事物的等待时间超过指定时限，则判定为出现死锁；等待图法：如果事务等待图中出现了回路，则判断出现了死锁。对于解决死锁的方法，只能是撤销一个处理死锁代价最小的事务，释放此事务持有的所有锁，同时对撤销的事务所执行的数据修改操作必须加以恢复。
参考资料
《Java程序员面试笔试真题与分析》 猿媛之家 编著 百度百科