Quick Review: Chapters 55 to 61 (Threads)

This is going to be the last quick recap chapter in this SCJP Series. This will cover the important points about Threads.

Defining, Instantiating, and Starting Threads

* Threads can be created by extending Thread and overriding the public void run() method.

* Thread objects can also be created by calling the Thread constructor that takes a Runnable argument. The Runnable object is said to be the target of the thread.

* You can call start() on a Thread object only once. If start() is called more than once on a Thread object, it will throw a RuntimeException.

* It is legal to create many Thread objects using the same Runnable object as the target.

* When a Thread object is created, it does not become a thread of execution until its start() method is invoked. When a Thread object exists but hasn’t been started, it is in the new state and is not considered alive.

Transitioning Between Thread States

* Once a new thread is started, it will always enter the runnable state.

* The thread scheduler can move a thread back and forth between the runnable state and the running state.

* For a typical single-processor machine, only one thread can be running at a time, although many threads may be in the runnable state.

* There is no guarantee that the order in which threads were started determines the order in which they’ll run.

* There’s no guarantee that threads will take turns in any fair way. It’s up to the thread scheduler, as determined by the particular virtual machine implementation. If you want a guarantee that your threads will take turns regardless of the underlying JVM, you can use the sleep() method. This prevents one thread from hogging the running process while another thread starves.

* A running thread may enter a blocked/waiting state by a wait(), sleep(), or join() call.

* A running thread may enter a blocked/waiting state because it can’t acquire the lock for a synchronized block of code.

* When the sleep or wait is over, or an object’s lock becomes available, the thread can only reenter the runnable state. It will go directly from waiting to running (well, for all practical purposes anyway).

* A dead thread cannot be started again.

Sleep, Yield, and Join

* Sleeping is used to delay execution for a period of time, and no locks are released when a thread goes to sleep.

* A sleeping thread is guaranteed to sleep for at least the time specified in the argument to the sleep() method (unless it’s interrupted), but there is no guarantee as to when the newly awakened thread will actually return to running.

* The sleep() method is a static method that sleeps the currently executing thread’s state. One thread cannot tell another thread to sleep.

* The setPriority() method is used on Thread objects to give threads a priority of between 1 (low) and 10 (high), although priorities are not guaranteed, and not all JVMs recognize 10 distinct priority levels—some levels may be treated as effectively equal.

* If not explicitly set, a thread’s priority will have the same priority as the priority of the thread that created it.

* The yield() method may cause a running thread to back out if there are runnable threads of the same priority. There is no guarantee that this will happen, and there is no guarantee that when the thread backs out there will be a different thread selected to run. A thread might yield and then immediately reenter the running state.

* The closest thing to a guarantee is that at any given time, when a thread is running it will usually not have a lower priority than any thread in the runnable state. If a low-priority thread is running when a high-priority thread enters runnable, the JVM will usually preempt the running low-priority thread and put the high-priority thread in.

* When one thread calls the join() method of another thread, the currently running thread will wait until the thread it joins with has completed. Think of the join() method as saying, “Hey thread, I want to join on to your end. Let me know when you’re done, so I can enter the runnable state.”

Synchronization

* synchronized methods prevent more than one thread from accessing an object’s critical method code simultaneously.

* You can use the synchronized keyword as a method modifier, or to start a synchronized block of code.

* To synchronize a block of code, you must specify an argument that is the object whose lock you want to synchronize on.

* While only one thread can be accessing synchronized code of a particular instance, multiple threads can still access the same object’s unsynchronized code.

* When a thread goes to sleep, its locks will be unavailable to other threads.

* static methods can be synchronized, using the lock from the java.lang.Class instance representing that class.

Thread Communication

* The wait() method lets a thread say, “I got nothing to do, so put me in your waiting pool and notify me when something happens that I care about.”

* The notify() method is used to send a signal to one and only one of the threads that are waiting in that same object’s waiting pool.

* The notify() method can NOT specify which waiting thread to notify.

* The method notifyAll() works in the same way as notify(), only it sends the signal to all of the threads waiting on the object.

* All three methods—wait(), notify(), and notifyAll()—must be called from within a synchronized context! A thread invokes wait() or notify() on a particular object, and the thread must currently hold the lock on that object.

Deadlocks

* Deadlocking is when thread execution grinds to a halt because the code is waiting for locks to be removed from objects.

* Deadlocking can occur when a locked object attempts to access another locked object that is trying to access the first locked object. In other words, both threads are waiting for each other’s locks to be released; therefore, the locks will never be released!


Previous Chapter: Chapter 61 - Thread Interaction

Next Chapter: Self Test - Chapters 55 to 61

Chapter 58: Preventing Thread Execution

