ConditionObject是同步器AbstractQueuedSynchronizer的内部类，它实现了Condition接口，因为Condition的操作需要获取相关联的锁，所以作为同步器的内部类也较为合理。每个Condition对象都包含着一个队列（以下称为等待队列），该队列是Condition对象实现等待/通知功能的关键。
等待
调用condition的await方法，将会使当前线程进入等待队列并释放锁(先加入等待队列再释放锁)，同时线程状态转为等待状态。
从同步队列和阻塞队列的角度看，调用await方法时，相当于同步队列的首节点移到condition的等待队列中
通知
调用condition的signal方法时，将会把等待队列的首节点移到等待队列的尾部，然后唤醒该节点。
被唤醒，并不代表就会从await方法返回，也不代表该节点的线程能获取到锁，它一样需要加入到锁的竞争acquireQueued方法中去，只有成功竞争到锁，才能从await方法返回。
CountDownLatch、CyclicBarrier的区别
CountDownLatch ： 一个线程 ( 或者多个) 在等待， 等另外N个线程完成某个事情之后，这 一个线程 才能执行。(基于AQS共享锁实现)
CyclicBarrier：N个线程相互等待，任何一个线程完成之前，所有的线程都必须等待。(基于Condition实现)
因此，CountDownLatch 的重点是那个 一个线程 ，是它在等待， 而另外那N的线程在把“某个事情”做完之后，这 一个线程 可以继续执行，或者终止。
而 CyclicBarrier 来说，重点是那 N个线程 ，他们之间任何一个没有完成，所有的线程都必须等待。
差异点：
1 CountDownLatch计数器只能使用一次。CyclicBarrier则可以调用其reset()方法进行重置多次使用(在计算错误时可重置后再计算)。
2 CountDownLatch使用countDown()+await()进行处理，需要通过countDown的次数到设置的次数，其await()才不会阻塞，往往是一个主线程中使用CountDownLatch然后控制所有子线程。CyclicBarrier的同步屏障是针对对应的子线程的，但同时设置了new CyclicBarrier(N)也需要对应N次的线程(部分主子线程)来执行await()，才能继续执行await()后面的代码。
Semaphore(计数信号量)限流
限制可以访问某些资源的线程数量，
它默认构造 AQS 的 state 为 permits。当执行任务的线程数量超出 permits,那么多余的线程将会被放入阻塞队列 Park,并自旋判断 state 是否大于 0。只有当 state 大于 0 的时候，阻塞的线程才能继续执行,此时先前执行任务的线程继续执行 release 方法，release 方法使得 state 的变量会加 1，那么自旋的线程便会判断成功。 如此，每次只有最多不超过 permits 数量的线程能自旋成功，便限制了执行任务线程的数量。
Semaphore 有两种模式，公平模式和非公平模式。
公平模式： 调用 acquire 的顺序就是获取许可证的顺序，遵循 FIFO；
非公平模式： 抢占式的。
ConcurrentHashMap 1.7与1.8的区别
一、其实可以看出JDK1.8版本的ConcurrentHashMap的数据结构已经接近HashMap，相对而言，ConcurrentHashMap只是增加了同步的操作来控制并发，从JDK1.7版本的ReentrantLock+Segment+HashEntry，到JDK1.8版本中synchronized+CAS+HashEntry+红黑树,相对而言，总结如下思考
JDK1.8的实现降低锁的粒度，JDK1.7版本锁的粒度是基于Segment的，包含多个HashEntry，而JDK1.8锁的粒度就是HashEntry（首节点）
JDK1.8版本的数据结构变得更加简单，使得操作也更加清晰流畅，因为已经使用synchronized来进行同步，所以不需要分段锁的概念，也就不需要Segment这种数据结构了，由于粒度的降低，实现的复杂度也增加了
JDK1.8使用红黑树来优化链表，基于长度很长的链表的遍历是一个很漫长的过程，而红黑树的遍历效率是很快的，代替一定阈值的链表，这样形成一个最佳拍档
JDK1.8为什么使用内置锁synchronized来代替重入锁ReentrantLock，我觉得有以下几点
因为粒度降低了，在相对而言的低粒度加锁方式，synchronized并不比ReentrantLock差，在粗粒度加锁中ReentrantLock可能通
-Condition来控制各个低粒度的边界，更加的灵活，而在低粒度中，Condition的优势就没有了
-JVM的开发团队从来都没有放弃synchronized，而且基于JVM的synchronized优化空间更大，使用内嵌的关键字比使用API更加自然
在大量的数据操作下，对于JVM的内存压力，基于API的ReentrantLock会开销更多的内存，虽然不是瓶颈，但是也是一个选择依据
二、put（）
1.7：先定位Segment，再定位桶，put全程加锁，没有获取锁的线程提前找桶的位置，并最多自旋64次获取锁，超过则挂起。
1.8：由于移除了Segment，类似HashMap，可以直接定位到桶，拿到first节点后进行判断，1、为空则CAS插入；2、为-1则说明在扩容，则跟着一起扩容；3、else则加锁put（类似1.7）
三、get（）
基本类似，由于value声明为volatile，保证了修改的可见性，因此不需要加锁。
四、resize（）
1.7：跟HashMap步骤一样，只不过是搬到单线程中执行，避免了HashMap在1.7中扩容时死循环的问题，保证线程安全。
1.8：支持并发扩容，HashMap扩容在1.8中由头插改为尾插（为了避免死循环问题），ConcurrentHashmap也是，迁移也是从尾部开始，扩容前在桶的头部放置一个hash值为-1的节点，这样别的线程访问时就能判断是否该桶已经被其他线程处理过了。
五、size（）
1.7：很经典的思路：计算两次，如果不变则返回计算结果，若不一致，则锁住所有的Segment求和。
1.8：用baseCount来存储当前的节点个数，这就设计到baseCount并发环境下修改的问题（说实话我没看懂-_-!）。
常见的阻塞队列？及其使用场景
JDK7提供了7个阻塞队列。分别是
ArrayBlockingQueue ：一个由数组结构组成的有界阻塞队列。
LinkedBlockingQueue ：一个由链表结构组成的有界阻塞队列。
PriorityBlockingQueue ：一个支持优先级排序的无界阻塞队列。
DelayQueue：一个使用优先级队列实现的无界阻塞队列。
SynchronousQueue：一个不存储元素的阻塞队列。
LinkedTransferQueue：一个由链表结构组成的无界阻塞队列。
LinkedBlockingDeque：一个由链表结构组成的双向阻塞队列。
