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

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