转自 : http://docs.oracle.com/javase/1.5.0/docs/guide/misc/threadPrimitiveDeprecation.html

1.Why is Thread.stop deprecated?

  Because it is inherently unsafe. Stopping a thread causes it to unlock all the monitors that it has locked. (The monitors are unlocked as the ThreadDeath exception propagates up the stack.) If any of the objects previously protected by these monitors were in an inconsistent state, other threads may now view these objects in an inconsistent state. Such objects are said to be damaged. When threads operate on damaged objects, arbitrary behavior can result. This behavior may be subtle and difficult to detect, or it may be pronounced. Unlike other unchecked exceptions, ThreadDeath kills threads silently; thus, the user has no warning that his program may be corrupted. The corruption can manifest itself at any time after the actual damage occurs, even hours or days in the future.

2.Couldn't I just catch the ThreadDeath exception and fix the damaged object?

  In theory, perhaps, but it would vastly complicate the task of writing correct multithreaded code. The task would be nearly insurmountable for two reasons:

  1. A thread can throw a ThreadDeath exception almost anywhere. All synchronized methods and blocks would have to be studied in great detail, with this in mind.
  2. A thread can throw a second ThreadDeath exception while cleaning up from the first (in the catch or finally clause). Cleanup would have to repeated till it succeeded. The code to ensure this would be quite complex.

  In sum, it just isn't practical.

3.What about Thread.stop(Throwable)?

  In addition to all of the problems noted above, this method may be used to generate exceptions that its target thread is unprepared to handle (including checked exceptions that the thread could not possibly throw, were it not for this method). For example, the following method is behaviorally identical to Java's throw operation, but circumvents the compiler's attempts to guarantee that the calling method has declared all of the checked exceptions that it may throw:

     static void sneakyThrow(Throwable t) {
         Thread.currentThread().stop(t);
     }

4.What should I use instead of Thread.stop?

  Most 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. (This is the approach that the Java Tutorial has always recommended.) To ensure prompt communication of the stop-request, the variable must be volatile (or access to the variable must be synchronized).

  For example, suppose your applet contains the following startstop and run methods:

    private Thread blinker;

     public void start() {
         blinker = new Thread(this);
         blinker.start();
     }

     public void stop() {
         blinker.stop();  // UNSAFE!
     }

     public void run() {
         Thread thisThread = Thread.currentThread();
         while (true) {
             try {
                 thisThread.sleep(interval);
             } catch (InterruptedException e){
             }
             repaint();
         }
     }

  You can avoid the use of Thread.stop by replacing the applet's stop and run methods with:

     private volatile Thread blinker;

     public void stop() {
         blinker = null;
     }

     public void run() {
         Thread thisThread = Thread.currentThread();
         while (blinker == thisThread) {
             try {
                 thisThread.sleep(interval);
             } catch (InterruptedException e){
             }
             repaint();
         }
     }

5.How do I stop a thread that waits for long periods (e.g., for input)?

  That's what the Thread.interrupt method is for. The same "state based" signaling mechanism shown above can be used, but the state change (blinker = null, in the previous example) can be followed by a call to Thread.interrupt, to interrupt the wait:

     public void stop() {
         Thread moribund = waiter;
         waiter = null;
         moribund.interrupt();
     }

  For this technique to work, it's critical that any method that catches an interrupt exception and is not prepared to deal with it immediately reasserts the exception. We say reasserts rather than rethrows, because it is not always possible to rethrow the exception. If the method that catches the InterruptedException is not declared to throw this (checked) exception, then it should "reinterrupt itself" with the following incantation:

   Thread.currentThread().interrupt();

  This ensures that the Thread will reraise the InterruptedException as soon as it is able.

6.What if a thread doesn't respond to Thread.interrupt?

  In some cases, you can use application specific tricks. For example, if a thread is waiting on a known socket, you can close the socket to cause the thread to return immediately. Unfortunately, there really isn't any technique that works in general. It should be noted that in all situations where a waiting thread doesn't respond to Thread.interrupt, it wouldn't respond to Thread.stop either. Such cases include deliberate denial-of-service attacks, and I/O operations for which thread.stop and thread.interrupt do not work properly.

7.Why are Thread.suspend and Thread.resume deprecated?

  Thread.suspend 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. Such deadlocks typically manifest themselves as "frozen" processes.

