并发编程篇

并发编程篇

线程基础

线程和进程的区别

面试官: 说一下线程和进程的区别?

候选人:

嗯,好~

  • 进程是正在运行程序的实例,进程中包含了线程,每个线程执行不同的任务
  • 不同的进程使用不同的内存空间,在当前进程下的所有线程可以共享内存空间
  • 线程更轻量,线程上下文切换成本一般上要比进程上下文切换低(上下文切换指的是从一个线程切换到另一个线程)

并行与并发的区别

面试官: 聊一下并行和并发有什么区别?

候选人:

是这样的~~

现在都是多核CPU,在多核CPU下

并发是同一时间应对多件事情的能力,多个线程轮流使用一个或多个CPU

并行是同一时间动手做多件事情的能力,4核CPU同时执行4个线程

线程创建的方式

面试官: 如果在Java中创建线程有哪些方式?

候选人:

在Java中一共有四种常见的创建方式,分别是:继承Thread类、实现runnable接口、实现Callable接口、线程池创建线程。通常情况下,我们项目中都会采用线程池的方式创建线程。

面试官: 好的,刚才你说的runnable 和 callable 两个接口创建线程有什么不同呢?

候选人:

是这样的~

最主要的两个线程一个是有返回值,一个是没有返回值的。

Runnable 接口run方法无返回值;Callable接口call方法有返回值,是个泛型,和Future、FutureTask配合可以用来获取异步执行的结果

还有一个就是,他们异常处理也不一样。Runnable接口run方法只能抛出运行时异常,也无法捕获处理;Callable接口call方法允许抛出异常,可以获取异常信息

在实际开发中,如果需要拿到执行的结果,需要使用Callable接口创建线程。调用FutureTask.get()可以得到返回值,此方法会阻塞主线程的继续往下执行,如果不调用不会阻塞。

面试官: run()和start()有什么区别?

候选人:

  • start():用来启动线程,通过该线程调用run方法执行run方法中所定义的逻辑代码。start方法只能调用一次。
  • run():封装了要被执行的代码,可以被调用很多次。

线程的状态

面试官: 线程包括哪些状态,状态之间是如何变化的?

候选人:

在JDK中的Thread类中的枚举State里面定义了6种线程的状态分别是:新建、可运行、终结、阻塞、等待和有时限等待六种。

关于线程的状态切换情况比较多。我分别介绍一下

当一个线程对象被创建,但还未被调用 start 方法时处于新建状态,调用了 start 方法,就会由新建进入可运行状态。如果线程内部代码已经执行完毕,由可运行进入终结状态。当然这些是一个线程正常执行情况。

如果线程获取锁失败后,由可运行进入 Monitor 的阻塞队列阻塞,只有当持锁线程释放锁时,会按照一定规则唤醒阻塞队列中的阻塞线程,唤醒后的线程进入可运行状态

如果线程获取锁成功后,但由于条件不满足,调用了 wait()方法,此时从可运行状态释放锁等待状态,当其它持锁线程调用 notify9() 或 notifyAll()方法,会恢复为可运行状态

还有一种情况是调用 sleep(long)方法也会从可运行状态进入有时限等待状态,不需要主动唤醒,超时时间到自然恢复为可运行状态

线程按顺序执行

面试官: 好的,我现在举一个场景,你来分析一下怎么做,新建T1、T2、T3 三个线程,如何保证它们按顺序执行?

候选人:

嗯~~,我思考一下(适当的思考或想一下属于正常情况,脱口而出反而太假[背诵痕迹])

可以这么做,在多线程种有多种方法让线程按特定顺序执行,可以用线程的join()方法在一个线程中启动另一个线程,另外一个线程完成该线程继续执行。

比如说:

使用join方法,T3调用T2,T2调用T1,这样就能确保T1就会先完成而T3最后完成

面试官: notify()和notifyAll()有什么区别?

候选人:

  • notifyAll:唤醒所有wait的线程
  • notify:只随机唤醒一个 wait 线程

wait和sleep方法的不同

