Recently, I find a good article about java thread and is worth learning。According to my reading it, some important contents will be listed as follow.
Start your vehicles
Threads resemble vehicles: they move programs from start to finish. Thread and Thread subclass objects are not threads. Instead, they describe a thread's attributes, such as its name, and contain code (via a run() method) that the thread executes. When the
time comes for a new thread to execute run(), another thread calls the Thread's or its subclass object's start() method. For example, to start a second thread, the application's starting thread—which executes main()—calls start(). In response, the JVM's thread-handling
code works with the platform to ensure the thread properly initializes and calls a Thread's or its subclass object's run() method.
The behaviors of a starting thread's and a newly created thread's execution positions versus time. The chart shows several significant time periods:
* The starting thread's initialization
* The moment that thread begins to execute main()
* The moment that thread begins to execute start()
* The moment start() creates a new thread and returns to main()
* The new thread's initialization
* The moment the new thread begins to execute run()
* The different moments each thread terminates
Note that the new thread's initialization, its execution of run(), and its termination happen simultaneously with the starting thread's execution.After a thread calls start(), subsequent calls to that method before the run() method exits cause start() to
throw a java.lang.IllegalThreadStateException object.
Is it dead or alive?
When a program calls Thread's start() method, a time period (for initialization) passes before a new thread calls run(). After run() returns, a time period passes before the JVM cleans up the thread. The JVM considers the thread to be alive immediately
prior to the thread's call to run(), during the thread's execution of run(), and immediately after run() returns. During that interval, Thread's isAlive() method returns a Boolean true value. Otherwise, that method returns false.
A thread could possibly call the isAlive() method on itself. However, that does not make sense because isAlive() will always return true.
Joining forces
Because the while loop/isAlive() method/sleep() method technique proves useful, Sun packaged it into a trio of methods: join(), join(long millis), and join(long millis, int nanos). The current thread calls join(), via another thread's thread object reference
when it wants to wait for that other thread to terminate. In contrast, the current thread calls join(long millis) or join(long millis, int nanos) when it wants to either wait for that other thread to terminate or wait until a combination of millis millseconds
and nanos nanoseconds passes.
Caution
Do not attempt to join the current thread to itself because the current thread will wait forever.
The caste system
Not all threads are created equal. They divide into two categories: user and daemon. A user thread performs important work for the program's user, work that must finish before the application terminates. In contrast, a daemon thread performs housekeeping
(such as garbage collection) and other background tasks that probably do not contribute to the application's main work but are necessary for the application to continue its main work. Unlike user threads, daemon threads do not need to finish before the application
terminates. When an application's starting thread (which is a user thread) terminates, the JVM checks whether any other user threads are running. If some are, the JVM prevents the application from terminating. Otherwise, the JVM terminates the application
regardless of whether daemon threads are running.
When a thread calls a thread object's start() method, the newly started thread is a user thread. That is the default. To establish a thread as a daemon thread, the program must call Thread's setDaemon(boolean isDaemon) method with a Boolean true argument
value prior to the call to start(). Later, you can check if a thread is daemon by calling Thread's isDaemon() method. That method returns a Boolean true value if the thread is daemon.
Runnables
After studying the previous section's examples, you might think that introducing multithreading into a class always requires you to extend Thread and have your subclass override Thread's run() method. That is not always an option, however. Java's enforcement
of implementation inheritance prohibits a class from extending two or more superclasses. As a result, if a class extends a non-Thread class, that class cannot also extend Thread. Given that restriction, how is it possible to introduce multithreading into a
class that already extends some other class? Fortunately, Java's designers realized that situations would arise where subclassing Thread wouldn't be possible. That realization led to the java.lang.Runnable interface and Thread constructors with Runnable parameters,
such as Thread(Runnable target).
The Runnable interface declares a single method signature: void run();. That signature is identical to Thread's run() method signature and serves as a thread's entry of execution. Because Runnable is an interface, any class can implement that interface
by attaching an implements clause to the class header and by providing an appropriate run() method. At execution time, program code can create an object, or runnable, from that class and pass the runnable's reference to an appropriate Thread constructor. The
constructor stores that reference within the Thread object and ensures that a new thread calls the runnable's run() method after a call to the Thread object's start() method.
The Original Article
The original aritcle:http://www.javaworld.com/javaworld/jw-05-2002/jw-0503-java101.html?page=1
http://www.javaworld.com/javaworld/jw-06-2002/jw-0607-java101.html?
http://www.javaworld.com/javaworld/jw-07-2002/jw-0703-java101.html?
http://www.javaworld.com/javaworld/jw-08-2002/jw-0802-java101.html?