多线程：到底什么时候该用多线程

标签：参考   数据源   在线   过多   必须   自动化   通过   行高   bsp   

一、高并发

系统接受实现多用户多请求的高并发时，通过多线程来实现。

二、线程后台处理大任务

一个程序是线性执行的。如果程序执行到要花大量时间处理的任务时，那主程序就得等待其执行完才能继续执行下面的。那用户就不得不等待它执行完。

这时候可以开线程把花大量时间处理的任务放在线程处理，这样线程在后台处理时，主程序也可以继续执行下去，用户就不需要等待。线程执行完后执行回调函数。

三、大任务

大任务处理起来比较耗时，这时候可以起到多个线程并行加快处理（例如：分片上传）。

----------------------------------------------------------------------------------------------------

连续的操作，需要花费忍无可忍的过长时间才可能完成
并行计算
为了等待网络、文件系统、用户或其他I/O响应而耗费大量的执行时间
所以说，在动手之前，先保证自己的应用程序中是否出现了以上3种情形。

----------------------------------------------------------------------------------------------------

文章一：

我想大多数人在学习多线程时都会对此问题有所顾虑，尽管多线程的概念不难理解，那我们什么时候该用它呢？在大多数情况下，我们写了程序，发现有时必须使用多线程才能得到理想的运行结果，于是我们按照资料调用相关的线程类库或API改善程序，并使其正常运行；但是，到底存不存在一种判断依据，能够明确的指导我们正确地使用多线程机制来解决问题呢？笔者对此进行了一番思考，在此说说我的想法以供参考。

    在开始之前，先引入几个问题，这些问题最终都会在这篇文章里找到答案。

问题情景[0]：设计一个简单的UI：包括一个文本标签和一个按钮，在点击按钮时文本显示由0~10的增长，每秒增长量为1。

问题情景[1]：某同学编写的坦克大战程序中，每一个坦克和子弹均使用一个独立的线程，这是否合理？（当然不合理。。。）如果是你，你会怎么编写这个程序？

    笔者认为，多线程的使用离不开“阻塞”这个概念，不过，我想先对这个概念加以扩充，首先先来回想一下阻塞概念原本的意思，简单的说，就是程序运行到某些函数或过程后等待某些事件发生而暂时停止CPU占用的情况；也就是说，是一种CPU闲等状态，不过有时我们使用多线程并不一定是保持闲等时的程序响应，例如在追求高性能的程序中，某条线程在进行高强度的运算，此时若对运算性能不满意，我们也许会再启动若干条运算线程（当然，是在CPU有运算余力的情况下），此时，高强度运算应该归为一种“忙等”状态。

    说到这，多线程归根究底是为了解决"等"的问题，那我们这样定义一个阻塞过程：程序运行该过程所消耗的时间有可能在运行上下文间产生明显的卡顿；这里使用“可能”是因为有些情况下，诸如Socket通信，如果数据源源不断的进入，那么阻塞的时间可能非常小，但我们还是使用了一条线程（nio另说）来处理它，因为我们无法保证数据到来的持续性和有效性;"卡顿"带有主观臆想，也就是说是使用者（人或一些自动化程序）不可接受的。

接下来，对什么时候使用多线程做一个回答：编写程序过程中需要使用某些阻塞过程时，我们才使用多线程，或者更进一步讲，使用多线程的目的是对阻塞过程中的实际阻塞的抽象提取。前半句话应该很好理解，而后面的一句虽然不太好懂，不过它对一个程序应具有的合理线程数量进行了阐释（这点接下来解释）。