概述
跟synchronized一样，lock也是常用的用于多线程开发线程同步的一种手段，有相似的点也有不同的点。
他是java的一个类，基本都是在java类中实现同步，而synchronized是在JVM中实现的。
synchronized和lock他们的不同点
- 一个是关键字标识符，一个是一个类，在代码中的用法不同
- 一个是在JVM中实现的，一个是用java代码实现的，实现的层面不同。
- sunchronized在jdk1.6以后，优化了很多，如自旋锁，偏向锁，轻量级锁，锁粗化，锁消除等，使用起来清晰简单。而lock则更多适用于应用层，比如开发出读写锁（可同时读，但不可同时写和同时读写）、公平锁等，只需要继承和重写一些方法即可。所以两者在适用的情况也有着区别。
- 前者还不可以判断是否获得锁，后者可以判断
- 前者会阻塞，后者可能在未获得锁的情况下直接结束
- 前者不需要手动释放锁，自动的。而后者需要在finally中手动释放锁
相同点
- 都能够解决多线程同步的问题
- 都能可以线程间相互作用，比如wait,notify和notifyAll方法。而lock则是Condition对象的：await, signal,signalAll 方法
- 他们内部大部分实现都通过基于CAS来确定更新安全的（自我感觉）
- 阻塞都是交给操作系统来实现，调用操作系统的pthread_mutex_lock，所以阻塞操作操作系统在内核态和用户态切换，很浪费资源
Lock实现思想
简单说来，AbstractQueuedSynchronizer会把所有的请求线程构成一个CLH队列，当一个线程执行完毕（lock.unlock()）时会激活自己的后继节点，但正在执行的线程并不在队列中，而那些等待执行的线程全部处于阻塞状态，经过调查线程的显式阻塞是通过调用LockSupport.park()完成，而LockSupport.park()则调用sun.misc.Unsafe.park()本地方法，再进一步，HotSpot在Linux中中通过调用pthread_mutex_lock函数把线程交给系统内核进行阻塞。
既当有线程请求获得该锁时会先尝试，失败了再加入到队列（一般队列先执行head节点，所以先进的先获得锁，后进的在尾部），所以可能后请求的未进入队列就可以获得锁，既非公平锁。当head获得锁之后会出队列，然后next节点变成head节点，等待，当使用的线程解锁后再下一位HEAD节点
LOCK源码
先贴出来可重入锁大概的内部结构
package java.util.concurrent.locks;
import java.util.concurrent.TimeUnit;
public interface Lock {
//取得锁，但是要注意lock()忽视interrupt(), 拿不到锁就 一直阻塞
void lock();
//同样也是取得锁，但是lockInterruptibly()会响应打扰 interrupt()并catch到InterruptedException，从而跳出阻塞
void lockInterruptibly() throws InterruptedException;
//尝试取得锁，成功返回true
boolean tryLock();
//在规定的时间等待里，如果取得锁就返回tre
boolean tryLock(long time, TimeUnit unit) throws InterruptedException;
//释放锁
void unlock();
//条件状态，非常有用，Blockingqueue阻塞队列就是用到它了
Condition newCondition();
}原始的锁接口，常用的方法
public class ReentrantLock implements Lock, java.io.Serializable {
private static final long serialVersionUID = 7373984872572414699L;
private final Sync sync; //就只有一个Sync变量，ReentrantLock的所有方法基本都是调用Sync的方法
//构造函数
public ReentrantLock() {
sync = new NonfairSync(); //默认非公平锁
}
public ReentrantLock(boolean fair) {
sync = (fair)? new FairSync() : new NonfairSync();//公平锁
}
//其里的公平锁的意思是哪个线程先来等待，谁就先获得这个锁。而非公平锁则是看操作系统的调度，有不确定//性。一般设置成非公平锁的性能会好很多。
//然后看看部分lock方法
public void lock() {
sync.lock();
}
//还有这个
public void lockInterruptibly() throws InterruptedException {
sync.acquireInterruptibly(1);
}
//在来看看一些内置类
//Sync
abstract static class Sync extends AbstractQueuedSynchronizer {
private static final long serialVersionUID = -5179523762034025860L;
}
//非公平锁
final static class NonfairSync extends Sync {
private static final long serialVersionUID = 7316153563782823691L;
final void lock() {
if (compareAndSetState(0, 1)) //0未获取，1已经获取
setExclusiveOwnerThread(Thread.currentThread());//设置独占模式，则一个锁只能被一个线程持有，其他线程必须要等待。
else
acquire(1);//如果没有取得锁，尝试使用信号量的方式
}
protected final boolean tryAcquire(int acquires) {
return nonfairTryAcquire(acquires);
}
//公平锁 类似的，没有深入查看，感兴趣的自己去看源码
static final class FairSync extends Sync {
private static final long serialVersionUID = -3000897897090466540L;
final void lock() {
acquire(1);
}
}
}常用的ReentrantLock，有sync成员变量，从部分方法中可以看出，大部分功能的实现都是sync在实现.
sync有公平锁与非公平锁两种，默认是非公平锁。
lock（）（示例代码为非公平锁）
final void lock() {
if (compareAndSetState(0, 1)) //0未获取，1已经获取
setExclusiveOwnerThread(Thread.currentThread());//设置独占模式，则一个锁只能被一个线程持有，其他线程必须要等待。
else
acquire(1);//如果没有取得锁，尝试使用信号量的方式
}使用CAS的原理进行把state换成1（CAS的原理，要改一个值时，先拷贝旧值，然后做修改，然后再回到内存中判断，内存中的值如果等于之前取出来的旧值则认为安全的，替换内存中的旧值，如若不同，则不修改。具体的可以百度CAS）
//设置状态
protected final boolean compareAndSetState(int expect, int update) {
return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
}
//可以看到, compareAndSwapInt不是用Java实现的, 而是通过JNI调用操作系统的原生程序.注意它是原子方法(C++写的)
public final native boolean compareAndSwapInt(Object o, long offset,int expected, int x);所以lock方式使用CAS原理进行获得锁（0如果换成1则代表成功）,获得成功则设置当前锁的占有者为该线程（独占），不成功则尝试acquire方法，该方法最终也是使用的nonfairTryAcquire方法（下面有）获取锁，如果还是没有获取到，则加入到阻塞队列。
TryLock（）
public boolean tryLock() {
return sync.nonfairTryAcquire(1);
}
//再看sync的方法
final boolean nonfairTryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();//取得状态
if (c == 0) {//0表示未获取锁
if (compareAndSetState(0, acquires)) {//CAS设置状态
setExclusiveOwnerThread(current);//设置独占线程
return true;
}
}
else if (current == getExclusiveOwnerThread()) {//当前线程已有这个锁了
int nextc = c + acquires;//设置重入的次数，如果是一个线程在有锁的情况下多次调用tryLock就有可能进入这个方法
if (nextc < 0) // 重入数溢出了
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;//如果到这里就是没有取到锁了，
}trylock方法没有lock方法这么直接，他首先是判断c的状态
（c为AbstractQueuedSynchronizer类中的一个变量private volatile int state;）
state为0代表还没有线程获得锁，为1或者以上为有线程获得和代表重入的次数。
c==0代表没有线程使用，可获取，不等于0判断获得锁的是不是自己，如果是则修改重入次数（state的值），如果不是则返回false，代表没有获得锁，和Lock()相比是不会进入阻塞状态
tryLock(long timeout, TimeUnit unit)
public final boolean tryAcquireNanos(int arg, long nanosTimeout) throws InterruptedException {
if (Thread.interrupted())//检测到当前线程的中断标志为true
throw new InterruptedException();
return tryAcquire(arg) ||
doAcquireNanos(arg, nanosTimeout);
}
protected final boolean tryAcquire(int acquires) {
return nonfairTryAcquire(acquires);
}
//这是1.8的源码，思路是一样的
private boolean doAcquireNanos(int arg, long nanosTimeout)
throws InterruptedException {
if (nanosTimeout <= 0L)
return false;
final long deadline = System.nanoTime() + nanosTimeout;
final Node node = addWaiter(Node.EXCLUSIVE);
boolean failed = true;
try {
for (;;) {
final Node p = node.predecessor();
if (p == head && tryAcquire(arg)) {
setHead(node);
p.next = null; // help GC
failed = false;
return true;
}
nanosTimeout = deadline - System.nanoTime();
if (nanosTimeout <= 0L)
return false;
if (shouldParkAfterFailedAcquire(p, node) &&
nanosTimeout > spinForTimeoutThreshold)
LockSupport.parkNanos(this, nanosTimeout);
if (Thread.interrupted())
throw new InterruptedException();
}
} finally {
if (failed)
cancelAcquire(node);//取消阻塞和移出队列
//先是取消Node关联的线程，再是移出队列
}
}这个方法首先是尝试获取锁，如果获取不到则放入到阻塞队列中，死循环的获取，时间到了还是未获取的到则调用最后的cancelAcquire(node)函数退出获取该锁的行列。
解锁
释放锁的过程便是释放锁的过程（state置为0），和唤醒head节点的过程，需要注意的是head节点唤醒之后只是要重新去尝试获取锁，并不一定一定能获取到锁，也可能没有获取（有新线程加入，还没进入队列就可以竞争一次）到从而导致再次进入阻塞状态，既非公平锁
源码
public final boolean release(int arg) {
if (tryRelease(arg)) {
Node h = head;
if (h != null && h.waitStatus != 0)
unparkSuccessor(h);
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;
}解锁主要是tryRelease与tryAcquire，他们语义相同，把如何释放的逻辑延迟到子类中。
tryRelease语义很明确：如果线程多次锁定，则进行多次释放，直至status==0则真正释放锁，所谓释放锁即设置status为0，因为无竞争所以没有使用CAS。
release的语义在于：如果可以释放锁，则唤醒队列第一个线程（Head），具体唤醒代码如下：
private void unparkSuccessor(Node node) {
/*
* If status is negative (i.e., possibly needing signal) try
* to clear in anticipation of signalling. It is OK if this
* fails or if status is changed by waiting thread.
*/
int ws = node.waitStatus;
if (ws < 0)
compareAndSetWaitStatus(node, ws, 0);
/*
* Thread to unpark is held in successor, which is normally
* just the next node. But if cancelled or apparently null,
* traverse backwards from tail to find the actual
* non-cancelled successor.
*/
Node s = node.next;
if (s == null || s.waitStatus > 0) {
s = null;
for (Node t = tail; t != null && t != node; t = t.prev)
if (t.waitStatus <= 0)
s = t;
}
if (s != null)
LockSupport.unpark(s.thread);
} 这段代码的意思在于找出第一个可以unpark的线程，一般说来head.next == head，Head就是第一个线程，但Head.next可能被取消或被置为null，因此比较稳妥的办法是从后往前找第一个可用线程。貌似回溯会导致性能降低，其实这个发生的几率很小，所以不会有性能影响。之后便是通知系统内核继续该线程，在Linux下是通过pthread_mutex_unlock完成。之后，被解锁的线程进入上面所说的重新竞争状态。
157
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