面试官: 嗯,好的,刚才你说的线程中的 wait 和 sleep 方法有什么不同呢?

候选人:

wait(),wait(long) 和 sleep(long) 的效果都是让当前线程暂时放弃 CPU 的使用权,进入阻塞状态。

不同点主要有三个方面:

第一:方法归属不同

sleep(long)是 Thread 的静态方法。而wait(),是 Object 的成员方法,每个对象都有

第二:醒来时机不同

线程执行sleep(long)会在等待相应毫秒后醒来,而wait()需要被 notify 唤醒,wait()如果不唤醒就一直等下去

第三:锁特性不同

wait 方法的调用必须先获取 wait 对象的锁,而sleep 则无此限制

wait 方法执行后会释放对象锁,允许其它线程获得该对象锁(相当于我放弃 cpu,但你们还可以用)

而sleep 如果在 synchronized 代码块种执行,并不会释放对象锁(相当于我放弃 cpu,你们也用不了)

如何停止一个正在运行的线程

面试官: 那如何停止一个正在运行的线程呢?

候选人:

有三种方式可以停止线程

第一:可以使用退出标志,使线程正常退出,也就是当run方法完成后线程终止,一般我们加一个标记

第二:可以使用线程的stop方法强行终止,不过一般不推荐,这个方法已作废

第三:可以使用线程的interrupt方法中断线程,内部其实也是使用中断标志来中断线程

我们项目种使用的话,建议使用第一种或第三种方式中断线程

线程安全

synchronized关键字的底层原理(基础回答)

面试官: 讲一下synchronized关键字的底层原理?

候选人:

嗯~~好的,

synchronized 底层使用的JVM级别的级别中的Monitor 来决定当前线程是否获得了锁,如果某一个线程获得了锁,在没有释放锁之前,其他线程是不能得到锁的。synchronized 属于悲观锁。

synchronized 因为需要依赖JVM级别的Monitor,相对性能也比较低。

面试官: 好的,你能具体说下Monitor 吗?

候选人:

monitor对象存在于每个Java对象的对象头中,synchronized 锁便是通过这种方式获取锁的,也是为什么Java对象中任意对象可以作为锁的原因

monitor内部维护了三个变量

  • WaitSet:保存处于Waiting状态的线程
  • EntryList:保存处于Blocked状态的线程
  • Owner:持有锁的线程

只有一个线程获取到的标志就是在monitor中设置了Owner,一个monitor中只能有一个Owner

在上锁的过程中,如果有其他线程也来抢锁,则进入EntryList 进行阻塞,当获得锁的线程执行完了,释放了锁,就会唤醒EntryList 中等待的线程竞争锁,竞争的时候是非公平的。

synchronized关键字的底层原理(进阶回答)

面试官: 好的,那关于synchronized 的锁升级的情况了解吗?

候选人:

嗯,知道一些(要谦虚)

Java中的synchronized有偏向锁、轻量级锁、重量级锁三种形式,分别对应了锁只被一个线程持有、不同线程交替持有锁、多线程竞争锁三种情况。

重量级锁:底层使用的Monitor实现,里面涉及到了用户态和内核态的切换、进程的上下文切换,成本较高,性能比较低。

轻量级锁:线程加锁的时间是错开的(也就是没有竞争),可以使用轻量级锁来优化。轻量级修改了对象头的锁标志,相对重量级锁性能提升很多。每次修改都是CAS操作,保证原子性

偏向锁:一段很长的时间内都只被一个线程使用锁,可以使用偏向锁,在第一次获得锁时,会有一个CAS操作,之后该线程再获取锁,只需要判断mark word中是否是自己的线程id即可,而不是开销相对较大的CAS命令

一旦锁发生了竞争,都会升级为重量级锁

JMM(Java内存模型)

面试官: 你谈谈 JMM(Java内存模型)

候选人:

  • JMM(Java Memory Model)Java内存模型,定义了共享内存多线程程序读写操作的行为规范,通过这些规则来规范对内存的读写操作从而保证指令的正确性
  • JMM把内存分为两块,一块是私有线程的工作区域(工作内存),一块是所有线程的共享区域(主内存)
  • 线程跟线程之间是相互隔离,线程跟线程交互需要通过主内存

