java多线程为啥一直用的一个线程_分析一个常见的java多线程通信问题(假死现象)...

一件复杂的事,一个人如果不能做,两个人又做的不好,一群人就可能很好的解决了。对于线程来说也是,通过多个线程就能完成一个更复杂的功能,这就需要多个线程协作,协作就需要交流,但是交流总是会出问题的。在这篇文章中我们分析一下java多线程通信过程中出现的一个假死现象。然后给出一个解决办法。

一、假死现象重现

为了更好地演示我们的实例,我们使用生产者消费者模式,一边生产一边消费。

22499db0b118b227be6f856ff82206e7.gif

下面我们先试着实现一下。这个例子的功能描述如下:

有一个产品a,生产方法生产a,消费方法消费a。然后10个生产线程生产,10个消费线程消费。永不停息。
36e737946679a8b2f978c81d590ce16a.png

上面的流程很清晰,一堆线程生产,生产了之后notify消费者去消费。上面的图指的是一堆线程生产,一堆线程消费,可能箭头画的指示的一个。

第一步:定义变量

92bdc40a6004ef1482d8fd66a851f787.png

第二步:生产和消费方法(定义在上面的类中)

首先是生产方法

8ff72275e894fe416fbbf355a5b5825b.png

然后是消费方法

38bea421cd08feaf5ceb6328ee8a2223.png

第三步:测试

995f5469a70004fd4f56e3a33f8f99bf.png

上面这个例子的功能,在一开始也已经说明了,这里produce和consume方法中,使用的是wait/notify机制来实现的,我们运行一下看会出现什么结果:

83b1f7813c671715893da5cb8207d2a9.png

我们看到,本来整个程序是永不停歇的,但是在生产了6个产品之后,突然间就停歇了,也就是我们今天的主题,多线程通信出现了假死状态。为什么会出现这种现象呢?我们来分析一下原因。

二、假死状态分析

其实出现这个现象的原因很简单,那就是和我们的wait/notify机制有关,我们几句话来总结一下:

“假死”的现象就是全部线程都进入了WAITING状态(死锁),则程序就不再执行任何业务功能了,整个项目呈停止状态。上面的案例中出现假死的现象是由于仅仅唤醒了同类(生产者唤醒了生产者,消费者唤醒了消费者)的现象大量出现导致的。

下面我们画一张图来分析一下:

e9e92a04d1c2c226d45b4f348705e742.png

打开UC浏览器 查看更多精彩图片

也就是说notify通知的是是同类。造成了这种堵塞现象。这是其根本原因,而且这张图是我们自己画的。下面我们就直接使用jstack工具来分析一下线程的状态。这两个工具是jdk自带的,我们可以直接使用。

第一步:使用jps查看当前电脑存在的所有java线程

5ad754e2173b6b532639b45fd07e6c5e.png

第二步:使用jstack工具查看线程状态信息

461b9d19ff9f56f7d3917dc9046d5330.png

现在我们知道了,目前所有的线程都是出于等待的状态,这也就是假死现象的验证。

假死现象的原因我们知道了,那么我们如何改正呢?

三、假死状态修复

假死现象的改正其实很简单,网上的方式也很多,比如说通过BlockingQueue或者是notifyAll方法。notifyAll方法超级简单,就是把上面produce和consume方法中的notify改成notifyAll方法即可。目的就是通知到所有的其他线程,生产线程该生产的生产,消费线程该消费的消费。

感谢支持。OK,今天的文章先到这。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值