这是一个创建于 1545 天前的主题，其中的信息可能已经有所发展或是发生改变。
public static class Stack {
private final LinkedList<Integer> queue = new LinkedList<>();
public synchronized Integer pop() throws InterruptedException {
if (queue.size() <= 0) {
wait();
}
return queue.removeLast();
}
public synchronized void push(Integer integer) {
queue.addFirst(integer);
notify();
}
}
面试题..题目说这个栈在多线程中可能出现问题,请指出出现问题的情景...我想了半天也没想出来什么情景下回出问题,还请指教..
谢谢
18 条回复 • 2020-08-30 11:30:39 +08:00
 |
1
Jooooooooo 2020-08-29 17:38:30 +08:00
pop 和 push 是可以并发的啊
线程 1 判断 if(queue.size() <= 0), 成功 线程 2 执行 push 并且 notify 线程 1 执行 wait |
 |
2
Newyorkcity OP @Jooooooooo 额?你是说限制得过分了?
|
|
3
Jooooooooo 2020-08-29 18:34:26 +08:00
@Newyorkcity 线程 1 执行 wait 之后程序就死在那了
|
|
4
Newyorkcity OP @Jooooooooo 线程 1 判断 if(queue.size() <= 0) 成功，此时还没有执行 wait，线程 1 持有锁，线程 2 无法执行 push 方法的吧？
|
|
5
Jooooooooo 2020-08-29 19:05:07 +08:00
@Newyorkcity 记错了
这个我想了一下, 应该是 synchronized 只能作用在 stack 上而无法作用在 queue 上, 导致 queue 内部的行为无法遵守 happen before 原则. |
 |
6
iseki 2020-08-29 19:19:46 +08:00 via Android
不是吧…synchronized 是锁 this 的我如果没记错，那么从并发安全上看应该没问题？
|
|
7
iseki 2020-08-29 19:20:04 +08:00 via Android
|
 |
8
jimages 2020-08-29 19:28:20 +08:00 via iPhone
死锁，当 size 为 0 的时候，在里面 wait，但是此时已经拿了锁了。push 没有拿到锁，无法 push 。所以一个已经持有锁的线程在 wait，没有持有锁的线程想 push 得等锁，形成死锁。
|
|
9
Newyorkcity OP @jimages 额。。。wait 函数一旦执行，线程转入等待状态并会释放由于 synchronized 拿到的对象锁，所以生产者线程有机会生产出产品的吧。。
|
|
10
jimages 2020-08-29 19:43:40 +08:00 via iPhone
@Newyorkcity 哦哦哦，我看错了😂。那应该是两个 pop 线程一个 push 线程的问题，就比如一个在 wait 被卡住，一个在访问 pop 的时候被卡住。如果比如现在 push 了一个，然后 notify 。现在有两个线程需要锁，一个是 wait 那需要一个锁，一个是新进入的 pop 需要锁，假如是新来的那个 pop 拿到了锁，pop 出最后一个元素。然后是 wait 那个线程拿到元素。由于是 if 不是一个 while 判断。所以此时 pop 出一个，但此时 queue 已经没有元素了。
|
 |
11
LinJunzhu 2020-08-29 19:55:52 +08:00  1
@jimages synchronized 的 monitor 中，线程 A 调用 notify() 后，默认策略是从 WaitSet 队列内拿出被堵塞的线程，插入 EntrySet 队列头，随后线程 A 执行完毕，便会去 EntrySet 拿出堵塞的线程来唤醒执行，所以不存在你说的被 [新来的 pop 线程] 拿到了锁
|
 |
12
MoHen9 2020-08-29 21:15:39 +08:00 via Android
可能是执行效率低吧，你这是实现了个阻塞队列，面试官可能认为直接使用阻塞队列会更好。
|
 |
13
leafre 2020-08-29 21:41:25 +08:00
我觉得没问题，有大佬找出问题 @我下
|
|
14
LinJunzhu 2020-08-30 00:57:13 +08:00 1
重新看了下 Monitor 的源码，更正一下，是会存在 @jimages 所说的， 当持有锁的线程 A(push 方法)调用 notify()后 并退出同步代码块时，会释放持有的锁，此时唤醒的堵塞线程 B （在 wait() 处的线程）重新争抢锁，是有可能会被新来的线程 C 调用 pop() 抢到锁的，此时 C 执行完毕后，锁释放，若恰好轮到线程 B 获得了锁，此时队列已经空了，不满足条件，执行则会报错，因此应该修改为：
while (queue.size() <= 0) { wait(); } 在该处进行死循环判断。 |
 |
15
776491381 2020-08-30 09:56:54 +08:00 via Android
使用 notifyAll，不要使用 notify，可能会陷入死锁，具体可以自己分析一下多线程调用流程以及 notify 原理
|
|
16
776491381 2020-08-30 09:57:27 +08:00 via Android
同时需要使用 while 循环判断
|
|
17
Newyorkcity OP @776491381 额..就是想过了没想出所以然来....请具体说说?
|
 |
18
falsemask 2020-08-30 11:30:39 +08:00 1
线程会被虚假唤醒，if 要改成 while
|
Select Language