8.What should I use instead of Thread.suspend and Thread.resume?

  As with Thread.stop, the prudent approach is to have the "target thread" poll a variable indicating the desired state of the thread (active or suspended). When the desired state is suspended, the thread waits using Object.wait. When the thread is resumed, the target thread is notified using Object.notify.

  For example, suppose your applet contains the following mousePressed event handler, which toggles the state of a thread called blinker:

     private boolean threadSuspended;

     Public void mousePressed(MouseEvent e) {
         e.consume();

         if (threadSuspended)
             blinker.resume();
         else
             blinker.suspend();  // DEADLOCK-PRONE!

         threadSuspended = !threadSuspended;
     }

  You can avoid the use of Thread.suspend and Thread.resume by replacing the event handler above with:

     public synchronized void mousePressed(MouseEvent e) {
         e.consume();

         threadSuspended = !threadSuspended;

         if (!threadSuspended)
             notify();
     }

  and adding the following code to the "run loop":

1  synchronized(this) {
     while (threadSuspended)
        wait();
4  }

  The wait method throws the InterruptedException, so it must be inside a try ... catch clause. It's fine to put it in the same clause as the sleep. The check should follow (rather than precede) the sleepso the window is immediately repainted when the the thread is "resumed." The resulting run method follows:

     public void run() {
         while (true) {
             try {
                 Thread.currentThread().sleep(interval);

                 synchronized(this) {
                     while (threadSuspended)
                         wait();
                 }
             } catch (InterruptedException e){
             }
             repaint();
         }
     }

  Note that the notify in the mousePressed method and the wait in the run method are inside synchronized blocks. This is required by the language, and ensures that wait and notify are properly serialized. In practical terms, this eliminates race conditions that could cause the "suspended" thread to miss a notify and remain suspended indefinitely.

  While the cost of synchronization in Java is decreasing as the platform matures, it will never be free. A simple trick can be used to remove the synchronization that we've added to each iteration of the "run loop." The synchronized block that was added is replaced by a slightly more complex piece of code that enters a synchronized block only if the thread has actually been suspended:

     if (threadSuspended) {
         synchronized(this) {
           while (threadSuspended)
              wait();
         }
     }

  In the absence of explicit synchronization, threadSuspended must be made volatile to ensure prompt communication of the suspend-request.

  The resulting run method is:

     private boolean volatile threadSuspended;

     public void run() {
         while (true) {
             try {
                 Thread.currentThread().sleep(interval);

                 if (threadSuspended) {
                     synchronized(this) {
                         while (threadSuspended)
                             wait();
                     }
                 }
             } catch (InterruptedException e){
             }
             repaint();
         }
     }

9.Can I combine the two techniques to produce a thread that may be safely "stopped" or "suspended"?

  Yes; it's reasonably straightforward. The one subtlety is that the target thread may already be suspended at the time that another thread tries to stop it. If the stop method merely sets the state variable (blinker) to null, the target thread will remain suspended (waiting on the monitor), rather than exiting gracefully as it should. If the applet is restarted, multiple threads could end up waiting on the monitor at the same time, resulting in erratic behavior.

  To rectify this situation, the stop method must ensure that the target thread resumes immediately if it is suspended. Once the target thread resumes, it must recognize immediately that it has been stopped, and exit gracefully. Here's how the resulting run and stop methods look:

 1  public void run() {
         Thread thisThread = Thread.currentThread();
         while (blinker == thisThread) {
             try {
                 thisThread.sleep(interval);

                 synchronized(this) {
                     while (threadSuspended && blinker==thisThread)
                         wait();
                 }
             } catch (InterruptedException e){
             }
             repaint();
         }
     }

     public synchronized void stop() {
         blinker = null;
         notify();
     }

  If the stop method calls Thread.interrupt, as described above, it needn't call notify as well, but it still must be synchronized. This ensures that the target thread won't miss an interrupt due to a race condition.

10.What about Thread.destroy?

  Thread.destroy has never been implemented. If it were implemented, it would be deadlock-prone in the manner of Thread.suspend. (In fact, it is roughly equivalent to Thread.suspend without the possibility of a subsequent Thread.resume.) We are not implementing it at this time, but neither are we deprecating it (forestalling its implementation in future). While it would certainly be deadlock prone, it has been argued that there may be circumstances where a program is willing to risk a deadlock rather than exit outright.

11.Why is Runtime.runFinalizersOnExit deprecated?

  Because it is inherently unsafe. It may result in finalizers being called on live objects while other threads are concurrently manipulating those objects, resulting in erratic behavior or deadlock. While this problem could be prevented if the class whose objects are being finalized were coded to "defend against" this call, most programmers do not defend against it. They assume that an object is dead at the time that its finalizer is called.

  Further, the call is not "thread-safe" in the sense that it sets a VM-global flag. This forces every class with a finalizer to defend against the finalization of live objects!

