多线程面试题_c#多线程面试题_c 多线程面试题(2)

Mojarra兄， 感谢你的思路。没想到还有这样简单的解法。

这道题是我和同学研究新浪面试题的时候发现的，我为此思考了好多个小时才想出解法一，郁闷的是我们老师几天之后讲解了这道题，他初始的解法和我的思考结果不谋而合。

至于解法二，则完全是老师的功劳，他用解法二向我们简单了介绍了一下JDK1.5中的并发访问控制。 JDK1.5的Lock和Condition结合可以做到精确唤醒waitset中的一个线程，这确实挺让人兴奋的。这几天我终于下定了决心好好学习一下java并发， 所以才把这道题发出来的。

希望以后能多与你交流。

run为什么要synchronized的呢？ 这三个线程产生竞争的。

关于问题1，考虑以下场景，即abc顺序步骤。

a、1处于synchronized，2处于waiting，3抢到锁后notifyAll结束5轮打印，剩下1和2竞争锁；

b、2抢到锁继续执行，执行后state变为3并notifyAll；

c、2在notifyAll后1还没来得及抢到锁，2就执行到了synchronized，并又再次获取了锁，由于state=3，2就waiting，这个时候处于synchronized的1抢到锁，由于state=3，1也waiting。

c也可以换为：1抢到了锁，由于state=3，1就waiting，这个时候处于synchronized的2抢到锁，由于state=3，2也waiting。多线程面试题

1. 解法一和解法二中的while (state != xx)是否可以换成if(state != xx), 为什么?

不能。若换成if，会有以下情况：

1、不是按照线程123依次打印的顺序；

2、有可能线程3程1和线程2之前5轮打印完毕，1,2来互相竞争，如果2抢到锁，state变为3，这个时候就悲剧了，线程1和线程2永远就waiting吧！

2. 解法一的中的pn.notifyAll()是否可以换成pn.notify(), 为什么?

不能。因为换成pn.notify()，理论上会出现某个线程永远抢不到锁导致饿死。

3. 暂时没考虑。

兄弟，这个写法扩展性不好，如果不是三个线程而是X个线程，每次打钱y个数，直到打印到Z，你的程序怎么办.

你说的对, 扩展性确实不好, 当时写这个程序的时候没有想这么多...

不过做一个简单的重构就可以, 多谢建议

兄弟，这个写法扩展性不好，如果不是三个线程而是X个线程，每次打钱y个数，直到打印到Z，你的程序怎么办.

原描述有误！

我在运行程序的时候发现3个线程有“竞争”情况，让线程打印一轮后休眠500ms，则可以避免“竞争”。大概的思想是既然不唤醒其他的线程，自己休眠，避免在变量state，c上的竞争。

这个题目很有意思，我还研究出一些其它的解法。等把java5的那个concurrent用法一起，总结出一篇小搏客

嗯, 到时一定拜读

原描述有误！

我在运行程序的时候发现3个线程有“竞争”情况，让线程打印一轮后休眠500ms，则可以避免“竞争”。大概的思想是既然不唤醒其他的线程，自己休眠，避免在变量state，c上的竞争。

这个题目很有意思，我还研究出一些其它的解法。等把java5的那个concurrent用法一起，总结出一篇小搏客

搂主的第二种思路具有很高的研究价值

对于第一种方法，我这里有个思路要简单些，这个题目其实是3个运行中的线程，在某一个时刻只有一是可以打印数字的，其他2个都必须是等待状态。给每一个线程一个id，state表示打印序列，75/5/3，可以得出来共有15个打印序列，如果state%3==id,表示当前线程可以打印，否则必须等到一个可打印的序列完成才可以进行下一轮循环。那么可以在方法级上用synchronized关键字声明。虽然有线程竞争的情形出现，但不会出现思锁。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-35308-2.html