在Java中，可以这么使用乐观锁：
// 创建一个原子类的Integer类型
AtomicInteger integer = new AtomicInteger();
// 加1操作
int res = integer.getAndIncrement();
复制代码
我们创建了一个 AtomicInteger 类型的对象，然后对该对象执行了 getAndIncrement 方法，该方法的作用是先获取值然后再自增1。
自增操作的内部就是使用CAS算法，也就是无锁的操作。
CAS算法的步骤：CAS算法需要使用三个值，分别为期望值、实际值、新值。假如integer现在为0，现在需要进行自增操作
-
首先获取integer目前的值，为0，这个值被称为期望值
-
接着根据该对象在内存中的偏移量，获取内存中存储的值，这个值被称为实际值
-
对比期望值与实际值。
-
如果相等，则表示没有其他线程修改过该变量的值，那么就可以使用新值去进行修改。
-
如果不相等，则表示存在其他线程修改过该变量的值，那么就放弃此次操作。
-
如果失败了则从步骤1重新开始执行。
除了第1步之外，剩下的2，3，4，5步骤是一个原子操作，通过CPU的cmpxchg指令完成。如果不能保证是原子操作的话，将不能保证在获取完内存中的值后，是否会有其他线程去修改该内存中的值。
我们通过Java的源代码来看CAS的具体实现过程：
通过源码发现，实际是调用了unsafe对象的一个方法来实现的，unsafe对象是属于 Unsafe 这个类。该类的作用是可以获取到对象中指定变量在内存中的偏移量的值。这个类似于C语言中的指针操作，直接通过指
【一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义】
浏览器打开：qq.cn.hn/FTf 免费领取
针获取指定内存中的值。该类对于一般的开发人员是不可以使用的，只有JDK内部的开发人员可以使用，因为指针操作是不安全的，开发人员必须小心使用才能保证不会破坏内存中的数据，而对于部分使用Java的程序员来说，并没有这方面的知识储备，所以oracle才不开放使用（猜的）。如果想要使用的话，可以通过反射来使用。
我们可以看到 getAndAddInt 方法中，var5就是期望值、var2是偏移量、var5 + var4是新值。通过一个 while
循环，直到成功才会退出循环，否则将会一直重试。
CAS的缺点也是很明显的：
-
ABA问题?：假设线程1获取到的期望值为A，然后被其他线程修改为B，接着又被其他线程修改为A，此时线程1去获取实际值依然是A，但是该值却是被修改过的。通过ABA问题对于程序来说都不会造成太大的影响，如果需要解决该问题的话，可以使用一个带有版本号的值，每次执行CAS时，还会对比该版本号，只有版本号一致，才认为该值没有被修改过。Java也提供了一个 AtomicStampedReference 来解决ABA问题，此时值的修改就会变为A1 -> B2 -> A3
-
循环开销?：如果CAS自旋长时间不成功的话，将会消耗大量的CPU时间。
-
只能保证单个变量的原子操作?：每一次的CAS都只能对一个变量起作用，如果需要同时使用CAS修改多个变量的值，CAS就无法保证原子性了。Java中提供了 AtomicReference 类将多个变量都集中在一起，只要把多个变量都放入到 AtomicReference 的对象中就可以实现多个变量原子性的CAS操作。
在Java中，可以这么使用悲观锁：
// 隐式加锁
// synchronized同步方法
public synchronized void test(){}
// synchronized同步块
public void test(){
synchronized{
}
}
// 显示加锁
ReentrantLock lock = new ReentrantLock();
public void test(){
// 加锁
lock.lock();
// 释放锁
lock.unlock();
}
复制代码
在Java中，这两种加锁方式是比较常见的。悲观锁每次只有一个线程可以获得锁，获得锁后就可以执行临界区中的代码，其他线程如果要进入临界区，只能等待持有锁的线程释放锁，然后才会有机会获得锁，并执行临界区代码。
================================================================================
自旋锁是线程在遇到需要阻塞等待锁的时候，并不会马上进行阻塞，而是自旋获取锁，如果可以获得锁，那么就不需要进行阻塞挂起，如果自旋一定时间或次数还是没有获得锁，才进行阻塞挂起。
要了解自旋锁的目的首先要知道阻塞和唤醒Java线程是需要切换CPU状态来完成的，发生阻塞或者唤醒线程的系统调用导致CPU从用户态切换为核心态时，是需要消耗较多CPU资源的。如果我们让线程先自旋一定次数或时间，在这段时间如果能够获取到锁，那么就会减少CPU状态的切换，从而避免了线程切换的开销。
在许多场景下，同步资源的锁定时间都是很短的，为了这很短的时间从而增加了保存现场和恢复现场的开销是得不偿失的。
自旋锁也是存在缺点的，它不能代替阻塞。自旋虽然避免了线程切换带来的开销，但同时也增加了CPU执行的时间。在自旋的这段时间中，CPU的资源是白白消耗了的，如果锁持有的时间是很短的情况下，自旋的效果是很好的，但是如果长时间自旋得不到结果，那么就会导致过多的CPU资源被消耗掉，所以，线程不能无限制的自旋下去，而是要限制自旋的次数，当达到自旋次数限制的时候就要进行阻塞。在Java中，默认的自旋次数为10次。
JVM中可以通过设置 -XX:+UseSpinning 开启自旋锁，JDK6之后，默认是开启的。
JVM中可以通过设置 -XX:PreBlockSpin 来设置自旋次数。默认是10次。
在JDK6中，Java团队又为自旋锁增加了自适应，变为了自适应自旋锁，也就是自旋锁的次数（时间）不再是固定的了。而是根据上一个持有该锁的线程的自旋次数（时间）和状态来决定的，如果上一个线程刚刚通过自旋获得了锁，并且该线程还在运行中，那么JVM认为此次自旋的也是可以成功的，所以会适当的延长自旋时间，如果某一个自旋锁很少成功，那么JVM就会认为自旋的成功率很小，从而忽略自旋，直接进行阻塞。因为自旋所能获得的收益非常小，甚至可能是负收益。
自适应的自旋锁避免了因为长等待的锁也使用自旋锁，导致浪费了很多不必要的CPU资源的情况。
如果是短等待的锁的话，自旋带有的收益是很明显了，它避免了线程切换带来的开销。
==============================================================================
公平锁是指线程成功获取锁的顺序按照线程申请获取锁的顺序进行，线程申请锁的时候会进入到一个队列中排队，每一次有线程申请获取锁都会排在队列的最末尾，排在最前面的线程首先获取锁，以此类推。
对于公平锁形象化的解释就是：有一个售票处，每个人都必须按照先后秩序排队购票，因为有管理员的存在，不会存在插队的情况，每个需要购票的用户都必须排在队伍的末尾，而且只有前面的顾客购票完成之后才可以去购票，否则只能等待。
非公平锁则存在一种插队的情况，但是插队也不是任何时候都可以插队的，只有在刚好前一个购票完成，后一个购票还未开始时，才可以进行插队。如果在前一个还未购票完成时，是无法进行插队的，只能正常排队。
非公平锁也不一定就是随机获取的，依然存在排队的情况，而且排队中的线程获取锁的情况是与公平锁一样的。不一样的只有线程在获取锁的时候是有机会直接获取到锁，而不需要等待已经在队列中的线程都获取完锁。
非公平锁的性能比公平锁的性能要高一些，因为它较少了线程切换的开销：
-
对于公平锁而言，只要队列中存在等待的线程，那么当前线程就必定会被阻塞挂起，等待唤醒。
-
对于非公平锁而言，如果队列中存在等待的线程，在获取锁的时候，会先尝试是否可以成功获取到锁，如果能够成功，则避免了线程切换的开销。如果失败了，则依然要被阻塞挂起，等待唤醒，再获取锁资源。
在Java中， ReentrantLock 提供了公平锁和非公平锁。
public class ReentrantLock implements Lock{
public ReentrantLock() {
sync = new NonfairSync();
}
public ReentrantLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
}
}
复制代码
ReentrantLock 默认是为非公平锁，可以通过给构造函数传递 true 来显示指定获得公平锁。
================================================================================
可重入锁是指已经获取了指定锁资源的线程，在未释放指定锁资源的情况下，再次获取该指定的锁资源的时候不会发生阻塞。更加通俗的讲就是在外层代码已经获取了锁资源的情况下，在内层代码中依然可以获取到相同的锁资源。Java中的 ReentrantLock 、 synchronized 都是可重入锁。可重入锁在一定程序上避免了死锁的发生。
可重入锁：每个顾客在买票的时候，管理员允许了每一个锁跟每一个顾客的多个取票票据绑定，顾客可以在取完一次票后，可以不放弃锁，继续选择将锁与其他票据绑定去取票。
但如果是不可重入锁的话，管理员只允许每一个锁与每个顾客的一个取票票据绑定。那么顾客就不能在取完一个票后继续取票，因为锁还未归还给管理员，另外一个票据还无法与锁绑定。此时，就会发生死锁。
不可重入锁：在主流程中已经获得了锁，如果想要在子流程中再次获取该锁，是无法获取的，并且会发生死锁，因为子流程一直在等待主流程释放锁，而主流程因为子流程没有执行完，并不会释放锁。
我们可以想象一下如果 synchronized 是非可重入锁的话会怎么样：
public class Test {
public synchronized void firstStep(){
}
public synchronized void secondStep(){
}
}
复制代码
对于这个示例，如果在 firstStep 方法中调用 secondStep 方法的话，就会发生死锁。这样，我们在编写代码的时候，发生死锁的几率就会很大，因为这两个方法的锁都是同一个对象。
=============================================================================
共享锁是对于同一个锁，可以有多个线程同时获得锁；
独占锁则是每次只有一个线程可以获得锁，其他线程需要获得该锁，则需要等待获得锁的线程释放锁才有机会。
在 ReentrantReadWriteLock 中则同时使用了共享锁和独占锁。其中，共享锁用于读操作、独占锁用于写操作。
因为读操作是使用共享锁，所以可以支持高效的并发读操作。而对于读写、写写、写读操作，为了数据的一致性，都是必须互斥的。因为读锁和写锁的分离，相比于一般的互斥锁，有较大的性能提升。
我们直接看 ReentrantReadWriteLock 中是如何通过AQS来实现读锁和写锁共存的：
public class ReentrantReadWriteLock
implements ReadWriteLock, java.io.Serializable {
private static final long serialVersionUID = -6992448646407690164L;
/** Inner class providing readlock */
private final ReentrantReadWriteLock.ReadLock readerLock;
/** Inner class providing writelock */
private final ReentrantReadWriteLock.WriteLock writerLock;
/** Performs all synchronization mechanics */
final Sync sync;
/**
-
Creates a new {@code ReentrantReadWriteLock} with
-
default (nonfair) ordering properties.
*/
public ReentrantReadWriteLock() {
this(false);
}
/**
-
Creates a new {@code ReentrantReadWriteLock} with
-
the given fairness policy.
-
@param fair {@code true} if this lock should use a fair ordering policy
*/
public ReentrantReadWriteLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
readerLock = new ReadLock(this);
writerLock = new WriteLock(this);
}
}
复制代码
我们可以看到类中里面存在一个 ReadLock 和一个 WriteLock ，而这两个类实现了 Lock 接口，也就是真正的锁是由这两个类来实现的。
我们可以看到这两个类里面都有 Sync 类成员，该类则继承了AQS。 Sync 类才是真正的锁。
在 ReentrantReadWriteLock 中将锁的状态切分为了两种状态，其中高16位表示读锁的个数，低16位表示写锁的个数。
我们直接看写锁的加锁代码：
final boolean tryWriteLock() {
Thread current = Thread.currentThread(); // 获取当前线程
int c = getState(); // 获取锁的状态
if (c != 0) { // 判断是否存在线程获取了锁
int w = exclusiveCount?; // 获取占有独占锁的线程数量
if (w == 0 || current != getExclusiveOwnerThread()) // 存在读锁或者占有独占锁的线程不是当前线程，则失败
return false;
if (w == MAX_COUNT) // 如果可重入的独占锁数量饱和，则失败
throw new Error(“Maximum lock count exceeded”);
}
if (!compareAndSetState(c, c + 1)) // 设置写锁的状态。因为写锁是低16位，所以直接加1即可
return false;
setExclusiveOwnerThread(current); // 设置当前占有独占锁的线程
return true; // 成功
}
复制代码
-
如果存在读锁、或者当前线程不等于独占锁的线程，则返回失败
-
如果锁的数量已经饱和，返回失败。读锁和写锁最大可重入的锁数量均为65535
-
如果上面皆为失败，则使用CAS设置写锁的状态，设置独占锁的线程为当前线程。
写锁除了是独占锁这个条件之外，还添加了一个判断是否存在读锁的条件，如果存在读锁，则加锁失败。这是为了保证写锁期间的修改，对于正在运行的读锁的线程来说必须是可见的。如果允许在读锁期间，写锁也可以被获取，那么在当前正在运行的读线程就无法感知到写线程的操作，从而造成读写不一致的情况。
我们接着来看读锁的加锁代码：
final boolean tryReadLock() {
Thread current = Thread.currentThread(); \ 获取当前线程
for (;😉 { \ 无限循环
int c = getState(); \ 获取当前锁状态
if (exclusiveCount? != 0 && \ 如果存在写锁并且占用写锁的线程不是当前线程，则返回失败
getExclusiveOwnerThread() != current)
return false;
int r = sharedCount?; \ 获取共享锁的数量
if (r == MAX_COUNT) \ 确定锁的数量未饱和
throw new Error(“Maximum lock count exceeded”);
if (compareAndSetState(c, c + SHARED_UNIT)) { // 后面就是添加读锁的个数
if (r == 0) {
firstReader = current;
firstReaderHoldCount = 1;
} else if (firstReader == current) {
firstReaderHoldCount++;
} else {
HoldCounter rh = cachedHoldCounter;