简历上写精通多线程！殊不知道：多线程为何会有并发问题？

时间  2021-05-14
标签 java 面试 编程 后端 数组 缓存 安全 数据结构 多线程 并发 栏目 Java 繁體版
原文   原文链接

前言

多线程并发问题，基本是面试必问的。java

大部分同窗应该都知道 Synchronized ， Lock ，部分同窗能说到 volatile 、 并发包 ，优秀的同窗则能在前面的基础上，说出Synchronized、volatile的原理，以及并发包中经常使用的数据结构，例如ConcurrentHashMap的原理。面试

这篇文章将总结多线程并发的各类处理方式，JVM调优实战笔记也分享给你们，但愿对你们有所帮助，编程

1、多线程为何会有并发问题

为何多线程同时访问（读写）同个变量，会有并发问题？后端

  1. Java 内存模型规定了全部的变量都存储在主内存中，每条线程有本身的工做内存。
  2. 线程的工做内存中保存了该线程中用到的变量的主内存副本拷贝，线程对变量的全部操做都必须在工做内存中进行，而不能直接读写主内存。
  3. 线程访问一个变量，首先将变量从主内存拷贝到工做内存，对变量的写操做，不会立刻同步到主内存。
  4. 不一样的线程之间也没法直接访问对方工做内存中的变量，线程间变量的传递均须要本身的工做内存和主存之间进行数据同步进行。

2、Java 内存模型（JMM）

Java 内存模型(JMM) 做用于工做内存（本地内存）和主存之间数据同步过程，它规定了如何作数据同步以及何时作数据同步，以下图。数组

简历上写精通多线程！殊不知道：多线程为何会有并发问题？

3、并发编程三要素

原子性：在一个操做中，CPU 不能够在中途暂停而后再调度，即不被中断操做，要么执行完成，要么就不执行。缓存

可见性：多个线程访问同一个变量时，一个线程修改了这个变量的值，其余线程可以当即看获得修改的值。安全

有序性：程序执行的顺序按照代码的前后顺序执行。数据结构

3、怎么作，才能解决止并发问题？（重点）

下面结合不一样场景分析解决并发问题的处理方式。多线程

1、volatile

1.1 volatile 特性

保证可见性，不保证原子性并发

  1. 当写一个volatile变量时，JVM会把本地内存的变量强制刷新到主内存中
  2. 这个写操做致使其余线程中的缓存无效，其余线程读，会从主内存读。volatile的写操做对其它线程实时可见。

禁止指令重排序指令重排序是指编译器和处理器为了优化程序性能对指令进行排序的一种手段，须要遵照必定规则：

  1. 不会对存在依赖关系的指令重排序，例如 a = 1;b = a; a 和b存在依赖关系，不会被重排序
  2. 不能影响单线程下的执行结果。好比：a=1;b=2;c=a+b这三个操做,前两个操做能够重排序，可是c=a+b不会被重排序，由于要保证结果是3

1.2 使用场景

对于一个变量，只有一个线程执行写操做，其它线程都是读操做，这时候能够用 volatile 修饰这个变量。

1.3 单例双重锁为何要用到volatile？

public class TestInstance {
private static volatile TestInstance mInstance;
public static TestInstance getInstance(){ //1
 if (mInstance == null){ //2
 synchronized (TestInstance.class){ //3
 if (mInstance == null){ //4
 mInstance = new TestInstance(); //5
 }
 }
 }
 return mInstance;
}
复制代码

}

假如没有用volatile，并发状况下会出现问题，线程A执行到注释5 new TestInstance() 的时候，分为以下几个几步操做：

  1. 分配内存
  2. 初始化对象
  3. mInstance 指向内存

这时候若是发生指令重排，执行顺序是132，执行到第3的时候，线程B恰好进来了，而且执行到注释2，这时候判断mInstance 不为空，直接使用一个未初始化的对象。因此使用volatile关键字来禁止指令重排序。

1.4 volatile 原理

在JVM底层volatile是采用 内存屏障 来实现的，内存屏障会提供3个功能：

  1. 它确保指令重排序时不会把其后面的指令排到内存屏障以前的位置，也不会把前面的指令排到内存屏障的后面；即在执行到内存屏障这句指令时，在它前面的操做已经所有完成；
  2. 它会强制将缓存的修改操做当即写到主内存
  3. 写操做会致使其它CPU中的缓存行失效，写以后，其它线程的读操做会从主内存读。

1.5 volatile 的局限性

**volatile 只能保证可见性，不能保证原子性。**写操做对其它线程可见，可是不能解决多个线程同时写的问题。

2、Synchronized

2.1 Synchronized 使用场景

