From：Java并发编程的艺术
- 目录
BiBi - 并发编程 -0- 开篇
BiBi - 并发编程 -1- 挑战
BiBi - 并发编程 -2- volatile
BiBi - 并发编程 -3- 锁
BiBi - 并发编程 -4- 原子操作
BiBi - 并发编程 -5- Java内存模型
BiBi - 并发编程 -6- final关键字
BiBi - 并发编程 -7- DCL
BiBi - 并发编程 -8- 线程
BiBi - 并发编程 -9- ReentrantLock
BiBi - 并发编程 -10- 队列同步器
BiBi - 并发编程 -11- 并发容器
BiBi - 并发编程 -12- Fork/Join框架
BiBi - 并发编程 -13- 并发工具类
BiBi - 并发编程 -14- 线程池
BiBi - 并发编程 -15- Executor框架
1. ReentrantLock
ReentrantLock的简单实例
Lock lock = new ReentrantLock();
lock.lock();
try {
...
} finally {
lock.unlock();
}
提示：不要将
lock.lock()获取锁的过程写在try块中，因为如果在获取锁【自定义的锁】时发生了异常，异常抛出的同时，会导致锁被释放。
Lock与synchronized相比独有的特性
1）尝试非阻塞的获取锁 - tryLock()
2）能被中断地获取锁 - lockInterruptibly()。该方法会响应中断，即在锁的获取中
可以中断当前线程
3）超时获取锁 - tyrLock(long time)
重入锁简介
任意线程在获取到锁之后能够再次获取该锁而不会被锁所阻塞。ReentrantLock默认是非公平的，但可以通过构造函数设置为公平的；Synchronized是非公平的，不可以改变。
重入锁在获取锁时会对同步状态值进行增加；释放锁时会减少同步状态值，只有当同步状态值为0时，才表示该锁释放成功。
公平性/非公平性
定义：公平性，先对锁进行获取的请求一定先被满足，反之为不公平的。
对于非公平锁，只要CAS设置同步状态成功，则表示当前线程获取了锁。而对于公平锁还要判断在同步队列中当前节点是否有前驱节点，如果有，则表示有线程比当前线程更早地请求获取该锁。
优缺点：非公平锁可以让一个线程连续获取锁，因为刚释放锁的线程再次获取同步状态的几率会非常大，这样比公平锁能够减少不同线程【线程上下文】的切换，从而开销少，能保证更大的吞吐量。所以，非公平性锁是默认的选择。但非公平锁可能会使线程出现【饥饿】状态。公平锁能保证锁按照FIFO原则，但会进行大量的线程切换。
2. 读写锁
ReentrantReadWriteLock 读写锁能在同一时刻允许多个读线程访问【读：共享锁】，但写线程访问时，其它读写线程都会被阻塞【写：独占锁】，如果存在读锁，写锁只有再等所有读锁都释放之后才能获取从而保证写操作对读操作的可见性。
读写锁例子
package ljg.concurrent;
import java.util.HashMap;
import java.util.Map;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantReadWriteLock;
public class Cache {
static Map<String, Object> map = new HashMap<>();
static ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
static Lock r = rwl.readLock();
static Lock w = rwl.writeLock();
public static Object get(String key) {
r.lock();
try {
return map.get(key);
} finally {
r.unlock();
}
}
public static void put(String key, Object value) {
w.lock();
try {
map.put(key, value);
} finally {
w.unlock();
}
}
}
将非线程安全的HashMap与ReentrantReadWriteLock结合应用来保证线程安全。保证了能够并发读数据而不阻塞；写数据对读可见。【知道使用场景】
读写锁的实现
读写锁依赖自定义同步器来实现同步功能。其同步状态值设置的很巧妙，在一个整型变量上维护两个【读写】状态，使用【按位切割】方法，高16位表示读，低16位表示写。
读写锁的降级
先获取写锁，再获取读锁，随后释放之前拥有的写锁过程。【顺序不能错】
3. Condition接口
Condition比Object中的wait、notify、notifyAll的优势
1）等待队列有多个，而Object的监视器方法只有一个
2）在线程等待状态支持中断响应
Condition实例
获取一个Condition必须通过Lock的newCondition()方法。
要求：当队列为空时，队列的获取数据操作阻塞；当队列已满时，队列的插入操作阻塞。
package ljg.concurrent;
import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
public class BoundedQueue<T> {
private Object[] items;
private int addIndex;
private int removeIndex;
private int count;
private Lock lock = new ReentrantLock();
private Condition notEmpty = lock.newCondition();
private Condition notFull = lock.newCondition();
public BoundedQueue(int size) {
items = new Object[size];
}
private void add(T t) throws InterruptedException {
lock.lock();
try {
while (count == items.length) {
notFull.await(); // 会释放锁
}
items[addIndex] = t;
if (++addIndex == items.length) {
addIndex = 0;
}
++count;
notEmpty.signal();
} finally {
lock.unlock();
}
}
//循环数组，覆盖数据并不删除
public T remove() throws InterruptedException {
lock.lock();
try {
while (count == 0) {
notEmpty.await();
}
Object x = items[removeIndex];
if (++removeIndex == items.length) {
removeIndex = 0;
}
--count;
notFull.signal();
return (T) x;
} finally {
lock.unlock();
}
}
}
该队列删除数据从index=0开始；添加满数据后，再添加数据也是从index=0开始。通过count来控制是否进行添加/删除操作。 循环数组，覆盖数据并不删除。
4. ConditionObject
ConditionObject是同步器AQS的内部类，它实现了Condition接口。因此每个Condition实例都能访问同步器提供的方法，每个Condition都拥有所属同步器的引用。
每个Condition对象都包含着一个【等待队列】。同步队列和等待队列中的节点都是同步器的静态内部类AbstractQueuedSynchronizer.Node。等待队列中的节点添加和删除不需要CAS保证，因为该线程已经获取了锁。
当调用await()方法时，会将同步队列中的首节，构造成一个新节点【不是直接加入】，并移动到等待队列中，然后释放锁，唤醒同步队列中的后继节点，当前线程进入等待状态。
当调用signal()方法时，会将等待队列中的首节点，移动到同步队列并使用LickSupport唤醒节点中的线程。signalAll()将等待队列中的所有节点全部移动到同步队列中，并唤醒每个节点的线程。
