Lock锁学习总结

synchronized是java底层支持的，而concurrent包则是jdk实现
在java.util.concurrent.locks包中有很多Lock的实现类，常用的有ReentrantLock、ReadWriteLock，其实现都依赖java.util.concurrent.AbstractQueuedSynchronizer类
ReentrantLock – NonFairSync/FairSync — Sync —AQS（AbstractQueuedSynchronizer） — AOS（AbstractOwnableSynchronizer） AOS主要是保存获取当前锁的线程对象
AQS中有NODE （head，tail） 存储结构就两个东西:“双向链表” + “int类型状态”，双向链表就是线程等待队列，int（state）是是否获取锁标识。node中有pre和next

获取锁：AQS中的int类型的state值，通过CAS去修改state的值。lock的基本操作还是通过乐观锁来实现的。

总结：
lock的存储结构：一个int类型状态值（用于锁的状态变更），一个双向链表（用于存储等待中的线程）
lock获取锁的过程：本质上是通过CAS来获取状态值修改，如果当场没获取到，会将该线程放在线程等待链表中。
lock释放锁的过程：修改状态值State，调整等待链表，更新下一个链表中的线程等待节点

等待获取锁是如何实现的:
1.tryAcquire：会尝试再次通过CAS获取一次锁。
2.addWaiter：将当前线程加入上面锁的双向链表（同步队列）中
3.acquireQueued：通过自旋，判断当前队列节点是否可以获取锁。

ReetrantLock中非公平锁：

ReetrantLock中公平锁：
在使用CAS设置尝试设置state值前，调用了hasQueuedPredecessors()判断同步队列是否存在结点，如果存在必须先执行完同步队列中结点的线程，当前线程进入等待状态

await()方法主要做了3件事，一是调用addConditionWaiter()方法将当前线程封装成node结点加入等待队列，
二是调用fullyRelease(node)方法释放同步状态并唤醒后继结点的线程。
三是调用isOnSyncQueue(node)方法判断结点是否在同步队列中，注意是个while循环，如果同步队列中没有该结点就直接挂起该线程，需要明白的是如果线程被唤醒后就调用acquireQueued(node, savedState)执行自旋操作争取锁，即当前线程结点从等待队列转移到同步队列并开始努力获取锁。

doSignal(first)方法中做了两件事，一是从条件等待队列移除被唤醒的节点，然后重新维护条件等待队列的firstWaiter和lastWaiter的指向。
二是将从等待队列移除的结点加入同步队列(在transferForSignal()方法中完成的)，如果进入到同步队列失败并且条件等待队列还有不为空的节点，则继续循环唤醒后续其他结点的线程。

共享锁：
在AQS中存在一个变量state，当我们创建Semaphore对象传入许可数值时，最终会赋值给state，state的数值代表同一个时刻可同时操作共享数据的线程数量，
每当一个线程请求(如调用Semaphored的acquire()方法)获取同步状态成功，state的值将会减少1，直到state为0时，表示已没有可用的许可数，
也就是对共享数据进行操作的线程数已达到最大值，其他后来线程将被阻塞，此时AQS内部会将线程封装成共享模式的Node结点，加入同步队列中等待并开启自旋操作。
只有当持有对共享数据访问权限的线程执行完成任务并释放同步状态后，同步队列中的对于的结点线程才有可能获取同步状态并被唤醒执行同步操作，
注意在同步队列中获取到同步状态的结点将被设置成head并清空相关线程数据(毕竟线程已在执行也就没有必要保存信息了)，AQS通过这种方式便实现共享锁

release:尝试更新state值，更新成功调用doReleaseShared()方法唤醒后继结点对应的线程。

共享锁中的公平锁：尝试获取同步状态前，先调用了hasQueuedPredecessors()方法判断同步队列中是否存在结点，如果存在则返回-1，即将线程加入同步队列等待
共享锁小结：
通过对Semaphore的内部实现原理分析后，AQS中通过state值来控制对共享资源访问的线程数，
每当线程请求同步状态成功，state值将会减1，如果超过限制数量的线程将被封装共享模式的Node结点加入同步队列等待，
直到其他执行线程释放同步状态，才有机会获得执行权，而每个线程执行完成任务释放同步状态后，state值将会增加1，这就是共享锁的基本实现模型。
至于公平锁与非公平锁的不同之处在于公平锁会在线程请求同步状态前，判断同步队列是否存在Node，如果存在就将请求线程封装成Node结点加入同步队列，
从而保证每个线程获取同步状态都是先到先得的顺序执行的。非公平锁则是通过竞争的方式获取，不管同步队列是否存在Node结点，只有通过竞争获取就可以获取线程执行权。

cas：Compare and Swap，即比较再交换。
CAS是一种无锁算法，CAS有3个操作数，内存值V，旧的预期值A，要修改的新值B。当且仅当预期值A和内存值V相同时，将内存值V修改为B，否则什么都不做。
CAS（比较并交换）是CPU指令级的操作，只有一步原子操作，所以非常快。不用麻烦操作系统，直接在CPU内部就搞定了

并发包中的原子操作类(Atomic系列)
aotmic – unsafe – cas
AtomicBoolean：原子更新布尔类型
AtomicInteger：原子更新整型
AtomicLong：原子更新长整型
3个类的实现原理和使用方式几乎是一样的，以AtomicInteger为例进行，AtomicInteger主要是针对int类型的数据执行原子操作
AtomicInteger原子类的内部几乎是基于前面分析过Unsafe类中的CAS相关操作的方法实现的，这也同时证明AtomicInteger是基于无锁实现的
AtomicInteger类中所有自增或自减的方法都间接调用Unsafe类中的getAndAddInt()方法实现了CAS操作，从而保证了线程安全

cas解决ABA问题：
AtomicStampedReference原子类是一个带有时间戳的对象引用，在每次修改后，AtomicStampedReference不仅会设置新值而且还会记录更改的时间。
当AtomicStampedReference设置对象值时，对象值以及时间戳都必须满足期望值才能写入成功