java如何给数据库加行锁

与java无关，要用sql语句实现

前提目标表要有索引，查询要开启事物，使用select from tb with(updlock) where col ＝ xxx将一行数据锁住，其他连接不能再修改表

MyISAM和InnoDB存储引擎使用的锁：

封锁粒度小：

由于InnoDB存储引擎支持的是行级别的锁，因此意向锁（因为意向锁是表锁）其实不会阻塞除全表扫以外的任何请求。故表级意向锁与行级锁的兼容性如下所示

参考

参考

行锁的三种算法：

这条语句阻止其他事务插入10和20之间的数字，无论这个数字是否存在。 间隙可以跨越0个，单个或多个索引值。

>

您好！锁是数据库中的一个非常重要的概念，它主要用于多用户环境下保证数据库完整性和一致性。

我们知道，多个用户能够同时 *** 纵同一个数据库中的数据，会发生数据不一致现象。即如果没有锁定且多个用户同时访问一个数据库，则当他们的事务同时使用相同的数据时可能会发生问题。这些问题包括：丢失更新、脏读、不可重复读和幻觉读。数据库加锁就是为了解决以上的问题。

当然，加锁固然好，但是一定要避免死锁的出现。

在数据库系统中，死锁是指多个用户（进程）分别锁定了一个资源，并又试图请求锁定对方已经锁定的资源，这就产生了一个锁定请求环，导致多个用户（进程）都处于等待对方释放所锁定资源的状态。这种死锁是最典型的死锁形式, 例如在同一时间内有两个事务A和B，事务A有两个 *** 作：锁定表part和请求访问表supplier；事务B也有两个 *** 作：锁定表supplier和请求访问表part。结果，事务A和事务B之间发生了死锁。死锁的第二种情况是，当在一个数据库中时，有若干个长时间运行的事务执行并行的 *** 作，当查询分析器处理一种非常复杂的查询例如连接查询时，那么由于不能控制处理的顺序，有可能发生死锁现象。

在应用程序中就可以采用下面的一些方法来尽量避免死锁了： （1）合理安排表访问顺序。 （2）在事务中尽量避免用户干预，尽量使一个事务处理的任务少些, 保持事务简短并在一个批处理中。 （3）数据访问时域离散法, 数据访问时域离散法是指在客户机/服务器结构中，采取各种控制手段控制对数据库或数据库中的对象访问时间段。主要通过以下方式实现: 合理安排后台事务的执行时间，采用工作流对后台事务进行统一管理。工作流在管理任务时，一方面限制同一类任务的线程数（往往限制为1个），防止资源过多占用; 另一方面合理安排不同任务执行时序、时间，尽量避免多个后台任务同时执行，另外， 避免在前台交易高峰时间运行后台任务。 （4）数据存储空间离散法。数据存储空间离散法是指采取各种手段，将逻辑上在一个表中的数据分散到若干离散的空间上去，以便改善对表的访问性能。主要通过以下方法实现: 第一，将大表按行或列分解为若干小表; 第二，按不同的用户群分解。 （5）使用尽可能低的隔离性级别。隔离性级别是指为保证数据库数据的完整性和一致性而使多用户事务隔离的程度，SQL92定义了4种隔离性级别：未提交读、提交读、可重复读和可串行。如果选择过高的隔离性级别，如可串行，虽然系统可以因实现更好隔离性而更大程度上保证数据的完整性和一致性，但各事务间冲突而死锁的机会大大增加，大大影响了系统性能。 （6）使用绑定连接, 绑定连接允许两个或多个事务连接共享事务和锁，而且任何一个事务连接要申请锁如同另外一个事务要申请锁一样，因此可以允许这些事务共享数据而不会有加锁的冲突。

总之，了解SQL Server的锁机制，掌握数据库锁定方法, 对一个合格的DBA来说是很重要的。

锁是

数据库保护数据表的一种机制，通常是自动的，分级别的，如果你访问一个表的并发量太大，可以试试拆分这个表，比如按日期拆分成月表，或者利用oracle的功能（分区）进行拆分来分散压力，如果没有依据拆分的话，可以做成实体化快照，将一些查询类的 *** 作指向这个快照，分摊表的访问量，也可以通过提升硬件，比如上SSD磁盘，然后将这个表放到这个磁盘上，提高访问速度。

ConnectOracle con = new ConnectOracle();

Connection connect = congetConnection();

// 设置手动提交事务