多个线程同时写一个变量。

例如售票，余票是100张，窗口A和窗口B同时各卖出一张票， 假如余票变量用 volatile 修饰，是有问题的。

A窗口获取余票是100，B窗口获取余票也是100，A卖出一张变成99，刷新回主内存，同时B卖出一张变成99，也刷新回主内存，会致使最终主内存余票是99而不是98。

前面说到 volatile 的局限性，就是多个线程同时写的状况，这种状况通常可使用 Synchronized 。

Synchronized 能够保证同一时刻，只有一个线程可执行某个方法或某个代码块。

2.2 Synchronized 原理

public class SynchronizedTest {
public static void main(String[] args) {
 synchronized (SynchronizedTest.class) {
 System.out.println("123");
 }
 method();
}
private static void method() {
}
}
复制代码

将这段代码先用 javac 命令编译，再 java p -v SynchronizedTest.class 命令查看字节码，部分字节码以下

public static void main(java.lang.String[]);
descriptor: ([Ljava/lang/String;)V
flags: ACC_PUBLIC, ACC_STATIC
Code:
 stack=2, locals=3, args_size=1
 0: ldc #2 // class com/lanshifu/opengldemo/test/SynchronizedTest
 2: dup
 3: astore_1
 4: monitorenter
 5: getstatic #3 // Field java/lang/System.out:Ljava/io/PrintStream;
 8: ldc #4 // String 123
 10: invokevirtual #5 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
 13: aload_1
 14: monitorexit
 15: goto 23
 18: astore_2
 19: aload_1
 20: monitorexit
 21: aload_2
 22: athrow
 23: invokestatic #6 // Method method:()V
 26: return
复制代码

能够看到 4: monitorenter 和 14: monitorexit ，中间是打印的语句。

执行同步代码块，首先会执行 monitorenter 指令，而后执行同步代码块中的代码，退出同步代码块的时候会执行 monitorexit 指令 。

使用Synchronized进行同步，其关键就是必需要对对象的监视器monitor进行获取，当线程获取monitor后才能继续往下执行，不然就进入同步队列，线程状态变成BLOCK，同一时刻只有一个线程可以获取到monitor，当监听到monitorexit被调用，队列里就有一个线程出队，获取monitor。

每一个对象拥有一个计数器，当线程获取该对象锁后，计数器就会加一，释放锁后就会将计数器减一，因此只要这个锁的计数器大于0，其它线程访问就只能等待。

2.3 Synchronized 锁的升级

你们对Synchronized的理解可能就是重量级锁，可是Java1.6对 Synchronized 进行了各类优化以后，有些状况下它就并不那么重，Java1.6 中为了减小得到锁和释放锁带来的性能消耗而引入的偏向锁和轻量级锁。

偏向锁：大多数状况下，锁不只不存在多线程竞争，并且老是由同一线程屡次得到，为了让线程得到锁的代价更低而引入了偏向锁。

当一个线程A访问加了同步锁的代码块时，会在对象头中存 储当前线程的id，后续这个线程进入和退出这段加了同步锁的代码块时，不须要再次加锁和释放锁。

轻量级锁：在偏向锁状况下，若是线程B也访问了同步代码块，比较对象头的线程id不同，会升级为轻量级锁，而且经过自旋的方式来获取轻量级锁。

重量级锁：若是线程A和线程B同时访问同步代码块，则轻量级锁会升级为重量级锁，线程A获取到重量级锁的状况下，线程B只能入队等待，进入BLOCK状态。

2.4 Synchronized 缺点

  1. 不能设置锁超时时间
  2. 不能经过代码释放锁
  3. 容易形成死锁

3、ReentrantLock

上面说到 Synchronized 的缺点，不能设置锁超时时间和不能经过代码释放锁， ReentranLock就能够解决这个问题。

在多个条件变量和高度竞争锁的地方，用ReentrantLock更合适，ReentrantLock还提供了 Condition ，对线程的等待和唤醒等操做更加灵活，一个ReentrantLock能够有多个Condition实例，因此更有扩展性。

3.1 ReentrantLock 的使用

lock 和 unlock

ReentrantLock reentrantLock = new ReentrantLock();
 System.out.println("reentrantLock->lock");
 reentrantLock.lock();
 try {

 System.out.println("睡眠2秒...");
 Thread.sleep(2000);
 } catch (InterruptedException e) {
 e.printStackTrace();
 }finally {
 reentrantLock.unlock();
 System.out.println("reentrantLock->unlock");
 }
复制代码

实现可定时的锁请求：tryLock

public static void main(String[] args) {
 ReentrantLock reentrantLock = new ReentrantLock();
 Thread thread1 = new Thread_tryLock(reentrantLock);
 thread1.setName("thread1");
 thread1.start();
 Thread thread2 = new Thread_tryLock(reentrantLock);
 thread2.setName("thread2");
 thread2.start();
}
 static class Thread_tryLock extends Thread {
 ReentrantLock reentrantLock;
 public Thread_tryLock(ReentrantLock reentrantLock) {
 this.reentrantLock = reentrantLock;
 }
 @Override
 public void run() {
 try {
 System.out.println("try lock:" + Thread.currentThread().getName());
 boolean tryLock = reentrantLock.tryLock(3, TimeUnit.SECONDS);
 if (tryLock) {
 System.out.println("try lock success :" + Thread.currentThread().getName());
 System.out.println("睡眠一下：" + Thread.currentThread().getName());
 Thread.sleep(5000);
 System.out.println("醒了：" + Thread.currentThread().getName());
 } else {
 System.out.println("try lock 超时 :" + Thread.currentThread().getName());
 }
 } catch (InterruptedException e) {
 e.printStackTrace();
 } finally {
 System.out.println("unlock:" + Thread.currentThread().getName());
 reentrantLock.unlock();
 }
 }
 }
复制代码

打印的日志：

try lock:thread1
try lock:thread2
try lock success :thread2
睡眠一下：thread2
try lock 超时 :thread1
unlock:thread1
Exception in thread "thread1" java.lang.IllegalMonitorStateException
    at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:151)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1261)
    at java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:457)
    at com.lanshifu.demo_module.test.lock.ReentranLockTest$Thread_tryLock.run(ReentranLockTest.java:60)
