悲观锁

68 阅读2分钟

开启掘金成长之旅!这是我参与「掘金日新计划 · 2 月更文挑战」的第 20 天,点击查看活动详情

前言

为了应付多线程下发生的一些并发问题,我们需要加锁来保证业务的完成。在前一天的文章中已经讲了其中一种锁——乐观锁,所以接下来我们来将另一种锁——悲观锁。

悲观锁的实际应用

就拿我前一篇文章的限量购买问题举一个例子,我们在上一篇文章中说明这个购买的时候加入一个乐观锁就阻止了超卖问题的发生。可是现在我们想要这么一个设定,我只允许一个人买一件,这个时候就不行了。这时就会有聪明的掘友就会说了,你不会在去设置一个表,然后记录一下,谁谁购买了,通过查边确定一人一单。这样做在单线程情况下肯定是没有问题的,但是在多线程情况下,在第一个线程将自己的记录写入表时,第二个线程发起请求,这个时候数据库还有对应的数据所以也会写入购买记录表。在就会造成一人一单功能的失效。这时我们就需要悲观锁。

悲观锁

首先来一段悲观锁大概的定义,“认为线程安全问题一定会发生,因此在操作数据之前先获取锁,确保线程串行执行。”像就Java中的 Synchronized、Lock都属于悲观锁。像上面这个例子我们需要拿到对应订单人的信息作为锁,然后直到拿到锁的这个线程成功完成写入数据时,释放锁就好了。

悲观锁的优缺点

像悲观锁因为他是认为问题一定会发生的,所以安全性比较好,但是因为认为一定会发生,所以做了相应的处理,性能也比较慢。同时悲观锁有时也要考虑是否在方法外面拿到锁,以及对应的事务会不会失效的问题。