何时用多线程？多线程需要加锁吗？线程数多少最合理？

爱生活，爱编码，微信搜一搜【架构技术专栏】关注这个喜欢分享的地方。

本文架构技术专栏已收录，有各种视频、资料以及技术文章。

一、什么时候应该使用多线程？

今天看到一个问题，突然有感而发，想聊下这个话题。

不知道大家有没有想过这个问题，就是什么时候我该使用多线程呢？使用多线程就一定会提升系统性能吗？

1、其实是否应该使用多线程在很大程度上取决于应用程序的类型。

计算密集型（如纯数学运算）的，并受CPU 功能的制约，则只有多CPU(或者多个内核) 机器能够从更多的线程中受益，单CPU下，多线程不会带来任何性能上的提升，反而有可能由于线程切换等额外开销而导致性能下降
IO密集型的，当我的应用必须等待缓慢的资源（如网络连接或者数据库连接上返回数据）时，那么多线程会让系统的CPU充分的利用起来，当一个线程阻塞挂起时，另一个线程可以继续使用CPU资源。
其实，就是多线程不会增加CPU的处理能，而是能够更加充分地利用CPU资源。

由于同一进程的多个线程是共享同一片内存资源的，在带来方便的同时也必然会增加其复杂性，如何保证多线程访问数据的一致性问题等。而多线程属于编程中容易翻车的地方。并且多线程编程问题的测试定位也是比较难的。总体来说，好的多线程是写出来，将多线程问题寄希望于测试中发现，无疑是极度不可靠的。SO，努力的学习吧。

Java API 与多线程息息相关的的几大关键字：volatile、synchronized、 wait、 notify. 理解了这几个关键字，就可以编写多线程的代码了。

二、什么时候需要加锁？

在多线程场合下，最重要的就是保障数据的一致性问题，而保障数据一致性问题，就需要借助于锁了。

其实我们在多线程的场景下应该搞清楚一个问题，就是到底什么需要保护？并不是所有的的数据都需要加锁保护，只有那些涉及到被多线程访问的共享的数据才需要加锁保护。

锁的本质其实就是确保在同一时刻，只有一个线程在访问共享数据，那么此时该共享数据就能得到有效的保护。

举例说明下，比如我们想构造一个多线程下安全的单向链表：

假如现在有两个线程在操作这个链表，一个写线程插入一个新元素7，另一个读线程遍历链表数据，如果不使用任何锁，那就有可能出现下面的执行顺序：

步骤	写线程	读线程
0	修改链表元素2的next指针指向7这个元素	... ...
1	... ...	遍历链表，到7的时候发现next 为null,遍历结束
2	修改元素7的next 指针指向3	... ...

通过上面的例子我们可以明显看到在多线程下操作这个链表，有可能会导致读线程读到的数据不完整，只有从链表头部到元素7的位置的数据。由此可见，不加入任何保护措施的多线程保护，势必会导致数据的混乱。为了避免数据一致性问题，我们就需要将操作该队列的代码放入同步块内（锁的对象也就是这个链表实例），来确保同一时刻只有一个线程可以访问该链表。

如何加锁？

这里简单的说下，一般我们都是使用synchronized（如果没有特殊需求建议直接使用这个关键字，jdk新版本它真的很快），记住synchronized 锁的就是对象头。

简单的说下，主要有下面几种用法：

synchronized 放在方法上，锁的是当前synchronized 方法的对象实例
synchronized在static 方法上，锁的是synchronized 方法的class 类对象，注意这里class 其实也是一个对象。
synchronized（this）在代码块中，锁的是代码块括号内的对象，这里this指的就是调用这个方法的类实例对象

三、多线程中易犯的错误

1、锁范围过大

共享资源访问完成后，后续的代码没有放在synchronized同步代码块之外。会导致当前线程长期无效的占用该锁，而其它争用该锁的线程只能等待，最终导致性能受到极大影响。

 public void test()
 {
 		synchronized(lock){
 		... ... //正在访问共享资源
 		... ... //做其它耗时操作,但这些耗时操作与共享资源无关
 	}
 }

面对上面这种写法，会导致此线程长期占有此锁，从而导致其他线程只能等待，下面来讨论下解决方法：

1）单CPU场景下，将不需要同步的耗时操作拿到同步块外面，有的情况可以提升性能，有的却不行。

