笔记——有关于Java thread类 的一个作业完成 与 对于线程和同步锁(synchronization)的思考

本文记录了一个使用Java实现的多线程站台售票作业,通过同步锁(synchronization)确保售票操作的互斥。在实践中遇到的问题是线程调度不精确,即便使用`thread.sleep`也无法严格控制执行顺序。运行结果显示多线程环境下结果的不确定性,引发了对虚拟机线程调度原理的探讨。
摘要由CSDN通过智能技术生成

今天写了一个多线程的应用作业。看完书本上的内容之后觉得应该很简单。题目是这样的
  “
  (1)创建一个站台类Station,继承Thread,重写run方法,在run方法里面执行售票操作!售票要使用同步锁:即有一个站台卖这张票时,其他站台要等这张票卖完!
(2)创建主方法调用类”
  然后完成的样式是这样子的:
  在这里插入图片描述
  第一眼我还以为要构建窗口1,窗口2,窗口3,跟前天写的监视器的知识结合起来,结果定睛以看发现是console上面显示的内容。于是感觉事情一下子简单了太多,看过书本之后想通过建立三个thread派生类窗口123来完成。
  但是在使用synchronization的时候碰到了问题,我构建的程序只能一路到底,不能够分担到别的线程。在尝试了一些方法之后我发掘对于票数的限制是关键,我个人的理解下,既然是用implement runnable连接起来的三个线程,那么他们就等于走了一条道,就好像三个人一起玩台球一样,按照规则来说,假设第一个人没有错误那么他就可以一直打到底,但是桌子上的台球只有那么多,打完自然也就轮不到另外两个人了,于是就可以引入thread.sleep,让其每次击打台球后都进入睡眠,给另外两个机会,但是我好奇的是这个sleep的时间足够长的话还是不能精确的控制先后顺序,按照我的理解里面的站台1sleep了很久那么在这段时间里他就不应该出现才对。这可能就涉及到了虚拟机到底如何操作了,暂时也没

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值