在我们一个多线程程序中，同步是实现对一个方法或者模块进行独占式访问的方法，那么如何进行同步的操作呢？首先我们就会想到最常使用的方式就是synchronize同步块,但是在一个频繁发生操作的程序中如果一直使用synchronize同步块，那么就会大大影响程序的性能，并且同步块也有其使用的限制语境，所以我们必须寻找其他更灵活，性能更棒的同步方式。假如我们想进行在一个时间点内修改一个变量的值，我们可以使用volatile来修饰这个变量而不是synchronize，这样就会大大增加对变量独占操作的性能，另外我们也可以使用显式锁的方式来增加同步操作的灵活性,下面我们就来了解了解Java中的锁。
让我们来想一下synchronize的语义是什么：
1. 进入同步块
2. 对同步块中的内容进行单线程操作，阻塞其它线程
3. 跳出同步块，让其它的线程获取锁并执行同步块中的内容，即重复上面的步骤1和2
我们可以使用显式的锁来达到同样的目的，这个显式的锁就是Lock接口，让我们来看下面一个例子:
Lock lock = new ReentrantLock();
lock.lock();
try{
//do something
}finally{
lock.unlock();
}
上面就是一个显式锁的简单例子，这种方式比同步块来的更加的灵活，注意上面的代码，我们获取锁的语句写在了try-finally的外面，这是因为，假如我们把语句写到里面，假如我们获取锁的过程出现了异常，我们就会不必要地释放锁。我们来看下面一个例子
package com.fan.ThreadDemo;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.locks.AbstractQueuedSynchronizer;
import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.Lock;
public class Mutex implements Lock {
//静态内部类，用以实现对同步状态的基本操作
private static class Syn extends AbstractQueuedSynchronizer{
private static final long serialVersionUID = -8152719729798280428L;
protected boolean isHeldExclusively(){
return getState() == 1;//判断锁有没有被获取
}
public boolean tryAcquire(int acquire){
if(compareAndSetState(0, 1))//尝试使用CAS来对同步状态进行原子操作
{
setExclusiveOwnerThread(Thread.currentThread());//将当前线程设为获取锁的线程
return true;
}
return false;
}
public boolean tryRealease(){
Thread currentThread = Thread.currentThread();
if(getState() == 0)
throw new IllegalMonitorStateException();
if(currentThread == getExclusiveOwnerThread()){
setExclusiveOwnerThread(null);//释放锁
setState(0);
return true;
}
return false;
}
Condition newcondition(){return new ConditionObject();}
}
private final Syn syn = new Syn();
@Override
public void lock() {syn.acquire(1);}
@Override
public void lockInterruptibly() throws InterruptedException {syn.acquireInterruptibly(1);}
@Override
public boolean tryLock() {return syn.tryAcquire(1);}
@Override
public boolean tryLock(long time, TimeUnit unit)
throws InterruptedException {return syn.tryAcquireNanos(1, unit.toNanos(time));}
@Override
public void unlock() {syn.release(1);}
@Override
public Condition newCondition() {return syn.newcondition();}
public boolean hasQueuedThreads(){return syn.hasQueuedThreads();}
}
上例是一个实现对一个锁的进行线程互斥获取的类，在Mutex的静态内部类Syn中,tryAcquire使用判断CAS（CAS：利用原子操作的方式来进行判断并比较）操作是否成功的方式来设置当前线程为获取锁的线程，tryRealease中则采用采用将同步状态设为0，获取锁的线程设为空的方式来释放锁
AQS
显式锁和同步块的语义是一样的，让我们再看一下锁的语义的第二句，其中的阻塞其它线程中被阻塞的线程是个什么状态，等锁被释放后，被阻塞的锁获取锁采用的是什么策略呢，这些与一个同步组件的基础框架---AbstractQueueSynchronizer(AQS：队列同步器)有关，队列同步器使用了一个int型的变量来表示同步状态，通过内置的FIFO的同步队列来完成资源获取线程的排队工作，那么AQS是如何实现同步操作的呢，我们看下图
一个同步队列
当线程在获取锁的过程中被阻塞之后，这个线程会被包装成一个Node节点并被添加到如上图所示的一个线程同步队列之中
同步队列的节点的加入
假如现在有多个线程同时被阻塞，那么各个线程所获取的尾节点就有可能相同，这样，线程就不能被正确地添加到同步队列中去了，我们可以使用
compareAndSetTail(Node expect,Node update)来对加入同步队列的线程进行安全地插入
同步队列节点的删除
假如获取锁的线程现在释放了锁，并且同步队列的头结点获取了锁，那么同步队列的头结点的
prev和next会被设为null，同步器的head指向第二个节点，并改变第二个节点的状态。我们看上面的例子中的
lock()方法,这个方法的实现就是AQS的一个使用，它的代码如下
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
上面的例子的逻辑是这样的，假如获取锁失败则采用阻塞的方式加入等待的同步队列，我们再来看一下acquireQueued(addWaiter(Node.EXCLUSIVE), arg))的实现。
addWaiter(Node node)：
private Node addWaiter(Node mode) {
Node node = new Node(Thread.currentThread(), mode);
// Try the fast path of enq; backup to full enq on failure
Node pred = tail;
if (pred != null) {
node.prev = pred;
if (compareAndSetTail(pred, node)) {
pred.next = node;
return node;
}
}
enq(node);
return node;
}
private Node enq(final Node node) {
for (;;) {
Node t = tail;
if (t == null) { // Must initialize
if (compareAndSetHead(new Node()))
tail = head;
} else {
node.prev = t;
if (compareAndSetTail(t, node)) {
t.next = node;
return t;
}
}
}
}
上面的代码就是讲当前的线程打包为Node对象并插入同步队列，我们看一下上面的enq方法，这是为了保证当前的线程一定要被插入到同步队列中,好了，现在线程被插入到了同步队列，我们下面将插入的节点交给acquireQueued(Node node,int arg)处理，acquireQueued(Node node,int arg)的实现如下所示
final boolean acquireQueued(final Node node, int arg) {
boolean failed = true;
try {
boolean interrupted = false;
for (;;) {
final Node p = node.predecessor();
if (p == head && tryAcquire(arg)) {
setHead(node);
p.next = null; // help GC
failed = false;
return interrupted;
}
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
}
} finally {
if (failed)
cancelAcquire(node);
}
}
可以看到，这个方法会根据自身的前驱节点是不是头结点来决定要不要进行获取锁的操作，加入不是，则进入一个休眠期，当获取锁成功后，则将其next设为null并唤醒下一个节点。以上就是根据阻塞获取锁的方式来分析了一下AQS的实现原理
公平锁和非公平锁
公平锁是指希望获取锁的线程可以按照请求的顺序进行获取锁，而非公平锁则是获取锁的过程是一个竞争的过程，非公平锁的效率在大量的获取锁的程序中效率要远高于公平锁，但是容易出现获取锁时间长的线程无法获取锁的现象，我们把这种情况称为‘饥饿’，ReetrantLock锁可以使用其构造参数来确定这个锁是公平的还是非公平的
new ReetrantLock(true);//公平锁
new ReetrantLock(false);//非公平锁
重入锁(ReetrantLock)
重入锁是一种重复获取的锁，我们在使用这样的锁时，可以对其进行重复的加锁。我们看一下非公平重入锁的获取实现
final boolean nonfairTryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
if (compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0) // overflow
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}
可以看到，非公平锁并没有把获取锁失败的线程加入同步队列中去，再看一下它重入的过程，就是只有已经获取锁的线程才可以继续获取锁，并更新状态，一般是自增地增加状态
再看一下非公平锁的释放过程
protected final boolean tryRelease(int releases) {
int c = getState() - releases;
if (Thread.currentThread() != getExclusiveOwnerThread())
throw new IllegalMonitorStateException();
boolean free = false;
if (c == 0) {
free = true;
setExclusiveOwnerThread(null);
}
setState(c);
return free;
}
可以看到也是一个不停地自减锁的状态，直到状态为0时将锁设为null以便后面的线程可以接着获取这个锁
既然我们把非公平锁的实现贴上来了，那我们不妨也将公平锁的实现也来分析一下
protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
if (!hasQueuedPredecessors() &&
compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0)
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}
}
可以看到和非公平锁唯一的区别就是多了一个! hasQueuedPredecessors()这样的判断，这样就可以保证每次都只是头结点获取锁了
读写锁
我们之前用来同步的资源是独占式访问的，但是我们有一些资源的访问方式有两种，即读和写，而且有时候读取的次数远比写入的次数多，假如我们在每次读的时候都要加锁，而读的时候数据并没有发生变化，那么很明显就会出现读访问效率低下的问题，假如我们在任何时候都不加锁，那么资源的修改和读取的安全性就得不到保证，为此，我们引入了读写锁的概念，读写锁的语义如下
1. 在写锁被当前线程获取的时候，任何锁都不能被其它线程获取
2. 在读锁被获取的情况下，任何线程都可以继续获取读锁，但是写锁不能被获取
3. 当读写锁在读模式的锁状态时，如果有另外的线程试图以写模式加锁，读写锁通常会阻塞随后的读模式锁的请求，这样可以避免读模式锁长期占用，而等待的写模式锁请求则长期阻塞
很明显，读写锁很适合大量读访问和少量写访问的程序。
那么读写锁是怎么实现的呢，读写锁的状态是32位的整型数字，假设用State表示。前16位表示读，后16位表示写，当获取写锁时，State的低位自增1，即执行这样的操作：State + 1，当读锁被获取时，执行这样的操作：State+(1<<16),具体的我们看下面的代码
写锁的获取：
protected final boolean tryAcquire(int acquires) {
Thread current = Thread.currentThread();
int c = getState();
int w = exclusiveCount(c);
if (c != 0) {
// (Note: if c != 0 and w == 0 then shared count != 0)
if (w == 0 || current != getExclusiveOwnerThread())
return false;
if (w + exclusiveCount(acquires) > MAX_COUNT)
throw new Error("Maximum lock count exceeded");
// Reentrant acquire
setState(c + acquires);
return true;
}
if (writerShouldBlock() ||
!compareAndSetState(c, c + acquires))
return false;
setExclusiveOwnerThread(current);
return true;
}
从上面的代码我们可以看到，当只有读锁的情况下，是不能获取写锁的，但是写锁可以进行重入
读锁的获取:
final boolean tryReadLock() {
Thread current = Thread.currentThread();
for (;;) {
int c = getState();
if (exclusiveCount(c) != 0 &&
getExclusiveOwnerThread() != current)
return false;
int r = sharedCount(c);
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;
}
}
}
从上面的代码来看，它是这样工作的
.首先判断写锁是否被获取，假如被获取，而且获取的线程不是当前线程，那么读锁将不能被获取
.不能获取超过设限数目的锁
.利用HoldCounter对象来存储当前线程获取的读锁数目，假如获取读锁成功，那么当前的HoldCounter里面的counter成员变量自增1
网友评论