connectsetAutoCommit(false);

Statement stmt = connectcreateStatement();

// 锁表

stmtaddBatch("lock table t_symbol_code_fee in exclusive mode");

// 此处打上断点后，执行另一个类，你会发现，执行成功后并没有更改记录，因为表已经被锁定。只有提交事务后，TestOracle中执行的修改才能生效。

stmtexecuteBatch();

// 提交后自动解锁，回滚时也会自动解锁

connectcommit();

stmtclose();

connectclose();

您好：

提供一下数据库锁的概念。

数据库是一个多用户使用的共享资源。当多个用户并发地存取数据时，在数据库中就会产生多个事务同时存取同一数据的情况。若对并发 *** 作不加控制就可能会读取和存储不正确的数据，破坏数据库的一致性。

加锁是实现数据库并发控制的一个非常重要的技术。当事务在对某个数据对象进行 *** 作前，先向系统发出请求，对其加锁。加锁后事务就对该数据对象有了一定的控制，在该事务释放锁之前，其他的事务不能对此数据对象进行更新 *** 作。

锁是为了各个用户能够准确的 *** 作数据而存在的。

Java中的锁主要包括synchronized锁和JUC包中的锁，这些锁都是针对单个JVM实例上的锁，对于分布式环境如果我们需要加锁就显得无能为力。在单个JVM实例上，锁的竞争者通常是一些不同的线程，而在分布式环境中，锁的竞争者通常是一些不同的线程或者进程。如何实现在分布式环境中对一个对象进行加锁呢？答案就是分布式锁。

目前分布式锁的实现方案主要包括三种：

基于数据库实现分布式锁主要是利用数据库的唯一索引来实现，唯一索引天然具有排他性，这刚好符合我们对锁的要求：同一时刻只能允许一个竞争者获取锁。加锁时我们在数据库中插入一条锁记录，利用业务id进行防重。当第一个竞争者加锁成功后，第二个竞争者再来加锁就会抛出唯一索引冲突，如果抛出这个异常，我们就判定当前竞争者加锁失败。防重业务id需要我们自己来定义，例如我们的锁对象是一个方法，则我们的业务防重id就是这个方法的名字，如果锁定的对象是一个类，则业务防重id就是这个类名。

基于缓存实现分布式锁：理论上来说使用缓存来实现分布式锁的效率最高，加锁速度最快，因为Redis几乎都是纯内存 *** 作，而基于数据库的方案和基于Zookeeper的方案都会涉及到磁盘文件IO，效率相对低下。一般使用Redis来实现分布式锁都是利用Redis的 SETNX key value 这个命令，只有当key不存在时才会执行成功，如果key已经存在则命令执行失败。

基于Zookeeper：Zookeeper一般用作配置中心，其实现分布式锁的原理和Redis类似，我们在Zookeeper中创建瞬时节点，利用节点不能重复创建的特性来保证排他性。

在实现分布式锁的时候我们需要考虑一些问题，例如：分布式锁是否可重入，分布式锁的释放时机，分布式锁服务端是否有单点问题等。

上面已经分析了基于数据库实现分布式锁的基本原理：通过唯一索引保持排他性，加锁时插入一条记录，解锁是删除这条记录。下面我们就简要实现一下基于数据库的分布式锁。

id字段是数据库的自增id，unique_mutex字段就是我们的防重id，也就是加锁的对象，此对象唯一。在这张表上我们加了一个唯一索引，保证unique_mutex唯一性。holder_id代表竞争到锁的持有者id。

如果当前sql执行成功代表加锁成功，如果抛出唯一索引异常(DuplicatedKeyException)则代表加锁失败，当前锁已经被其他竞争者获取。

解锁很简单，直接删除此条记录即可。

是否可重入 ：就以上的方案来说，我们实现的分布式锁是不可重入的，即是是同一个竞争者，在获取锁后未释放锁之前再来加锁，一样会加锁失败，因此是不可重入的。解决不可重入问题也很简单：加锁时判断记录中是否存在unique_mutex的记录，如果存在且holder_id和当前竞争者id相同，则加锁成功。这样就可以解决不可重入问题。

锁释放时机 ：设想如果一个竞争者获取锁时候，进程挂了，此时distributed_lock表中的这条记录就会一直存在，其他竞争者无法加锁。为了解决这个问题，每次加锁之前我们先判断已经存在的记录的创建时间和当前系统时间之间的差是否已经超过超时时间，如果已经超过则先删除这条记录，再插入新的记录。另外在解锁时，必须是锁的持有者来解锁，其他竞争者无法解锁。这点可以通过holder_id字段来判定。

