(2) thread can sleep with or without acquiring a lock, inside or outside synchronized block. When sleeping without a lock, the CPU resource is re-allocated to one of the ready-to-run threads. When sleeping inside synchronized block with a monitor lock, the lock is not relinquished, and the CPU is re-allocated to one of the other runnable threads that are not waiting on this lock.
(3) wait-notify-flag pattern. wait is almost always inside a while(flag) loop. There can be multiple threads waiting on the same monitor, some is waiting for the flag to change value, and others are not. In other words, there could be homogeneous threads and/or heterogeneous waiters. Once the flag changes value and notifyAll() is invoked, all threads waiting on the same monitor will be awaken. All of them exit waiting state and enter ready-to-run state, but only one of them will get the lock and proceed. If the lucky one consumes (reset) the flag after obtaining the lock, the previous flag set in notifyAll() becomes obsolete. Therefore, other threads, after they get the monitor, will need to recheck the flag to decide to wait again or proceed.
Another reason wait is inside a loop is there can be spurious wakeup, which are not triggered by notify or notifyAll calls. wait can also be interrupted by other threads. So the wait-notify protocol is not 100% reliable, and that's why a flag is needed to aid the inter-thread communication.
When to use notify and when to use notifyAll? When all waiters are homogeneous, i.e., whoever gets the monitor doesn't matter, use notify. When waiters are heterogeneous, use notifyAll to ensure the correct threads are awaken. If waiter are heterogeneous and we call notify, a waiter that does not care about the flag may be picked to proceed, while those waiters interested in the flag will not get the signal.
The flag should be exclusively for this purpose, not used by other part of the application. All access to this flag is inside synchronized block, so no need to make it volatile or AtomicBoolean.
(4) make the lock object final if possible, for example:
private final Object lock = new Object();Do not synchronize on string literals, which are merely reference to the same string object in the string pool, or global constants. It will unintentionally cause too many threads competing for the same lock.
(5) volatile can be used on fields of primitive type, primitive wrapper types, or any other Object types. A typical use is in singleton DCL pattern. If a mutable field is simply read or written by multiple threads, then making it volatile usually suffice. One step up in concurrency is to use java.util.concurrent.atomic.* classes like AtomicInteger, AtomicBoolean, etc. Atomic types are ideal for simple compound operations like read-update-assignment, or if-absent-set. Anything more complicated than that will need synchronized access.
Further readings:
Sun's Java Concurrency Tutorial
stackoverflow discussion on wait, notify, CountdownLatch, etc
(6), 3 ways to get a new thread:
* extend java.lang.Thread class and overriding its run() method;
* provide an impl of Runnable interface and use it to instantiate a new thread;
* provide an impl of Runnable interface and call ThreadFactory.newThread(runnable). Get the default ThreadFactory with Executors.defaultThreadFactory().
See their differences in another post: Extend Thread vs implement Runnable
Add a comment