Question

java 多线程问题 真的提高了效率吗？

并行与并发：
并行：多个cpu实例或者多台机器同时执行一段处理逻辑，是真正的同时。
并发：通过cpu调度算法，让用户看上去同时执行，实际上从cpu操作层面不是真正的同时。并发往往在场景中有公用的资源，那么针对这个公用的资源往往产生瓶颈，我们会用TPS或者QPS来反应这个系统的处理能力。

比如A B两个代码块，A需要30sCPU，B需要20sCPU，如果用单线程，A先运行完再运行B，不考虑CPU调度时间，AB运行完需要运行50s;如果使用多线程,假如运行按如下流程：threadA:10s-->threadB:5s-->threadA:10s-->threadB:10s-->threadA:10s-->threadB:5s 这样，最终两个线程运行完还是用了50s,并没有提高速度啊？

比如挖一个隧道，有2种开工方法
1、只在山的一头挖，直至挖到山的另一头，从而打通隧道，这可以看成是单线程
2、在山的两头挖，同时开工，最后在山的中间接通，从而打通隧道，这感觉肯定比1快了很多，好比多线程
但是2成立的前提是必须有两个工人。而我们的计算机中一般来说只有一个CPU，也就是说只有一个工人。
多线程不过是CPU在不同的时间片之间切换，而表现出齐头并进的样子。
既然挖隧道的人只有一个，虽然我的施工方案是在山的两头开挖，但是由于工作的人只有一个，所以只有让这个人在山的两头跑，挖一会这头再去挖另一头，来回跑是要花费额外时间的（好比线程的切换和调度）。
那么，我们是不是可以说，在单CPU的机器中，多线程反而降低了效率呢？

Answer 1

你钻了牛角尖了。不要从cpu耗时上看，并行一般是为了任务处理。并发是为了资源共享和资源的充分利用。二者可比性不大。

1. 你所说的cpu一般是指，分时系统中的cpu，比如linux，其中一个用户A的一个线程要30个小时完成，另外一个用户B的线程需要1000个小时。而且其中需要用户不断响应，如果没有并发，B用户先开始，A用户需要等待1030小时。如果使用并发，A用户可能四五十个小时就搞定了。如果A和B都比较有money，一人买一台，没有这个问题的。这就是并行。资源充足怎么着都行，资源不足只能找折中方案了。

2. 如果你觉得这是进程的概念，java里一样的。你做过web开发吧。你肯定不想每个请求都分一个服务器吧。开发一个网页，一台电脑同时有上千个人访问你的tomcat，一般不会有问题。浏览也顺畅。这就是并发的作用。这种情况如果使用单线程。一千个人有999个人等着看你的网页，而第一个人操作的时候cpu大部分时间是空闲的。怎么利用起来就成了个问题。这也叫效率。

3. 如果确实必须要考虑问题处理的效率问题。你访问数据库的时候用过线程池吗？是不是能缩短访问数据库所耗费的时间。所以效率高不高不能只看cpu用了多少时间。你可以再考虑考虑，不用多线程，你怎么设计一个单线程程序，同时监听键盘和麦克风的信息录入？

4. 其实计算机底层是有天然的异步特性的。这个东西就是中断。有些耗时的io操作，什么时候处理完是可以不用管的。剩下的无关线程就可以自由自在的进行了。这样效率是不是也高了。
   

5. 单cpu一般也是多核的。
   

Answer 2

多线程效率 我认为未必会高，而且有时候相反会低。
多线程并不是为了提高效率，而是不必等待 可以并行执行多条数据。
可以这么想 我们通过xp系统复制文件。你可以复制一份文件这叫是单线呈，但是你要等这个复制完了才能复制另一份文件，而且不能多复制。这样很难受，所以你可以选择多复制文件,这就是多线程。但复制多份文件用的时间未必会比一份一份文件所用时间少。只是它合理利用了时间进行了多个操作。
如果是买票系统就会用到多线呈。买票是同时进行的，如果一个用户一个用户等下去不是办法，所以可以多个用户同时买票，效率也就提高了。这里的效率不是执行的效率而是时间的合理利用,多个线呈同时进行。

Answer 3

比如A B两个代码块，A需要30sCPU，B需要20sCPU；这个问题应该这么理解：
如果AB俩个代码块在执行时不存在阻塞，那么使用多线程（并发）去解决这个问题，是不会提高效率的，反而会由于cpu反复切换时间片，导致效率有所下降；但是，当AB俩个代码块在执行的过程中存在阻塞的话，那么使用多线程是会提高效率的。因为阻塞时，不需要CPU处理线程。那么，如果A阻塞时间为20s，B阻塞时间为15s，那么俩个线程分别处理这AB代码块的话，耗时应该为30s。
这个就是多线程并发编程的优点。