Why are stop/suspend/resume deprecated?

• Thread.stop() – forcibly throws ThreadDeath at an arbitrary point, releasing all monitors and leaving shared objects in a half-updated state.
• Thread.suspend() – freezes a thread without releasing its locks, so any thread needing those locks deadlocks.
• Thread.resume() – deprecated because it only pairs with the unusable suspend().
• Correct replacement – cooperative interruption with interrupt(), checking isInterrupted() at safe points, and handling InterruptedException.
• For pausing – use Object.wait() on a condition, which releases the lock while paused.

Why is Thread.stop() dangerous?

It throws ThreadDeath at whatever instruction the thread is executing. If the thread is between debit and credit, stop fires after the debit and before the credit. As the thread unwinds it releases all monitors, so other threads see the corrupted state as valid.

// The danger: stop fires between these two lines
synchronized (ledger) {
    rajesh.debit(amount);   // done
    // ← ThreadDeath thrown here
    priya.credit(amount);   // never executed
}   // lock released with inconsistent state

Why is Thread.suspend() dangerous?

It pauses the thread immediately but does not release any locks it holds. If the suspended thread holds the ledger lock and the resuming thread needs it, deadlock results.

// Thread A holds the lock and is suspended
synchronized (ledger) {
    // ← suspended here, lock NOT released
}
// Thread B tries to acquire the same lock to call resume
synchronized (ledger) {  // DEADLOCK: lock held by frozen Thread A
    threadA.resume();
}

What is the correct replacement for stop?

Cooperative interruption. The controller calls interrupt(), the worker checks the flag only between complete operations.

package com.bank.worker;

public class TransferWorker implements Runnable {

    @Override
    public void run() {
        while (!Thread.currentThread().isInterrupted()) {
            doOneTransfer();  // interruption can only take effect between transfers
        }
        System.out.println("Stopped between transfers, ledger is consistent.");
    }
}

What is the correct replacement for suspend/resume?

A guarded wait on a condition that releases the lock while paused.

package com.bank.worker;

public class PausableWorker implements Runnable {

    private volatile boolean paused = false;
    private final Object pauseLock = new Object();

    public void pause() { paused = true; }

    public void resumeWork() {
        synchronized (pauseLock) {
            paused = false;
            pauseLock.notifyAll();
        }
    }

    @Override
    public void run() {
        while (!Thread.currentThread().isInterrupted()) {
            synchronized (pauseLock) {
                while (paused) {
                    try {
                        pauseLock.wait();  // releases the lock while paused
                    } catch (InterruptedException e) {
                        Thread.currentThread().interrupt();
                        return;
                    }
                }
            }
            doOneTransfer();
        }
    }
}

What are the key differences?

| Method | Problem | Safe Replacement |
|--------|---------|------------------|
| stop() | Inconsistent state, released locks | interrupt() + check at safe point |
| suspend() | Deadlock: holds locks while frozen | wait() releases lock while paused |
| resume() | Only pairs with broken suspend() | notifyAll() |

What should a senior engineer know?

ThreadDeath is a Throwable that can be caught, leading to even weirder behaviour where a thread refuses to die. Forced control over another thread is never safe; cooperative signalling is the only correct approach.

What are common interview follow-up questions?

• Can ThreadDeath be caught to prevent stopping?
• How does ExecutorService.shutdownNow() use interrupt instead of stop?
• What happens if you call stop on a thread that has already exited?