你谈谈对CAS的理解

面试官: CAS 你知道吗?

候选人:

  • CAS的全称是:Compare And Swap(比较再交换);它体现的一种乐观锁的思想,在无锁状态下保证线程操作数据的原子性。
  • CAS使用到的地方很多:AQS框架、AtomicXXX类
  • 在操作共享变量的时候实用的自旋锁,效率上更高一些
  • CAS的底层是调用的Unsafe类中的方法,都是操作系统提供的,其他语言实现(C,C++)

面试官: 乐观锁和悲观锁的区别?

候选人:

  • CAS 是基于乐观锁的思想:最乐观的估计,不怕别的线程来修改共享变量,就算改了也没关系,我吃点亏再重试呗。
  • synchronized 是基于悲观锁的思想:最悲观的估计,得防着其他线程来修改共享变量,我上了锁你们都别想改,我改完了解开锁,你们才有机会。

请谈谈你对volatile 的理解

面试官: 请谈谈你对 volatile 的理解?

候选人:

①保证线程间的可见性

用volatile修饰共享变量,能够防止编译器等优化发生,让一个线程对共享变量的修改对另一个线程可见

②禁止进行指令重排序

指令重排:用volatile修饰共享变量会在读、写共享变量时加入不同的屏障,阻止其他读写操作越过屏障,从而达到阻止重排序的效果

什么是AQS

面试官: 什么是AQS?

候选人:

  • 是多线程中的队列同步器。是一种锁机制,它是作为一个基础框架使用的,像ReentrantLock、Semaphore都是基于AQS实现的
  • AQS内部维护了一个先进先出的双向队列,队列中存储的排队的线程
  • 在AQS内部还有一个属性state,这个state就相当于是一个资源,默认是0(无锁状态),如果队列中的有一个线程修改成功了state为1,则当前线程就相当于获取了资源
  • 在对state修改的时候使用的cas操作,保证多个线程修改的情况下原子性

ReentrantLock的实现原理

面试官: 好的,你刚才说了下synchronized它在高并发量的情况下,性能不高,在项目中该如何控制使用锁呢?

候选人:

嗯,其实,在高并发下,我们可以使用ReentrantLock来加锁。

面试官: 嗯,那你说下ReentrantLock的使用方式和底层原理?

候选人:

好的,ReentrantLock是一个可重入锁;调用 lock 方法获取了锁之后,再次调用 lock,是不会再阻塞,内部直接增加重入次数就行了,标识这个线程已经重复获取一把锁而不需要等待锁的释放。

ReentrantLock是属于juc包下的类,属于api层面的锁,跟synchronized一样,都是悲观锁。通过lock()用来获取锁,unlock()释放锁。

它的底层实现原理主要利用CAS+AQS队列来实现。它支持公平锁和非公平锁,两者的实现类似

构造方法接受一个可选的公平参数(默认非公平锁),当设置为true时,表示公平锁,否则为非公平锁。公平锁的效率往往没有非公平锁的效率高。

面试官: 好的,刚才你说了CAS和AQS,你能介绍一下吗?

候选人:

好的。

CAS的全称是:Compare And Swap(比较再交换);它体现的一种乐观锁的思想,在无锁状态下保证线程操作数据的原子性。

  • CAS使用到的地方很多:AQS框架、AutomicXXX类
  • 在操作共享变量的时候使用的自旋锁,效率上更高一些
  • CAS的底层是调用的Unsafe类中的方法,都是操作系统提供的,其他语言实现

AQS的话,其实就一个jdk提供的类AbstractQueuedSynchronizer,是阻塞式和相关的同步器工具的框架。

内部有一个属性state来表示资源的状态,默认state等于0,表示没有获取锁,state等于1的时候才标明获取到了锁。通过cas机制设置state状态

