不優雅的suspend

import java.util.concurrent.TimeUnit;public class SuspendTest {static Object lock = new Object();@SuppressWarnings("deprecation")public static void main(String[] args) {Suspend s1 = new Suspend();Suspend s2 = new Suspend();s1.start();try {TimeUnit.SECONDS.sleep(1);} catch (InterruptedException e) {e.printStackTrace();}s1.resume();s2.start();s2.resume();}static class Suspend extends Thread{@SuppressWarnings("deprecation")@Overridepublic void run() {synchronized(lock){try {TimeUnit.MILLISECONDS.sleep(500);} catch (InterruptedException e) {e.printStackTrace();}Thread.currentThread().suspend();}}}}

上面的例子的一般情況s1是可以執行完成的，是因為先執行了suspend，后執行resume，而s2就被掛死了，因為s2先執行了resume，后執行的suspend。

下面是掛死之后上的堆棧信息：

"Thread-1" prio=6 tid=0x000000000c7bf000 nid=0x15a4 runnable [0x000000000d21e000]java.lang.Thread.State: RUNNABLEat java.lang.Thread.suspend0(Native Method)at java.lang.Thread.suspend(Unknown Source)at cn.d.concurrent.SuspendTest$Suspend.run(SuspendTest.java:34)- locked <0x00000007d5e99f78> (a java.lang.Object)

從上面的堆棧信息分析可以知道被掛死的s2的線程狀態是RUNNABLE，并且沒有釋放它鎖占用的鎖0x00000007d5e99f78。

上面被掛死的原因有一部分是刻意為之，但是在多線程調度不確定的情況下不刻意，使用suspend也很容易找出掛死，因為它的確有一些問題，所以才會被廢棄。

suspend的代替方法

需要用到suspend的地方基本都刻意替換為wait，notify模式，如果你想要簡單實現，刻意考慮JUC提供的工具LockSupport。下面的例子使用LockSupport工具替換上面例子的suspend和resume方法。

import java.util.concurrent.TimeUnit;
import java.util.concurrent.locks.LockSupport;public class SuspendTest2 {static Object lock = new Object();public static void main(String[] args) {Suspend s1 = new Suspend();Suspend s2 = new Suspend();s1.start();try {TimeUnit.SECONDS.sleep(1);} catch (InterruptedException e) {e.printStackTrace();}LockSupport.unpark(s1);s2.start();LockSupport.unpark(s2);}static class Suspend extends Thread{@Overridepublic void run() {synchronized(lock){try {TimeUnit.MILLISECONDS.sleep(500);} catch (InterruptedException e) {e.printStackTrace();}LockSupport.park();}}}}

使用LockSupport工具的靜態方法輕松加愉快的就解決了suspend和resume帶來的問題。

總結

1. 盡量不要使用suspend來掛起線程
2. 考慮使用wait,notify模式來代替suspend
3. 考慮使用JUC的LockSupport來代替suspend