接着之前的Java-并发高频面试题
7. synchronized的实现原理是怎么样的?
首先我们要知道synchronized它是解决线程安全问题的一种方式,而具体是怎么解决的呢?主要是通过加锁的方式来解决
在底层实现上来看 是通过 monitorenter、monitorexit两个指令来实现同步,monitorenter 指令指向同步代码块的开始位置, monitorexit 指令则指向同步代码块的结束位置。
那么synchronized是如何保证原子性的呢?
synchronized保证原子性主要就是通过上面说的monitorenter、monitorexit两个指令,当执行到monitoreter的时候要先获得锁,而执行monitorexit的时候则要释放锁,
这样一来通过两个指令就可以保证被synchronized修饰的代码同一时间只能被一个线程访问,在锁未释放之前,无法被其他线程访问到。所以说synchronized是可以保证原子性的
那么synchronized是如何保证可见性的呢?
- 线程加锁前,将清空工作内存中共享变量的值,从而使用共享变量时需要从主内存中重新读取最新的值。
- 线程加锁后,其它线程无法获取主内存中的共享变量。
- 线程解锁前,必须把共享变量的最新值刷新到主内存中。
简单说来就是被synchronized修饰的代码,为了保证可见性,它在对变量解锁之前,会强制将变量的值同步回主内存中,这样在解锁之后,其他线程也就可以访问到被修改后的值;
那么synchronized是如何保证有序性的呢?
首先我们要知道有序性的定义就是按照代码的先后顺序来去执行,那么synchronized基于monitorenter 和monitorexit加锁后本身就是会单个线程来去运行,而按照as-if-sieal语义来看,编译器和执行器即便在进行指令重排 也必须要保证单线程的执行结果不能改变
所以总结一下:因为被synchronized修饰的代码,同一个时间只能被一个线程访问,也就是单线程执行的,所以是天然可以保证有序性的
8. 锁升级?synchronized锁优化介绍下?
如果要想清楚锁升级,需要先知道不同锁的状态,这个锁状态其实就是java对象头中的mark word 标记字段,而这块结构会随着锁的状态的变化而变化。
如下图所示:
再具体细看 Mark Word存储的是对象自身的 运行数据,如哈希码、GC分代年龄、锁状态标志、偏向时间戳(Epoch) 等信息。
而从上图也可以看出因为mark word状态的不同又可以区分出无锁,偏向锁,轻量级锁,重量级锁,我们依次介绍下吧
无锁:简单来说就是mark word中锁状态为01时,同时在低三位不是偏向锁的状态
偏向锁:就是mark word 中锁状态为01 同时低三位是偏向锁状态
轻量级锁:mark word中锁状态为00标志
重量级锁:mark word中锁状态为10标志
那么他们之间是怎么转化升级的呢?
锁升级方向:无锁–>偏向锁—> 轻量级锁---->重量级锁,这个方向基本上是不可逆的。
首先呢其实是无锁状态 也就是不加锁;
之后当一个线程第一次访问对象时,jvm它其实会在对象头中设置该线程的thread ID,然后将对象的状态位设置为偏向锁,设置成偏向锁以后,如果有其他线程来访问该对象,那么就会检查该对象的偏向锁状态标志,如果说和自己的线程ID相同那么就会直接获取到锁,而如果不同,那么偏向锁就会升级为轻量级锁状态,而轻量级锁下,jvm会将mark word复制一份到线程栈中,并在对象头中存储线程栈的指针。
然后如果有其他线程来访问该对象时,会发现该对象已经处于轻量级锁状态,那么就会尝试用cas操作将对象头中的指针替换成自己的指针。如果能够替换成功,也就会获取到锁;如果替换失败,表示已经有其他线程获取了锁,那么这个轻量级锁就会升级为重量级锁。
如果锁一旦升级为重量级锁,其实也就是最笨重原始的加锁,会基于objectMonitor中的等待队列排队加锁,并会在对象头中记录指向等待队列的指针,也就是说在这种情况下 如果一个线程想要加锁,就需要先进入等待队列,等待锁被释放,当锁被释放以后,jvm会从等待队列中选择一个线程来唤醒,然后线程会进入就绪状态,等待重新获取对象的锁
9.synchronized和ReentrantLock的区别有哪些?
其实大致可以从锁的实现,使用,性能,功能特点来展开去描述
锁的实现:synchronized是关键字,是基于JVM来去实现的,而ReentrantLock是类,是基于java api来去实现的
锁的使用:synchronized作为关键字 是可以修饰方法和同步代码块,会自动释放锁,而ReentrantLock 作为类是通过lock、unlock方法来完成加锁和解锁,需要手动释放锁。
性能:synchronized在早期版本中性能不如ReentrantLock,但是在1.6后增加了适应性自旋、锁消除等,两者性能就差不多了
功能特点:Reentrantlock支持公平锁和非公平锁,但是synchronized是非公平锁,(即线程是否要排队加锁)
synchronized与wait()和notify()/notifyAll()方法结合实现等待/通知机制,ReentrantLock类借助Condition接口与newCondition()方法实现。
ReentrantLock提供了能够中断等待锁的线程机制,即通过lock.lockInterruptibly()来实现该机制
10.什么是AQS?
简单来说AQS 就是抽象队列同步器,是java并发编程底层的核心实现类,
AQS 的核心思想是利用一个双向队列来保存等待锁的线程,同时利用一个 state 变量来表示锁的状态。AQS 的同步器可以分为独占模式和共享模式两种。
独占模式是指同一时刻只允许一个线程获取锁,常见的实现类有 ReentrantLock;
共享模式是指同一时刻允许多个线程同时获取锁,常见的实现类有 Semaphore、CountDownLatch、CyclicBarrier 等。
我们首先看下独占模式的原理
简单说就是独占模式下AQS 维护了一个同步队列,和一个state变量,队列中会保存了所有等待获取锁的线程。如果有多个线程同时再执行加锁操作时,会通过cas操作才更新AQS内部的state的值,如果某一个线程加锁成功会将state的值更改为1,同时aqs中会指定加锁线程为当前线程,与此同时别的线程加锁失败会进入等待队列
一旦加锁线程释放锁就会将state的值设为0,同时将加锁线程更新为null,而加锁线程也会通知排在等待队列中的头元素
同时 独占模式又分为公平锁和非公平锁:默认非公平锁
公平锁:按照线程在队列中的排队顺序,先到者先拿到锁;
非公平锁:当线程要获取锁时,无视队列顺序直接去抢锁,谁抢到就是谁的。
共享模式的原理
AQS 维护了一个等待队列和一个共享计数器。共享计数器表示当前允许获取锁的线程数,当一个线程尝试获取锁时,如果当前允许获取锁的线程数已经达到了最大值,则将该线程加入到等待队列中,并挂起线程,等待其他线程释放锁或者共享计数器增加。
当锁被释放时,会从等待队列中取出一个线程,使其获取锁,同时将它从队列中移除,唤醒该线程继续执行。
11 保证线程安全的手段有哪些?
在 Java 中,多线程并发操作同一个共享变量时,就可能会发生线程安全问题。
在 Java 中保证线程安全的常用手段有以下三个:
锁机制:在 Java 中,锁机制主要有两种:synchronized 关键字和 Lock 接口。synchronized 关键字是 Java 中最基本的锁机制,它可以用来修饰方法或代码块,以实现对共享资源的互斥访问。而 Lock 接口是 Java5 中新增的一种锁机制,它提供了比 synchronized 更强大、更灵活的锁定机制,例如可重入锁、读写锁等;
使用线程安全的容器:如 **ConcurrentHashMap、Hashtable、Vector。**需要注意的是,线程安全的容器底层通常也是使用锁机制实现的;
使用本地变量ThreadLocal:线程本地变量是一种特殊的变量,它只能被同一个线程访问。在 Java 中,线程本地变量可以通过 ThreadLocal 类来实现。每个 ThreadLocal 对象都可以存储一个线程本地变量,而且每个线程都有自己的一份线程本地变量副本,因此不同的线程之间互不干扰。
12 ThreadLocal是什么?
ThreadLocal,也就是线程本地变量。如果你创建了一个ThreadLocal变量,那么访问这个变量的每个线程都会有这个变量的一个本地拷贝,多个线程操作这个变量的时候,实际是操作自己本地内存里面的变量,从而起到线程隔离的作用,避免了线程安全问题。
而ThreadLocal用起来并不麻烦,就是声明该变量,然后通过set 写入和get获取就可以进行操作
那你在工作中有用到ThreadLocal吗?
threadLocal的场景很多 比如说可以基于threadlocal做用户信息的上下文存储,以及cookie,session等的隔离,还有比如数据库连接池 可以交给ThreadLoca进行管理,保证当前线程的操作都是同一个Connnection
ThreadLocal怎么实现的呢?实现原理是啥?
其实TheadLocal本身并不存储数据,真正存储数据的是Threadlocalmap,
也就是说每个线程都会有一个属于自己的ThreadLocalMap,
而ThreadLocalMap内部维护着Entry数组,每个Entry代表一个完整的对象,key是ThreadLocal的弱引用,value是ThreadLocal的泛型值。
每个线程在往ThreadLocal里设置值的时候,都是往自己的ThreadLocalMap里存,读也是以某个ThreadLocal作为引用,在自己的map里找对应的key,从而实现了线程隔离。
ThreadLocal 内存泄露是怎么回事?
因为 ThreadLocalMap中使用的 key 为 ThreadLocal 的弱引用。
而“弱引用的定义是 只要垃圾回收机制一运行,不管JVM的内存空间是否充足,都会回收该对象占用的内存。”
所以说 弱引用很容易被回收,如果ThreadLocal(ThreadLocalMap的Key)被垃圾回收器回收了,但是ThreadLocalMap生命周期和Thread是一样的,它这时候如果不被回收,就会出现这种情况:ThreadLocalMap的key没了,value还在,这就会造成了内存泄漏问题。
那怎么解决内存泄漏问题呢?
其实 很简单,使用完ThreadLocal后,及时调用remove()方法释放内存空间。
那为什么key还要设计成弱引用?
key设计成弱引用同样是为了防止内存泄漏。
假如key被设计成强引用,如果ThreadLocal 的引用即指针被销毁,此时它指向ThreadLoca的强引用就没有了,但是此时key还强引用指向ThreadLocal,就会导致ThreadLocal不能被回收,这时候就发生了内存泄漏的问题。
13 线程死锁的条件有哪些?
死锁的产生需要满足以下 4 个条件:
互斥条件:也就是说在一段时间内某个锁资源只能被一个运算单元所占用。
请求和保持条件:说白了就是当前线程A占用着某个资源a,但是又去请求其他资源b,而资源b又恰好被其他线程B占用着不释放,就是处于这种请求保持条件
不可剥夺条件:指运算单元已获得的资源,在未使用完之前,不能被剥夺。
环路等待条件:指在发生死锁时,必然存在运算单元和资源的环形链,即运算单元正在等待另一个运算单元占用的资源,而对方又在等待自己占用的资源,从而造成环路等待的情况。
只有以上 4 个条件同时满足,才会造成死锁。
死锁的常用解决方案有以下两个:
按照顺序加锁:尝试让所有线程按照同一顺序获取锁,从而避免死锁。
设置获取锁的超时时间:尝试获取锁的线程在规定时间内没有获取到锁,就放弃获取锁,避免因为长时间等待锁而引起的死锁。
死锁排查工具有哪些?
常见的工具有以下几个:
jstack:可以查看 Java 应用程序的线程状态和调用堆栈,可用于发现死锁线程的状态。
jconsole 和 JVisualVM:这些是 Java 自带的监视工具,可以用于监视线程、内存、CPU 使用率等信息,从而帮助排查死锁问题。
14 CAS了解吗?有哪些实现?以及存在哪些问题?
CAS叫做CompareAndSwap,⽐较并交换,主要是通过处理器的指令来保证操作的原⼦性的。
CAS 指令包含 3 个参数:共享变量的内存地址 A、预期的值 B 和共享变量的新值 C。
只有当内存中地址 A 的值等于 B 时,才能将内存中地址 A 的值更新为新值 C。作为一条 CPU 指令,CAS 指令本身是能够保证原子性的
具体实现:在 Java 中,CAS 操作被封装在 Atomic 类中,例如 AtomicInteger 类就是利用了 CAS 操作来实现线程安全的自增操作。同时,Java 还提供了一些工具类来支持 CAS 操作,例如 Unsafe 类,它提供了一些原始的 CAS 操作方法,供 JVM 内部使用
CAS存在的问题
1. ABA问题
并发环境下,假设初始条件是A,去修改数据时,发现是A就会执行修改。但是看到的虽然是A,中间可能发生了A变B,B又变回A的情况
那该如何解决ABA问题呢?
加版本号或者时间戳,说白了就是每次修改变量,都在这个变量的版本号上加1,这样,刚刚A->B->A,虽然A的值没变,但是它的版本号已经变了,再判断版本号就会发现此时的A已经被改过了。参考乐观锁的版本号,这种做法可以给数据带上了一种实效性的检验。
Java提供了AtomicStampReference类,它的compareAndSet方法首先检查当前的对象引用值是否等于预期引用,并且当前印戳(Stamp)标志是否等于预期标志,如果全部相等,则以原子方式将引用值和印戳标志的值更新为给定的更新值。
2. 只能保证一个变量的原子操作
CAS 保证的是对一个变量执行操作的原子性,如果对多个变量操作时,CAS 目前无法直接保证操作的原子性的。
怎么解决只能保证一个变量的原子操作问题?
可以考虑改用锁来保证操作的原子性
可以考虑合并多个变量,将多个变量封装成一个对象,java中可以用AtomicReference来保证原子性
3. 无限循环导致性能降低
自旋CAS,如果一直循环执行,一直不成功,会给CPU带来非常大的执行开销。
那么如何来解决循环问题呢?可以通过设置自旋次数,即超过一定次数,就停止自旋
15. AtomicInteger 的原理?
说白了 就是基于CAS来实现的,在底层是用Unsafe类的实例来进行添加操作,而Unsafe类中的compareAndSwapInt其实就是一个native方法,基于CAS来操作int类型变量。
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;
}