在它的内部还提供了基于 FIFO 的等待队列,是一个双向列表,其中

  • tail 指向队列最后一个元素
  • head 指向队列中最久的一个元素

其实我们刚刚聊的ReentrantLock底层的实现就是一个AQS。

synchronized和Lock有什么区别

面试官: synchronized和Lock有什么区别 ?

候选人:

嗯~~,好的,主要有三个方面不太一样

第一,语法层面

  • synchronized 是关键字,源码在 jvm 中,用 c++ 语言实现,退出同步代码块锁会自动释放
  • Lock 是接口,源码由 jdk 提供,用 java 语言实现,需要手动调用 unlock 方法释放锁

第二,功能层面

  • 二者均属于悲观锁、都具备基本的互斥、同步、锁重入功能
  • Lock 提供了许多 synchronized 不具备的功能,例如获取等待状态、公平锁、可打断、可超时、多条件变量,同时Lock锁可以实现不同的场景,如ReentrantLock、ReentrantReadWriteLock

第三、性能层面

  • 在没有竞争时,synchronized 做了很多优化,如偏向锁、轻量级锁,性能不赖
  • 在竞争激烈时,Lock的实现通常会提供更好的性能

综合来看,需要根据不同的场景来选择不同的锁的使用。

死锁产生的条件以及死锁排查方案

面试官: 死锁产生的条件是什么 ?

候选人:

嗯,是这样的,一个线程需要同时获取多把锁,这时就容易发生死锁,举个例子来说:

t1 线程获得A对象锁,接下来想获取B对象的锁

t2 线程获得B对象锁,接下来想获取A对象的锁

这个时候t1线程和t2线程都在互相等待对方的锁,就产生了死锁

面试官: 那如果产生了这样的,如何进行死锁诊断 ?

候选人:

这个也容易,我们只需要通过jdk自动的工具就能搞定

我们可以先通过jps来查看当前Java程序运行的进程id

然后通过jstack来查看这个进程id,就能展示出来死锁的问题,并且,可以定位代码的具体行号范围,我们再去找到对应的代码进行排查就行了。

另外还有可视化工具jconsole、VisualV

聊一下ConcurrentHasp

本文作者: 接《集合相关面试题》

面试官: 那你能聊一下ConcurrentHashMap的原理吗 ?

候选人:

好的,

ConcurrentHashMap 是一种线程安全的高效Map集合,jdk1.7和1.8也做了很多调整。

  • JDK1.7的底层采用的是分段的数组+链表 实现
  • JDK1.8采用的数据结构跟HashMap1.8的结构一样,数组+链表/红黑二叉树。

在jdk1.7中 ConcurrentHashMap 里面包含一个 Segment 数组。Segment 的结构和HashMap类似,是一种数组和链表结构,一个Segment 包含一个 HashEntry 数组,每个 HashEntry 是一个链表结构的元素,每个 Segment 守护着一个HashEntry数组里的元素,当对 HashEntry 数组的数据进行修改时,必须首先获得对应的 Segment 的锁。

Segment 是一种可重入的锁 ReentrantLock,每个 Segment 守护一个 HashEntry 数组里的元素,当对 HashEntry 数组的数据进行修改时,必须首先获得对应的 Segment 锁

在jdk1.8中的 ConcurrentHashMap 做了较大的优化,性能提升了不少。首先是它的数据结构与jdk1.8的hashMap数据结构完全一致。其次是放弃了Segment臃肿的设计,取而代之的是采用Node + CAS + Synchronized来保证并发安全进行实现,synchronized只锁定当前链表或红黑二叉树的首节点,这样只要hash不冲突,就不会产生并发,效率得到提升。

导致并发程序出现问题的根本原因是什么

面试官: 导致并发程序出现问题的根本原因是什么 ?

候选人:

  1. 原子性:synchronized、lock
  2. 内存可见性:volatile、synchronized、lock
  3. 有序性:volatile

**面试官:**好的,那该如何保证Java程序在多线程的情况下执行安全呢?

候选人:

