目录
3 原子类AtomicInteger的ABA问题谈谈?原子更新引用知道吗?
4 我们知道ArrayList是线程不安全,请编码写一个不安全的案例并给出解决方案。
5 公平锁/非公平锁/可重入锁/递归锁/自旋锁谈谈你的理解?请手写一个自旋锁
6 CountDownLatch/cyclicBarrier/semaphore使用过吗?
这里是下半部分:
大厂高频面试题复习JAVA学习笔记-JUC多线程及高并发(下)-CSDN博客
-
0 JUC基础概念
JUC:让开发者进行多线程编程时减少竞争条件和死锁的问题!(一般指这三个并发包中的内容)
wait/sleep的区别
- wait来自object类, sleep来自线程类
- wait会释放锁, sleep不会释放锁
- wait必须在同步代码块中, sleep可以在任何地方睡眠
并发与并行的区别
- 并发(多线程操作同一个资源,交替执行) CPU一核, 模拟出来多条线程,快速交替
- 并行(多线程同时进行) CPU多核,多个线程同时进行 ; 用线程池来操作
线程的六个状态
1. 初始(NEW):新创建了一个线程对象,但还没有调用start()方法。
2. 运行(RUNNABLE):Java线程中将就绪(ready)和运行中(running)两种状态笼统的称为“运行”。
线程对象创建后,其他线程(比如main线程)调用了该对象的start()方法。该状态的线程位于可运行线程池中,等待被线程调度选中,获取CPU的使用权,此时处于就绪状态(ready)。就绪状态的线程在获得CPU时间片后变为运行中状态(running)。
3. 阻塞(BLOCKED):表示线程阻塞于锁。
4. 等待(WAITING):进入该状态的线程需要等待其他线程做出一些特定动作(通知或中断)。
5. 超时等待(TIMED_WAITING):该状态不同于WAITING,它可以在指定的时间后自行返回。
6. 终止(TERMINATED):表示该线程已经执行完毕。
- 线程等待时间到了或被notify/notifyAll唤醒后,会进入同步队列竞争锁,如果获得锁,进入RUNNABLE状态,否则进入BLOCKED状态等待获取锁。
Thread.sleep(long millis),一定是当前线程调用此方法,当前线程进入TIMED_WAITING状态,但不释放对象锁,millis后线程自动苏醒进入就绪状态。作用:给其它线程执行机会的最佳方式。
- Thread.yield(),一定是当前线程调用此方法,当前线程放弃获取的CPU时间片,但不释放锁资源,由运行状态变为就绪状态,让OS再次选择线程。作用:让相同优先级的线程轮流执行,但并不保证一定会轮流执行。实际中无法保证yield()达到让步目的,因为让步的线程还有可能被线程调度程序再次选中。Thread.yield()不会导致阻塞。该方法与sleep()类似,只是不能由用户指定暂停多长时间。
- thread.join()/thread.join(long millis),当前线程里调用其它线程t的join方法,当前线程进入WAITING/TIMED_WAITING状态,当前线程不会释放已经持有的对象锁。线程t执行完毕或者millis时间到,当前线程一般情况下进入RUNNABLE状态,也有可能进入BLOCKED状态(因为join是基于wait实现的)。
- obj.wait(),当前线程调用对象的wait()方法,当前线程释放对象锁,进入等待队列。依靠notify()/notifyAll()唤醒或者wait(long timeout) timeout时间到自动唤醒。
obj.notify()唤醒在此对象监视器上等待的单个线程,选择是任意性的。notifyAll()唤醒在此对象监视器上等待的所有线程。
- LockSupport.park()/LockSupport.parkNanos(long nanos),LockSupport.parkUntil(long deadlines), 当前线程进入WAITING/TIMED_WAITING状态。对比wait方法,不需要获得锁就可以让线程进入WAITING/TIMED_WAITING状态,需要通过LockSupport.unpark(Thread thread)唤醒
JUC结构
- tools(工具类):信号量三组工具类,包含:
- CountDownLatch(闭锁) ,一个同步辅助类,在完成一组正在其他线程中执行的操作之前,它允许一个或多个线程一直等待
- CyclicBarrier(栅栏), 之所以叫barrier,是因为是一个同步辅助类,允许一组线程互相等待,直到到达某个公共屏障点 ,并且在释放等待线程后可以重用。
- Semaphore(信号量), 一个计数信号量,它的本质是一个“共享锁“。信号量维护了一个信号量许可集。线程可以通过调用 acquire()来获取信号量的许可;当信号量中有可用的许可时,线程能获取该许可;否则线程必须等待,直到有可用的许可为止。 线程可以通过release()来释放它所持有的信号量许可。
- executor(执行者):是Java里面线程池的顶级接口,但它只是一个执行线程的工具,真正的线程池接口是ExecutorService,里面包含的类有:
- ScheduledExecutorService 解决那些需要任务重复执行的问题
- ScheduledThreadPoolExecutor 周期性任务调度的类实现
- atomic(原子性包):是JDK提供的一组原子操作类,
包含有AtomicBoolean、AtomicInteger、AtomicIntegerArray等原子变量类,他们的实现原理大多是持有它们各自的对应的类型变量value,而且被volatile关键字修饰了。这样来保证每次一个线程要使用它都会拿到最新的值。
- locks(锁包):是JDK提供的锁机制,相比synchronized关键字来进行同步锁,功能更加强大,它为锁提供了一个框架,该框架允许更灵活地使用锁包含的实现类有:
- ReentrantLock 它是独占锁,是指只能被独自占领,即同一个时间点只能被一个线程锁获取到的锁。
- ReentrantReadWriteLock 它包括子类ReadLock和WriteLock。ReadLock是共享锁,而WriteLock是独占锁。
- LockSupport 它具备阻塞线程和解除阻塞线程的功能,并且不会引发死锁。
- collections(集合类):主要是提供线程安全的集合, 比如:
- ArrayList对应的高并发类是CopyOnWriteArrayList,
- HashSet对应的高并发类是 CopyOnWriteArraySet,
- HashMap对应的高并发类是ConcurrentHashMap等等
-
1 请谈谈你对volatile的理解
volatile是java虚拟机提供的轻量级的同步机制,他有三大特性:
- 保证可见性
- 不保证原子性
- 禁止指令重排
JMM(java内存模型)
- JMM(ava内存模型java Memory Model,简称JMM)本身是一种抽象的概念并不真实存在,它描述的是一组规则或规范,通过这组规范定义了程序中各个变量(包括实例字段,静态字段和构成数组对象的元素)的访问方式。
- JMM关于同步的规定:
- 线程解锁前,必须把共享变量的值刷新回主内存
- 线程加锁前,必须读取主内存的最新值到自己的工作内存
- 加锁解锁是同一把锁
可见性
比如一个线程A改变了主内存的某个数值,注意此时这个数值是被从主存中被A拷贝到自己的栈空间修改,再写回主内存,但其他线程自己的工作内存(栈空间,独属于每一条线程)中数值还没有被修改过来,此时A就要告诉其他线程数据已经修改,让此数据全线程可见;
- 可见性案例:
不加volatile,AAA线程修改完number数值为60后传回主内存,但是main线程眼中number依然还是0,所以程序会一直在循环,加上volatile后main才会第一时间知道主存中的值被修改
不保证原子性
案例:
20个线程,每一个线程对number++执行一千次,所以按理说最终结果应该是20000,但实际结果却不是20000,因为实际情况中,线程会覆盖,所以会丢失写值,可以看看字节码细节:
所以number++多线程下是不安全的,可以
- 直接加synchronized(杀鸡用牛刀):
- 使用atomic类中的方法
执行结果:
有序性
指令重排
编译器执行每一条指令时不是按照我们写代码的顺序执行的,是看哪个线程拿到数据就执行哪条线程,如以下资源类,可能线程不是按照方法顺序执行资源类,一致性不能保证:
加上volatile后就能禁止指令重排
哪些地方用到volatile:
单例模式
单线程下,只一main执行,不会出问题,但多线程下会出现:
解决办法1:
在方法加同步锁,可是弊端很大,因为我们只想锁一行代码,但锁的是整个方法,是重锁,并发性下降。
双端检查机制DLC
解决办法2,使用DCL模式,双端检查机制,在锁前后都进行判断:
结果:
但DCL也可能出问题,线程不一定安全,因为指令重排的存在,会出现如下情况:
使用最安全的方法是加入volatile可以防止指令重排
volatile作用总结:
- 工作内存与主内存同步延迟现象导致的可见性问题可以使用synchronized或volatile关键字解决,它们都可以使一个线程修改后的变量立即对其他线程可见。
- 对于指令重排导致的可见性问题和有序性问题可以利用volatile关键字解决,因为volatile的另外一个作用就是禁止重排序优化。
-
2 CAS你知道吗?
CompareAndSwapInt,比较并交换,如果aotointeger==expect,则其值变为update:
结果:
底层原理:
- unsafe类+自旋
- cas底层是unsafe类的方法,直接调用java的底层资源,通过native方法访问,根据valueoffset内存偏移量获取内存地址,在操作系统级别,cas是一条CPU并发原语,这意味着其每一条指令不会被打断,在底层天生具有一致性
- CAS缺点
如果cas失败,会一直循环,一直自旋,会带来cpu的很大开销,synchronized加重锁,保证了一致性,但是降低了并发性,由此引出ABA问题:
-
3 原子类AtomicInteger的ABA问题谈谈?原子更新引用知道吗?
-
ABA问题:
AB两个线程,A执行时间需要2s,B需要10秒,假如主内存中数据被A改完又改回去,此时B去取数据发现和原来一样,B就CAS成功,但是中间数据可能被别人动过,而且不止一次,这就是ABA问题。
-
原子引用
原子类可以是引用类型,
- 规避ABA问题,加版本号:
每次修改数据,数据版本加一,最后T1线程发现主存数据还是100,想修改成2019,但是因为自己版本是2小于3,使用T1知道了数据被修改过。
- 带时间戳的原子引用,解决ABA:
-
4 我们知道ArrayList是线程不安全,请编码写一个不安全的案例并给出解决方案。
-
list
但增加到三十个线程:
解决办法:
- 使用vector类,加锁数据一致性保证,但并发性下降
- 使用Collections工具类
- JUC下的写时复制,
,其数据是用volatile机制,其add方法如下:
不直接对原容器修改,而是复制一份数据,在复制后的数据中add元素,这样原来的数据依然可以并发读,数据一致性能保证,利用了读写分离思想
set
hashset,底层是hashmap,初始内存16,负载因子0.75,键值对中value全部都是PRESETNT
map
- ConcurrentHashmap
参数传递
age:在栈中传值,main的age一直是age,方法1中的age从20变成30然后从栈弹出,但栈里面的main里面的age是最后弹出的,还是20.
person:传引用,直接更改引用的地址所存的值,虽然两个person不同,但都指向同一块物理地址
String:main方法的指向abc,changevalue3的指向xxx,虽然名字一样,实际上是两个引用
-
5 公平锁/非公平锁/可重入锁/递归锁/自旋锁谈谈你的理解?请手写一个自旋锁
公平锁和非公平锁
可重入锁,默认是非公平锁,可以填写参数,填写true是公平锁
公平锁先来先得,对每一个线程都公平;非公平锁下一个线程进来直接尝试占有锁,可以会出现饥饿现象
可重用锁(递归锁)
- lock和unlock,指的是同一线程外层函数获得锁之后 ,内层递归函数仍然能获取该锁的代码,在同一个线程在外层方法获取锁的时候,在进入内层方法会自动获取锁
也即是说,线程可以进入任何一个它已经拥有的锁所同步着的代码块。
相当于只要拥有外层的大锁,里面所以方法的小锁你都有🔑,
- 经典可重复锁:synchronized
若一个线程调用sendSMS,则也会自动调用sendEmil,因为同样都是synchronized,线程可以递归获得其内所有方法的锁。
- 经典可重复锁:reentrantlock
原理与synchronized一样
特殊情况:
加两层锁,结果也是一样的,所以锁的数量不影响什么。
但是如果加锁忘记解锁,程序就会一直卡死,t4出不来。
独占锁(写锁)、共享锁(读锁)
- 独占锁指该锁一次只能被一个线程所持有。对ReentrantLock和Synchronized而言都是独占锁
- 共享锁:指该锁可被多个线程所持有。
- 对ReentrantReadWriteLock其读锁是共享锁,其写锁是独占锁。
- 读锁的共享锁可保证并发读是非常高效的,读写,写读,写写的过程是互的。
加了读写锁,缓存数据用volatile,即可实现读写分离:
自旋锁
spinlock,CAS中的aotomicInteger自旋锁:
自旋锁实现,B一直在循环等待A、释放锁:
-
6 CountDownLatch/cyclicBarrier/semaphore使用过吗?
CountDownLatch
可见main线程并没有最后执行,使用countdownlatch:
使用倒计时,减为零班长才能走人
自定义枚举类
可以方便的把小数据存在java程序里,而不用存数据库
CyclicBarrier
cyclicBarrier的字面意思是可循环(cyclic)使用的屏障(Barrier)让一组线程到达一个屏障(也可以叫同步点)时被阻塞,到最后一个线程到达屏障时,屏障才会开门,所有被屏障拦截的线程才会继续干活,线程进入屏障通过cyclicBarrier的await0)方法。
Srmaphore
下半部分: