本文主要是介绍爪哇学习笔记—并发编程4，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
4、显式锁和AQS
显式锁
Lock接口和核心方法
Lock接口和synchronized的比较
synchronized 代码简洁，Lock：获取锁可以被中断，超时获取锁，尝试获取锁，读多写少用读写锁
可重入锁ReentrantLock、所谓锁的公平和非公平
如果在时间上，先对锁进行获取的请求，一定先被满足，这个锁就是公平的，不满足，就是非公平的
非公平的效率一般来讲更高
ReadWriteLock接口和读写锁ReentrantReadWriteLock
ReentrantLock和Syn关键字，都是排他锁，
读写锁：同一时刻允许多个读线程同时访问，但是写线程访问的时候，所有的读和写都被阻塞，最适宜与读多写少的情况
Condition接口
用Lock和Condition实现等待通知
了解LockSupport工具
park开头的方法
负责阻塞线程
unpark(Thread thread)方法
负责唤醒线程
AbstractQueuedSynchronizer深入分析
什么是AQS？学习它的必要性
AQS使用方式和其中的设计模式
继承，模板方法设计模式
了解其中的方法
模板方法：
独占式获取
accquire
acquireInterruptibly
tryAcquireNanos
共享式获取
acquireShared
acquireSharedInterruptibly
tryAcquireSharedNanos
独占式释放锁
release
共享式释放锁
releaseShared
需要子类覆盖的流程方法
独占式获取 tryAcquire
独占式释放 tryRelease
共享式获取 tryAcquireShared
共享式释放 tryReleaseShared
这个同步器是否处于独占模式 isHeldExclusively
同步状态state：
getState:获取当前的同步状态
setState：设置当前同步状态
compareAndSetState 使用CAS设置状态，保证状态设置的原子性
AQS中的数据结构-节点和同步队列
竞争失败的线程会打包成Node放到同步队列，Node可能的状态里：
CANCELLED：线程等待超时或者被中断了，需要从队列中移走
SIGNAL：后续的节点等待状态，当前节点，通知后面的节点去运行
CONDITION :当前节点处于等待队列
PROPAGATE：共享，表示状态要往后面的节点传播
- 表示初始状态
节点在同步队列中的增加和移出
独占式同步状态获取与释放
其他同步状态获取与释放
Condition分析
mutex体现的是一种竞争，我离开了，通知你进来。
cond体现的是一种协作，我准备好了，通知你开始吧。
互斥锁一个明显的缺点是它只有两种状态：锁定和非锁定。而条件变量通过允许线程阻塞和等待另一个线程发送信号的方法弥补了互斥锁的不足，它常和互斥锁一起配合使用。使用时，条件变量被用来阻塞一个线程，当条件不满足时，线程往往解开相应的互斥锁并等待条件发生变化。一旦其他的某个线程改变了条件变量，他将通知相应的条件变量唤醒一个或多个正被此条件变量阻塞的线程。这些线程将重新锁定互斥锁并重新测试条件是否满足。一般说来，条件变量被用来进行线程间的同步。
两个线程操作同一临界区时，通过互斥锁保护，若A线程已经加锁，B线程再加锁时候会被阻塞，直到A释放锁，B再获得锁运行，进程B必须不停的主动获得锁、检查条件、释放锁、再获得锁、再检查、再释放，一直到满足运行的条件的时候才可以（而此过程中其他线程一直在等待该线程的结束），这种方式是比较消耗系统的资源的。而条件变量同样是阻塞，还需要通知才能唤醒，线程被唤醒后，它将重新检查判断条件是否满足，如果还不满足，该线程就休眠了，应该仍阻塞在这里，等待条件满足后被唤醒，节省了线程不断运行浪费的资源。这个过程一般用while语句实现。当线程B发现被锁定的变量不满足条件时会自动的释放锁并把自身置于等待状态，让出CPU的控制权给其它线程。其它线程 此时就有机会去进行操作，当修改完成后再通知那些由于条件不满足而陷入等待状态的线程。这是一种通知模型的同步方式，大大的节省了CPU的计算资源，减少了线程之间的竞争，而且提高了线程之间的系统工作的效率。这种同步方式就是条件变量。
以上说明可能有点抽象，考虑这样的简单场景：通过伪代码说明。
A线程从队列中取元素，B线程往队列中存放元素。不考虑免锁的实现。需要一个mutex用来保护队列的一致性，避免两个线程同时操作队列破坏数据结构。
当队列为空的时候，A需要不断的探测队列状态 :
while(1)
{
if(队列为空)
休眠10s
else{加锁取元素解锁}
}
这就有一个问题，可能在刚进入休眠时，B放入元素了，但仍然需要休眠完整个10s的时间。造成不必要的延迟。当然如果不sleep，也可以，但会造成不必要的CPU开销。使用基于条件变量的事件通知唤醒机制，就可以避免这些问题。
一旦B放入元素完成后就执行pthread_cond_signal()，当前阻塞的线程就会立即被唤醒开始干活儿。
while(1) {pthread_mutex_lock();pthread_cond_wait();取元素；pthread_mutex_unlock();
}
条件变量都用互斥锁进行保护，条件变量状态的改变都应该先锁住互斥锁，pthread_cond_wait()需要传入一个已经加锁的互斥锁，该函数把调用线程加入等待条件的调用列表中，然后释放互斥锁，在条件满足从而离开pthread_cond_wait()时，mutex将被重新加锁，这两个函数是原子操作。
可以消除条件发生和线程睡眠等待条件发生间的时间间隙。其他线程在获得互斥量之前不会察觉到这种改变，因为必须锁定互斥量才能计算条件。
总而言之，为了避免因条件判断语句与其后的正文或wait语句之间的间隙而产生的漏判或误判，所以用一个mutex来保证: 对于某个cond的包括(判断,修改)在内的任何有关操作某一时刻只有一个线程在访问。也就是说条件变量本身就是一个竞争资源，这个资源的作用是对其后程序正文的执行权，于是用一个锁来保护。
这样就关闭了条件检查和线程进入休眠状态等待条件改变这两个操作之间的时间通道，这样线程就不会有任何变化。
感觉可以总结为：条件变量用于某个线程需要在某种条件成立时才去保护它将要操作的临界区，这种情况从而避免了线程不断轮询检查该条件是否成立而降低效率的情况，这是实现了效率提高。。。在条件满足时，自动退出阻塞，再加锁进行操作。
以上是关于效率问题，此外互斥锁还有一个缺点就是会造成死锁。
例如线程A和线程B都需要独占使用2个资源，但是他们都分别先占据了一个资源，然后又相互等待另外一个资源的释放，这样就形成了一个死锁。
条件变量起到了阻塞和唤醒线程的作用，所以通常互斥锁要和条件变量配合。
为了解决以上问题，条件变量常和互斥锁一起使用，条件变量通过允许线程阻塞和等待另一个线程发送信号的方法弥补了互斥锁的不足。使用时，条件变量被用来阻塞一个线程，当条件不满足时，线程往往解开相应的互斥锁并等待条件发生变化。一旦其它的某个线程改变了条件变量，它将通知相应的条件变量唤醒一个或多个正被此条件变量阻塞的线程。这些线程将重新锁定互斥锁并重新测试条件是否满足。
这篇关于爪哇学习笔记—并发编程4的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
