- The wait()
and notify() methods of the Object class extend this capability by allowing us to
explicitly coordinate the waiting and running threads.
-By executing wait() from a synchronized block, a thread gives up its hold on the lock
and goes to sleep. A thread might do this if it needs to wait for something to happen in
another part of the application, as we’ll see shortly.
-Later, when the necessary event
happens, the running thread calls notify() from a block synchronized on the same
object
-A ThreadLocal is an object
wrapper that automatically maintains a separate value for any thread calling it
-At any given time, a thread is in one of five general states that encompass its lifecycle
and activities.
-NEW
The thread has been created but not yet started.
-RUNNABLE
The normal active state of a running thread, including the time when a thread is
blocked in an I/O operation, like a read or write or network connection.
-BLOCKED
The thread is blocked, waiting to enter a synchronized method or code block. This
includes the time when a thread has been awakened by a notify() and is attempting
to reacquire its lock after a wait() .
-WAITING, TIMED_WAITING
The thread is waiting for another thread via a call to wait() or join() . In the case
of TIMED_WAITING , the call has a timeout.
-TERMINATED
The thread has completed due to a return, an exception, or being stopped.
-In a time-sliced system,
thread processing is chopped up so that each thread runs for a short period of time
before the context is switched to the next thread,
-Higher-priority threads still preempt lower-priority threads in this scheme. The addi‐
tion of time-slicing mixes up the processing among threads of the same priority;
-The subtleties relating to priority and performance relate to
how Java threads and priorities are mapped to real threads in the OS. For this reason,
thread priorities should be reserved for system and framework development.
-Whenever a thread sleeps, waits, or blocks on I/O, it gives up its time slot and another
thread is scheduled.
-The ThreadGroup class allows us to deal with threads wholesale: we can use it to arrange
threads in groups and deal with the groups as a whole.
-For example, we can forbid threads in a particular group from
interacting with threads in other groups. This is one way web browsers can prevent
threads started by Java applets from stopping important system threads.
ThreadGroup
myTaskGroup = new ThreadGroup("My Task Group");
Thread myTask = new Thread( myTaskGroup, taskPerformer );
-The ThreadGroup class exists so that you can control threads in batches. It has methods
that parallel the basic Thread control methods—even the deprecated stop() , sus
pend() , and resume()
-We can set the maximum priority for threads created in a thread group by calling
setMaximumPriority() .
-Finally, you can get a list of all threads in a group. The method activeCount() tells you
how many threads are in the group;
-We can handle uncaught excep‐
tions for a single thread like this:
-An alternative approach is to create “thread pools” where a fixed number of threads pull
tasks from a queue and return for more when they are finished.
-he java.util.concurrent package and
subpackages introduced with Java 5.0 build on this functionality, adding important
threading utilities and codifying some common design patterns by supplying standard
implementations
-One such related pair of patterns is the concept
of an executor service that manages tasks and that of a thread pool that services tasks in
an efficient way.