学会数据库悲观锁的设置方法 (怎么在数据库上加悲观锁)
随着数据库技术的不断发展，对数据的操作越来越频繁，对数据的安全性和一致性的要求也越来越高。为了保证数据的一致性，数据库引入了锁机制。锁可以分为乐观锁和悲观锁两种，其中悲观锁是最常用的一种锁。在本文中，我们将介绍，以达到更好的数据保护结果。
什么是悲观锁
悲观锁是一种独占锁，它假设数据的并发访问量非常高，每当一个事务想要访问某个数据时，就会先把该数据加锁，这样，其他访问该数据的事务就需要等待该数据的锁被释放。在悲观锁的情况下，只允许一个事务对数据进行更新，避免了数据的冲突和脏数据。
设置悲观锁的方法
数据库中悲观锁的使用方法和实现方式有多种，其中最常用的方式是基于事务的悲观锁。在使用基于事务的悲观锁时，我们可以使用select … for update语句将需要访问的数据加上悲观锁，该语句会锁住所有访问该数据的记录，直到某个事务完成为止。
以下是基于事务的悲观锁的实现代码示例：
BEGIN;
SELECT * FROM table WHERE id = 1 FOR UPDATE;
UPDATE table SET name = ‘New Name’ WHERE id = 1;
COMMIT;
在这个实例中，我们首先使用BEGIN语句标记一个事务，然后在SELECT语句中使用FOR UPDATE将需要访问的数据加上悲观锁。在UPDATE语句中，我们对数据进行了修改，最后使用COMMIT语句提交事务。
除了基于事务的悲观锁，我们还可以使用数据库锁机制来实现悲观锁。在数据库锁的实现中，我们可以对需要访问的数据行或列加锁，在列锁和行锁的选择上，需要根据具体的业务需求来决定。
如果需要加锁的是某个列，我们可以使用FOR UPDATE关键字将该列加上悲观锁，以下是一个示例代码：
SELECT name FROM table WHERE id = 1 FOR UPDATE;
在这个示例中，我们使用SELECT语句查询了表中ID为1的记录，同时使用FOR UPDATE将name列加上了悲观锁。这样，当其他事务尝试访问该记录时，会被阻塞，直到该悲观锁被释放。
如果需要加锁的是某一行数据，我们可以使用SELECT … FOR UPDATE语句加上悲观锁，以下是一个实例代码：
SELECT * FROM table WHERE id = 1 FOR UPDATE;
在这个代码示例中，我们使用SELECT … FOR UPDATE锁定了ID为1的行数据，这样其他事务就无法对该行进行更新操作。
悲观锁是一种常用的数据锁技术，在实际应用场景中具有重要的作用。为了提高数据库的数据保护效果，需要合理、准确地应用悲观锁技术。本文中，我们介绍了基于事务的悲观锁和数据库锁机制的悲观锁两种实现方式，都是比较常用的实现方式。通过掌握这些实现方式，我们可以更加有效地对数据进行保护，确保数据的安全性和完整性。
相关问题拓展阅读：
如何给oracle数据库添加乐观锁
乐观锁一开始也说了，就是一开始假设不会造成数据冲突，在最后提交的时候再册信进行数据冲突检测。在乐观锁中，我们有3种
常用的做法来实现。
之一种就是在数据取得的时候把整个数据都copy到应用中，在进行提交的时候比对当前数据库中的数据和开始的时候更新前取得的数据。当发现两个数据一模一样以后，就表示没有冲突可以提交，否则则是并发冲突，需要去用业务逻辑进行解决。
第二种乐观锁的做法就是采用版本戳，这个在Hibernate中得到了使用。采用版本戳的话，首先需要在你有乐观锁的数据库table上建立一个新的column，比如为number型，当你数据每更新一次的时候，版本数就会往上增加1。比如同样有2个session同样对某条数据进行操作。两者都取到当前的数据的版本号为1，当之一个session进行数据更新后，在提交的时候查看到当前数据的版本还为1，和自己一开始取到的版本相同。就正式提交，然后把版本号增加1，这个时候当前数据的版本为2。当第二个session也更新了数据提交的时候，发现数据库中版本为2，和一开始这个session取到的版本号不一致，就知道别人更新过此条数据，这个
时候再进行业务处理，比如整个Transaction都Rollback等等操作。在用版本戳的时候如姿升，可以在应用程序侧使用版本戳的验证，也可以在数据库侧采用Trigger(触发器)来进行验证。不过数据库的Trigger的性能开销还是比较的大，所以能在应用侧进行验证的话还是推荐不用Trigger。
第三种做法和第二种做法有点类似，就是也新增一个Table的Column，不过这次这个column是采用timestamp型，存储渣老数据最后更新的时间。在Oracle9i以后可以采用新的数据类型，也就是timestamp with time zone类型来做时间戳。这种Timestamp的数据精度在Oracle的时间类型中是更高的，精确到微秒(还没与到纳秒的级别)，一般来说，加上数据库处理时间和人的思考动作时间，微秒级别是非常非常够了，其实只要精确到毫秒甚至秒都应该没有什么问题。和刚才的版本戳类似，也是在更新提交的时候检查当前数据库中数据的时间戳和自己更新前取到的时间戳进行对比，如果一致则OK，否则就是版本冲突。如果不想把代码写在程序中或者由于别的原因无法把代码写在现有的程序中，也可以把这个时间戳乐观锁逻辑写在Trigger或者存储过程中。
synchronized是悲观锁吗
你碰到这个问题属于多线程共享资源（余额）的问肢则题，可以给使用资源加锁的做禅饥渗法，悲观锁和乐观锁都可以实现，悲观锁适用于并发压力小的情况，乐观锁适用于并发压力大的情况。具体概念可以百度查询。在changeBalance的方法上加synchronized声明是属于悲观锁的做法，实际操作一般使用数据库提供的锁，余额是保存在数据库中的，使用select for update来加悲观锁。乐观锁一般是在更新余额之前先查询余额相关的版本，然后在事物操作要提交之前再查一次版本，将两个版本比对，如果相同说明没有其它线程贺脊或进程更新过此资源，可以提交，提交过后版本更新，否则则回滚之前的操作，重新执行此事物操作。实际操作过程中，锁操作一般由数据库提供支持，分布式系统中现在最常用的的是zookeeper。
关于怎么在数据库上加悲观锁的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。
