为什么不推荐使用Thread.interrupted作为线程终止的判读条件

　　写一个线程类，个人习惯如下：

class MyWorkRunnable implements Runnable {
        volatile Thread mTheThread = null;
        @Override
        public void run() {
            if (mTheThread != Thread.currentThread()) {
                throw new RuntimeException();// 防止外部调用Thread.start方法启动该线程
            }
            while (!Thread.interrupted()) {
                // 处理所要处理的工作
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                    mTheThread.interrupt();        //此处不要忘记！！
                }
            }
        }
        public void start() {
            mTheThread = new Thread(this);
            mTheThread.start();
        }
        public void stop() {
            if (mTheThread != null) {
                mTheThread.interrupt();
                try {
                    mTheThread.join(); // 等待线程彻底结束
                } catch (InterruptedException e) {
                    e.printStackTrace();
                    mTheThread.interrupt();
                }
            }
        }

　　乍一看，没有多余的标志位来作为是否继续执行的条件，代码很整洁很干净，但是看到一些经典教材上面，往往会附加个标志位，比如：　　　　

　　while(!Thread.interrupted() && mKeepWork)

　　相信我们很多人会很疑惑，为什么作者要多此一举？第一种方式不是更加完美吗？直到今天才发现原因。。

　　在android里，我们通常会在子线程中渲染SurfaceView，如下面的代码所示：

　　　　Canvas canvas = getHolder().lockCanvas();
　　　　if (canvas != null) {
    　　　　// 用canvas绘图
    　　　　getHolder().unlockCanvasAndPost(canvas);
　　　　}

　　如果在我所写的线程类中执行上面的工作，那么在stop时，可能导致死锁！人人都痛恨死锁，为什么会死锁呢？我一度怀疑是android的一个bug。。在纠结这个问题一周后，终于找到了原因。原来，当界面无效（比如尚未创建成功或者已经被销毁了）时，getHolder().lockCanvas() 方法会sleep 100毫秒，用以释放出CPU资源（your calls will be throttled to a slow rate in order to avoid consuming CPU）。然而，当sleep方法抛出InterruptedException后，会取消线程的中断状态，但是在这个函数里，设计者却把sleep的异常给swallow了。因此，在调用了mTheThread.interrupt()之后，线程的中断状态被sleep给取消了，导致在while里，条件永远是成立的。而线程不退出，stop函数里的join函数也会一直阻塞，因而出现死锁。

　　加个标志位是解决这个问题的一个很好的选择。重写run代码如下：　　

　　　　 @Override
        public void run() {
            if (mTheThread != Thread.currentThread()) {
                throw new RuntimeException();
            }
            while (!Thread.interrupted() && mTheThread != null) {// 如果标志位为null，不再继续。
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                    Thread.currentThread().interrupt();    //mTheThread可能已经为空了，因此用Thread.currentThread()替代之
                }
            }
        }

　　lockCanvas里简单捕获中断异常的做法是不提倡的，一定要养成习惯，不要将中断异常轻易捕获后不管了。但是换句话说这种代码也是无法避免的，那么我们只能加个标志位作为判断条件了。

转载于:https://www.cnblogs.com/jiaozebo/archive/2013/01/12/2857846.html