乐观锁与悲观锁
乐观锁和悲观锁是在数据库中引入的名词，但是在并发包锁里面也引入了类似的思想。
悲观锁指对数据被外界修改持保守态度，认为数据很容易就会被其他线程修改，所以在数据被处理前先对数据进行加锁，并在整个数据处理过程中，使数据处于锁定状态。
悲观锁的实现往往依靠数据库提供的锁机制，即在数据库中，在对数据记录操作前给记录加排它锁。
- 如果获取锁失败，则说明数据正在被其他线程修改，当前线程则等待或者抛出异常。
- 如果获取锁成功，则对记录进行操作，然后提交事务后释放排它锁。
来看个例子
public int updateentry(long id) { //(1)使用悲观锁获取指定记录 Entryobiect entry = query("select * from tablel where id=#(id) for update", id); //(2)修改记录内容,根据计算修改 entry记录的属性 String name=generatorname(entry); entry.setname(name); //(3) update操作 int count= update("update tablel set name=#(name], age=#fage] where id =#{id}", entry); return count; }
假设updateEntry、query、update方法都使用了事务切面的方法，并且事务传播性被设置为required
执行updateEntry方法时如果上层调用方法里面没有开启事务，则会即时开启一个事务，然后执行代码（1）
代码（1）调用了query方法，其根据指定id从数据库里面查询出一个记录。由于事务传播性为requried，所以执行query时没有开启新的事务，而是加入了updateEntry开启的事务，也就是在updateEntry方法执行完毕提交事务时，query方法才会被提交，就是说记录的锁定会持续到updateEntry执行结束
代码（2）则对获取的记录进行修改，代码（3）把修改的内容写回数据库，同样代码（3)的update方法也没有开启新的事务，而是加入了updateEntry的事务。也就是updateEntry、query、update方法共用同一个事务
当多个线程同时调用updateEntry方法，并且传递的是同一个id时，只有一个线程执行代码（1）会成功，其他线程则会被阻塞，这是因为在同一时间只有一个线程可以获取对应记录的锁，在获取锁的线程释放锁前（updateEntry执行完毕，提交事务前），其他线程必须等待，也就是在同一时间只有一个线程可以对该记录进行修改。
乐观锁是相对悲观锁来说的，它认为数据在一般情况下不会造成冲突，所以在访问记录前不会加排它锁，而是在进行数据提交更新时，才会正式对数据冲突与否进行检测。具体来说，根据 update 返回的行数让用户决定如何去做。
将上面的例子改为使用乐观锁的代码如下。
public boolean updateentry(long id){ boolean result = false; int retrynum = 5; while(retrynum >0){ //(1.1)使用乐观锁获取指定记录 Entryobject entry =query("select *from tablel where id =#[id)",id); //(2.1)修改记录内容, version字段不能被修改 String name =generatorname(entry); entry. setname(name); //(3.1) update操作 int count = update("update tablel set name=#(name), age=#(age), version=${version}+1 where id =#(id) and version=#(version)", entry); if (count == 1){ result = true ; break; } retrynum--; } return result; }
如上代码使用retryNum设置更新失败后的重试次数，如果代码（3.1）执行后返回0，则说明代码（1.1）获取的记录已经被修改了，则循环一次，重新通过代码（1.1）获取最新的数据，然后再次执行代码（3.1）尝试更新。这类似CAS的自旋操作，只是这里没有使用死循环，而是指定了尝试次数。
乐观锁并不会使用数据库提供的锁机制，一般在表中添加 version 字段或者使用业务状态来实现。乐观锁直到提交时才锁定，所以不会产生任何死锁。
公平锁与非公平锁
根据线程获取锁的抢占机制，锁可以分为公平锁和非公平锁
- 公平锁表示线程获取锁的顺序是按照线程请求锁的时间早晚来决定的，也就是最早请求锁的线程将最早获取到锁。
- 非公平锁则在运行时闯入，也就是先来不一定先得。
ReentrantLock 提供了公平和非公平锁的实现。
- 公平锁：
ReentrantLock pairLock = new ReentrantLock(true)。 - 非公平锁：ReentrantLock pairLock = new ReentrantLock(false)。如果构造函数不传递参数，则默认是非公平锁。
假设线程 A 已经持有了锁，这时候线程 B 请求该锁其将会被挂起。当线程 A释放锁后，假如当前有线程 C 也需要获取该锁，如果采用非公平锁方式，则根据线程调度策略，线程 B 和 线程C 两者之一可能获取锁，这时候不需要任何其他干涉，而如果使用公平锁则需要把 C 挂起，让 B 获取当前锁。
在没有公平性需求的前提下尽量使用非公平锁，因为公平锁会带来性能开销。
独占锁与共享锁
根据锁只能被单个线程持有还是能被多个线程共同持有，锁可以分为独占锁和共享锁。
- 独占锁保证任何时候都只有一个线程能得到锁
- 独占锁是一种悲观锁，由于每次访问资源都先加上互斥锁，这限制了并发性，因为读操作并不会影响数据的一致性，而独占锁只允许在同一时间由一个线程读取数据，其他线程必须等待当前线程释放锁才能进行读取。
- 共享锁则是一种乐观锁，它放宽了加锁的条件，允许多个线程同时进行读操作。
- ReentrantLock 就是以独占方式实现的。
- 共享锁则可以同时由多个线程持有 ReadWriteLock 读写锁，它允许一个资源可以被多线程同时进行读操作。
可重入锁
当一个线程要获取一个被其他线程持有的独占锁时，该线程会被阻塞，那么当一个线程再次获取它自己已经获取的锁时是否会被阻塞呢？如果不被阻塞，那么我们说该锁是可重入的，也就是只要该线程获取了该锁，那么可以无限次数（严格来说是有限次数）地进入被该锁锁住的代码。
来个Demo， 看看在什么情况下会使用可重入锁
/** * @author 小工匠 * @version 1.0 * @description: TODO * @date 2021/11/27 10:43 * @mark: show me the code , change the world */ public class KeCongRuLockDemo { // synchronized public synchronized void lockA(){ System.out.println("lockA"); } // synchronized public synchronized void lockB(){ System.out.println("lockB ， then call lockA"); // 调用加锁的A方法 lockA(); } public static void main(String[] args) { KeCongRuLockDemo lockDemo = new KeCongRuLockDemo(); lockDemo.lockB(); } }
在如上代码中，调用 lockB方法前会先获取内置锁，然后打印输出。之后调用 lockA方法，在调用前会先去获取内置锁，如果内置锁不是可重入的，那么调用线程将会一直被阻塞。
实际上， synchronized 内部锁是可重入锁。
可重入锁的原理是在锁内部维护一个线程标示，用来标示该锁目前被哪个线程占用，然后关联一个计数器。一开始计数器值为0，说明该锁没有被任何线程占用。当一个线程获取了该锁时，计数器的值会变成1，这时其他线程再来获取该锁时会发现锁的所有者不是自己而被阻塞挂起。
但是当获取了该锁的线程再次获取锁时发现锁拥有者是自己，就会把计数器值加+1，当释放锁后计数器值-1。当计数器值为0时，锁里面的线程标示被重置为 null，这时候被阻塞的线程会被唤醒来竞争获取该锁。
可重入锁两个关键字： 线程标示 + 计数器
自旋锁
由于Java中的线程是与操作系统中的线程一一对应的，所以当一个线程在获取锁（比如独占锁）失败后，会被切换到内核状态而被挂起。
当该线程获取到锁时又需要将其切换到内核状态而唤醒该线程。而从用户状态切换到内核状态的开销是比较大的，在一定程度上会影响并发性能。
自旋锁是当前线程在获取锁时，如果发现锁已经被其他线程占有，它不马上阻塞自己，在不放弃CPU使用权的情况下，多次尝试获取（默认次数是10，可以使用-XX:PreBlockSpinsh参数设置该值），很有可能在后面几次尝试中其他线程已经释放了锁。如果尝试指定的次数后仍没有获取到锁则当前线程才会被阻塞挂起。
由此看来自旋锁是使用CPU时间换取线程阻塞与调度的开销，但是很有可能这些CPU时间白白浪费了.
