Why Are Thread.suspend and Thread.resume Deprecated?

Thread.suspend is inherently deadlock prone. If the target thread holds a lock on the monitor protecting a critical system resource when it is suspended, no thread can access this resource until the target thread is resumed. If the thread that would resume the target thread attempts to lock this monitor prior to calling resume, deadlock results. Such deadlocks typically manifest themselves as "frozen" processes.

What Should I Use Instead of Thread.suspend and Thread.resume?

As with Thread.stop, the prudent approach is to have the "target thread" poll a variable indicating the desired state of the thread (active or suspended). When the desired state is suspended, the thread waits, using Object.wait. When the thread is resumed, the target thread is notified, using Object.notify.

For example, suppose that your applet contains the following mousePressed event handler, which toggles the state of a thread called blinker:

private boolean threadSuspended; 

Public void mousePressed(MouseEvent e) { 
 e.consume(); 

 if (threadSuspended) 
 blinker.resume(); 
 else 
 blinker.suspend(); // DEADLOCK-PRONE! 
 threadSuspended = !threadSuspended; 
} 

You can avoid the use of Thread.suspend and Thread.resume by replacing the preceding event handler with:

public synchronized void mousePressed(MouseEvent e) { 
 e.consume(); 

 threadSuspended = !threadSuspended; 

 if (!threadSuspended) 
 notify(); 
} 

You can also add the following code to the run loop:

synchronized(this) { 
 while (threadSuspended) 
 wait(); 
} 

The wait method throws the InterruptedException, so it must be inside a try-catch clause. It's fine to put it in the same clause as the sleep. The check should follow (rather than precede) the sleep so the window is immediately repainted when the thread is "resumed." The resulting run method follows:

public void run() { 
 while (true) { 
 try { 
 Thread.currentThread().sleep(interval); 

 synchronized(this) { 
 while (threadSuspended) 
 wait(); 
 } 
 } catch (InterruptedException e){ 
 } 
 repaint(); 
 } 
} 

Note that the notify in the mousePressed method and the wait in the run method are inside synchronized blocks. This is required by the language and ensures that wait and notify are properly serialized. In practical terms, this eliminates race conditions that could cause the "suspended" thread to miss a notify and to remain suspended indefinitely.

Although the cost of synchronization in Java is decreasing as the platform matures, it will never be free. A simple trick can be used to remove the synchronization that we've added to each iteration of the "run loop." The synchronized block that was added is replaced by a slightly more complex piece of code that enters a synchronized block only if the thread has been suspended:

if (threadSuspended) { 
 synchronized(this) { 
 while (threadSuspended) 
 wait(); 
 } 
} 

The resulting run method is:

public void run() { 
 while (true) { 
 try { 
 Thread.currentThread().sleep(interval); 

 if (threadSuspended) { 
 synchronized(this) { 
 while (threadSuspended) 
 wait(); 
 } 
 } 
 } catch (InterruptedException e){ 
 } 
 repaint(); 
 } 
} 

In the absence of explicit synchronization, threadSuspended must be made volatile to ensure prompt communication of the suspend request.

Can I Combine the Two Techniques to Produce a Thread That May Be Safely "Stopped" or "Suspended"?

Yes, it's reasonably straightforward. The one subtlety is that the target thread may already be suspended at the time that another thread tries to stop it. If the stop method merely sets the state variable (blinker) to null, the target thread will remain suspended (waiting on the monitor) rather than exiting gracefully, as it should. If the applet is restarted, multiple threads could end up waiting on the monitor at the same time, resulting in erratic behavior.

To rectify this situation, the stop method must ensure that the target thread resumes immediately if it is suspended. Once the target thread resumes, it must recognize immediately that it has been stopped and exit gracefully. Here's how the resulting run and stop methods look:

public void run() { 
 Thread thisThread = Thread.currentThread(); 
 while (blinker == thisThread) { 
 try { 
 thisThread.sleep(interval); 

 synchronized(this) { 
 while (threadSuspended && blinker==thisThread) 
 wait(); 
 } 
 } catch (InterruptedException e){ 
 } 
 repaint(); 
 } 
} 

public synchronized void stop() { 
 blinker = null; 
 notify(); 
} 

If the stop method calls Thread.interrupt, as described earlier, it needn't call notify as well, but it still must be synchronized. This ensures that the target thread won't miss an interrupt due to a race condition.