在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;
if (rh == null || rh.tid != getThreadId(current))
cachedHoldCounter = rh = readHolds.get();
else if (rh.count == 0)
readHolds.set(rh);
rh.count++;
}
return true;
}
}
}
复制代码
-
如果其他线程中已经持有了写锁，那么当前线程获取读锁失败
-
如果读锁的数量已经饱和，那么获取读锁失败
-
增加读锁的状态、成功获取读锁。
每次读锁的释放都会减少读状态。只有读读的状态是共享的，只有存在着写锁相关的操作，那么就都是互斥的。
============================================================================================
要理解Java中的锁对象，那么Java对象头结构就必须得了解清楚。
Java的对象头包括两部分内容：
-
Mark Word : 默认存储对象的HashCode，分代年龄和锁标志位信息。但是会根据对象的锁状态，从而改变这部分的内容。如下图所示。
-
Klass Point : 指向类型的指针，用于确定该对象是属于哪个类的实例
锁的级别目前有四级：有低至高分别是：无锁 -> 偏向锁 -> 轻量级锁 -> 重量级锁
锁只能升级，不能降级。也就是不能从轻量级锁变为偏向锁状态等等，但是只要对象释放了锁，那么就会恢复到无锁状态，到时候就又要从无锁状态开始，慢慢升级。
=====================================================================
无锁就是没有对资源进行锁定，所有的线程都可以对资源进行访问和修改，但是只有一个线程可以成功。
其实CAS就是无锁的一样实现方式，但是无锁并不能替代锁，因为无锁的弊端也是很明显的，我们只有在某些场景下才能使用无锁。
======================================================================
偏向锁的目的是消除数据在无竞争情况下的同步原语，进一步提高程序的运行性能。
偏向锁就是在无竞争的情况下把整个同步都消除掉，连CAS操作都不去做了。偏向锁会偏向于第一个获得它的线程，如果在接下来的执行过程中，该锁一直没有被其他的线程获取，则持有偏向锁的线程将永远不需要再进行同步。
如果锁总是由同一个线程获得，不存在多线程竞争，那么偏向锁的效果将会非常明显，因为它消除了获取锁的代价。
当锁对象第一次被线程获取的时候，虚拟机将会把对象头中的标志位设置为01，把偏向模式设置为1，表示进入偏向模式。同时使用CAS操作把获取到这个锁的线程的ID记录在对象的Mark Word之中。如果CAS操作成功，持有偏向锁的线程以后每次进入这个锁相关的同步块时，虚拟机都可以不再进行任何同步操作（例如加锁，解锁及对Mark Word的更新操作等）
一旦出现另外一个线程去尝试获取这个锁的情况，偏向锁模式就马上宣告结束。根据锁对象目前是否处于被锁定的状态决定是否撤销偏向，撤销后标志位恢复到未锁定或者轻量级锁定的状态，后续的同步操作就按照轻量级锁那样去执行。
假设一个对象刚开始实例化的时候，还没有任何线程持有该对象的锁，此时它是可以被偏向的。如果此时有一个线程来获取该对象的锁，它会偏向该线程，设置对象为偏向模式，并用CAS操作去设置对象的Mark Word，将Thread Id设置为获取该对象锁的线程的ID。如果该线程下次再来获取该对象的锁时就无需再进行CAS操作了，直接对比Mark Word中的Thread ID即可。
如果有第二个线程来获取该对象的锁，因为偏向锁不会主动释放，所以第二个线程是可以看得到该锁的偏向模型，此时它会检测第一个线程是否还存活，如果已经死去了，则设置对象为无锁状态，重新进入偏向模式。
如果检测到第一个线程依然存活，则会去检测该线程的操作栈，检测该线程是否依然需要持有偏向锁，如果不需要，则设置对象为无锁状态，重新进入偏向模式。
如果检测到第一个线程依然存活，并且检测到该线程依然需要持有偏向锁，则会将该偏向锁升级为轻量级锁。
如果在轻量级锁期间，第一个线程持有锁，第二个线程自旋等待获取锁，一个新的第三个线程也来获取该锁，此时就会出现对象锁的竞争，则会将该轻量级锁升级为重量级锁，重量级锁会将除了使用该锁的线程之外，都阻塞等待，防止CPU资源浪费。
在偏向锁的状态下，对象头的Mark Word都存储了线程ID，那么它要如何恢复对象的哈希码呢？因为哈希码只会计算一次，计算过一次之后就应该保持该值不变。所以应该要有一个地方将该计算好的哈希码存储起来，在轻量级锁的状态下，该哈希码是存储栈的Displaced Mark Word中的，在重量级锁的状态下，对象头指向了重量级锁的位置，代表重量级锁的 ObjectMonitor 类中有字段记录非加锁状态下的Mark Word。
但是偏向锁并没有存储能够存储哈希码的地方，所以当一个对象已经计算过一次一致性哈希码后，它就再也无法进入偏向锁状态了；而当一个对象当前正处于偏向锁状态，又收到需要计算其一致性哈希码请求时，它的偏向状态会被立即撤销，并且锁会膨胀为重量级锁。
计算一致性哈希码是说调用 Object::hashCode() 、 System:identityHashCode(Object) 这两个方法，如果程序员重写了对象的 hashCode() 方法，那么就不会发生将锁膨胀为重量级锁的情况。
=======================================================================
扫一扫
40万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
