哪一个更好的性能来检查java中的另一个线程boolean

Question

while(!anotherThread.isDone());

or

while(!anotherThread.isDone())
    Thread.sleep(5);

Answer 1

If you really need to wait for a thread to complete, use

anotherThread.join()

(You may want to consider specifying a timeout in the join call.)

You definitely shouldn't tight-loop like your first snippet does... and sleeping for 5ms is barely better.

If you can't use join (eg you're waiting for a task to complete rather than a whole thread) you should look at the java.util.concurrent package - chances are there's something which will meet your needs.

Answer 2

IMHO, avoid using such logic altogether. Instead, perhaps implement some sort of notification system using property change listeners.

Answer 3

I would recommend utilizing the wait/notify mechanism that is built into all Java objects (or using the new Lock code in Java 5 ).

Thread 1 (waiting for Thread2)

while(!thread2.isDone()) {
  synchronize(thread2.lockObject) {
    thread2.lockObject.wait();
  }
}

Thread 2

// finish work, set isDone=true, notify T1
thread2.lockObject.notify();

'lockObject' is just a plain (Object lockObject = new Object()) -- all Java objects support the wait/notify calls.

After that last call to notify(), Thread1 will wake up, hit the top of the while, see that T2 is now done, and continue execution.

You should account for interrupt exceptions and the like, but using wait/notify is hugely helpful for scenarios like this.

If you use your existing code, with or without sleep, you are burning a huge number of cycles doing nothing ... and that's never good.

ADDENDUM

I see a lot of comments saying to use join - if the executing thread you are waiting on will complete, then yes, use join. If you have two parallel threads that run at all times (eg a producer thread and a consumer) and they don't "complete", they just run in lock-step with each other, then you can use the wait/notify paradigm I provided above.

Answer 4

As others have said, it's better to just use join in this case. However, I'd like to generalize your question and ask the following:

In general when a thread is waiting for an event that depends on another thread to occur is it better to:

1. Use a blocking mechanism (ie join, conditional variable, etc.) or
2. Busy spin without sleep or
3. Busy spin with sleep?

Now let's see what are the implications for each case:

1. In this case, using a blocking call will effectively take your thread off the CPU and not schedule it again until the expected event occurs. Good for resource utilization (the thread would waste CPU cycles otherwise), but not very efficient if the event may occur very frequently and at small intervals (ie a context switch is much more time-consuming than the time it takes for the event to occur). Generally good when the event will occur eventually, but you don't know how soon.
2. In case two, you are busy spinning, meaning that you are actively using the CPU without performing useful work. This is the opposite of case 1: it is useful when the event is expected to occur very very soon , but otherwise may occupy the CPU unnecessarily.
3. This case is a sort of trade-off. You are busy spinning, but at the same time allowing other threads to run by giving up the CPU. This is generally employed when you don't want to saturate the CPU, but the event is expected to occur soon and you want to be sure that you will still be there in almost real time to catch it when it occurs.

Answer 5

The second one.

Better though is to use the join() method of a thread to block the current thread until it is complete :).

EDIT:

I just realised that this only addresses the question as it applies to the two examples you gave, not the question in general (how to wait for a boolean value to be changed by another Thread, not necessarily for the other Thread to actually finish).

To answer the question in general I would suggest that rather than using the methods you described, to do something like this I would recommend using the guarding block pattern as described here . This way, the waiting thread doesn't have to keep checking the condition itself and can just wait to be notified of the change. Hope this helps!

Answer 6

Have you considered: anotherThread.join() ? That will cause the current one to be 'parked' without any overhead until the other one terminates.

Answer 7

The second is better than the first, but neither is very good. You should use anotherThread.join() (or anotherThread.join(timeout) ).

Answer 8

Neither, use join() instead:

anotherThread.join();
// anotherThread has finished executing.