在上一次https://www.cnblogs.com/webor2006/p/11792954.html对于Lock的具体实现类ReentrantLock用了一个示例对它进行了一个简单的了解，而它其实里面有很多东东，不过得循序渐进一步步来，目前还不适合来从底层分析它，另外在上次对于Lock和syncronized对于同步的区别做了一个文字的总结，这里回顾一下，相当之重要：

而对于Lock这个接口其实提供的方法是比较少的，纵览一下：

其中大部分都是跟锁相关的方法，除了标红的这个是跟一个新的Condition条件相关，这也是接下来要仔细研究的东东，先来读一下该方法的javadoc，看这个东东的出现是为了解决啥问题的：

懵懵的。。没关系，才刚学嘛，这里先来对Condition的出现的原因做一个理论上的描述，得明白这个东东的一个角色这才在之后的学习中才会更加的踏实，而不至于只是API的一个学习，学完了也就学完了，不知其所以然，好，费话不多说，先来看一下理论描述：

“传统上，我们可以通过synchronized关键字 + wait + notify/notifyAll 来实现多个线程之间的协调与通信，整个过程都是由JVM来帮助我们实现的【native方法嘛】；开发者无需（也是无法）了解底层的实现细节。

从JDK 5开始，并发包提供了Lock，Condition(里面有await()与signal()/signalAll())来实现多个线程之间的协调与通信，整个过程都是由开发者来控制的，而且相比于传统方式，更加灵活，功能也更加强大。”

也就是Lock相当于原来的synchronized关键字，Condition.await()相当于原来Object.wait()，Condition.signal()或Condition.signalAll()相当于原来Object.notify()或Object.notifyAll()，而Lock和Condition是纯Java层的东东，可以人为来控制，嗯，大概了解到这么一个讯息，好，接下来咱们来读一读Condition这个接口的javadoc：

其文档说明不少，一点点去读，这样是最权威的：

读到这一句话，是不是有点逆天，也就是说有了这个Condition之后比如有10个线程，可以让前2个线程进入同一个对象的第一个等待集合当中，让中间6个线程也进入同一个对象的第二个等待集合当中，让最后2个线程进入同一个对象的第三个等待集合当中。。貌似颠覆了对于Object.wait()的行为，我们知道对于Object.wait()只会存于当前对象的同一个等待集合中，也就是Condition要比传统的方式要灵活很多，这也是一个非常大的改进，好，继续阅读：

好，先关于这块的javadoc先分析到这~下次继续学习。