锁(Lock/synchronized)只能实现互斥不能实现通信,Condition的功能类似于在传统的线程技术中的,Object.wait()和Object.notify()的功能,在等待Condition时,允许发生"虚假唤醒",这通常作为对基础平台语义的让步,对于大多数应用程序,这带来的实际影响很小,因为Condition应该总是在一个循环中被等待,并测试正被等待的状态声明.某个实现可以随意移除可能的虚假唤醒,但是建议程序员总是假定这些虚假唤醒可能发生,因此总是在一个循环中等待.
一个锁内部可以有多个Condition,即有多路等待和通知,可以参看jdk1.5提供的Lock与Condition实现的可阻塞队列的应用案例,从中要体味算法,还要体味面向对象的封装.在传统的线程机制中,一个监视器对象上只能有一路等待和通知,要想实现多路等待和通知,必须嵌套使用多个同步监视器对象.(如果只用一个Condition,两个放的都在等,一旦一个放进去了,那么它会通知可能会导致另一个放的接着往下走).
我们也可以通过Lock和Condition来实现上面我们讲的例子:
子线程循环10次,接着主线程循环100,接着又回到子线程循环10次,接着再回到主线程又循环100,如此循环50次,请写出程序。
package javaplay.thread.test;
import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
public class ConditionCommunication {
public static void main(String[] args) {
final Business business = new Business();
new Thread(new Runnable() {
@Override
public void run() {
for (int i = 0; i < 5; i++) {
business.sub(i);
}
}
}).start();
for (int i = 0; i < 5; i++) {
business.main(i);// 此处不能是sub 否则死锁
}
}
static class Business {
// 使用lock与原来的synchronized几乎一模一样的
// 思想和套路是一样的 不在乎用得是什么新技术
// 所以程序员如果崇拜哪种语言或者技术都是很可笑的一件事
Lock lock = new ReentrantLock();
Condition condition = lock.newCondition();
private boolean bShouldSub = true;// volatile???
public void sub(int i) {
lock.lock();
try {
while (!bShouldSub) {
try {
// this.wait();
condition.await();// 不是wait wait是任何对象都有的,继承自Object