All programmers are familiar with writing sequential programs. You've probably written a program that displays "Hello World!" or sorts a list of names or computes a list of prime numbers. These are sequential programs. That is, each has a beginning, an execution sequence, and an end. At any given time during the runtime of the program, there is a single point of execution.
A thread is similar to the sequential programs described previously. A single thread also has a beginning, a sequence, and an end. At any given time during the runtime of the thread, there is a single point of execution. However, a thread itself is not a program; a thread cannot run on its own. Rather, it runs within a program. Figure 80 shows this relationship.
Figure 80. A thread is not a program; a thread runs within a program.
A thread is a single sequential flow of control within a program.
The real hoopla surrounding threads is not about a single sequential thread. Rather, it's about the use of multiple threads running at the same time and performing different tasks in a single program. This use is illustrated in Figure 81.
Figure 81. Two threads running concurrently in a single program.
A Web browser is an example of a multithreaded application. Within a typical browser, you can scroll a page while it's downloading an applet or an image, play animation and sound concurrently, print a page in the background while you download a new page, or watch three sorting algorithms race to the finish.
Some texts call a thread a lightweight process. A thread is similar to a real process in that both have a single sequential flow of control. However, a thread is considered lightweight because it runs within the context of a full-blown program and takes advantage of the resources allocated for that program and the program's environment.
As a sequential flow of control, a thread must carve out some of its own resources within a running program. For example, a thread must have its own execution stack and program counter. The code running within the thread works only within that context. Some other texts use execution context as a synonym for thread.
Thread programming can be tricky, so if you think you might need to implement threads, consider using high-level thread API. For example, if your program must perform a task repeatedly, consider using the java.util.Timer class introduced in version 1.3 of the Java platform. The Timer class is also useful for performing a task after a delay. Examples of its use are in the section Using the Timer and TimerTask Classes (page 273).
If you're writing a program with a graphical user interface (GUI), you might want to use the javax.swing.Timer class (added in version 1.2) instead of java.util.Timer. Another utility class, SwingWorker, helps you with another common job: performing a task in a background thread, optionally updating the GUI when the task completes. You can find information about both the Swing Timer class and the SwingWorker class in the section Threads and Swing (page 378) in Chapter 10.
Basic support for threads in all versions of the Java platform is in the class java.lang.Thread.  It provides a thread API and provides all the generic behavior for threads.  These behaviors include starting, sleeping, running, yielding, and having a priority. To implement a thread using the Thread class, you need to provide it with a run method that performs the thread's task. The section Customizing a Thread's run Method (page 277) tells you how to do this.
 The actual implementation of concurrent operation is provided by a system-specific implementation. For most programming needs, the underlying implementation doesn't matter.
The first section in this chapter discusses practical aspects of using timers to implement threads. If you're using version 1.3 or a compatible release and want to put a thread in your program, the first section might be all you need. Subsequent sections go on to discuss the low-level thread API and explain threads through examples that use that API.