Java-multithreading-Analysis of an Alibaba interview question

It is said that this is an interview question from Alibaba: It is also said that the author of this question has gone to tmail. The following is a description of the question:

This code runs normally in most cases, but in some cases there may be problems. When will there be any problems? How to fix it? Visible blog http://yueyemaitian.iteye.com/blog/1387901

Java code

1. Public class mystack {
2. Private list <string> List = new arraylist <string> ();
4. Public synchronized void push (string value ){
5. Synchronized (this ){
6. List. Add (value );
7. Notify ();
8. }
9. }
11. Public synchronized string POP () throws interruptedexception {
12. Synchronized (this ){
13. If (list. Size () <= 0 ){
14. Wait ();
15. }
16. Return list. Remove (list. Size ()-1 );
17. }
18. }
19. }

The following is an analysis of this question:

List. Remove (list. Size ()-1); this Code may throw the array subscript out of bounds.
Cause:
Assume one of these situations! There may be many problems, but the principles are similar. The following number indicates the sequence of the program sequence.
1. At initialization, the value of list is 0, and thread 1 calls pop, so it is wait and the lock is released.
2. Thread 2 calls push, and thread 3 calls pop before thread y (remember that thread 1 has not been woken up yet and is still in wait ), at this time, thread 3 will be suspended or spin because of waiting for the lock. It is waiting for the lock to be available. 3. Then thread 2 continues to run, and thread y is executed (but thread 1 will not wake up at this time, because the lock is still occupied by thread 2). Thread 2 exits the push method, release the built-in lock. At this time, both thread 1 and thread 3 are in the built-in lock wait queue. Because synchronized cannot guarantee the fairness of thread competition, thread 1 and thread 3 may be locked.
4. Assume that thread 1 competes with the lock and there will be no problems. The list value will be removed normally, and then removed. After the execution, thread 3 will be executed, which will also be occupied by wait.
5. Suppose thread 3 is competing for the lock. The problem is that thread 3 will judge that the size of the list is not 0, so remove, so the size of the List is 0, then thread 3 releases the lock. At this time, thread 1 gets the lock, so it wakes up from wait, continues to execute, and then directly calls the remove of list, because the size of list is 0, so remove (-1) will generate an out-of-bounds error.

Some people say that the two threads are waiting at wait and there will also be problems. In fact, there will be no problems, because it is called y rather than notifyall. If it is called notifyall, the same problem will occur.

Improvement: I am wondering why dual locks are used, as if there is no need for dual locks. When I first saw the double lock, I was wondering whether the problem was simulating a deadlock in the casing. I did spend some time looking for the deadlock. However, this double check is a reentrant lock and is a lock on this object. So there is no casing deadlock. Improvement 1, -- minimum code change, check list before removing. size = 0 Improvement 2, -- remove the second lock check in the push and pop methods. I did not find any use of this lock, but it consumes performance. Of course, there must be a judgment on solution 1. 3, -- re-design. If I design such a producer and consumer model. I prefer to use javasblockingqueue, which has the take method to block consumers until the queue is available. The offer method also blocks producers until the queue can be inserted, effectively blocking oom. This is a good question. Has someone made this mistake in Alibaba! Haha!
If you have any questions about this question, please point them out in time!