数据库单点问题 ：单个数据库容易产生单点问题：如果数据库挂了，我们的锁服务就挂了。对于这个问题，可以考虑实现数据库的高可用方案，例如MySQL的MHA高可用解决方案。

使用Jedis来和Redis通信。

可以看到，我们加锁就一行代码：

jedisset(String key, String value, String nxxx, String expx, int time);

这个set()方法一共五个形参：

第一个为key,我们使用key来当锁，因为key是唯一的。

第二个为value，这里写的是锁竞争者的id，在解锁时，我们需要判断当前解锁的竞争者id是否为锁持有者。

第三个为nxxx，这个参数我们填的是NX，意思是SET IF NOT EXIST，即当key不存在时，我们进行set *** 作；若key已经存在，则不做任何 *** 作。

第四个为expx，这个参数我们传的是PX，意思是我们要给这个key加一个过期时间的设置，具体时间由第五个参数决定；

第五个参数为time，与第四个参数相呼应，代表key的过期时间。

总的来说，执行上面的set()方法就只会导致两种结果：1当前没有锁（key不存在）,那么久进行加锁 *** 作，并对锁设置一个有效期，同时value表示加锁的客户端。2已经有锁存在，不做任何 *** 作。

上述解锁请求中， SET_IF_NOT_EXIST (不存在则执行)保证了加锁请求的排他性，缓存超时机制保证了即使一个竞争者加锁之后挂了，也不会产生死锁问题：超时之后其他竞争者依然可以获取锁。通过设置value为竞争者的id，保证了只有锁的持有者才能来解锁，否则任何竞争者都能解锁，那岂不是乱套了。

解锁的步骤：

注意到这里解锁其实是分为2个步骤，涉及到解锁 *** 作的一个原子性 *** 作问题。这也是为什么我们解锁的时候用Lua脚本来实现，因为Lua脚本可以保证 *** 作的原子性。那么这里为什么需要保证这两个步骤的 *** 作是原子 *** 作呢？

设想：假设当前锁的持有者是竞争者1，竞争者1来解锁，成功执行第1步，判断自己就是锁持有者，这是还未执行第2步。这是锁过期了，然后竞争者2对这个key进行了加锁。加锁完成后，竞争者1又来执行第2步，此时错误产生了：竞争者1解锁了不属于自己持有的锁。可能会有人问为什么竞争者1执行完第1步之后突然停止了呢？这个问题其实很好回答，例如竞争者1所在的JVM发生了GC停顿，导致竞争者1的线程停顿。这样的情况发生的概率很低，但是请记住即使只有万分之一的概率，在线上环境中完全可能发生。因此必须保证这两个步骤的 *** 作是原子 *** 作。

是否可重入 ：以上实现的锁是不可重入的，如果需要实现可重入，在 SET_IF_NOT_EXIST 之后，再判断key对应的value是否为当前竞争者id，如果是返回加锁成功，否则失败。

锁释放时机 ：加锁时我们设置了key的超时，当超时后，如果还未解锁，则自动删除key达到解锁的目的。如果一个竞争者获取锁之后挂了，我们的锁服务最多也就在超时时间的这段时间之内不可用。

Redis单点问题 ：如果需要保证锁服务的高可用，可以对Redis做高可用方案：Redis集群+主从切换。目前都有比较成熟的解决方案。

利用Zookeeper创建临时有序节点来实现分布式锁：

其基本思想类似于AQS中的等待队列，将请求排队处理。其流程图如下：

解决不可重入 ：客户端加锁时将主机和线程信息写入锁中，下一次再来加锁时直接和序列最小的节点对比，如果相同，则加锁成功，锁重入。

锁释放时机 ：由于我们创建的节点是顺序临时节点，当客户端获取锁成功之后突然session会话断开，ZK会自动删除这个临时节点。

单点问题 ：ZK是集群部署的，主要一半以上的机器存活，就可以保证服务可用性。

Zookeeper第三方客户端curator中已经实现了基于Zookeeper的分布式锁。利用curator加锁和解锁的代码如下：

以上就是关于java如何给数据库加行锁全部的内容，包括:java如何给数据库加行锁、深入理解MySQL数据库各种锁（总结）、“sql”加锁机制是什么等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！