In the previous chapters we saw what a thread is and how to run or execute them. But, there is one more important thing that we need to know. Let me give a clue. Lets say you have multiple threads and you want one of your threads to finish before the others. It would definitely be sweet to alter the way our threads run and finish, wouldn't it? That is exactly what we are going to learn in this chapter.

Before we begin, I repeat something I said earlier.
WE CANNOT AND I MEAN CANNOT GUARANTEE THE WAY THREADS EXECUTE IN OUR PROGRAM.

We can only request the scheduler to run the threads the way we want but that by no means is guarantee. Think of the scheduler as your hard headed boss who ends up irritating you even if you try out of your way to please him. Though it's a bad analogy, that's exactly how the scheduler works. Stubborn and all by itself and not listening to anyone.

Lets get started!!!

Stopping a Thread from Executing

A thread that’s been stopped usually means a thread that’s moved to the dead state. But you should be able to recognize when a thread will get kicked out of running but not be sent back to either runnable or dead.

For the purpose of the exam, we aren’t concerned with a thread blocking on I/O (say, waiting for something to arrive from an input stream from the server). We are concerned with the following:
• Sleeping
• Waiting
• Blocked because it needs an object’s lock

Sleeping

The sleep() method is a static method of class Thread. You use it in your code to “slow a thread down” by forcing it to go into a sleep mode before coming back to runnable. When a thread sleeps, it drifts off somewhere and doesn’t return to runnable until it wakes up.

So why would you want a thread to sleep? Well, you might think the thread is moving too quickly through its code. Or you might need to force your threads to take turns, since reasonable turn-taking isn’t guaranteed in the Java specification.

You do this by invoking the static Thread.sleep() method, giving it a time in milliseconds as follows:
try {
Thread.sleep(5*1000); // Sleep for 5 seconds
} catch (InterruptedException ex) { }

Notice that the sleep() method can throw a checked InterruptedException (you’ll usually know if that is a possibility, since another thread has to explicitly do the interrupting), so you must acknowledge the exception with a handle or declare. Typically, you wrap calls to sleep() in a try/catch, as in the preceding code.

Let’s modify our Rocky, Cena, Triple H code by using sleep() to try to force the threads to alternate rather than letting one thread dominate for any period of time. Where do you think the sleep() method should go?

class NameRunnable implements Runnable {

public void run() {

for (int x = 1; x < 4; x++) {

System.out.println("Run by "

+ Thread.currentThread().getName());

try {

Thread.sleep(1000);

} catch (InterruptedException ex) { }

}

}

}


public class SleepExample {

public static void main (String [] args) {


// Make one Runnable

NameRunnable nr = new NameRunnable();


Thread one = new Thread(nr);

one.setName("Rocky");

Thread two = new Thread(nr);

two.setName("Cena");

Thread three = new Thread(nr);

three.setName("Triple H");


one.start();

two.start();

three.start();

}

}

Running this code shows Rocky, Cena, and Triple H alternating nicely:

% java SleepExample

Run by Rocky

Run by Cena

Run by Triple H

Run by Rocky

Run by Cena

Run by Triple H

Run by Rocky

Run by Cena

Run by Triple H


Just keep in mind that the behavior in the preceding output is still not guaranteed. You can’t be certain how long a thread will actually run before it gets put to sleep, so you can’t know with certainty that only one of the three threads will be in the runnable state when the running thread goes to sleep. In other words, if there are two threads awake and in the runnable pool, you can’t know with certainty that the least recently used thread will be the one selected to run. Still, using sleep() is the best way to help all threads get a chance to run! Or at least to guarantee that one thread doesn’t get in and stay until it’s done. When a thread encounters a sleep call, it must go to sleep for at least the specified number of milliseconds (unless it is interrupted before its wake-up time, in which case it immediately throws the InterruptedException).

Exam Tip: Just because a thread’s sleep() expires, and it wakes up, does not mean it will return to running! Remember, when a thread wakes up, it simply goes back to the runnable state. So the time specified in sleep() is the minimum duration in which the thread won’t run, but it is not the exact duration in which the thread won’t run. So you can’t, for example, rely on the sleep() method to give you a perfectly accurate timer. Although in many applications using sleep() as a timer is certainly good enough, you must know that a sleep() time is not a guarantee that the thread will start running again as soon as the time expires and the thread wakes

Remember that sleep() is a static method, so don’t be fooled into thinking that one thread can put another thread to sleep. You can put sleep() code anywhere, since all code is being run by some thread. When the executing code (meaning the currently running thread’s code) hits a sleep() call, it puts the currently running thread to sleep.

Previous Chapter: Chapter 57 - Thread States & Transitions

Next Chapter: Chapter 59 - Thread Priorities, yield and join