悲观锁
总是假设最坏的情况,每次去拿数据的时候都认为别人会修改数据,所以每次在拿数据的时候都会上锁,这样别人想去那这个数据就会阻塞直到它拿到锁。
传统的关系型数据库里面就用到了很多这种的锁机制,比如:行锁、表锁、写锁、读锁等,都是在做操作之前先上锁,再比如 Java 里面的 synchronized 关键字的实现也是悲观锁(非公平锁)。
乐观锁
跟它名字一样,人家就是谜一样的自信。
线程每次去拿数据的时候都认为别人不会修改数据,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版本号等机制。
乐观锁适用于多读的应用类型,这样可以提高吞吐量,像数据库提供类似于 write_condition 机制,其实都是提供的乐观锁。在 java 中 java.util.concurrent.atomic 包下的原子变量类就是使用了乐观锁的一种实现方式 CAS 实现的。
乐观锁的实现方式
- 使用版本标识来确定读到的数据与提交时的数据是否一致,提交后修改版本标识,不一致时可以采取丢弃和再次尝试的策略。
- java 中的 Compare and Swap 即 CAS ,当多个线程尝试使用 CAS 同时更新同一个变量时,只有其中一个线程能更新变量的值,而其他线程都失败,失败的线程并不会挂起,而被告知这次的竞争你这次失败了,并可以再次尝试。CAS 操作中包含三个操作数 —— 需要读写的内存位置(V)、进行比较的预期原值(A)和拟写入的新值(B)。如果内存位置 V 的值与预期的原值 A 相匹配,那么处理器会自动将该位置值更新为新值 B 。否则,处理器啥也不干,不做任何操作。