嗯,刚才讲过了导致线程安全的原因,如果解决的话,jdk中也提供了很多的类帮助我们解决多线程安全的问题,比如:

  • JDK Atomic开头的原子类、synchronized、LOCK,可以解决原子性问题
  • synchronized、volatile、LOCK,可以解决可见性问题
  • Happens-Before 规则可以解决有序性问题

线程池

说一下线程池的核心参数(线程池的执行原理知道嘛)

面试官: 线程池的核心参数有哪些 ?

候选人:

在线程池中一共有7个核心参数:

  1. corePoolSize 核心线程数目 - 池中会保留的最多线程数
  2. maximumPoolSize 最大线程数目 - 核心线程 + 救急线程的最大数目
  3. keepAliveTime 生存时间 - 救急线程的生存时间,生存时间内没有新任务,此线程资源会释放
  4. unit 时间单位 - 救急线程的生存时间单位,如秒、毫秒等
  5. workQueue - 当没有空闲核心线程时,新来任务会加入此队列排队,队列满会创建救急线程执行任务
  6. threadFactory 线程工厂 - 可以定制线程对象的创建,例如设置线程名字、是否是守护线程等
  7. handler 拒绝策略 - 当所有线程都在繁忙,workQueue 也放满时,会触发拒绝策略

在拒绝策略中又有4种拒绝策略

当线程数过多以后,第一种是抛线程、第二种是由调用者执行任务、第三是丢弃当前的任务,第四是丢弃最早排队任务。默认是直接抛异常。

面试官:线程池的执行原理知道吗?

候选人

嗯~,它是这样的

首先判断线程池里的核心线程是否都在执行任务,如果不是则创建一个新的工作线程来执行任务。如果核心线程都在执行任务,则线程池判断工作队列是否已满,如果工作队列没有满,则将新提交的任务存储在这个工作队 列里。如果工作队列满了,则判断线程池里的线程是否都处于工作状态,如果没有,则创建一个新的工作线程来执行任 务。如果已经满了,则交给拒绝策略来处理这个任务。

线程池有哪些常见的阻塞队列

面试官: 线程池有哪些常见的阻塞队列 ?

候选人:

workQueue - 当没有空闲核心线程时,新来任务会加入此队列排队,队列满会创建救急线程执行任务

  1. ArrayBlockingQueue:基于数组结构的有界阻塞队列,FIFO。
  2. LinkedBlockingQueue:基于链表结构的有界阻塞队列,FIFO。
  3. DelayedWorkQueue:是一个优先级队列,它可以保证每次出队的任务都是当前队列中执行时间最靠前的
  4. SynchronousQueue:不存储元素的阻塞队列,每个插入操作都必须等待一个移出操作

ArrayBlockingQueueLinkedBlockingQueue的区别

ArrayBlockingQueue:强制有界、底层是数组、提前初始化 Node 数组、Node需要是提前创建好的、一把锁

LinkedBlockingQueue:默认无界,支持有界、底层是链表、是懒惰的,创建节点的时候添加数据、入队会生成新 Node、两把锁(头尾)

如何确定核心线程数

面试官: 如何确定核心线程池呢 ?

候选人:

是这样的,我们公司当时有一些规范,为了减少线程上下文的切换,要根据当时部署的CPU核数来决定,我们规则是:CPU核数 + 1就是最终的核心线程数
并发编程篇_第1张图片

线程池的种类有哪些

面试官: 线程池的种类有哪些 ?

候选人:

嗯!是这样

在jdk中默认提供了4种方式创建线程池

第一个是:newCachedThreadPool创建一个可缓存线程池,如果线程池长度超过处理需要,可灵活回收空闲线程,若无可回收,则新建线程。

第二个是:newFixedThreadPool创建一个定长线程池,可控制线程最大并发数,超出的线程会在队列中等待。

第三个是:newScheduledThreadPool创建一个定长线程池,支持定时及周期性任务执行。

第四个是:newSingleThreadExecutor创建了一个单线程化的线程池,它只会用唯一的工作线程来执行任务,保证所有任务按照指定顺序(FIFO,LIFO,优先级)执行。

