Java中的线程Thread方法之---stop()

搞过Java线程的人都知道，stop这个方法是臭名昭著了，早就被弃用了，但是现在任然有很多钟情与他的人，永远都放不下他，因为从他的字面意思上我们可以知道他貌似可以停止一个线程，这个需求是每个搞线程开发的人都想要的操作，但是他并非是真正意义上的停止线程，而且停止线程还会引来一些其他的麻烦事，下面就来详细的介绍一下这个方法的历史：

从SUN的官方文档可以得知，调用Thread.stop()方法是不安全的，这是因为当调用Thread.stop()方法时，会发生下面两件事：

1. 即刻抛出ThreadDeath异常，在线程的run()方法内，任何一点都有可能抛出ThreadDeath Error，包括在catch或finally语句中。

2. 会释放该线程所持有的所有的锁，而这种释放是不可控制的，非预期的。

当线程抛出ThreadDeath异常时，会导致该线程的run()方法突然返回来达到停止该线程的目的。ThreadDetath异常可以在该线程run()方法的任意一个执行点抛出。但是，线程的stop()方法一经调用线程的run()方法就会即刻返回吗？

 packagecom.threadstop.demo;

 publicclassThreadStopTest{
 publicstaticvoidmain(String[]args){
 try{
 Threadt=newThread(){
 //对于方法进行了同步操作，锁对象就是线程本身
 publicsynchronizedvoidrun(){
 try{
 longstart=System.currentTimeMillis();
 //开始计数
 for(inti=0;i<100000;i++)
 System.out.println("runing.."+i);
 System.out.println((System.currentTimeMillis()-start)+"ms");
 }catch(Throwableex){
 System.out.println("Caughtinrun:"+ex);
 ex.printStackTrace();
 }
 }
 };
 //开始计数
 t.start();
 //主线程休眠100ms
 Thread.sleep(100);
 //停止线程的运行
 t.stop();
 }catch(Throwablet){
 System.out.println("Caughtinmain:"+t);
 t.printStackTrace();
 }

 }
 }

运行结果如下：

由于打印的数据太多了，就没有全部截图了，但是我们可以看到，调用了stop方法之后，线程并没有停止，而是将run方法执行完。那这个就诡异了，多次运行之后发现每次运行的结果都表明，工作线程并没有停止，而是每次都成功的数完数(执行完run方法)，然后正常中止，而不是由stop()方法进行终止的。这个是为什么呢？根据SUN的文档，原则上只要一调用thread.stop()方法，那么线程就会立即停止，并抛出ThreadDeath error，查看了Thread的源代码后才发现，原先Thread.stop(Throwable obj)方法是同步的，而我们工作线程的run()方法也是同步，那么这样会导致主线程和工作线程共同争用同一个锁（工作线程对象本身），由于工作线程在启动后就先获得了锁，所以无论如何，当主线程在调用t.stop()时，它必须要等到工作线程的run()方法执行结束后才能进行，结果导致了上述奇怪的现象。

下面看一下stop的源码：

 @Deprecated
 publicfinalvoidstop(){
 stop(newThreadDeath());
 }

再进到stop看:

 @Deprecated
 publicfinalsynchronizedvoidstop(Throwableobj){
 if(obj==null)
 thrownewNullPointerException();

 SecurityManagersecurity=System.getSecurityManager();
 if(security!=null){
 checkAccess();
 if((this!=Thread.currentThread())||
 (!(objinstanceofThreadDeath))){
 security.checkPermission(SecurityConstants.STOP_THREAD_PERMISSION);
 }
 }
 //Azerostatusvaluecorrespondsto"NEW",itcan'tchangeto
 //not-NEWbecauseweholdthelock.
 if(threadStatus!=0){
 resume();//Wakeupthreadifitwassuspended;no-opotherwise
 }

 //TheVMcanhandleallthreadstates
 stop0(obj);
 }

stop0(obj)是一个native方法，我们看到stop方法是同步的，而这个同步的锁对象正好也是线程本身，所以造成上面的现象。

把上述工作线程的run()方法的同步去掉，再进行执行，结果就如上述第一点描述的那样了，运行结果如下：

从结果中我们可以看到，调用stop方法会抛出一个ThreadDeath异常，这时候run方法也就执行结束了，线程就终止了，这种是用抛异常来结束线程的，但是这种抛出线程是不安全的，因为他不可控制，不知道到在run方法中的何处就可能抛出异常，所以是危险的。下面在看一下stop的这个隐患可能造成的影响：

接下来是看看当调用thread.stop()时，被停止的线程会不会释放其所持有的锁，看如下代码：

 publicstaticvoidmain(String[]args){
 <spanstyle="white-space:pre"></span>//定义锁对象
 finalObjectlock=newObject();
 //定义第一个线程，首先该线程拿到锁，而后等待3s,之后释放锁
 try{
 Threadt0=newThread(){
 publicvoidrun(){
 try{
 synchronized(lock){
 System.out.println("thread->"+getName()+"acquirelock.");
 sleep(3*1000);
 System.out.println("thread->"+getName()+"等待3s");
 System.out.println("thread->"+getName()+"releaselock.");
 }
 }catch(Throwableex){
 System.out.println("Caughtinrun:"+ex);
 ex.printStackTrace();
 }
 }
 };

 //定义第二个线程，等待拿到锁对象
 Threadt1=newThread(){
 publicvoidrun(){
 synchronized(lock){
 System.out.println("thread->"+getName()+"acquirelock.");
 }
 }
 };

 //线程一先运行，先拿到lock
 t0.start();
 //而后主线程等待100ms,为了做延迟
 Thread.sleep(100);
 //停止线程一
 //t0.stop();
 //这时候在开启线程二
 t1.start();
 }catch(Throwablet){
 System.out.println("Caughtinmain:"+t);
 t.printStackTrace();
 }

 }

运行结果如下：

从运行结果中我们可以看到，当没有进行t0.stop()方法的调用时， 可以发现，两个线程争用锁的顺序是固定的。这个现象是正常的。

下面我们把t0.stop注释的哪行，删除注释，调用t0.stop()方法，运行结果如下：

从运行结果中我们可以看到，调用了t0.stop()方法后，可以发现，t0线程抛出了ThreadDeath error并且t0线程释放了它所占有的锁。

从上面的程序验证结果来看，thread.stop()确实是不安全的。它的不安全主要是：释放该线程所持有的所有的锁。一般任何进行加锁的代码块，都是为了保护数据的一致性，如果在调用thread.stop()后导致了该线程所持有的所有锁的突然释放(不可控制)，那么被保护数据就有可能呈现不一致性，其他线程在使用这些被破坏的数据时，有可能导致一些很奇怪的应用程序错误。

下面顺便说一下：

Java中多线程锁释放的条件：

1）执行完同步代码块，就会释放锁。（synchronized）
2）在执行同步代码块的过程中，遇到异常而导致线程终止，锁也会被释放。（exception）
3）在执行同步代码块的过程中，执行了锁所属对象的wait()方法，这个线程会释放锁，进入对象的等待池。(wait)

从上面的三点我就可以看到stop方法释放锁是在第二点的，通过抛出异常来释放锁，通过证明，这种方式是不安全的，不可靠的。

好吧，Thread中的stop方法就说到这里了，后续还会有关Thread中的一些方法的详解，一定要关注奥！