醒了：thread2
unlock:thread2
复制代码

上面演示了 trtLock 的使用， trtLock 设置获取锁的等待时间，超过3秒直接返回失败，能够从日志中看到结果。 有异常是由于thread1获取锁失败，不该该调用unlock。

3.2 Condition 条件

public static void main(String[] args) {
 Thread_Condition thread_condition = new Thread_Condition();
 thread_condition.setName("测试Condition的线程");
 thread_condition.start();
 try {
 Thread.sleep(2000);
 } catch (InterruptedException e) {
 e.printStackTrace();
 }
 thread_condition.singal();
 }
static class Thread_Condition extends Thread {
 @Override
 public void run() {
 await();
 }
 private ReentrantLock lock = new ReentrantLock();
 public Condition condition = lock.newCondition();
 public void await() {
 try {
 System.out.println("lock");
 lock.lock();
 System.out.println(Thread.currentThread().getName() + ":我在等待通知的到来...");
 condition.await();//await 和 signal 对应
 //condition.await(2, TimeUnit.SECONDS); //设置等待超时时间
 System.out.println(Thread.currentThread().getName() + ":等到通知了，我继续执行>>>");
 } catch (Exception e) {
 e.printStackTrace();
 } finally {
 System.out.println("unlock");
 lock.unlock();
 }
 }
 public void singal() {
 try {
 System.out.println("lock");
 lock.lock();
 System.out.println("我要通知在等待的线程，condition.signal()");
 condition.signal();//await 和 signal 对应
 Thread.sleep(1000);
 } catch (InterruptedException e) {
 e.printStackTrace();
 } finally {
 System.out.println("unlock");
 lock.unlock();
 }
 }
 }
复制代码

运行打印日志

lock
测试Condition的线程:我在等待通知的到来...
lock
我要通知在等待的线程，condition.signal()
unlock
测试Condition的线程:等到通知了，我继续执行>>>
unlock
复制代码

上面演示了 Condition的 await 和 signal 使用，前提要先lock。

3.3 公平锁与非公平锁

ReentrantLock 构造函数传true表示公平锁。

公平锁表示线程获取锁的顺序是按照线程加锁的顺序来分配的，即先来先得的顺序。而非公平锁就是一种锁的抢占机制，是随机得到锁的，可能会致使某些线程一致拿不到锁，因此是不公平的。

3.4 ReentrantLock 注意点

  1. ReentrantLock使用lock和unlock来得到锁和释放锁
  2. unlock要放在finally中，这样正常运行或者异常都会释放锁
  3. 使用condition的await和signal方法以前，必须调用lock方法得到对象监视器

4、并发包

经过上面分析，并发严重的状况下，使用锁显然效率低下，由于同一时刻只能有一个线程能够得到锁，其它线程只能乖乖等待。

Java提供了并发包解决这个问题，接下来介绍并发包里一些经常使用的数据结构。

4.1 ConcurrentHashMap

