//读写锁的使用
public class ThreadDemo {
    private static ReentrantReadWriteLock lock = new ReentrantReadWriteLock();//读写锁

    public static void read() {
        lock.readLock().lock();//读加锁
        try {
            System.out.println(Thread.currentThread().getName() + "读操作");
            Thread.sleep(1000);
            System.out.println(Thread.currentThread().getName() + "读取完毕");
        } catch (InterruptedException e) {
            e.printStackTrace();
        } finally {
            lock.readLock().unlock();//读解锁
        }
    }

    public static void write() {
        lock.writeLock().lock();//写加锁
        try {
            System.out.println(Thread.currentThread().getName() + "写操作");
            Thread.sleep(1000);
            System.out.println(Thread.currentThread().getName() + "写入完毕");
        } catch (InterruptedException e) {
            e.printStackTrace();
        } finally {
            lock.writeLock().unlock();//写解锁
        }
    }
    public static void main(String[] args) {
        new Thread(() -> write()).start();
        new Thread(() -> read()).start();
    }
}

轻量级锁和重量级锁

当涉及到大量的内核态用户态切换时，需要用到重量级锁；当涉及到很少的内核态操作而大多是用户态操作时，往往只用到轻量级锁。轻量级锁更加高效，往往在加锁解锁频繁情况下使用；重量级锁的操作成本较高，不轻易使用。轻量级锁往往频繁使用，因此通常也是乐观锁；而重量级锁也往往是悲观锁。

自旋锁和挂起等待锁

当多个对象竞争同一把锁时，就会出现加锁失败的情况，没有抢到锁的对象因为采取的措施不同而分为自旋锁和挂起等待锁。自旋锁指的是加锁失败时，不释放CPU资源，而是进入空循环，直到获取到锁才会退出循环；挂起等待锁则在加锁失败时释放CPU资源，等到锁释放后再去竞争锁。

自旋锁是一种极其耗费CPU资源的手段，但在某些情况下却不得不使用。

自旋锁伪代码：

while (竞争锁 == 失败) {}

公平锁和非公平锁

公平锁指的是遵循“先来后到”原则，竞争锁失败的对象有顺序地进入等待队列，释放锁后再按顺序获取锁；非公平锁则不遵循这个原则，竞争锁失败的对象不管先后都处于同一起跑线，锁释放后同时竞争锁。

比如说线程A、B、C三个线程，A先获取到锁，B首先进入等待，然后是C。锁释放后，如果是公平锁，则B获取到锁，而如果是非公平锁，则B和C同时竞争释放的锁。

可重入锁和不可重入锁

可重入锁指的是同一线程可以重复获取锁，而不会发生死锁的现象；不可重入锁指的是同一线程不能两次获得同一把锁，否则发生死锁现象。

当线程第一次加锁时，可以正常加锁；第二次加锁时，由于线程已被锁，只能进入阻塞等待，而解除阻塞等待只能先解锁，要解锁就要解除阻塞等待，这种情况就称为死锁。就好比家钥匙落在车里，车钥匙落在家里的情况。

可重入锁的实现逻辑是在加锁前先进行判断识别，如果识别到该锁和第一次加锁是同一把锁，则不进行加锁。

死锁

一个线程一把锁，多次加锁，可重入锁不死锁，不可重入锁死锁。但是，多个线程多把锁，可重入锁也会导致死锁现象：

假如t1线程拿到lock1，t2线程拿到lock2，这时t1线程拿不到lock2就只能阻塞等待，但同样t2线程也拿不到lock1，因此也只能阻塞等待，这就发生了死锁。

线程越多，锁越多，就越容易发生死锁现象。

发生死锁的必要条件

发生死锁有四个必要条件，缺一不可，分别是：互斥条件、请求和保持条件、不剥夺条件和循环等待条件。

互斥条件：一个线程拿到一把锁后，其他线程不能使用。
请求和保持条件：线程在阻塞等待时，不会放弃已获取的资源。
不剥夺条件：一个线程在获取锁以后，只能自己使用完释放，不可被提前抢占。
循环等待条件：每个线程都在等待获取下一个线程占有的资源。

两个线程发生死锁现象的特点是互不相让，你占有了我需要的资源，我占有了你需要的资源，都想让对方先释放资源。而多个线程发生死锁现象通常会形成循环，A需要的资源被B占有，B需要的资源被C占有，C需要的资源被D占有，D需要的资源又被A占有。

为了解决这种情况，通常的做法是，针对锁进行编号，每次加锁按照顺序加：

例如上述死锁情况，只需要约定第一层加lock1，第二层加lock2即可：

synchronized锁

synchronized是JVM基于操作系统提供的mutex（互斥锁）实现的。synchronized既是乐观锁也是悲观锁，既是重量级锁也是轻量级锁，为轻量级锁时大概率也是自旋锁。synchronized同时也是非公平锁和可重入锁。

synchronized的锁升级

synchronized之所以可以同时是这么多种锁，主要在于synchronized的工作流程是基于锁升级实现的：

偏向锁：加偏向锁也是无锁状态，只是一种偏向标记，记录了当前线程，如果后续不存在锁竞争，则处于无锁状态，当后续存在锁竞争时可以第一时间加锁。
轻量级锁：当存在锁竞争时，由偏向锁升级为轻量级锁，轻量级锁通常也是自旋锁，通过CAS指令实现，CAS检测更新内存，更新成功则加锁成功，停止自旋，反之继续空转，直到更新成功。（这里的自旋锁是自适应的，如果长时间没有获取到锁，也会停止自旋）

伪代码实现：

