其实在平时的开发中，很多程序员都不会去写线程，为啥？因为麻烦，其次是用到的地方并不多，除非逼不得已，大家都不会去写，毕竟写一天代码，拿一天工资，是吧？

资源利用率提升，程序处理效率提高

打个比方：我们做上传图片的时候，在上传成功后往往会进行图片的处理，原图保存后，会再生成一张小图以作为一些应用的预览图，那么原图的处理就需要程序去读取再处理，假设读取需要花费1秒，处理需要2秒，现在有3张大图，所需要耗费的时间就是（1+2）X3=9秒，根据图片的不同，那么单位时间会更多，总计时间就会更久。

那么如果把程序设计更好的话，那就是在读取文件的时候同时处理上一个文件，这样就可以尽可能的缩短时间，减少客户端的响应，同时也提升了CPU的使用率。

如果还不能理解的话那就再举个例子，我朋友公司是专为某银行处理数据同步的问题，每天凌晨银行那边会有几十万条数据发送过来进行处理，项目本身就是个坑，几百万条数据接收后直接去处理了，每次运行大多都要耗费2.5个小时，时间实在太久，如果哪天有几亿数据是不是要跑几十个小时了？那么就可以用多线程，切割这个数据，利用不同的线程来处理，最后把时间缩短到了半小时左右

代码会相对简单

如果利用单线程去处理文件，那么我们就得标记每次处理的各个节点的状态；而如果使用多线程的话处理完一个扔一个，可以简便不少

软件运行速度提升

就像之前所说的魔兽争霸那样，如果采矿伐木打猎都是由一个农民工来做的话，那他会累死，而如果分配3个农民工来做的话，那么时间大大缩短；同理，软件程序在处理文件的时候也是一个道理。

也就是说，往常我们监听的是用户请求，现在我们把用户请求塞给线程，我们去监听线程就可以了。

举一个不恰当的例子，我们在用eclipse的时候经常会出现这样的情况，一个progress被另一个卡住，下一个必须等待上一个执行完毕后再执行，完毕后我们方可编写代码，这种情况尤其出现在maven编译或者下载jar包的时候。

假如说，eclipse是同时进行任务处理的，那么每个任务处理完后响应一个状态，然后再提示给用户，可以弹出显示，或者在底部状态来加个有颜色的提醒，都可以。（如果理解成消息队列的处理方式也可以，在云计算业务中利用消息队列处理各种服务器请求也是类似道理）

那么，这样的程序设计对于软件自身来说响应速度就更快了，用户的体验也就更高了~