咱们都知道HashMap是线程不安全的数据结构，HashTable则在HashMap基础上，get方法和put方法加上Synchronized修饰变成线程安全，不过在高并发状况下效率底下，最终被 ConcurrentHashMap 替代。

ConcurrentHashMap 采用分段锁，内部默认有16个桶，get和put操做，首先将key计算hashcode，而后跟16取余，落到16个桶中的一个，而后每一个桶中都加了锁（ReentrantLock），桶中是HashMap结构（数组加链表，链表过长转红黑树）。

因此理论上最多支持16个线程同时访问。

4.2 LinkBlockingQueue

链表结构的阻塞队列，内部使用多个ReentrantLock

/** Lock held by take, poll, etc */
 private final ReentrantLock takeLock = new ReentrantLock();
 /** Wait queue for waiting takes */
 private final Condition notEmpty = takeLock.newCondition();
 /** Lock held by put, offer, etc */
 private final ReentrantLock putLock = new ReentrantLock();
 /** Wait queue for waiting puts */
 private final Condition notFull = putLock.newCondition();
private void signalNotEmpty() {
 final ReentrantLock takeLock = this.takeLock;
 takeLock.lock();
 try {
 notEmpty.signal();
 } finally {
 takeLock.unlock();
 }
 }
 /**
 * Signals a waiting put. Called only from take/poll.
 */
 private void signalNotFull() {
 final ReentrantLock putLock = this.putLock;
 putLock.lock();
 try {
 notFull.signal();
 } finally {
 putLock.unlock();
 }
 }
复制代码

源码不贴太多，简单说一下 LinkBlockingQueue 的逻辑：

  1. 从队列获取数据，若是队列中没有数据，会调用 notEmpty.await(); 进入等待。
  2. 在放数据进去队列的时候会调用 notEmpty.signal(); ，通知消费者，1中的等待结束，唤醒继续执行。
  3. 从队列里取到数据的时候会调用 notFull.signal(); ，通知生产者继续生产。
  4. 在put数据进入队列的时候，若是判断队列中的数据达到最大值，那么会调用 notFull.await(); ，等待消费者消费掉，也就是等待3去取数据而且发出 notFull.signal(); ，这时候生产者才能继续生产。

LinkBlockingQueue 是典型的生产者消费者模式，源码细节就很少说。

4.3 原子操做类：AtomicInteger

内部采用CAS（compare and swap）保证原子性

举一个int自增的例子

AtomicInteger atomicInteger = new AtomicInteger(0);
 atomicInteger.incrementAndGet();//自增
复制代码

源码看一下

/**
 * Atomically increments by one the current value.
 *
 * @return the updated value
 */
 public final int incrementAndGet() {
 return U.getAndAddInt(this, VALUE, 1) + 1;
 }
复制代码

U 是 Unsafe，看下 Unsafe#getAndAddInt

public final int getAndAddInt(Object var1, long var2, int var4) {
 int var5;
 do {
 var5 = this.getIntVolatile(var1, var2);
 } while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));
 return var5;
 }
复制代码

经过 compareAndSwapInt 保证原子性。

总结

面试中问到多线程并发问题，能够这么答：

  1. 当只有一个线程写，其它线程都是读的时候，能够用 volatile 修饰变量
  2. 当多个线程写，那么通常状况下并发不严重的话能够用 Synchronized ，Synchronized并非一开始就是重量级锁，在并发不严重的时候，好比只有一个线程访问的时候，是偏向锁；当多个线程访问，但不是同时访问，这时候锁升级为轻量级锁；当多个线程同时访问，这时候升级为重量级锁。因此在并发不是很严重的状况下，使用Synchronized是能够的。不过Synchronized有局限性，好比不能设置锁超时，不能经过代码释放锁。
  3. ReentranLock 能够经过代码释放锁，能够设置锁超时。
  4. 高并发下，Synchronized、ReentranLock 效率低，由于同一时刻只有一个线程能进入同步代码块，若是同时有不少线程访问，那么其它线程就都在等待锁。这个时候可使用并发包下的数据结构，例如 ConcurrentHashMap ， LinkBlockingQueue ，以及原子性的数据结构如： AtomicInteger 。

面试的时候按照上面总结的这个思路回答基本就ok了。既然说到并发包，那么除了 ConcurrentHashMap ，其它一些经常使用的数据结构的原理也须要去了解下，例如 HashMap、HashTabel、TreeMap原理， Arraylist、LinkList 对比，这些都是老生常谈的，本身去看源码或者一些博客，还有一些Java后端面试题也能去看看。

关于多线程并发就先总结到这里，若是是应付面试的话按照这篇文章的思路来准备应该是没太大问题的。

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程