1.1 说一说本身对于 synchronized 关键字的了解java
synchronized关键字解决的是多个线程之间访问资源的同步性,synchronized关键字能够保证被它修饰的方法或者代码块在任意时刻只能有一个线程执行。面试
另外,在 Java 早期版本中,synchronized属于重量级锁,效率低下,由于监视器锁(monitor)是依赖于底层的操做系统的 Mutex Lock 来实现的,Java 的线程是映射到操做系统的原生线程之上的。若是要挂起或者唤醒一个线程,都须要操做系统帮忙完成,而操做系统实现线程之间的切换时须要从用户态转换到内核态,这个状态之间的转换须要相对比较长的时间,时间成本相对较高,这也是为何早期的 synchronized 效率低的缘由。庆幸的是在 Java 6 以后 Java 官方对从 JVM 层面对synchronized 较大优化,因此如今的 synchronized 锁效率也优化得很不错了。JDK1.6对锁的实现引入了大量的优化,如自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁等技术来减小锁操做的开销。编程
1.2 说说本身是怎么使用 synchronized 关键字,在项目中用到了吗数组
synchronized关键字最主要的三种使用方式:安全
下面我已一个常见的面试题为例讲解一下 synchronized 关键字的具体使用。多线程
面试中面试官常常会说:“单例模式了解吗?来给我手写一下!给我解释一下双重检验锁方式实现单利模式的原理呗!”并发
双重校验锁实现对象单例(线程安全)框架
另外,须要注意 uniqueInstance 采用 volatile 关键字修饰也是颇有必要。函数
uniqueInstance 采用 volatile 关键字修饰也是颇有必要的, uniqueInstance = new Singleton(); 这段代码实际上是分为三步执行:工具
可是因为 JVM 具备指令重排的特性,执行顺序有可能变成 1->3->2。指令重排在单线程环境下不会出先问题,可是在多线程环境下会致使一个线程得到尚未初始化的实例。例如,线程 T1 执行了 1 和 3,此时 T2 调用 getUniqueInstance() 后发现 uniqueInstance 不为空,所以返回 uniqueInstance,但此时 uniqueInstance 还未被初始化。
使用 volatile 能够禁止 JVM 的指令重排,保证在多线程环境下也能正常运行。
1.3 讲一下 synchronized 关键字的底层原理
synchronized 关键字底层原理属于 JVM 层面。
① synchronized 同步语句块的状况
经过 JDK 自带的 javap 命令查看 SynchronizedDemo 类的相关字节码信息:首先切换到类的对应目录执行 javac SynchronizedDemo.java 命令生成编译后的 .class 文件,而后执行javap -c -s -v -l SynchronizedDemo.class。
从上面咱们能够看出:
synchronized 同步语句块的实现使用的是 monitorenter 和 monitorexit 指令,其中 monitorenter 指令指向同步代码块的开始位置,monitorexit 指令则指明同步代码块的结束位置。 当执行 monitorenter 指令时,线程试图获取锁也就是获取 monitor(monitor对象存在于每一个Java对象的对象头中,synchronized 锁即是经过这种方式获取锁的,也是为何Java中任意对象能够做为锁的缘由) 的持有权.当计数器为0则能够成功获取,获取后将锁计数器设为1也就是加1。相应的在执行 monitorexit 指令后,将锁计数器设为0,代表锁被释放。若是获取对象锁失败,那当前线程就要阻塞等待,直到锁被另一个线程释放为止。
② synchronized 修饰方法的的状况
synchronized 修饰的方法并无 monitorenter 指令和 monitorexit 指令,取得代之的确实是 ACC_SYNCHRONIZED 标识,该标识指明了该方法是一个同步方法,JVM 经过该 ACC_SYNCHRONIZED 访问标志来辨别一个方法是否声明为同步方法,从而执行相应的同步调用。
1.4 说说 JDK1.6 以后的synchronized 关键字底层作了哪些优化,能够详细介绍一下这些优化吗
JDK1.6 对锁的实现引入了大量的优化,如偏向锁、轻量级锁、自旋锁、适应性自旋锁、锁消除、锁粗化等技术来减小锁操做的开销。
锁主要存在四中状态,依次是:无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态,他们会随着竞争的激烈而逐渐升级。注意锁能够升级不可降级,这种策略是为了提升得到锁和释放锁的效率。
1.5 谈谈 synchronized和ReenTrantLock 的区别
① 二者都是可重入锁
二者都是可重入锁。“可重入锁”概念是:本身能够再次获取本身的内部锁。好比一个线程得到了某个对象的锁,此时这个对象锁尚未释放,当其再次想要获取这个对象的锁的时候仍是能够获取的,若是不可锁重入的话,就会形成死锁。同一个线程每次获取锁,锁的计数器都自增1,因此要等到锁的计数器降低为0时才能释放锁。
② synchronized 依赖于 JVM 而 ReenTrantLock 依赖于 API
synchronized 是依赖于 JVM 实现的,前面咱们也讲到了 虚拟机团队在 JDK1.6 为 synchronized 关键字进行了不少优化,可是这些优化都是在虚拟机层面实现的,并无直接暴露给咱们。ReenTrantLock 是 JDK 层面实现的(也就是 API 层面,须要 lock() 和 unlock 方法配合 try/finally 语句块来完成),因此咱们能够经过查看它的源代码,来看它是如何实现的。
③ ReenTrantLock 比 synchronized 增长了一些高级功能
相比synchronized,ReenTrantLock增长了一些高级功能。主要来讲主要有三点:①等待可中断;②可实现公平锁;③可实现选择性通知(锁能够绑定多个条件)
若是你想使用上述功能,那么选择ReenTrantLock是一个不错的选择。
④ 性能已不是选择标准
2.1 讲一下Java内存模型
在 JDK1.2 以前,Java的内存模型实现老是从主存(即共享内存)读取变量,是不须要进行特别的注意的。而在当前的 Java 内存模型下,线程能够把变量保存本地内存(好比机器的寄存器)中,而不是直接在主存中进行读写。这就可能形成一个线程在主存中修改了一个变量的值,而另一个线程还继续使用它在寄存器中的变量值的拷贝,形成数据的不一致。
要解决这个问题,就须要把变量声明为 volatile,这就指示 JVM,这个变量是不稳定的,每次使用它都到主存中进行读取。
说白了, volatile 关键字的主要做用就是保证变量的可见性而后还有一个做用是防止指令重排序。
2.2 说说 synchronized 关键字和 volatile 关键字的区别
synchronized关键字和volatile关键字比较
3.1 为何要用线程池?
线程池提供了一种限制和管理资源(包括执行一个任务)。 每一个线程池还维护一些基本统计信息,例如已完成任务的数量。
这里借用《Java并发编程的艺术》提到的来讲一下使用线程池的好处:
3.2 实现Runnable接口和Callable接口的区别
若是想让线程池执行任务的话须要实现的Runnable接口或Callable接口。 Runnable接口或Callable接口实现类均可以被ThreadPoolExecutor或ScheduledThreadPoolExecutor执行。二者的区别在于 Runnable 接口不会返回结果可是 Callable 接口能够返回结果。
备注: 工具类Executors能够实现Runnable对象和Callable对象之间的相互转换。(Executors.callable(Runnable task)或Executors.callable(Runnable task,Object resule))。
3.3 执行execute()方法和submit()方法的区别是什么呢?
1)execute() 方法用于提交不须要返回值的任务,因此没法判断任务是否被线程池执行成功与否;
2)submit()方法用于提交须要返回值的任务。线程池会返回一个future类型的对象,经过这个future对象能够判断任务是否执行成功,而且能够经过future的get()方法来获取返回值,get()方法会阻塞当前线程直到任务完成,而使用 get(long timeout,TimeUnit unit)方法则会阻塞当前线程一段时间后当即返回,这时候有可能任务没有执行完。
3.4 如何建立线程池
《阿里巴巴Java开发手册》中强制线程池不容许使用 Executors 去建立,而是经过 ThreadPoolExecutor 的方式,这样的处理方式让写的同窗更加明确线程池的运行规则,规避资源耗尽的风险**
Executors 返回线程池对象的弊端以下:
方式一:经过构造方法实现
方式二:经过Executor 框架的工具类Executors来实现
咱们能够建立三种类型的ThreadPoolExecutor:
对应Executors工具类中的方法如图所示:
4.1 介绍一下Atomic 原子类
Atomic 翻译成中文是原子的意思。在化学上,咱们知道原子是构成通常物质的最小单位,在化学反应中是不可分割的。在咱们这里 Atomic 是指一个操做是不可中断的。即便是在多个线程一块儿执行的时候,一个操做一旦开始,就不会被其余线程干扰。
因此,所谓原子类说简单点就是具备原子/原子操做特征的类。
并发包 java.util.concurrent 的原子类都存放在java.util.concurrent.atomic下,以下图所示。
4.2 JUC 包中的原子类是哪4类?
基本类型
使用原子的方式更新基本类型
数组类型
使用原子的方式更新数组里的某个元素
引用类型
对象的属性修改类型
4.3 讲讲 AtomicInteger 的使用
AtomicInteger 类经常使用方法
AtomicInteger 类的使用示例
使用 AtomicInteger 以后,不用对 increment() 方法加锁也能够保证线程安全
4.4 能不能给我简单介绍一下 AtomicInteger 类的原理
AtomicInteger 线程安全原理简单分析
AtomicInteger 类的部分源码:
AtomicInteger 类主要利用 CAS (compare and swap) + volatile 和 native 方法来保证原子操做,从而避免 synchronized 的高开销,执行效率大为提高。
CAS的原理是拿指望的值和本来的一个值做比较,若是相同则更新成新的值。UnSafe 类的 objectFieldOffset() 方法是一个本地方法,这个方法是用来拿到“原来的值”的内存地址,返回值是 valueOffset。另外 value 是一个volatile变量,在内存中可见,所以 JVM 能够保证任什么时候刻任何线程总能拿到该变量的最新值。
5.1 AQS 介绍
AQS的全称为(AbstractQueuedSynchronizer),这个类在java.util.concurrent.locks包下面。
AQS是一个用来构建锁和同步器的框架,使用AQS能简单且高效地构造出应用普遍的大量的同步器,好比咱们提到的ReentrantLock,Semaphore,其余的诸如ReentrantReadWriteLock,SynchronousQueue,FutureTask等等皆是基于AQS的。固然,咱们本身也能利用AQS很是轻松容易地构造出符合咱们本身需求的同步器。
5.2 AQS 原理分析
AQS 原理这部分参考了部分博客,在5.2节末尾放了连接。
在面试中被问到并发知识的时候,大多都会被问到“请你说一下本身对于AQS原理的理解”。下面给你们一个示例供你们参加,面试不是背题,你们必定要假如本身的思想,即便加入不了本身的思想也要保证本身可以通俗的讲出来而不是背出来。
下面大部份内容其实在AQS类注释上已经给出了,不过是英语看着比较吃力一点,感兴趣的话能够看看源码。
5.2.1 AQS 原理概览
AQS核心思想是,若是被请求的共享资源空闲,则将当前请求资源的线程设置为有效的工做线程,而且将共享资源设置为锁定状态。若是被请求的共享资源被占用,那么就须要一套线程阻塞等待以及被唤醒时锁分配的机制,这个机制AQS是用CLH队列锁实现的,即将暂时获取不到锁的线程加入到队列中。
CLH(Craig,Landin,and Hagersten)队列是一个虚拟的双向队列(虚拟的双向队列即不存在队列实例,仅存在结点之间的关联关系)。AQS是将每条请求共享资源的线程封装成一个CLH锁队列的一个结点(Node)来实现锁的分配。
看个AQS(AbstractQueuedSynchronizer)原理图:
AQS使用一个int成员变量来表示同步状态,经过内置的FIFO队列来完成获取资源线程的排队工做。AQS使用CAS对该同步状态进行原子操做实现对其值的修改。
private volatile int state;//共享变量,使用volatile修饰保证线程可见性
状态信息经过procted类型的getState,setState,compareAndSetState进行操做
5.2.2 AQS 对资源的共享方式
AQS定义两种资源共享方式
ReentrantReadWriteLock 能够当作是组合式,由于ReentrantReadWriteLock也就是读写锁容许多个线程同时对某一资源进行读。
不一样的自定义同步器争用共享资源的方式也不一样。自定义同步器在实现时只须要实现共享资源 state 的获取与释放方式便可,至于具体线程等待队列的维护(如获取资源失败入队/唤醒出队等),AQS已经在顶层实现好了。
5.2.3 AQS底层使用了模板方法模式
同步器的设计是基于模板方法模式的,若是须要自定义同步器通常的方式是这样(模板方法模式很经典的一个应用):
这和咱们以往经过实现接口的方式有很大区别,这是模板方法模式很经典的一个运用。
AQS使用了模板方法模式,自定义同步器时须要重写下面几个AQS提供的模板方法:
默认状况下,每一个方法都抛出 UnsupportedOperationException。 这些方法的实现必须是内部线程安全的,而且一般应该简短而不是阻塞。AQS类中的其余方法都是final ,因此没法被其余类使用,只有这几个方法能够被其余类使用。
以ReentrantLock为例,state初始化为0,表示未锁定状态。A线程lock()时,会调用tryAcquire()独占该锁并将state+1。此后,其余线程再tryAcquire()时就会失败,直到A线程unlock()到state=0(即释放锁)为止,其它线程才有机会获取该锁。固然,释放锁以前,A线程本身是能够重复获取此锁的(state会累加),这就是可重入的概念。但要注意,获取多少次就要释放多么次,这样才能保证state是能回到零态的。
再以CountDownLatch以例,任务分为N个子线程去执行,state也初始化为N(注意N要与线程个数一致)。这N个子线程是并行执行的,每一个子线程执行完后countDown()一次,state会CAS(Compare and Swap)减1。等到全部子线程都执行完后(即state=0),会unpark()主调用线程,而后主调用线程就会从await()函数返回,继续后余动做。
通常来讲,自定义同步器要么是独占方法,要么是共享方式,他们也只需实现tryAcquire-tryRelease、tryAcquireShared-tryReleaseShared中的一种便可。但AQS也支持自定义同步器同时实现独占和共享两种方式,如ReentrantReadWriteLock。
5.3 AQS 组件总结