在开发的过程中遇到过这个问题，其实这个问题就像所报的错的提示一样，Handler.sendMessage(message); 这个message已经被消费了，所以就报出了这个错，

那么这个错是怎么出现的呢，一般是由于多线程问题导致的。我写了一个简单的demo进行了验证。

这段代码中，全局一个message变量，有两个线程，在按钮按下之后，我启动了一个每隔1秒就执行一次任务的定时器，然后开启了两个线程，这两个线程的区别是，

第一个线程：只给这个message重新赋值，然后让timer自己每隔一秒钟去给handler发送这个message。

第二个线程：不管你第一个线程如何如何，与我无关，我直接给handler发送message，共用同一个message，

所以两个线程冲突是必然的，不是24行报错，就是58行报错，

58行报错的概率很低，出现的概率微乎其微，那这个问题是怎么出现的呢？我们分析一下代码，thread1不断的给message赋值，但是同时timer已经开始计时，一秒之后，timer开始执行自己的任务，也是一个线程，他刚要用handler发送message，不巧，被thread2给这个message重新赋值并且还给把他消费了。所以24行就报错了This message is already in use.

这个只是帮你分析问题的源头，解决方法有很多，需要根据具体的需求去定制，不能简单的try catch就解决问题。

然后再记录一下我在工作中是如何遇到这个问题的。

有一个下载功能，提示下载页面弹出之后，用户点击立即下载，这些操作都是在主线程中完成的，如果说只是前台展示，就不存在任何问题，但是如果有个需求是，让弹窗在后台下载，通知栏能够显示进度，这时候就有问题了。下载进度就不说了，分两部分，一部分是下载过程中，一个是下载结束。但是不管是哪个点，我们都要去更新通知栏的进度状态，但是实时更新太浪费资源，而且会很卡顿，所以三秒更新一次通知栏进度，这时候message就是全局的了，在下载的时候，我们先开启定时器，让他每三秒执行一次handler的消息发送，然后handler负责通知NotificationManager去更新进度，在下载的过程中，我们不断地给message赋值，定时器定时去取值，各司其职，很友好，没问题，但是问题就出在了在快下载结束的时候，我在下载结束的终点，取消了定时器的任务，然后自己用handler发送了一个message，代码表示就是这样的

if (done) {

    //在这里取消定时器任务，

    message =mUpdateHandler.obtainMessage();

    message.what = -1;

    mUpdateHandler.sendMessage(message);

}else {

    message =mUpdateHandler.obtainMessage();

    message.what = (int) ((100 * bytesRead) / contentLength);

    //定时器启动相关逻辑

}

这样有两个问题，就是极限情况，大多数情况是没问题的，

第一个问题：timer的问题，因为是三秒执行一次timer，所以有个情况，三秒内我先执行了else内的代码，然后紧接着执行了if里面的代码，这时候三秒到了，timer要去执行，结果发现timer已经被取消了，所以崩溃。

第二个问题：在三秒的边缘，三秒时间到了，我执行timer，然后这个时候很巧，if里面的语句开始执行了，先取消了timer，然后紧接着给message赋值，并且消费了message。然后timer里面的语句要开始执行了，发现这个message已经被消费了。然后就报错了。

其实这个问题很好改。只需要删掉if里面的 mUpdateHandler.sendMessage(message);这句话就可以了，因为无论如何，最后肯定是if里面给message赋值，所以最后一个timer的message肯定是if里面赋值的那个，毋容置疑。同时定时任务的取消也不能放在if里面做，因为有一种情况，第三秒的时候我执行的是else里面的语句，然后接下来我就执行了timer的取消，那么他就永远卡在了最后的那个进度，不能正常安装。这时候我们可以生命一个变量，来记录这个结束的终点，然后在timer里面去取消。

谨以此记录我在版本升级中遇到的问题以及message的问题。