CPU密集型的代码 ,不存在磁盘IO/网络IO等低CPU消耗的代码。这种情况下， CPU 99%都在执行代码。因此缩小同步块也不会带来任何性能上的提升，同时缩小同步块也不会带来性能上的下降。
IO密集型的代码，在执行不消耗CPU的代码时，其实CPU属于空闲状态的。如果此时让CPU工作起来就可以带来整体上性能的提升。所以在这种情况下，就可以将不需要同步的耗时操作移到同步块外面了。

2）多CPU场景下，将耗时的CPU操作拿到同步块外面，总是可以提升性能的

CPU密集型的代码，不存在IO操作等不消耗CPU的代码片段。因为当前是多CPU，其他CPU也可能是空闲的。所以在缩小同步块的时候，也会让其他线程尽快的执行这段代码从而带来性能上的提升。
IO密集型的代码，因为当前PCU都是空闲的状态，所以将耗时的操作放在同步块外面，一定会带来整体上的性能提升。

当然，不管怎么样，缩小锁的同步范围对于系统来说都是百利而无一害的，因此上面的代码应该改为：

 public void test()
 {
 		synchronized(lock){
 		... ... //正在访问共享资源
 	}
 		... ... //做其它耗时操作,但这些耗时操作与共享资源无关
 }

综上所述，一个重点，就是只将访问共享资源的代码放在同步块内，保证快进快出。

2、死锁的问题

死锁要知道的：

死锁，简单地说就是两个线程或多个线程在同时等待被对方持有的锁导致的，死锁会导致线程无法继续执行并被永久挂起。
如果线程发生了死锁，那我们就能从线程堆栈中明显的看到”Found one Java-level deadlock“，并且线程栈还会给出死锁的分析结果。
死锁这种问题如果发生在关键系统上就可能会导致系统瘫痪，如果想要快速恢复系统，临时唯一的方法就是保留线程栈先重启，然后再尽快的恢复。
死锁这种问题有时候测试是很难被立即发现的，很多时候在测试时能否及时发现这类问题，就全看你的运气和你准备的测试用例了。
避免死锁这类问题，唯一的办法就是改代码。但一个可靠的系统是设计出来的，而不是通过改BUG改出来的，当出现这种问题的时候就需要从系统设计角度去分析了。
有人会认为死锁会导致CPU 100%，其实对也不对。要看使用的什么类型的锁了，比如synchronized导致的死锁，那就不会导致CPU100%，只会挂起线程。但如果是自旋锁这种才可能会消耗CPU。

3、共用一把锁的问题

就是多个共享变量会共用一把锁，特别是在方法级别上使用synchronized，从而人为导致的锁竞争。

上例子,下面是新手容易犯的错误：

1 public class MyTest
2 {
3 Object shared;
4 synchronized void fun1() {...} //访问共享变量shared
5 synchronized void fun2() {...} //访问共享变量shared
6 synchronized void fun3() {...} //不访问共享变量shared
7 synchronized void fun4() {...} //不访问共享变量shared
8 synchronized void fun5() {...} //不访问共享变量shared
9 }

上面的代码每一个方法都被加了synchronized ，明显违背了保护什么锁什么的原则。

三、线程数我们一般设多少比较合理呢？

其实大家都知道，在大多数场合下多线程都是可以提高系统的性能和吞吐量，但一个系统到底多少个线程才是合理的？

总的来说，线程数量太多太少其实都不太好，多了会因为线程频繁切换导致开销增大，有时候反而降低了系统性能。少了又会导致CPU资源不能充分的利用起来，性能没有达到瓶颈。

所以，系统到底使用多少线程合适，是要看系统的线程是否能充分的利用了CPU。其实实际情况，是很多时候不消耗CPU，如：磁盘IO、网络IO等。

磁盘IO、网络IO相比CPU的速度，那简直是相当的慢的，在执行IO的这段时间里CPU其实是空闲的。如果这时其他线程能把这空闲的CPU利用上，就可以达到提示系统性能和吞吐的目的。

其实上面我们也提到过，也就是两种计算特性：

CPU密集型：因为每个CPU都是高计算负载的情况，如果设置过多的线程反而会产生不必要的上下文切换。所以，一般线程我们会设置 CPU 核数 + 1就可以了，为啥要加1 呢，即使当计算（CPU）密集型的线程偶尔由于页缺失故障或者其他原因而暂停时，这个“额外”的线程也能确保 CPU 的时钟周期不会被浪费，其实就是个备份。

IO密集型：因为大量的IO操作，会导致CPU处于空闲状态，所以这时我们可以多设置些线程。所以，线程数 = CPU 核心数 * (1+ IO 耗时/CPU 耗时) 就可以了，希望能给你点启发。