epubjs

<?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"><head><title>Introducing Threads</title><link rel="stylesheet" href="core.css" type="text/css"/><meta name="generator" content="DocBook XSL Stylesheets V1.74.0"/></head><body><div class="sect1" title="Introducing Threads"><div class="titlepage"><div><div><h1 class="title"><a id="learnjava3-CHP-9-SECT-1"/>Introducing Threads</h1></div></div></div><p>Conceptually, a <span class="emphasis"><em>thread</em></span> is a flow of control within a program. A thread is similar to the more familiar notion of a <span class="emphasis"><em>process</em></span>, except that threads within the same application are much more closely related and share much of the same state. It’s kind of like a golf course, which many golfers use at the same time. The threads cooperate to share a working area. They have access to the same objects, including static and instance variables, within their application. However, threads have their own copies of local variables, just as players share the golf course but do not share some personal items like clubs and balls.</p><p>Multiple threads in an application have the same problems as the golfers—in a word, synchronization. Just as you can’t have two sets of players blindly playing the same green at the same time, you can’t have several threads trying to access the same variables without some kind of coordination. Someone is bound to get hurt. A thread can reserve the right to use an object until it’s finished with its task, just as a golf party gets exclusive rights to the green until it’s done. And a thread that is more important can raise its priority, asserting its right to play through.</p><p>The devil is in the details, of course, and those details have historically made threads difficult to use. Fortunately, Java makes creating, controlling, and coordinating threads simpler by integrating some of these concepts directly into the language.</p><p>It is common to stumble over threads when you first work with them because creating a thread exercises many of your new Java skills all at once. You can avoid confusion by remembering that two players are always involved in running a thread: a Java language <code class="literal">Thread</code> object that represents the thread itself and an arbitrary target object that contains the method that the thread is to execute. Later, you will see that it is possible to play some sleight of hand and combine these two roles, but that special case just changes the packaging, not the relationship.</p><div class="sect2" title="The Thread Class and the Runnable Interface"><div class="titlepage"><div><div><h2 class="title"><a id="learnjava3-CHP-9-SECT-1.1"/>The Thread Class and the Runnable Interface</h2></div></div></div><p>All execution in Java is associated with a <code class="literal">Thread</code> object, beginning with a “main” thread that is started by the Java VM to launch your application. A new thread is born when we create an instance of the <code class="literal">java.lang.Thread</code> class. The <code class="literal">Thread</code> object represents a real thread in the Java interpreter and serves as a handle for controlling and coordinating its execution. With it, we can start the thread, wait for it to complete, cause it to sleep for a time, or interrupt its activity. The constructor for the <code class="literal">Thread</code> class accepts information about where the thread should begin its execution. Conceptually, we would like to simply tell it what method to run, but because there are no pointers to methods in Java (not in this sense anyway), we can’t specify one directly. Instead, we have to take a short detour and use the <code class="literal">java.lang.Runnable</code> interface to create or mark an object that contains a “runnable” method. <code class="literal">Runnable</code> defines a single, general-purpose <a id="I_indexterm9_id714161" class="indexterm"/><code class="literal">run()</code> method:</p><a id="I_9_tt482"/><pre class="programlisting"> <code class="kd">public</code> <code class="kd">interface</code> <code class="nc">Runnable</code> <code class="o">{</code> <code class="kd">abstract</code> <code class="kd">public</code> <code class="kt">void</code> <code class="nf">run</code><code class="o">();</code> <code class="o">}</code></pre><p>Every thread begins its life by executing the <code class="literal">run()</code> method in a <code class="literal">Runnable</code> object, which is the “target object” that was passed to the thread’s constructor. The <code class="literal">run()</code> method can contain any code, but it must be public, take no arguments, have no return value, and throw no checked exceptions.</p><p>Any class that contains an appropriate <code class="literal">run()</code> method can declare that it implements the <a id="I_indexterm9_id714213" class="indexterm"/><a id="I_indexterm9_id714218" class="indexterm"/><code class="literal">Runnable</code> interface. An instance of this class is then a runnable object that can serve as the target of a new thread. If you don’t want to put the <code class="literal">run()</code> method directly in your object (and very often you don’t), you can always make an adapter class that serves as the <code class="literal">Runnable</code> for you. The adapter’s <code class="literal">run()</code> method can then call any method it wants after the thread is started. We’ll show examples of these options later.</p><div class="sect3" title="Creating and starting threads"><div class="titlepage"><div><div><h3 class="title"><a id="learnjava3-CHP-9-SECT-1.1.1"/>Creating and starting threads</h3></div></div></div><p><a id="idx10485" class="indexterm"/> <a id="idx10506" class="indexterm"/>A newly born thread remains idle until we give it a figurative slap on the bottom by calling its <a id="I_indexterm9_id714290" class="indexterm"/><code class="literal">start()</code> method. The thread then wakes up and proceeds to execute the <code class="literal">run()</code> method of its target object. <code class="literal">start()</code> can be called only once in the lifetime of a thread. Once a thread starts, it continues running until the target object’s <code class="literal">run()</code> method returns (or throws an unchecked exception of some kind). The <code class="literal">start()</code> method has a sort of evil twin method called <a id="I_indexterm9_id714327" class="indexterm"/><code class="literal">stop()</code>, which kills the thread permanently. However, this method is deprecated and should no longer be used. We’ll explain why and give some examples of a better way to stop your threads later in this chapter. We will also look at some other methods you can use to control a thread’s progress while it is running.</p><p>Let’s look at an example. The following class, <a id="I_indexterm9_id714346" class="indexterm"/><code class="literal">Animation</code>, implements a <code class="literal">run()</code> method to drive its drawing loop:</p><a id="I_9_tt483"/><pre class="programlisting"> <code class="kd">class</code> <code class="nc">Animation</code> <code class="kd">implements</code> <code class="n">Runnable</code> <code class="o">{</code> <code class="kt">boolean</code> <code class="n">animate</code> <code class="o">=</code> <code class="kc">true</code><code class="o">;</code> <code class="kd">public</code> <code class="kt">void</code> <code class="nf">run</code><code class="o">()</code> <code class="o">{</code> <code class="k">while</code> <code class="o">(</code> <code class="n">animate</code> <code class="o">)</code> <code class="o">{</code> <code class="c1">// draw Frames</code> <code class="o">...</code> <code class="o">}</code> <code class="o">}</code> <code class="o">}</code></pre><p>To use it, we create a <code class="literal">Thread</code> object, passing it an instance of <code class="literal">Animation</code> as its target object, and invoke its <a id="I_indexterm9_id714386" class="indexterm"/><code class="literal">start()</code> method. We can perform these steps explicitly:</p><a id="I_9_tt484"/><pre class="programlisting"> <code class="n">Animation</code> <code class="n">happy</code> <code class="o">=</code> <code class="k">new</code> <code class="n">Animation</code><code class="o">(</code><code class="s">"Mr. Happy"</code><code class="o">);</code> <code class="n">Thread</code> <code class="n">myThread</code> <code class="o">=</code> <code class="k">new</code> <code class="n">Thread</code><code class="o">(</code> <code class="n">happy</code> <code class="o">);</code> <code class="n">myThread</code><code class="o">.</code><code class="na">start</code><code class="o">();</code></pre><p>We created an instance of our <code class="literal">Animation</code> class and passed it as the argument to the constructor for <code class="literal">myThread</code>. When we call the <code class="literal">start()</code> method, <code class="literal">myThread</code> begins to execute <code class="literal">Animation</code>’s <code class="literal">run()</code> method. Let the show begin!</p><p>This situation is not terribly object-oriented. More often, we want an object to handle its own threads, as shown in <a class="xref" href="ch09s01.html#learnjava3-CHP-9-FIG-1" title="Figure 9-1. Interaction between Animation and its thread">Figure 9-1</a>, which depicts a <code class="literal">Runnable</code> object that creates and starts its own thread. We’ll show our <code class="literal">Animation</code> class performing these actions in its constructor, although in practice it might be better to place them in a more explicit controller method (e.g., <code class="literal">startAnimation()</code>):</p><a id="I_9_tt485"/><pre class="programlisting"><code class="n">n</code> <code class="kd">class</code> <code class="nc">Animation</code> <code class="kd">implements</code> <code class="n">Runnable</code> <code class="o">{</code> <code class="n">Thread</code> <code class="n">myThread</code><code class="o">;</code> <code class="n">Animation</code> <code class="o">(</code><code class="n">String</code> <code class="n">name</code><code class="o">)</code> <code class="o">{</code> <code class="n">myThread</code> <code class="o">=</code> <code class="k">new</code> <code class="n">Thread</code><code class="o">(</code> <code class="k">this</code> <code class="o">);</code> <code class="n">myThread</code><code class="o">.</code><code class="na">start</code><code class="o">();</code> <code class="o">}</code> <code class="o">...</code> <code class="o">}</code></pre><div class="figure"><a id="learnjava3-CHP-9-FIG-1"/><div class="figure-contents"><div class="mediaobject"><a id="I_9_tt486"/><img src="httpatomoreillycomsourceoreillyimages1707629.png" alt="Interaction between Animation and its thread"/></div></div><p class="title">Figure 9-1. Interaction between Animation and its thread</p></div><p>In this case, the argument that we pass to the <code class="literal">Thread</code> constructor is <code class="literal">this</code>, the current object (which is a <code class="literal">Runnable</code>). We keep the <code class="literal">Thread</code> reference in the instance variable <code class="literal">myThread</code> in case we want to interrupt the show or exercise some other kind of control later.<a id="I_indexterm9_id714529" class="indexterm"/><a id="I_indexterm9_id714536" class="indexterm"/></p></div><div class="sect3" title="A natural-born thread"><div class="titlepage"><div><div><h3 class="title"><a id="learnjava3-CHP-9-SECT-1.1.2"/>A natural-born thread</h3></div></div></div><p><a id="idx10486" class="indexterm"/> <a id="idx10507" class="indexterm"/>The <a id="I_indexterm9_id714577" class="indexterm"/><code class="literal">Runnable</code> interface lets us make an arbitrary object the target of a thread, as we did in the previous example. This is the most important general usage of the <code class="literal">Thread</code> class. In most situations in which you need to use threads, you’ll create a class (possibly a simple adapter class) that implements the <code class="literal">Runnable</code> interface.</p><p>However, we’d be remiss not to show you the other technique for creating a thread. Another design option is to make our target class a subclass of a type that is already runnable. As it turns out, the <code class="literal">Thread</code> class itself conveniently implements the <code class="literal">Runnable</code> interface; it has its own <a id="I_indexterm9_id714620" class="indexterm"/><code class="literal">run()</code> method, which we can override directly to do our bidding:</p><a id="I_9_tt487"/><pre class="programlisting"> <code class="kd">class</code> <code class="nc">Animation</code> <code class="kd">extends</code> <code class="n">Thread</code> <code class="o">{</code> <code class="kt">boolean</code> <code class="n">animate</code> <code class="o">=</code> <code class="kc">true</code><code class="o">;</code> <code class="kd">public</code> <code class="kt">void</code> <code class="nf">run</code><code class="o">()</code> <code class="o">{</code> <code class="k">while</code> <code class="o">(</code> <code class="n">animate</code> <code class="o">)</code> <code class="o">{</code> <code class="c1">// draw Frames</code> <code class="o">...</code> <code class="o">}</code> <code class="o">}</code> <code class="o">}</code></pre><p>The skeleton of our <code class="literal">Animation</code> class looks much the same as before, except that our class is now a subclass of <code class="literal">Thread</code>. To go along with this scheme, the default constructor of the <code class="literal">Thread</code> class makes itself the default target—that is, by default, the <code class="literal">Thread</code> executes its own <code class="literal">run()</code> method when we call the <code class="literal">start()</code> method, as shown in <a class="xref" href="ch09s01.html#learnjava3-CHP-9-FIG-2" title="Figure 9-2. Animation as a subclass of Thread">Figure 9-2</a>. Now our subclass can just override the <code class="literal">run()</code> method in the <code class="literal">Thread</code> class. (<code class="literal">Thread</code> itself defines an empty <code class="literal">run()</code> method.)</p><div class="figure"><a id="learnjava3-CHP-9-FIG-2"/><div class="figure-contents"><div class="mediaobject"><a id="I_9_tt488"/><img src="httpatomoreillycomsourceoreillyimages1707630.png" alt="Animation as a subclass of Thread"/></div></div><p class="title">Figure 9-2. Animation as a subclass of Thread</p></div><p>Next, we create an instance of <a id="I_indexterm9_id714727" class="indexterm"/><code class="literal">Animation</code> and call its <a id="I_indexterm9_id714738" class="indexterm"/><code class="literal">start()</code> method (which it also inherited from <code class="literal">Thread</code>):</p><a id="I_9_tt489"/><pre class="programlisting"> <code class="n">Animation</code> <code class="n">bouncy</code> <code class="o">=</code> <code class="k">new</code> <code class="n">Animation</code><code class="o">(</code><code class="s">"Bouncy"</code><code class="o">);</code> <code class="n">bouncy</code><code class="o">.</code><code class="na">start</code><code class="o">();</code></pre><p>Alternatively, we can have the <code class="literal">Animation</code> object start its thread when it is created, as before:</p><a id="I_9_tt490"/><pre class="programlisting"> <code class="kd">class</code> <code class="nc">Animation</code> <code class="kd">extends</code> <code class="n">Thread</code> <code class="o">{</code> <code class="n">Animation</code> <code class="o">(</code><code class="n">String</code> <code class="n">name</code><code class="o">)</code> <code class="o">{</code> <code class="n">start</code><code class="o">();</code> <code class="o">}</code> <code class="o">...</code> <code class="o">}</code></pre><p>Here, our <code class="literal">Animation</code> object just calls its own <code class="literal">start()</code> method when an instance is created. (It’s probably better form to start and stop our objects explicitly after they’re created rather than starting threads as a hidden side effect of object creation, but this serves the example well.)</p><p>Subclassing <a id="I_indexterm9_id714800" class="indexterm"/><code class="literal">Thread</code> may seem like a convenient way to bundle a thread and its target <code class="literal">run()</code> method. However, this approach often isn’t the best design. If you subclass <code class="literal">Thread</code> to implement a thread, you are saying you need a new type of object that is a kind of <code class="literal">Thread</code>, which exposes all of the public API of the <code class="literal">Thread</code> class. While there is something satisfying about taking an object that’s primarily concerned with performing a task and making it a <code class="literal">Thread</code>, the actual situations where you’ll want to create a subclass of <code class="literal">Thread</code> should not be very common. In most cases, it is more natural to let the requirements of your program dictate the class structure and use <code class="literal">Runnable</code>s to connect the execution and logic of your program.<a id="I_indexterm9_id714859" class="indexterm"/><a id="I_indexterm9_id714866" class="indexterm"/></p></div><div class="sect3" title="Using an adapter"><div class="titlepage"><div><div><h3 class="title"><a id="learnjava3-CHP-9-SECT-1.1.3"/>Using an adapter</h3></div></div></div><p><a id="idx10487" class="indexterm"/> <a id="idx10508" class="indexterm"/>Finally, as we have suggested, we can build an adapter class to give us more control over how to structure the code. It is particularly convenient to create an anonymous inner class that implements <code class="literal">Runnable</code> and invokes an arbitrary method in our object. This almost gives the feel of starting a thread and specifying an arbitrary method to run, as if we had method pointers. For example, suppose that our <code class="literal">Animation</code> class provides a method called <a id="I_indexterm9_id714924" class="indexterm"/><code class="literal">startAnimating()</code>, which performs setup (loads the images, etc.) and then starts a thread to perform the animation. We’ll say that the actual guts of the animation loop are in a private method called <code class="literal">drawFrames()</code>. We could use an adapter to run <code class="literal">drawFrames()</code> for us:</p><a id="I_9_tt491"/><pre class="programlisting"> <code class="kd">class</code> <code class="nc">Animation</code> <code class="o">{</code> <code class="kd">public</code> <code class="kt">void</code> <code class="nf">startAnimating</code><code class="o">()</code> <code class="o">{</code> <code class="c1">// do setup, load images, etc.</code> <code class="o">...</code> <code class="c1">// start a drawing thread</code> <code class="n">Thread</code> <code class="n">myThread</code> <code class="o">=</code> <code class="k">new</code> <code class="n">Thread</code> <code class="o">(</code> <code class="k">new</code> <code class="n">Runnable</code><code class="o">()</code> <code class="o">{</code> <code class="kd">public</code> <code class="kt">void</code> <code class="nf">run</code><code class="o">()</code> <code class="o">{</code> <code class="n">drawFrames</code><code class="o">();</code> <code class="o">}</code> <code class="o">}</code> <code class="o">);</code> <code class="n">myThread</code><code class="o">.</code><code class="na">start</code><code class="o">();</code> <code class="o">}</code> <code class="kd">private</code> <code class="kt">void</code> <code class="nf">drawFrames</code><code class="o">()</code> <code class="o">{</code> <code class="c1">// do animation ...</code> <code class="o">}</code> <code class="o">}</code></pre><p>In this code, the anonymous inner class implementing <code class="literal">Runnable</code> is generated for us by the compiler. We create a thread with this anonymous object as its target and have its <code class="literal">run()</code> method call our <code class="literal">drawFrames()</code> method. We have avoided implementing a generic <code class="literal">run()</code> method in our application code at the expense of generating an extra class.</p><p>Note that we could be even more terse in the previous example by simply having our anonymous inner class extend <code class="literal">Thread</code> rather than implement <code class="literal">Runnable</code>. We could also start the thread without saving a reference to it if we won’t be using it later:<a id="I_indexterm9_id715004" class="indexterm"/><a id="I_indexterm9_id715011" class="indexterm"/></p><a id="I_9_tt492"/><pre class="programlisting"> <code class="k">new</code> <code class="nf">Thread</code><code class="o">()</code> <code class="o">{</code> <code class="kd">public</code> <code class="kt">void</code> <code class="nf">run</code><code class="o">()</code> <code class="o">{</code> <code class="n">drawFrames</code><code class="o">();</code> <code class="o">}</code> <code class="o">}.</code><code class="na">start</code><code class="o">();</code></pre></div></div><div class="sect2" title="Controlling Threads"><div class="titlepage"><div><div><h2 class="title"><a id="learnjava3-CHP-9-SECT-1.2"/>Controlling Threads</h2></div></div></div><p>We have seen the <code class="literal">start()</code> method used to begin execution of a new thread. Several other instance methods let us explicitly control a thread’s execution:</p><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>The static <a id="I_indexterm9_id715047" class="indexterm"/><code class="literal">Thread.sleep()</code> method causes the currently executing thread to wait for a designated period of time, without consuming much (or possibly any) CPU time.</p></li><li class="listitem"><p>The methods <a id="I_indexterm9_id715062" class="indexterm"/><code class="literal">wait()</code> and <a id="I_indexterm9_id715072" class="indexterm"/><code class="literal">join()</code> coordinate the execution of two or more threads. We’ll discuss them in detail when we talk about thread synchronization later in this chapter.</p></li><li class="listitem"><p>The <a id="idx10472" class="indexterm"/><code class="literal">interrupt()</code> method wakes up a thread that is sleeping in a <code class="literal">sleep()</code> or <code class="literal">wait()</code> operation or is otherwise blocked on a long I/O operation.<sup>[<a id="learnjava3-CHP-9-FNOTE-1" href="#ftn.learnjava3-CHP-9-FNOTE-1" class="footnote">25</a>]</sup></p></li></ul></div><div class="sect3" title="Deprecated methods"><div class="titlepage"><div><div><h3 class="title"><a id="learnjava3-CHP-9-SECT-1.2.1"/>Deprecated methods</h3></div></div></div><p><a id="idx10461" class="indexterm"/> <a id="idx10494" class="indexterm"/>We should also mention three deprecated thread control methods: <a id="I_indexterm9_id715159" class="indexterm"/><code class="literal">stop()</code>, <a id="I_indexterm9_id715172" class="indexterm"/><code class="literal">suspend()</code>, and <a id="I_indexterm9_id715185" class="indexterm"/><code class="literal">resume()</code>. The <code class="literal">stop()</code> method complements <code class="literal">start()</code>; it destroys the thread. <code class="literal">start()</code> and the deprecated <code class="literal">stop()</code> method can be called only once in the thread’s lifecycle. By contrast, the deprecated <code class="literal">suspend()</code> and <code class="literal">resume()</code> methods were used to arbitrarily pause and then restart the execution of a thread.</p><p>Although these deprecated methods still exist in the latest version of Java (and will probably be there forever), they shouldn’t be used in new code development. The problem with both <code class="literal">stop()</code> and <code class="literal">suspend()</code> is that they seize control of a thread’s execution in an uncoordinated, harsh way. This makes programming difficult; it’s not always easy for an application to anticipate and properly recover from being interrupted at an arbitrary point in its execution. Moreover, when a thread is seized using one of these methods, the Java runtime system must release all its internal locks used for thread synchronization. This can cause unexpected behavior and, in the case of <code class="literal">suspend()</code>, can easily lead to deadlock.</p><p>A better way to affect the execution of a thread—which requires just a bit more work on your part—is by creating some simple logic in your thread’s code to use monitor variables (flags), possibly in conjunction with the <code class="literal">interrupt()</code> method, which allows you to wake up a sleeping thread. In other words, you should cause your thread to stop or resume what it is doing by asking it nicely rather than by pulling the rug out from under it unexpectedly. The thread examples in this book use this technique in one way or another.<a id="I_indexterm9_id715274" class="indexterm"/><a id="I_indexterm9_id715281" class="indexterm"/></p></div><div class="sect3" title="The sleep() method"><div class="titlepage"><div><div><h3 class="title"><a id="learnjava3-CHP-9-SECT-1.2.2"/>The sleep() method</h3></div></div></div><p><a id="I_indexterm9_id715295" class="indexterm"/> <a id="I_indexterm9_id715301" class="indexterm"/>We often need to tell a thread to sit idle, or “sleep,” for a fixed period of time. While a thread is asleep, or otherwise blocked from input of some kind, it doesn’t consume CPU time or compete with other threads for processing. For this, we can call the static method <code class="literal">Thread.sleep()</code>, which affects the currently executing thread. The call causes the thread to go idle for a specified number of milliseconds:</p><a id="I_9_tt493"/><pre class="programlisting"> <code class="k">try</code> <code class="o">{</code> <code class="c1">// The current thread</code> <code class="n">Thread</code><code class="o">.</code><code class="na">sleep</code><code class="o">(</code> <code class="mi">1000</code> <code class="o">);</code> <code class="o">}</code> <code class="k">catch</code> <code class="o">(</code> <code class="n">InterruptedException</code> <code class="n">e</code> <code class="o">)</code> <code class="o">{</code> <code class="c1">// someone woke us up prematurely</code> <code class="o">}</code></pre><p>The <code class="literal">sleep()</code> method may throw an <a id="I_indexterm9_id715341" class="indexterm"/><code class="literal">InterruptedException</code> if it is interrupted by another thread via the <code class="literal">interrupt()</code> method. As you see in the previous code, the thread can catch this exception and take the opportunity to perform some action—such as checking a variable to determine whether or not it should exit—or perhaps just perform some housekeeping and then go back to sleep.</p></div><div class="sect3" title="The join() method"><div class="titlepage"><div><div><h3 class="title"><a id="learnjava3-CHP-9-SECT-1.2.3"/>The join() method</h3></div></div></div><p><a id="idx10473" class="indexterm"/> <a id="idx10495" class="indexterm"/>Finally, if you need to coordinate your activities with another thread by waiting for it to complete its task, you can use the <code class="literal">join()</code> method. Calling a thread’s <code class="literal">join()</code> method causes the caller to block until the target thread completes. Alternatively, you can poll the thread by calling <code class="literal">join()</code> with a number of milliseconds to wait. This is a very coarse form of thread synchronization. Later in this chapter, we’ll look at a much more general and powerful mechanism for coordinating thread activity: <code class="literal">wait()</code>, <code class="literal">notify()</code>, and even higher-level APIs in the <a id="I_indexterm9_id715429" class="indexterm"/><code class="literal">java.util.concurrent</code> package.<a id="I_indexterm9_id715440" class="indexterm"/><a id="I_indexterm9_id715447" class="indexterm"/></p></div><div class="sect3" title="The interrupt() method"><div class="titlepage"><div><div><h3 class="title"><a id="learnjava3-CHP-9-SECT-1.2.4"/>The interrupt() method</h3></div></div></div><p><a id="I_indexterm9_id715461" class="indexterm"/>Earlier, we described the <code class="literal">interrupt()</code> method as a way to wake up a thread that is idle in a <code class="literal">sleep()</code>, <code class="literal">wait()</code>, or lengthy I/O operation. Any thread that is not running continuously (not a “hard loop”) must enter one of these states periodically and so this is intended to be a point where the thread can be flagged to stop. When a thread is interrupted, its <span class="emphasis"><em>interrupt status</em></span> flag is set. This can happen at any time, whether the thread is idle or not. The thread can test this status with the <a id="I_indexterm9_id715498" class="indexterm"/><code class="literal">isInterrupted()</code> method. <code class="literal">isInterrupted(boolean)</code>, another form, accepts a Boolean value indicating whether or not to clear the interrupt status. In this way, a thread can use the interrupt status as a flag and a signal.</p><p>This is indeed the prescribed functionality of the method. However, historically, this has been a weak spot, and Java implementations have had trouble getting it to work correctly in all cases. In early Java VMs (prior to version 1.1), <code class="literal">interrupt</code> did not work at all. More recent versions still have problems with interrupting I/O calls. By an I/O call, we mean when an application is blocked in a <code class="literal">read()</code> or <code class="literal">write()</code> method, moving bytes to or from a source such as a file or the network. In this case, Java is supposed to throw an <a id="I_indexterm9_id715539" class="indexterm"/><code class="literal">InterruptedIOException</code> when the <code class="literal">interrupt()</code> is performed. However, this has never been reliable across all Java implementations. To address this in Java 1.4, a new I/O framework (<code class="literal">java.nio</code>) was introduced with one of its goals being to specifically address these problems. When the thread associated with an NIO operation is interrupted, the thread wakes up and the I/O stream (called a “channel”) is automatically closed. (See <a class="xref" href="ch12.html" title="Chapter 12. Input/Output Facilities">Chapter 12</a> for more about the NIO package.)<a id="I_indexterm9_id715572" class="indexterm"/></p></div></div><div class="sect2" title="Death of a Thread"><div class="titlepage"><div><div><h2 class="title"><a id="learnjava3-CHP-9-SECT-1.3"/>Death of a Thread</h2></div></div></div><p><a id="idx10505" class="indexterm"/>A thread continues to execute until one of the following happens:</p><div class="itemizedlist"><ul class="itemizedlist"><li class="listitem"><p>It explicitly returns from its target <code class="literal">run()</code> method.</p></li><li class="listitem"><p>It encounters an uncaught runtime exception.</p></li><li class="listitem"><p>The evil and nasty deprecated <code class="literal">stop()</code> method is called.</p></li></ul></div><p>What happens if none of these things occurs, and the <code class="literal">run()</code> method for a thread never terminates? The answer is that the thread can live on, even after what is ostensibly the part of the application that created it has finished. This means we have to be aware of how our threads eventually terminate, or an application can end up leaving orphaned threads that unnecessarily consume resources or keep the application alive when it would otherwise quit.</p><p><a id="idx10460" class="indexterm"/>In many cases, we really want to create background threads that do simple, periodic tasks in an application. The <a id="I_indexterm9_id715646" class="indexterm"/><code class="literal">setDaemon()</code> method can be used to mark a thread as a daemon thread that should be killed and discarded when no other nondaemon application threads remain. Normally, the Java interpreter continues to run until all threads have completed. But when daemon threads are the only threads still alive, the interpreter will exit.</p><p>Here’s a devilish example using daemon threads:</p><a id="I_9_tt494"/><pre class="programlisting"> <code class="kd">class</code> <code class="nc">Devil</code> <code class="kd">extends</code> <code class="n">Thread</code> <code class="o">{</code> <code class="n">Devil</code><code class="o">()</code> <code class="o">{</code> <code class="n">setDaemon</code><code class="o">(</code> <code class="kc">true</code> <code class="o">);</code> <code class="n">start</code><code class="o">();</code> <code class="o">}</code> <code class="kd">public</code> <code class="kt">void</code> <code class="nf">run</code><code class="o">()</code> <code class="o">{</code> <code class="c1">// perform evil tasks</code> <code class="o">}</code> <code class="o">}</code></pre><p>In this example, the <code class="literal">Devil</code> thread sets its daemon status when it is created. If any <code class="literal">Devil</code> threads remain when our application is otherwise complete, the runtime system kills them for us. We don’t have to worry about cleaning them up.</p><p>Daemon threads are primarily useful in standalone Java applications and in the implementation of server frameworks, but not in component applications such as applets. Since an applet runs inside another Java application, any daemon threads it creates can continue to live until the controlling application exits—probably not the desired effect. A browser or any other application can use <a id="I_indexterm9_id715698" class="indexterm"/><code class="literal">ThreadGroups</code> to contain all the threads created by subsystems of an application and then clean them up if necessary.<a id="I_indexterm9_id715709" class="indexterm"/></p><p>One final note about killing threads gracefully. A very common problem new developers encounter the first time they create an application using an AWT or Swing component is that their application never exits; the Java VM seems to hang indefinitely after everything is finished. When working with graphics, Java has created an AWT thread to process input and painting events. The AWT thread is not a daemon thread, so it doesn’t exit automatically when other application threads have completed, and the developer must call <a id="I_indexterm9_id715728" class="indexterm"/><code class="literal">System.exit()</code> explicitly. (If you think about it, this makes sense. Because most GUI applications are event-driven and simply wait for user input, they would otherwise simply exit after their startup code completed.)<a id="I_indexterm9_id715741" class="indexterm"/></p></div><div class="footnotes"><br/><hr/><div class="footnote"><p><sup>[<a id="ftn.learnjava3-CHP-9-FNOTE-1" href="#learnjava3-CHP-9-FNOTE-1" class="para">25</a>] </sup><code class="literal">interrupt()</code> has not worked consistently in all Java implementations historically.</p></div></div></div></body></html>