为什么不建议用Executors创建线程池

面试官: 为什么不建议用Executors创建线程池 ?

候选人:

好的,其实这个事情在阿里提供的开发手册《Java开发手册-嵩山版》中也提到了

主要原因是如果使用Executors创建线程池的话,它允许的请求队列默认长度是Integer.MAX_VALUE,这样的话,有可能导致堆积大量的请求,从而导致OOM(内存溢出)。

所以,我们一般推荐使用ThreadPoolExecutor来创建线程池,这样可以明确规定线程池的参数,避免资源的耗尽。

使用场景

ES数据批量导入、数据汇总、异步线程

面试官: 你在项目中哪里用了多线程 ?

候选人:

嗯~~,我想一下当时的场景[根据自己简历上的模块设计多线程场景]

参考场景一:

es数据批量导入

在我们项目上线前,我们需要把数据量的数据一次性的同步到es索引库中,但是当时的数据好像是1000万左右,一次性读取数据肯定不行(omm异常),如果分批执行的话,耗时也太久了。所以,当时我就想到可以使用线程池的方式导入,利用CountDownLatch+Future来控制,就能大大提升导入的时间。

参考场景二:

在我做的那个xx电商网站的时候,里面有一个数据汇总的功能,在用户下单之后需要查询订单信息,也需要获得订单中的商品详细信息(可能是多个),还需要查看物流发货信息。因为它们三个对应的分别三个微服务,如果一个一个的操作的话,互相等待的时间比较长。所以,我当时就想到可以使用线程池,让多个线程同时处理,最终再汇总结果就可以了,当然里面需要用到Future来获取每个线程执行之后的结果才行。

参考场景三:

《黑马头条》项目中使用的

我当时做了一个文章搜索的功能,用户输入关键字要搜索文章,同时需要保存用户的搜索记录(搜索历史),这块我设计的时候,为了不影响用户的正常搜索,我们采用的异步的方式进行保存的,为了提升性能,我们加入了线程池,也就说在调用异步方法的时候,直接从线程池中获取线程使用

如何控制某个方法允许并发访问线程的数量

面试官: 如何控制某一个方法允许并发访问线程的数量 ?

候选人:

嗯~~,我想一下

在jdk中提供了一个Semaphore类(信号量)

它提供了两个方法,semaphore.acquire()请求信号量,可以限制线程的个数,是一个正数,如果信号量是-1,就代表已经用完了信号量,其他线程需要阻塞了

第二个方法是semaphore.release(),代表是释放了一个信号量,此时信号量的个数+1

其他

谈谈你对ThreadLocal的理解

面试官: 谈谈你对ThreadLocal的理解 ?

候选人:

嗯,是这样的~~

ThreadLocal主要功能有两个,第一个是可以实现资源对象的线程隔离,让每个线程各用各的资源对象,避免争用引发的线程安全问题,第二个是实现了线程内的资源共享

面试官: 好的,那你知道ThreadLocal的底层原理实现吗?

候选人:

嗯,知道一些~

在ThreadLocal内部维护了一个一个ThreadLocalMap类型的成员变量,用来存储资源对象

当我们调用set方法,就是以ThreadLocal自己作为key,资源对象作为value,放入当前线程的ThreadLocalMap集合中

当调用get方法,就是以ThreadLocal自己作为key,到当前线程中查找关联的资源值

当调用remove方法,就是以ThreadLocal自己作为key,移出当前线程相关联的资源值

面试官: 好的,那关于ThreadLocal会导致内存溢出这个事情,了解吗?

候选人:

嗯,我之前看过源码,我想一下~~

是因为ThreadLocalMap中的key被设计为弱引用,它是被动的被GC调用释放key,不过关键的是只有key可以得到内存释放,而value不会,因为value是一个强引用。

在使用ThreadLocal时都把它作为静态变量(即强引用),因此无法被动依靠GC回收,建议主动地remove释放key,这样就能避免内存溢出

你可能感兴趣的:(面试,java,开发语言)