Why Java’s Thread.stop and Thread.suspend Were Deprecated and What to Use Instead
This article explains why the historically used Thread.stop and Thread.suspend methods were deprecated in Java, illustrates their unsafe behavior with code examples, and demonstrates safer alternatives such as flag-controlled loops and the interrupt mechanism for graceful thread termination.
We know methods like Thread.stop and Thread.suspend are marked @Deprecated in recent Java versions. This article explores why they were introduced, why they were later removed, and how to replace them with safer techniques.
1. The End of Thread.stop
The source comment for stop reads: Forces the thread to stop executing. The Javadoc explains that stopping a thread is inherently unsafe because it releases all monitors held by the thread, potentially leaving shared objects in an inconsistent state.
This method is inherently unsafe. Stopping a thread with Thread.stop causes it to unlock all of the monitors that it has locked ... Many uses of stop should be replaced by code that simply modifies some variable to indicate that the target thread should stop running. The target thread should check this variable regularly, and return from its run method in an orderly fashion if the variable indicates that it is to stop running. If the target thread waits for long periods (on a condition variable, for example), the interrupt method should be used to interrupt the wait.
Key points:
Thread.stop is fundamentally unsafe.
Calling Thread.stop releases all locks held by the thread, causing other threads to see partially updated state.
Example demonstrating the problem:
public static void main(String[] args) throws InterruptedException {
Object o1 = new Object();
Object o2 = new Object();
Thread t1 = new Thread(() -> {
synchronized (o1) {
synchronized (o2) {
try {
System.out.println("t1获取到锁");
Thread.sleep(5000);
System.out.println("t1结束");
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
});
t1.start();
Thread.sleep(1000);
Thread t2 = new Thread(() -> {
synchronized (o1) {
synchronized (o2) {
try {
System.out.println("t2获取到锁");
Thread.sleep(5000);
System.out.println("t2结束");
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
});
t2.start();
t1.stop();
}When t1.stop() is invoked, t1 releases its locks prematurely, allowing t2 to acquire them while t1 never finishes its post‑sleep logic. This can leave resources unreleased and cause inconsistent program state.
2. Safer Ways to End a Thread
Two recommended approaches are:
2.1 Use a shared flag
volatile static boolean flag = false;
public static void main(String[] args) throws InterruptedException {
Object o1 = new Object();
Thread t1 = new Thread(() -> {
synchronized (o1) {
try {
System.out.println("t1获取到锁");
while (!flag) {
Thread.sleep(5000); // business logic
}
System.out.println("t1结束");
} catch (InterruptedException e) {
e.printStackTrace();
}
}
});
t1.start();
Thread.sleep(1000);
Thread t2 = new Thread(() -> {
synchronized (o1) {
try {
System.out.println("t2获取到锁");
Thread.sleep(5000); // business logic
System.out.println("t2结束");
} catch (InterruptedException e) {
e.printStackTrace();
}
}
});
t2.start();
flag = true; // signal t1 to finish
}The thread checks the flag and exits gracefully, allowing any finally blocks or resource cleanup to run.
2.2 Use interrupt()
public static void main(String[] args) throws InterruptedException {
Object o1 = new Object();
Thread t1 = new Thread(() -> {
synchronized (o1) {
System.out.println("t1获取到锁");
while (!Thread.currentThread().isInterrupted()) {
for (int i = 0; i < 100; i++) {
if (i == 50) System.out.println();
System.out.print(i + " ");
}
System.out.println();
}
System.out.println("t1结束");
}
});
t1.start();
Thread t2 = new Thread(() -> {
synchronized (o1) {
try {
System.out.println("t2获取到锁");
Thread.sleep(5000); // business logic
System.out.println("t2结束");
} catch (InterruptedException e) {
e.printStackTrace();
}
}
});
t2.start();
t1.interrupt(); // request interruption
}The interrupt flag is checked inside the loop; when set, the thread finishes its current work and exits, releasing locks in an orderly fashion.
3. The End of Thread.suspend
Thread.suspendpauses a thread without releasing the locks it holds, which can easily cause deadlocks. The Javadoc states:
This method has been deprecated, as it 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.
Key observations:
suspend is naturally deadlock‑prone.
Locks held by a suspended thread are not released.
If an exception occurs before resume, the lock may never be released, leading to a permanent deadlock.
Demonstration of a deadlock caused by suspend/resume:
public static void main(String[] args) throws InterruptedException {
Object o1 = new Object();
Object o2 = new Object();
Thread t1 = new Thread(() -> {
synchronized (o1) {
System.out.println("t1获取到o1锁开始执行");
try { Thread.sleep(5000); } catch (InterruptedException e) { e.printStackTrace(); }
System.out.println("t1执行结束");
}
});
t1.start();
Thread t2 = new Thread(() -> {
synchronized (o2) {
System.out.println("t2获取到o2开始执行");
try { Thread.sleep(2000); } catch (InterruptedException e) { e.printStackTrace(); }
synchronized (o1) {
System.out.println("t2获取到o1锁开始继续执行");
}
System.out.println("t2执行结束");
}
});
t2.start();
Thread.sleep(1000);
t1.suspend(); // thread t1 holds o1
int i = 1/0; // simulate unexpected exception
t1.resume();
}Because t1 remains suspended while holding o1, t2 cannot acquire the lock and the program deadlocks.
In summary, stop and suspend were deprecated due to their unsafe behavior and potential to cause deadlocks. Modern Java code should use flag‑controlled termination or the interrupt mechanism to stop threads gracefully.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Programmer DD
A tinkering programmer and author of "Spring Cloud Microservices in Action"
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
