问：多线程是不是能加快处理速度？
解析：
在使用多线程时，一定要知道一个道理：处理速度的最终决定因素是CPU、内存等，在单CPU（无论多少核）上，分配CPU资源的单位是“进程”而不是“线程”。我们可以做一个简单的试验
假设我要拷贝100万条数据，单CPU电脑，用一个进程，在单线程的情况下，CPU占用率为5%，耗时1000秒。那么当在这个进程下，开辟10个线程同时去运行，是不是CPU占用率增加到50%，耗时减少到100秒呢？显然不是。我实测出来的情况是这样的：
“CPU占用率仍然是5%，总耗时仍然是1000秒。且每个线程的运行时间也为1000秒。”
重点是后面那句，怎么理解？意味着什么？我的理解如下：进程只有一个，所以分配的CPU资源是一定的，多线程只不过是轮流抢占CPU而已，并不会真正提高处理速度。这意味着，多线程的作用主要在于提高了并发数量，比如http请求，如果是单线程，一次只能接收一个请求，多线程则可以同时接收多个请求。
但是多线程由于轮换使用CPU，会造成单个线程的执行速度变慢（以前CPU供一个线程使用，现在要供多个线程轮流使用了）。但是在多CPU的服务器上，多线程就很有优势了，它不但能提高并发数量，而且能提高处理速度。因为在多CPU的服务器上，CPU调度很灵活，当一个线程占用着一个CPU的时候，其他线程可以被分配给其他CPU去处理，从而实现了“真正意义上地并行”。
总结：
第一，看硬件。如果是在比较强大的、多CPU的服务器上运行程序，可以使用多线程来提高并发数和执行速度。但是线程也不宜过多，即使是16个CPU的服务器，同一时间最多也只能真正意义上地并发处理16个线程，多出来的线程还是要等待。
第二，看用途。如果你不在乎处理速度，仅仅是为了提高并发处理能力，那么理所当然地用多线程，但是如果你仅仅是想提高处理速度，且又是在单CPU机器上运行，那么多线程并不值得。如果你的任务很耗时，且可以一部分、一部分地做，那么最好不要用多线程（好比搬砖，单线程一次搬10块，总共搬10天，但搬一块算一块，到第9天的时候，你就搬完90块砖了；如果你用10个线程同时去搬砖，同样要搬10天，但是到第9天的时候，这10个线程100块砖都“还在路上”，一块砖都没搬完！）。
一个实际例子:
在单线程的情况下，假如说我们生成10个报表文件需要1个小时。
如果是在多线程的情况下呢，生成10个文件要多少个小时？
同样要1个小时。不管你有多少个线程，就算你有100个线程，一样需要1个小时。
这就是问题所在。单线程和多线程的区别在哪里？
单线程是先执行完第一个报表，用了6分钟，再执行第二个报表，也用6分钟。
多线程，是10个报表一起执行，但是每一个报表都要1个小时。
同一个线程，比如说一个servlet，一个人去访问，执行它，只需要2秒。
如果两个人同时去访问，可能就要4秒。如果10个人同时去访问，那么每个人就要
等待20秒。就是说它基本上是一个成倍的线性增长。
一个线程占2%的CPU，那是不是50个线程就占100%的CPU？不是。
50个线程仍然占2%的CPU，分配CPU资源的单位是进程，而不是线程。
所以说线程是无法加快执行速度的
多线程的总体执行时间和单线程是一样的，但是多线程单个线程的执行时间
是单线程的多倍。
我这里有一组数据，我有两个任务，如果是单线程。
先执行任务1，再执行任务2，一共用了80秒钟，每个任务花费40秒
如果我用2个线程同时跑，一共也用了80秒，但是每个任务都花费80秒（也就是说在最后一刻的时候，两个任务几乎是同时完成）。
https://blog.csdn.net/zollty/article/details/53944539