java中的线程(1):如何正确停止线程Why Are Thread.stop, Thread.suspend, Thread.resume and Runtime.runFinalizersOnExit Deprecated?的更多相关文章

  1. 正确停止线程的方式三 使用Thread类中的内置的中断标记位-----------不熟悉

    package charpter10; public class Processor implements Runnable { @Override public void run() { for ( ...

  2. [No000017E]改善C#程序的建议7:正确停止线程

    开发者总尝试对自己的代码有更多的控制.“让那个还在工作的线程马上停止下来”就是诸多要求中的一种.然而事与愿违,这里面至少存在两个问题: 第一个问题是:正如线程不能立即启动一样,线程也并不能说停就停.无 ...

  3. 编写高质量代码改善C#程序的157个建议——建议77: 正确停止线程

    建议77: 正确停止线程 开发者总尝试对自己的代码有更多的控制.例如,“让那个还在工作的线程马上停止下来”.然而,并非我们想怎样就可以怎样的,这至少涉及两个问题. 第一个问题 正如线程不能立即启动一样 ...

  4. 改善C#程序的建议7:正确停止线程

    原文:改善C#程序的建议7:正确停止线程 开发者总尝试对自己的代码有更多的控制.“让那个还在工作的线程马上停止下来”就是诸多要求中的一种.然而事与愿违,这里面至少存在两个问题: 第一个问题是:正如线程 ...

  5. Java中的线程Thread方法之---suspend()和resume()

    前篇说到了Thread中的join方法,这一篇我们就来介绍一下suspend()和resume()方法,从字面意义上可以了解到这两个方法是一对的,suspend()方法就是将一个线程挂起(暂停),re ...

  6. Java 中你怎样唤醒一个阻塞的线程?

    在 Java 发展史上曾经使用 suspend().resume()方法对于线程进行阻塞唤醒,但 随之出现很多问题,比较典型的还是死锁问题. 解决方案可以使用以对象为目标的阻塞,即利用 Object ...

  7. JAVA中判断年月日格式是否正确(支持判断闰年的2月份)

    一.先说一下年月日(yyyy-MM-dd)正则表达式: 1.年月日正则表达式:^((19|20)[0-9]{2})-((0?2-((0?[1-9])|([1-2][0-9])))|(0?(1|3|5| ...

  8. Java中Path和CLASSPATH的正确配置

    JAVA_HOME: D:\soft\study\jdk1.7.0_01 JAVA_HOME里配置的是我们jdk安装的路径,这样配置就好.如果你是要用到JAVA_HOME的话,那就不要在JAVA_HO ...

  9. java如何正确停止一个线程

    Thread类中有start(), stop()方法,不过stop方法已经被废弃掉. 平时其实也有用过,共享一个变量,相当于标志,不断检查标志,判断是否退出线程 如果有阻塞,需要使用Thread的in ...

随机推荐

  1. C# 世界坐标 页面坐标 PageUnit PageScale

    PageScale:  获取或设置此 Graphics 的世界单位和页单位之间的比例.PageUnit:  获取或设置用于此 Graphics 中的页坐标的度量单位. 话不多说,上代码: privat ...

  2. [GO]将随机生成的四位数字拆分后放到一个切片里

    package main import ( "math/rand" "time" "fmt" ) func InitData(p *int) ...

  3. ajax data参数

    表单 使用serializeArray获取所有: <form id='addForm' action='UserAdd.action' type='post'> <label for ...

  4. 【C#】CLR内存那点事(string)

    string是比特殊的类,说引用类型,但不存在堆里面,而且String str=new String("HelloWorld")这样的重装也说没有的. 我们先来看一个方法 clas ...

  5. Ubuntu的Unable to locate package无法更新源问题解决方案

    https://blog.csdn.net/long19910605/article/details/47017889/ 问题: 更新源时提示不能联网(does the network require ...

  6. .net core MVC Filters 过滤器介绍

    一.过滤器的优级依次介绍如下(逐次递减): Authorization Filter ->  Resource Filter -> Acton Filter -> Exception ...

  7. .net在线HTML编辑器

    //在线网页编辑器, <script> var editor2 = new baidu.editor.ui.Editor({//实例化编辑器 initialContent: '', min ...

  8. 可变大小、颜色边框、样式的UISwitch

    1.CHSwitch.h // // 文 件 名:CHSwitch.h // // 版权所有:Copyright © 2018 lelight. All rights reserved. // 创 建 ...

  9. python测试笔试题1

    哪一个方法用来返回变量类型? 答案 type 哪一个方法用来列出一个类下的所有属性,方法,以及变量? 答案 dir 字符串方法format是用来去掉字符串的左右空格的么? 答案 不是 python 的 ...

  10. PHP选项和运行

    PHP运行模式 五大运行模式 1.cgi 通用网关接口 2.fast-cgi cgi升级 3.cli (Command Line Interface) 4.isapi 微软提供的面向Internet服 ...