原文：《Java Thread Primitive Deprecation》
为什么 Thread.stop 被废弃了？
Thread.stop 不安全。
-
Stop 一个线程会导致它释放所持有的锁（monitor）。（ThreadDeatch 抛出后会释放 monitor 的锁。）
-
这可能会导致之前被 monitor 保护的对象处于 不一致的状态，并被其它线程看到。也就是说，这些 对象被损坏 了。
-
线程操作被损坏的对象会导致不可预料的行为。
-
这些行为可能很微妙难以被察觉，也可能非常明显。与其它异常不同的是，ThreadDeatch 异常会悄悄地杀掉线程，用户感知不到程序已被损坏。这种程序损坏可能在错误发生后任何时候显现，甚至是几小时、几天。
为什么 我不能捕获 ThreadDeath 异常，并修复损坏的对象？
理论上，也许是可以的。但这会使编写多线程任务代码非常复杂，几乎不可能实现。因为：
-
线程可能在任何地方抛出 ThreadDeatch 异常。必须非常详尽地分析所有同步方法和代码块，来处理这些情况。
-
线程在处理第一个 ThreadDeatch 异常期间（catch 或 finally），可能会再次抛出 ThreadDeatch 异常（嵌套异常）。你的异常处理操作必须不断重复，直到成功。这会导致代码非常复杂。
所以这种方案是不切实际的！
Thread.stop(Throwable) 如何？
上述提到的所有问题它都有。此外，此方法一般用于生成一个 目标线程未准备好处理的 异常（包括目标线程不可能抛出的一些 受检异常）。如，以下示例中方法的行为等价于 throw 操作，但它规避了编译器对受检异常的检查保障 —— 调用方法必须声明所有可能抛出的受检异常。
（即，这是一种不安全的错误代码模式。）
Java代码
-
void sneakyThrow(Throwable t) {
-
Thread.currentThread().stop(t);
-
}
我该用什么方法替代 Thread.stop ？
绝大多数使用 stop 的代码应改为：
-
修改一些标记性变量的值 以指示目标线程应停止运行；
-
目标线程应定期检查这些标记变量；当检测到变量值指示应停止运行时，再有条不紊地从运行方法中自行返回。
-
为了保证“停止请求”通信正确，此标记变量必须是 volatile 或 对其访问操作进行同步。
示例：假设你的程序中有以下三个方法 start、stop、run。
Java代码
-
private Thread blinker;
-
-
void start() {
-
blinker = new Thread(this);
-
blinker.start();
-
}
-
-
void stop() {
-
blinker.stop(); // 不安全的操作
-
}
-
-
void run() {
-
while (true) {
-
try {
-
Thread.sleep(interval);
-
} catch (InterruptedException e) {
-
}
-
repaint();
-
}
-
}
那么你可以改造自己的 stop 和 run，避免使用 Thread.stop：
Java代码
-
private volatile Thread blinker;
-
-
void stop() {
-
blinker = null;
-
}
-
-
void run() {
-
Thread thisThread = Thread.currentThread;
-
while (blinker == thisThread) { // 每次迭代前先检查标记变量
-
try {
-
Thread.sleep(interval);
-
} catch (InterruptedException e) {
-
repaint();
-
}
-
}
-
}
如何终止一个等待了很长时间的线程？（如，等待输入内容很久的线程）
Thread.interrupt 方法就是用来干这事的。
可以结合上述 “基于状态信号机制” 使用：状态变化后调用此方法，以中断等待。如：
Java代码
-
void stop() {
-
Thread moribund = waiter;
-
waiter = null;
-
moribund.interrupt();
-
}
这项技术中，非常关键的一点是，如果方法捕获到中断异常，但又不想立即处理它，那就得 “再次声明” 此异常。（因为 InterruptedException 是受检异常。）
之所以说是 “再次声明” 而不是 “再次抛出”，是因为并不是所有情况下都能再次抛出此异常。
如果方法捕获了 InterruptedException 且未声明会抛出此异常，那就需要 “重新中断自己”：
Java代码
-
Thread.currentThread().interrupt();
这样就可以再次让线程抛出 InterruptedException。
如果线程没有响应 Thread.interrupt 该怎么办？
在某些情况下，你可以使用一些特定于应用程序的技巧。例，如果线程正在等待一个 socket，你可以将该 socket 关闭，从而让线程立即返回。
不幸的是，这方面真的没有通用的技术。
需要说明的是，在所有场景中，如果一个等待线程没有响应 Thread.interrupt，那么它也不会响应 Thread.stop。如，恶意的拒绝服务攻击（DoS），某些 stop/interrupt 无法正确工作的 IO操作 等。
为什么 Thread.suspend 和 Thread.resume 被废弃了？
Thread.suspend 容易引发死锁。
如果目标线程持有某项资源的锁，然后被挂起（suspend），那么在它被恢复前（resume）其它线程无法访问该资源。
此时，如果那个可以恢复目标线程的另一个线程需要 “先获取该资源的锁 - 再恢复目标线程”，那么就形成了死锁。
这种死锁通常表现为“冻结”进程。
我该用什么替代 Thread.suspend 和 Thread.resume ？
类似 Thread.stop，谨慎的做法是：
-
设置一个标记性变量来表示期望的线程状态；
-
目标线程轮询该变量；当期望状态是“挂起”时，线程通过 Object.wait 方法将自己挂起等待；
-
当期望目标线程继续运行时，通过 Object.notify 方法唤醒它。
例，你的程序中有一个事件处理方法 mousePressed 用于切换 blinker 线程的状态：
Java代码
-
boolean threadSuspended;
-
void mousePressed(MouseEvent e) {
-
e.consume();
-
-
if (threadSuspended) {
-
blinker.resume();
-
} else {
-
blinker.suspened(); // 容易引发死锁
-
}
-
-
threadSuspended = !threadSuspended;
-
}
你可以改造为如下形式：
Java代码
-
volatile boolean threadSuspended;
-
-
synchronized void mousePressed(MouseEvent e) {
-
e.consume();
-
-
threadSuspended = !threadSuspended;
-
-
if (!threadSuspended) {
-
notify();
-
}
-
}
-
-
void run() {
-
while (true) {
-
try {
-
Thread.sleep(interval);
-
-
if (threadSuspended) {
-
synchronized(this) {
-
while (threadSuspended) {
-
wait();
-
}
-
}
-
}
-
} catch (InterruptedException e) {
-
}
-
repaint();
-
}
-
}
-
run 方法就是 blinker 线程运行的内容。
-
notify 和 wait 方法都被包在 synchronized 块中，保证它们的正确的执行顺序。这样可以避免因被挂起线程遗漏 notify 信号而导致无限挂起。
-
标记变量 threadSuspended 是 volatile，以保证挂起请求的正常通信。
-
run 方法中的利用 双检锁 的形式来减少不必要的同步。
我能利用上述两个技术创建一个可以被 安全地 “stopped” 和 “suspended” 的线程吗？
可以，而且很简单。
比较微妙的是，另一个线程尝试停止目标线程时，目标线程可能已经处于挂起状态。
如果你的 stop 方法仅仅是更改 状态变量的值，那么目标线程是继续挂起（在monitor上等待），而不是期望的“优雅退出”。这会导致程序行为不稳定。
为了矫正这种状况，stop 方法必须确保目标线程能从挂起状态立即恢复。
目标线程一旦恢复，必须能立即识别出自己已被标记为“需要终止”。
实现示例：
Java代码
-
private volatile Thread blinker;
-
-
void run() {
-
Thread thisThread = Thread.currentThread();
-
while (blinker == thisThread) { // 判断是否“需要终止”
-
try {
-
Thread.sleep(interval);
-
-
synchronized(this) {
-
// 只有当 不需要终止 且 期望挂起 时才会执行 wait
-
while (threadSuspended && blinker==thisThread) {
-
wait();
-
}
-
}
-
} catch (InterruptedException e) {
-
}
-
repaint();
-
}
-
}
-
-
synchronized void stop() {
-
blinker = null; // 会被目标线程判定为“需要终止”
-
notify(); // 立即唤醒目标线程
-
}
当然，你也可以在 stop 方法中调用 Thread.interrupt 来终止目标线程，这样就不需要调用 notify。
但 interrupt 方法也必须包含到 synchronized 中，确保目标线程不会错过 interrupt 信号。
Thread.destroy 如何？
Thread.destroy 从来都没有被实现过，且已经被废弃了。如果它被实现了，那么它会像 Thread.suspend 那样容易引发死锁。（事实上，它相当于 Thread.suspend，且没有后续的 Thread.resume）
为什么 Runtime.runFinalizersOnExit 被废弃了？
Runtime.runFinalizersOnExit 不安全。
它可能会导致存活对象被finalize，且同时有其它线程正在操作这些对象，导致不稳定的行为或死锁。
虽然可以通过 Class 实现来避免存活对象被finalize，但最大多数程序员都不会怎么设计。他们都会假设对象被finalize时肯定已经死了。
而且此方法是设置 JVM 的一个标记变量，它会影响到所有类。让所有类的设计者都增加避免过早被finalize的防御肯定是不切实际的。
