众所周知在Thread类的API中有一个停止线程的方法stop()，但是它是不安全的，我们可以看一下Oracle的官方API中是怎样解释这个方法的：
thread1.png
我们可以看到从Java1.2版本开始这个方法就被废弃了~
废弃的原因是：如果调用stop()方法去停止一个线程，会去释放该线程所持有的全部锁，这样就会导致被释放锁保护的对象们进入一个不一致的状态，这种状态也可以被称为损坏状态。当线程对被损坏状态的对象进行操作时，可能会产生意想不到的严重后果，并且难以发现。
举个栗子：
有一块共享内存区域，线程1和线程2都需要访问。线程1首先访问了这块内存，并且添加了锁。线程2这时候也想访问这块内存，但由于线程1持有着锁，所以线程2只能阻塞等待。但就在这个时候我们调用了线程1的stop()方法，会发生什么？
线程1立刻释放了内存锁，线程2立刻获取了内存锁。如果线程1原来在写数据只写了一半，也没有机会写了，也根本没时间进行清理了。这时候线程2拿到CPU的时间片开始读内存状态，结果发现内存状态是异常的，读到了莫名其妙的数。因为线程1刚才还没有来得及清理就挂了，留下了烂摊子给线程2，这时候如果线程2处理不来这个烂摊子，就可能会Crash了。
这样的操作是非常危险的，也正是因为这样的原因，基本上不管是什么语言，在线程这块都把它们直接停止线程的方法废弃掉了。
上面巴拉巴拉说了一堆，那么到底应该怎样去停止一个线程呢？
线程这个东西呢，其实是任务执行的一个设计。也即是说线程和任务是一种强绑定的关系，任务执行完了，线程也就结束了。所以线程的执行模式就是一个协作的任务执行模式。既然线程不能直接被停止，那么我们可以让任务结束，线程自然也就停止了。
也就是说如果我们想要停止某个线程，一定需要有个前提：目标线程应当具有处理中断线程的能力。
具体做法：
- boolean标志位
- Interrupt原生支持
- boolean标志位退出法：
public class ThreadFlagTest {
public static void main(String[] args) {
FlagThread flagThread = new FlagThread();
flagThread.start();
flagThread.cancel();
}
public static class FlagThread extends Thread {
private volatile boolean isCancelled;
public void run() {
while (!isCancelled) {
//do something
}
}
public void cancel() {
isCancelled = true;
}
}
}
代码非常简单，我就不过多解释了，唯一需要注意的是需要给boolean标志位加上volatile关键字，因为isCancelled存在线程间可见性的问题。
- Interrupt的原生支持：
-
void interrupt()
如果线程处于被阻塞状态（例如处于 sleep, wait, join 等状态），那么线程将立即退出被阻塞状态，并抛出一个 InterruptedException 异常
如果线程处于正常活动状态，那么会将该线程的中断标志设置为 true。被设置中断标志的线程将继续正常运行，不受影响。 -
static boolean interrupted()
测试当前线程（正在执行这一命令的线程）是否被中断。这一调用会将当前线程的中断状态重置为 false -
boolean isInterrupted()
测试线程是否被终止。不像静态的中断方法，这一调用不改变线程的中断状态
我们需要知道的是interrupt() 方法并不能真正的中断线程，需要被调用的线程自己进行配合才行，可以在调用阻塞方法时正确处理 InterruptedException 异常（例如，catch 异常后就结束线程）
public class ThreadInterruptTest {
public static void main(String[] args) {
InterruptThread interruptThread = new InterruptThread();
interruptThread.start();
try {
Thread.sleep(2000);
} catch (InterruptedException e) {
e.printStackTrace();
}
interruptThread.interrupt();//中断通知
}
//目标线程
static class InterruptThread extends Thread {
@Override
public void run() {
super.run();
try {
Thread.sleep(5000);
System.out.println("Done~~~~");
} catch (InterruptedException e) {
//这里可以进行线程中断后的清理工作
System.out.println("Interrupt~~~~");
Thread.currentThread().interrupt();
System.out.println(Thread.currentThread().isInterrupted());
}
}
}
在上面的这个例子里面，最终的执行结果是：
输出“Interrupt~~~”这行文字；
并没有输出“Done~~~”这行文字；
说明当我们在主线程中调用InterruptThread线程的interrupt()方法后，InterruptThread线程就被中断了。
但是有一点需要注意，我们来看一下Thread类的API文档：
thread2.png
Thread.sleep 这个阻塞方法，接收到中断请求，会抛出 InterruptedException，让上层代码处理。这时，可以什么都不做，结果就是中断标记会被重新设置为 false！看 Thread.sleep方法的注释，也强调了这点。
在接收到中断请求时，标准做法是执行 Thread.currentThread().interrupt() 恢复中断，让线程退出。
所以上面的例子里面我们的代码执行后打印的中断标记是true。
讲到这里肯定有同学会好奇，interrupt()方法底层到底是如何去实现的呢？现在让我们走进interrupt()方法的native世界去看一下。
我们首先去解决一个疑问就是为什么线程的静态方法interrupted()会把线程的中断状态重置为false，而isInterrupted()不会改变中断状态？
Thread.java类的相关源码：
public static boolean interrupted() {
return currentThread().isInterrupted(true);
}
public boolean isInterrupted() {
return isInterrupted(false);
}
private native boolean isInterrupted(boolean ClearInterrupted);
native层源码：
bool os::is_interrupted(Thread* thread, bool clear_interrupted) {
assert(Thread::current() == thread || Threads_lock->owned_by_self(),
"possibility of dangling Thread pointer");
OSThread* osthread = thread->osthread();
bool interrupted = osthread->interrupted();
if (interrupted && clear_interrupted) {
osthread->set_interrupted(false);
// consider thread->_SleepEvent->reset() ... optional optimization
}
return interrupted;
}
看了源码立刻恍然大悟，原来就是只有当传递的参数ClearInterrupted为true的时候才会重置中断状态为false，毫无神秘感可言。
接下来我们重点分析下Thread类的interrupt()方法：
native层源码：
void os::interrupt(Thread* thread) {
assert(Thread::current() == thread || Threads_lock->owned_by_self(),
"possibility of dangling Thread pointer");
//获取本地线程对象
OSThread* osthread = thread->osthread();
if (!osthread->interrupted()) {
osthread->set_interrupted(true);//设置中断状态为true
// More than one thread can get here with the same value of osthread,
// resulting in multiple notifications. We do, however, want the store
// to interrupted() to be visible to other threads before we execute unpark().
//使得interrupted状态对其他线程立即可见
OrderAccess::fence();
//_SleepEvent相当于Thread.sleep，表示如果线程调用了sleep方法，则通过unpark唤醒
ParkEvent * const slp = thread->_SleepEvent ;
if (slp != NULL) slp->unpark() ;
}
// For JSR166. Unpark even if interrupt status already was set
if (thread->is_Java_thread())
((JavaThread*)thread)->parker()->unpark();
//_ParkEvent用于synchronized同步块和Object.wait()，这里相当于也是通过unpark进行唤醒
ParkEvent * ev = thread->_ParkEvent ;
if (ev != NULL) ev->unpark() ;
}
JVM_ENTRY(void, JVM_Sleep(JNIEnv* env, jclass threadClass, jlong millis))
JVMWrapper("JVM_Sleep");
if (millis < 0) {
THROW_MSG(vmSymbols::java_lang_IllegalArgumentException(), "timeout value is negative");
}
//判断并清除线程中断状态，如果中断状态为true,抛出中断异常
if (Thread::is_interrupted (THREAD, true) && !HAS_PENDING_EXCEPTION) {
THROW_MSG(vmSymbols::java_lang_InterruptedException(), "sleep interrupted");
}
// Save current thread state and restore it at the end of this block.
// And set new thread state to SLEEPING.
JavaThreadSleepState jtss(thread);
...
上面源码里面重要的代码行逻辑我都加上中文注释了，thread.interrupt()方法就是设置interrupted状态为true、并且通过ParkEvent的unpark方法来唤醒线程。
同时通过源码我们也知道了当中断状态为true的时候，Object.wait、Thread.sleep、Thread.join会抛出InterruptedException，这里我们只看了sleep()的native层源码。
最后我们通过一张图来总结下吧：
thread3.png
结论就是如果能用boolean 标志位的情况，尽量使用boolean标志位，毕竟调用jni是有性能开销的。
网友评论