public class spinLock {
private Thead cur = null;//代表当前锁对象没有被持有

public void lock() {
//通过CAS判断当前锁对象是否被占有
//this.cur == null代表该锁没有被占用，可以被获取到
//当前锁对象尝试对Thread.currentThread()加锁
while (!CAS(this.cur, null, Thread.currentThread())) {
}
}
public void unlock() {
this.cur = null;//置为null代表该锁没有被占用，也就是锁被释放
}
}

重量级锁：当锁竞争比较频繁时，自旋锁会耗费大量的CPU资源，因此轻量级锁会升级为重量级锁，重量级锁需要用到内核的mutex锁，在内核态判断锁是否被占用，没有则加锁成功并切换回用户态；反之则加锁失败，挂起等待，直到锁被释放再重新竞争。

JVM实现的synchronized只能发生锁升级，目前还不能实现降级，一旦锁升级为重量级，就不可能再降级为轻量级。

CAS指令

CAS（Compare and Swap）指令指的是一种通过硬件实现并发安全的常用技术,意为“比较和交换”，CAS是原子的，其实现步骤不可拆分，实现原理如下：

//address代表需要更新的内存，oldValue为旧值，newValue为需要更改的新值
boolean CAS(address, oldValue, newValue) {
if (&address == prevValue) {//&address意为获取到内存address处存放的值
&address = newValue;
return true;
}
return false;
}

注意上述过程是一步完成的，不受多线程的抢占式执行影响。

基于CAS指令的原子性，通常用来作为实现锁的底层原理，以及可以用来进行无锁并发编程。

编译器+JVM的其他优化

通过编译器+JVM还可以实现synchronized的锁消除和锁粗化。

锁消除

在单线程环境下使用synchronized时，并不会真的加锁。Java源码中有很多方法的实现都会提供无锁版本和加锁版本，例如StringBulider类和StringBuffer类的区别就在于StringBulider是无锁版本，StringBuffer是加锁版本。当我们在单线程使用StringBuffer时，就会进行锁消除的优化。

锁粗化

当出现多次加锁时，编译器+JVM就会进行锁粗化的优化。锁粗化的是锁的粒度。锁的粒度是指锁定资源的细化程度。锁的粒度越大，则并发性越低，开销越大；粒度越小，并发性越高，开销越小。

虽然锁的粒度越细，开销越小。但是频繁加锁解锁的开销有时会更高。比如你妈妈让你去超市买东西A、B、C，你有两种方式：

方式一、去超市，买A，回家；去超市，买B，回家；去超市，买C，回家。

方式二、去超市，买A、B、C，回家。

显然呢，方式一是一个非常弱智的做法，明明可以一次性做完，却非得分成三次，吃力不讨好。

编程也同理，对于某些操作，如果需要频繁的加锁，编译器+JVM就会优化为只加锁一次，执行完所有操作后再解锁。

ReentrantLock锁

Java中虽然synchronized锁已经可以解决开发中的大部分需要加锁的场景，但是synchronized锁是一个非公平锁，与之相对的，Java源码也实现了ReentrantLock来补足这方面的缺点。

ReentrantLock为可重入锁，但是可以通过构造方法传入true变成公平锁。

ReentrantLock的用法

lock()：获取锁。
unlock()：释放锁。
tryLock()：尝试获取锁，如果获取成功返回true，否则返回false。
tryLock(long timeout, TimeUnit unit)：在指定时间内尝试获取锁，如果获取成功返回true，否则返回false。
getHoldCount()：查询当前线程保持此锁定的个数，即调用lock()方法的次数。
getQueueLength()：返回正等待获取此锁定的线程估计数。
isHeldByCurrentThread()：查询当前线程是否保持此锁定。
isLocked()：查询此锁定是否由任意线程保持。

代码案例：

ReentrantLock lock = new ReentrantLock(true);
//传入true代表公平锁，不写参数默认非公平锁
lock.lock();//加锁
try {
    //执行代码
} finally {
    lock.unlock();//解锁
}

synchronized与ReentrantLock的区别

底层实现不同：synchronized是关键字，基于JVM内部实现，ReentrantLock是Java的一个类，基于Java实现。
使用方式不同：对象在获取synchronized锁时发生阻塞只能死等，而获取ReentrantLock锁可以定义等待的最大时间，超时就放弃锁；使用synchronized出代码块系统自动释放锁，而使用ReentrantLock必须使用lock()加锁，并在最后unlock()解锁，否则发生死锁。
公平性不同：synchronized是非公平锁，ReentrantLock默认是非公平锁，构造时传入true变为公平锁。
唤醒机制不同：synchronized只能通过wait()和notify()/notifyAll()随机唤醒某个线程或者唤醒全部线程；ReentrantLock通过与Condition搭配唤醒线程更加灵活，Condition与Lock绑定，通过await()方法让线程等待，通过signal()方法唤醒一个等待的线程。

//ReentrantLock唤醒
public class ReentrantLock_test {
    private static final ReentrantLock lockA = new ReentrantLock();
    private static final ReentrantLock lockB = new ReentrantLock();

    private static final Condition conditionA = lockA.newCondition();
    private static final Condition conditionB = lockB.newCondition();

    public static void main(String[] args) throws InterruptedException {
        lockA.lock();
        lockB.lock();
        conditionA.await();//使lockA锁等待
        conditionB.await();//使lockB锁等待

        conditionA.signal();//唤醒lockA
        conditionB.signal();//唤醒lockB
    }
}

没有说哪一种锁就一定优于其他的锁。在不同的情况下需要选择不同的锁，synchronized效率更高，ReentrantLock使用更灵活，具体使用哪一种锁还要根据实际情况判断。

JavaEE——锁相关

锁策略

乐观锁和悲观锁

互斥锁和读写锁