多线程应用场景

1.例如Tomcat的线程池的最大Thread数为4, 现在需要执行的任务有1000个(理解为有1000个用户点了你的网站的某个功能)。

2.比如脏数据的处理。

3.兄弟，直白一点说。就类似银行的柜台，如果只开通一个柜台的话，其他人的都会在一个柜台等下去，一个一个的，等着处理，但是如果银行柜台同时开通5个（类似于5个线程）那么只要有一个柜台空闲，你就可以直接过去处理事情，而不用一直等待着。

4、后台任务，例如：定时向大量（100w以上）的用户发送邮件或者短信；
5、异步处理，例如：发微博、记录日志等； 开不同的线程去处理。。。
6、生产者-消费者模式

7, 现成的线程池 Executors.newCachedThreadPool()

8.

--举个简单的例子：
假设有个请求，这个请求服务端的处理需要执行3个很缓慢的IO操作（比如数据库查询或文件查询），那么正常的顺序可能是（括号里面代表执行时间）：
a、读取文件1  （10ms）
b、处理1的数据（1ms）
c、读取文件2  （10ms）
d、处理2的数据（1ms）
e、读取文件3  （10ms）
f、处理3的数据（1ms）
g、整合1、2、3的数据结果 （1ms）
单线程总共就需要34ms。
那如果你在这个请求内，把ab、cd、ef分别分给3个线程去做，就只需要12ms了

所以多线程不是没怎么用，而是，你平常要善于发现一些可优化的点。然后评估方案是否应该使用。
假设还是上面那个相同的问题：但是每个步骤的执行时间不一样了。
a、读取文件1  （1ms）
b、处理1的数据（1ms）
c、读取文件2  （1ms）
d、处理2的数据（1ms）
e、读取文件3  （28ms）
f、处理3的数据（1ms）
g、整合1、2、3的数据结果 （1ms）
单线程总共就需要34ms。
如果还是按上面的划分方案（上面方案和木桶原理一样，耗时取决于最慢的那个线程的执行速度），在这个例子中是第三个线程，执行29ms。那么最后这个请求耗时是30ms。比起不用单线程，就节省了4ms。但是有可能线程调度切换也要花费个1、2ms。因此，这个方案显得优势就不明显了，还带来程序复杂度提升。不太值得。

那么现在优化的点，就不是第一个例子那样的任务分割多线程完成。而是优化文件3的读取速度。
可能是采用缓存和减少一些重复读取。
首先，假设有一种情况，所有用户都请求这个请求，那其实相当于所有用户都需要读取文件3。那你想想，100个人进行了这个请求，相当于你花在读取这个文件上的时间就是28×100=2800ms了。那么，如果你把文件缓存起来，那只要第一个用户的请求读取了，第二个用户不需要读取了，从内存取是很快速的，可能1ms都不到。

伪代码：

Java code

?

1 2 3 4 5 6 7 8 9 10 11

public  class  MyServlet  extends  Servlet{      private  static  Map<String, String> fileName2Data =  new  HashMap<String, String>();      private  void  processFile3(String fName){          String data = fileName2Data.get(fName);          if (data== null ){              data = readFromFile(fName);     //耗时28ms