日历
«  2018 7  »
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
最新评论
网站统计
  • 建站时间: 2010/03/29
  • 日记:4142 篇
  • 照片:45 张
  • 话题:14 篇
  • 评论:1108 篇
  • 注册用户:14
  • 今日访问:669
  • 本周访问:7074
  • 本月访问:59161
  • 全部访问:6088597
最后,我们构造汉堡店,让这个故事发生:
转载注明出处:http://x- spirit.javaeye.com/、http: //www.blogjava.net/zhangwei217245/
public class HambergShop {

    Waiter waiter 
= new Waiter();
    HambergFifo hambergPool 
= new HambergFifo();
    Customer c1 
= new Customer(waiter, hambergPool);
    Customer c2 
= new Customer(waiter, hambergPool);
    Customer c3 
= new Customer(waiter, hambergPool);
    Cooker cooker 
= new Cooker(waiter, hambergPool);

    
public static void main(String[] args) {
        HambergShop hambergShop 
= new HambergShop();
        Thread t1 
= new Thread(hambergShop.c1, "Customer 1");
        Thread t2 
= new Thread(hambergShop.c2, "Customer 2");
        Thread t3 
= new Thread(hambergShop.c3, "Customer 3");
        Thread t4 
= new Thread(hambergShop.cooker, "Cooker 1");
        Thread t5 
= new Thread(hambergShop.cooker, "Cooker 2");
        Thread t6 
= new Thread(hambergShop.cooker, "Cooker 3");
        t4.start();
        t5.start();
        t6.start();
        
try {
            Thread.sleep(
10000);
        } 
catch (Exception e) {
        }

        t1.start();
        t2.start();
        t3.start();
    }
}

运行这个程序吧,然后你会看到我们汉堡店的比赛进行的很好,只是不

 

知道那些顾客是不是会被撑到。。。
转载注明出处:http://x- spirit.javaeye.com/、http: //www.blogjava.net/zhangwei217245/
读到这里,有的读者可能会想到前面介绍的重入锁ReentrantLock。
有的读者会问:如果我用ReentrantLock来代替上面这些例程当中的 synchronized块,是不是也可以呢?感兴趣的读者不妨一试。
转载注明出处:http://x- spirit.javaeye.com/、http: //www.blogjava.net/zhangwei217245/
但是在这里,我想提前给出结论,就是,
如果用ReentrantLock的lock()和unlock()方法代替上面的synchronized块,那么上面这些程序还是要抛出java.lang.IllegalMonitorStateException异常的,不仅如此,你甚至还会看到线程死锁。原因就是当某个线程调用第三方对象的wait或者notify方法的时候,并没有进入第三方对象的监视器,于是抛出了异常信息。但此时,程序流程如果没有用finally来处理unlock方法,那么你的线程已经被lock方法上锁,并且无法解锁。程序在java.util.concurrent框架的语义级别死锁了,你用JConsole这种工具来检测JVM死锁,还检测不出来。
转载注明出处:http://x- spirit.javaeye.com/、http: //www.blogjava.net/zhangwei217245/
正确的做法就是,只使用ReentrantLock,而不使用wait或者notify方法。因为ReentrantLock已经对这种互斥和协作进行了概括。所以,根据你程序的需要,请单独采用重入锁或者synchronized一种同步机制,最好不要混用。
转载注明出处:http://x- spirit.javaeye.com/、http: //www.blogjava.net/zhangwei217245/

好了,我们现在明白:转载注明出处:http://x- spirit.javaeye.com/、http: //www.blogjava.net/zhangwei217245/
1. 线程的等待或者唤醒,并不是让线程调用自己的wait或者notify方法,而是通过调用线程共享对象的wait或者notify方法来实现。
2. 线程要调用某个对象的wait或者notify方法,必须先取得该对象的监视器。
3. 线程的协作必须以线程的互斥为前提,这种协作实际上是一种互斥下的协作。
转载注明出处:http://x- spirit.javaeye.com/、http: //www.blogjava.net/zhangwei217245/
下一讲当中,我们来看看如何实实在在的解决线程之间抢占共享资源的问题。敬请期待!
发表于 2010-03-29 09:24 X-Spirit 阅读(2508) 评论(6)  编辑  收藏 所属分类: Java SE
 
评论
围观
# re: Java 多线程同步问题的探究(四、协作,互斥下的协作——Java多线程协作(wait、notify、notifyAll))
@hxb
欢迎围观~~
# re: Java 多线程同步问题的探究(四、协作,互斥下的协作——Java多线程协作(wait、notify、notifyAll))
期待下一讲,如何实实在在的解决线程之间抢占共享资源的问题。
# re: Java 多线程同步问题的探究(四、协作,互斥下的协作——Java多线程协作(wait、notify、notifyAll))
synchronized, wait, notify, notifyAll 都是 JVM 的实现方式所以它与 Lock 是没有交叉点的,混用就可能出现问题的。

flag!="false" 字符串在这里这样比较容易使人产生误解的,虽然不会有任何其他的问题。
# re: Java 多线程同步问题的探究(四、协作,互斥下的协作——Java多线程协作(wait、notify、notifyAll))
楼主是首先发布在 javaeye 上的吧,然后再贴到这里来的,所以页面 ctrl+a 全选一下,可以看到很多:
转载注明出处:http://x- spirit.javaeye.com/、http: //www.blogjava.net/zhangwei217245/
在 blogjava 怎么不用一样的用户名呢?
# re: Java 多线程同步问题的探究(四、协作,互斥下的协作——Java多线程协作(wait、notify、notifyAll))
@隔叶黄莺

呵呵,其实这个系列的文章都是直接发表在blogjava上的,然后我才导入到javaeye上面。

至于那个反白的防盗版提示,是本人想起来以后先在javaeye上加上去的,然后又随机COPY到了这里。

本人网络昵称X-Spirit,电子邮箱用户名是zhangwei217245,所以blogjava上就用了电邮的,而javaeye用的是我的网络昵称。

本人之前糟蹋过的博客也用的是X-Spirit,是微软的MSN Space。有兴趣的读者可以去访问:

http://x-spirit.spaces.live.com/
# re: Java 多线程同步问题的探究(四、协作,互斥下的协作——Java多线程协作(wait、notify、notifyAll))
引用地址: http://blogzdycserver/html/trackback.do?id=7&type=1 (复制地址)
java工作学习总结 | 评论(8) | 阅读(14995) | Trackback(0) |