J.U.C并发包（1）
AbstractQueuedSynchronizer
AbstractQueuedSynchronizer是JUC并发包中锁的底层支持，AbstractQueuedSynchronizer是抽象同步队列，简称AQS，是实现同步器的基础组件，并发包中锁的实现底层就是使用AQS实现，
- 从类图的关系可以看到AQS是一个FIFO的双向队列，内部通过节点head 和 tail 记录队首和队尾元素，队列元素类型为Node。其中Node中Thread变量用来存放进入AQS队列里面的线程
- Node 节点内部SHARED用来标记该线程是获取共享资源时候被阻塞挂起来后放入AQS队列，
- EXCLUSIVE标记线程是获取独占资源时候被挂起后放入AQS队列;
- waitStatus记录当前线程等待状态，分别为CANCELLED(线程被取消了)，SIGNAL(线程需要被唤醒)，CONDITION(线程在条件队列里面等待)，PROPAGATE(释放共享资源时候需要通知其他节点）；
- AQS中维持了一个单一的状态信息state，可以通过getState,setState,compareAndSetState 函数修改其值；对于ReentrantLock 的实现来说，state 可以用来表示当前线程获取锁的可重入次数；
- pre记录当前节点的前驱节点，next记录当前节点后继节点
- 调用acquire(int arg)方法获取独占资源，调用release(int arg)方法释放资源；
具体思路：
- 当多个线程同时调用 lock.lock() 获取锁的时候，同时只有一个线程获取到了该锁，其他线程会被转换为 Node 节点插入到 lock 锁对应的 AQS 阻塞队列里面，并做自旋 CAS 尝试获取锁，前提是head的直接后继；
- 如果获取到锁的线程又调用了对应的条件变量的 await() 方法，则该线程会释放获取到的锁，并被转换为 Node 节点插入到条件变量对应的条件队列里面；
- 这时候因为调用 lock.lock() 方法被阻塞到 AQS 队列里面的一个线程会获取到被释放的锁，如果该线程也调用了条件变量的 await（）方法则该线程也会被放入条件变量的条件队列；
- 当另外一个线程调用了条件变量的 signal() 或者 signalAll() 方法时候，会把条件队列里面的一个或者全部 Node 节点移动到 AQS 的阻塞队列里面，等待时机获取锁。
CountDownLatch
他是一个同步辅助类，可以实现类似阻塞当前线程的功能，使用了给定的计数器进行初始化，该计数器操作是原子操作，同一时刻只能有一个线程操作该计数器。
如上图中，TA线程由于await()方法被阻塞，除非前面的线程调用countDown()方法，当计数器为0，TA就可以继续往下执行。计数器不可重置。
private final static int threadCount = 200;
public static void main(String[] args) throws Exception {
ExecutorService exec = Executors.newCachedThreadPool();
final CountDownLatch countDownLatch = new CountDownLatch(threadCount);
for (int i = 0; i < threadCount; i++) {
final int threadNum = i;
exec.execute(() -> {
try {
test(threadNum);
} catch (Exception e) {
log.error("exception", e);
} finally {
countDownLatch.countDown();
}
});
}
countDownLatch.await();
log.info("finish");
exec.shutdown();
}
private static void test(int threadNum) throws Exception {
Thread.sleep(100);
log.info("{}", threadNum);
Thread.sleep(100);
}
Semaphore
他可以控制某个资源可以被多少个线程同时访问，使用Semaphore管理必须要先获取一个许可，执行完毕后释放一个许可，后面的线程才能继续访问，代码演示：
@Slf4j
public class SemaphoreExample1 {
private final static int threadCount = 20;
public static void main(String[] args) throws Exception {
ExecutorService exec = Executors.newCachedThreadPool();
final Semaphore semaphore = new Semaphore(3);
for (int i = 0; i < threadCount; i++) {
final int threadNum = i;
exec.execute(() -> {
try {
semaphore.acquire(); // 获取一个许可
test(threadNum);
semaphore.release(); // 释放一个许可
} catch (Exception e) {
log.error("exception", e);
}
});
}
exec.shutdown();
}
private static void test(int threadNum) throws Exception {
log.info("{}", threadNum);
Thread.sleep(1000);
}
}
CyclicBarrier
他是一个同步辅助类，允许一组线程相互等待，直到到达某个公共的屏障点，commonBarrierPoint，CyclicBarrier也具有一个计数器，当计数器达到设置的值，被await()方法阻塞的值会被唤醒，继续执行后续的操作，计数器可以被重置，适合并发情况下需要合并计算的场景。
演示代码如下：
@Slf4j
public class CyclicBarrierExample1 {
private static Logger log = LoggerFactory.getLogger(CyclicBarrierExample1.class);
private static CyclicBarrier barrier = new CyclicBarrier(5);
public static void main(String[] args) throws Exception {
ExecutorService executor = Executors.newCachedThreadPool();
for (int i = 0; i < 10; i++) {
final int threadNum = i;
Thread.sleep(1000);
executor.execute(() -> {
try {
race(threadNum);
} catch (Exception e) {
log.error("exception", e);
}
});
}
executor.shutdown();
}
private static void race(int threadNum) throws Exception {
Thread.sleep(1000);
log.info("{} is ready", threadNum);
barrier.await();
log.info("{} continue", threadNum);
}
}
console：
ReentrantLock
ReentrantLock（可重入锁）和Synchronize锁的区别
- 锁的实现：ReentrantLock通过jdk实现，synchronize是通过jvm实现，但注意ReentrantLock需要释放锁，而synchronize不需要释放锁，由jvm管理，也就是说synchronize不会产生死锁，而ReentrantLock可能产生死锁。
- 性能的区别：synchronize未做优化前，ReentrantLock优于synchronize，但synchronize在经过偏向锁，轻量级锁优化后性能就差不多了
- 功能区别：代码简洁synchronize优于ReentrantLock，锁的细粒度和灵活度ReentrantLock更好。
ReentrantLock独有功能
- 可指定公平锁还是非公平锁：公平锁（先等待的就先获取锁）；
- 提供了condition类，可以分组唤醒需要唤醒的线程；
- 提供锁的打断机制，lock.lockInterruptibly()。
ReentrantLock是一种自选锁，内部循环使用CAS操作实现加锁
ReentrantReadWriteLock
ReentrantReadWriteLock是读写锁，维护了一对锁，一个读锁，一个写锁，通过实现ReadWriteLock接口实现了readLock()方法和writeLock()方法。适用于多线程情况下的读写操作，但是要注意如果读操作过于频繁可能会导致写锁饥饿。
StampLock
StampLock有三种控制锁的方式：写，读和乐观读，StampLock会生成票据。
- 乐观读：乐观的认为写入和读取同时发生的概率很少，因此不悲观的使用读取锁定，程序可以查看读取数据时候遭到写入执行的变更之后，大幅提升程序的性能。
public class LockExample4 {
class Point {
private double x, y;
private final StampedLock sl = new StampedLock();
void move(double deltaX, double deltaY) { // an exclusively locked method
long stamp = sl.writeLock();
try {
x += deltaX;
y += deltaY;
} finally {
sl.unlockWrite(stamp);
}
}
//下面看看乐观读锁案例
double distanceFromOrigin() { // A read-only method
long stamp = sl.tryOptimisticRead(); //获得一个乐观读锁
double currentX = x, currentY = y; //将两个字段读入本地局部变量
if (!sl.validate(stamp)) { //检查发出乐观读锁后同时是否有其他写锁发生？
stamp = sl.readLock(); //如果没有，我们再次获得一个读悲观锁
try {
currentX = x; // 将两个字段读入本地局部变量
currentY = y; // 将两个字段读入本地局部变量
} finally {
sl.unlockRead(stamp);
}
}
return Math.sqrt(currentX * currentX + currentY * currentY);
}
//下面是悲观读锁案例
void moveIfAtOrigin(double newX, double newY) { // upgrade
// Could instead start with optimistic, not read mode
long stamp = sl.readLock();
try {
while (x == 0.0 && y == 0.0) { //循环，检查当前状态是否符合
long ws = sl.tryConvertToWriteLock(stamp); //将读锁转为写锁
if (ws != 0L) { //这是确认转为写锁是否成功
stamp = ws; //如果成功 替换票据
x = newX; //进行状态改变
y = newY; //进行状态改变
break;
} else { //如果不能成功转换为写锁
sl.unlockRead(stamp); //我们显式释放读锁
stamp = sl.writeLock(); //显式直接进行写锁 然后再通过循环再试
}
}
} finally {
sl.unlock(stamp); //释放读锁或写锁
}
}
}
}
