文章目录
谈谈你对volatile的理解
volatile是Java虚拟机提供的轻量级的同步机制。特点如下：
- 保证可见性
- 不保证原子性
- 禁止指令重排
你谈谈JMM
JMM(Java内存模型Java Memory Model，简称JMM)本身是一种抽象的概念并不真实存在，它描述的是一组规则或规范，通过这组规范定义了程序中各个变量（包括实例字段，静态字段和构成数组对象的元素）的访问方式。
由于JVM运行程序的实体是线程，而每个线程创建时JVM都会为其创建一个工作内存(有些地方称为栈空间，最大的工作内存就是main线程的)，工作内存是每个线程的私有数据区域，而Java内存模型中规定所有变量都存储在主内存，主内存是共享内存区域，所有线程都可以访问，但线程对变量的操作(读取赋值等)必须在工作内存中进行，首先要将变量从主内存拷贝到的线程自己的工作内存空间，然后对变量进行操作，操作完成后再将变量写回主内存，不能直接操作主内存中的变量，各个线程中的工作内存中存储着主内存中的变量副本拷贝，因此不同的线程间无法访问对方的工作内存，线程间的通信(传值)必须通过主内存来完成，其简要访问过程如下图：
JMM关于同步 的规定：
- 线程解锁前，必须把共享变量的值刷新回主内存。
- 线程加锁前，必须读取主内存的最新值到自己的工作内存。
- 加锁解锁是同一把锁。
JMM的特性：
-
原子性：指一个操作是不可中断的，即使是多个线程一起执行的时候，一个操作一旦开始，就不会被其他线程干扰；比如，对于一个静态全局变量int i，两个线程同时对它赋值，线程A 给他赋值 1，线程 B 给它赋值为 -1,。那么不管这两个线程以何种方式，何种步调工作，i的值要么是1，要么是-1，线程A和线程B之间是没有干扰的。这就是原子性的一个特点，不可被中断
-
可见性：指当一个线程修改了某一个共享变量的值，其他线程是否能够立即知道这个修改。显然，对于串行程序来说，可见性问题 是不存在。因为你在任何一个操作步骤中修改某个变量，那么在后续的步骤中，读取这个变量的值，一定是修改后的新值。但是这个问题在并行程序中就不见得了。如果一个线程修改了某一个全局变量，那么其他线程未必可以马上知道这个改动。
-
有序性：对于一个线程的执行代码而言，我们总是习惯地认为代码的执行时从先往后，依次执行的。这样的理解也不能说完全错误，因为就一个线程而言，确实会这样。但是在并发时，程序的执行可能就会出现乱序。给人直观的感觉就是：写在前面的代码，会先执行。有序性问题的原因是因为程序在执行时，可能会进行指令重排，重排后的指令与原指令的顺序未必一致。
什么是指令重排，并举几个案例
指令重排是指在程序执行过程中, 为了性能考虑, 编译器和CPU可能会对指令重新排序。即代码写的顺序和代码的执行顺序可能不一样。在保证数据依赖性的情况下看可以写在后面的代码可能会先执行。
案例：
public void mySort(){
int x=11;//语句1
int y=12;//语句2
x=x+5;//语句3
y=x*x;//语句4
}
代码正常的执行顺序是：1234
但是经过指令重排代码的执行顺序可能变为：
2134
1324
问题:
请问语句4 可以重排后变成第一条码?
存在数据的依赖性 没办法排到第一个
你在哪些地方用到过volatile?
单例模式的双重检测机制
public class SingletonDemo {
private static volatile SingletonDemo instance=null;
private SingletonDemo(){
System.out.println(Thread.currentThread().getName()+"\t 构造方法");
}
/**
* 双重检测机制
* @return
*/
public static SingletonDemo getInstance(){
if(instance==null){
synchronized (SingletonDemo.class){
if(instance==null){
instance=new SingletonDemo();
}
}
}
return instance;
}
public static void main(String[] args) {
for (int i = 1; i <=10; i++) {
new Thread(() ->{
SingletonDemo.getInstance();
},String.valueOf(i)).start();
}
}
}
如果不使用volatile双重检测机制会有什么问题
如果不使用volatile，DCL(双端检锁) 机制不一定线程安全,原因是有指令重排的存在,加入volatile可以禁止指令重排
原因在于某一个线程在执行到第一次检测,读取到的instance不为null时,instance的引用对象可能没有完成初始化.
instance=new SingletonDem();可以分为以下步骤(伪代码)
memory=allocate();//1.分配对象内存空间
instance(memory);//2.初始化对象
instance=memory;//3.设置instance的指向刚分配的内存地址,此时instance!=null
步骤2和步骤3不存在数据依赖关系.而且无论重排前还是重排后程序执行的结果在单线程中并没有改变,因此这种重排优化是允许的.
memory=allocate();//1.分配对象内存空间
instance=memory;//3.设置instance的指向刚分配的内存地址,此时instance!=null 但对象还没有初始化完。
instance(memory);//2.初始化对象
但是指令重排只会保证串行语义的执行一致性(单线程) 并不会关心多线程间的语义一致性
所以当一条线程访问instance不为null时,由于instance实例未必完成初始化,也就造成了线程安全问题。
volatile无法保证原子性，应该使用什么保证原子性
使用原子应用类AtomicReference或者使用原子包装类，例如：AtomicInteger
AtomicReference使用的演示：
/**
* Description:
*
* @author veliger@163.com
* @date 2019-04-12 21:23
**/
@Getter@Setter@AllArgsConstructor@ToString
class User{
private String name;
private int age;
}
public class AtomicReferenceDemo {
public static void main(String[] args) {
User zs = new User("zs", 22);
User ls = new User("ls", 22);
AtomicReference<User> userAtomicReference = new AtomicReference<>();
userAtomicReference.set(zs);
System.out.println(userAtomicReference.compareAndSet(zs, ls)+"\t"+userAtomicReference.get().toString());
System.out.println(userAtomicReference.compareAndSet(zs, ls)+"\t"+userAtomicReference.get().toString());
}
}
Atomiclnteger是怎么保证原子性
Atomiclnteger使用了CAS算法和UnSafe保证原子性
谈一谈CAS和UnSafe
- UnSafe是CAS的核心类 由于Java 方法无法直接访问底层 ，需要通过本地(native)方法来访问,UnSafe相当于一个工具，基于该类可以直接操作特额定的内存数据。UnSafe类在于sun.misc包中，其内部方法操作可以向C的指针一样直接操作内存，因为Java中CAS操作的助兴依赖于UnSafe类的方法。
注意UnSafe类中所有的方法都是native修饰的,也就是说UnSafe类中的方法都是直接调用操作底层资源执行响应的任务 - 变量ValueOffset，便是该变量在内存中的偏移地址，因为UnSafe就是根据内存偏移地址获取数据的。
- 变量value和volatile修饰,保证了多线程之间的可见性。
详细说一下CAS
CAS(Compare And Swap) 比较并交换
比较当前工作内存中的值和主内存中的值,如果相同则执行规定操作
否则继续比较直到主内存和工作内存中的值一致为止
CAS应用
CAS有3个操作数,内存值V,旧的预期值A,要修改的更新值B。
当且仅当预期值A和内存值V相同时,将内存值V修改为B，重新读取内存中的值，在进行修改，知道预期值和内存中的值相等时将内存值V修改为B。
用UnSafe中的getAndAddInt进行举例：
假设线程A和线程B两个线程同时执行getAndAddInt操作(分别在不同的CPU上)：
-
AtomicInteger里面的value原始值为3,即主内存中AtomicInteger的value为3,根据JMM模型,线程A和线程B各自持有一份值为3的value的副本分别到各自的工作内存。
-
线程A通过getIntVolatile(var1,var2) 拿到value值3,这是线程A被挂起。
-
线程B也通过getIntVolatile(var1,var2) 拿到value值3,此时刚好线程B没有被挂起并执行compareAndSwapInt方法比较内存中的值也是3 成功修改内存的值为4 线程B打完收工 一切OK。
-
这是线程A恢复,执行compareAndSwapInt方法比较,发现自己手里的数值和内存中的数字4不一致,说明该值已经被其他线程抢先一步修改了,那A线程修改失败,只能重新来一遍了。
-
线程A重新获取value值,因为变量value是volatile修饰,所以其他线程对他的修改,线程A总是能够看到,线程A继续执行compareAndSwapInt方法进行比较替换,直到成功。
CAS优点就是在不加锁的情况下保证原子性
CAS有没有缺点，是什么
-
循环时间长开销大
-
只能保证一个共享变量的原子性
当对一个共享变量执行操作时，我们可以使用循环CAS的方式来保证原子但是对多个共享变量操作时，循环CAS就无法保证操作的原子性，这个时候就可以用锁来保证原子性。 -
会导致ABA问题
什么是ABA问题，怎么解决
解决ABA问题可以使用带时间戳（版本号）的原子应用类AtomicStampedReference
原理就是在每次主内存数据的时候设置一个版本号，当线程要写回数据的时候不仅要判断期望值是否相同，也要判断期望的版本号是否相同。
代码演示如下：
import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicReference;
import java.util.concurrent.atomic.AtomicStampedReference;
/**
* Description: ABA问题的解决
*
* @author veliger@163.com
* @date 2019-04-12 21:30
**/
public class ABADemo {
private static AtomicReference<Integer> atomicReference = new AtomicReference<>(100);
private static AtomicStampedReference<Integer> stampedReference = new AtomicStampedReference<>(100, 1);
public static void main(String[] args) {
System.out.println("===以下是ABA问题的产生===");
new Thread(() -> {
atomicReference.compareAndSet(100, 101);
atomicReference.compareAndSet(101, 100);
}, "t1").start();
new Thread(() -> {
//先暂停1秒 保证完成ABA
try {
TimeUnit.SECONDS.sleep(1);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println(atomicReference.compareAndSet(100, 2019) + "\t" + atomicReference.get());
}, "t2").start();
//暂停两秒钟，保证上面的线程执行完了
try { TimeUnit.SECONDS.sleep(2); } catch (InterruptedException e) { e.printStackTrace(); }
System.out.println("===以下是ABA问题的解决===");
new Thread(() -> {
int stamp = stampedReference.getStamp();
System.out.println(Thread.currentThread().getName() + "\t 第1次版本号" + stamp + "\t值是" + stampedReference.getReference());
//暂停1秒钟t3线程，保证t4能拿到一样的初始值
try {
TimeUnit.SECONDS.sleep(1);
} catch (InterruptedException e) {
e.printStackTrace();
}
stampedReference.compareAndSet(100, 101, stampedReference.getStamp(), stampedReference.getStamp() + 1);
System.out.println(Thread.currentThread().getName() + "\t 第2次版本号" + stampedReference.getStamp() + "\t值是" + stampedReference.getReference());
stampedReference.compareAndSet(101, 100, stampedReference.getStamp(), stampedReference.getStamp() + 1);
System.out.println(Thread.currentThread().getName() + "\t 第3次版本号" + stampedReference.getStamp() + "\t值是" + stampedReference.getReference());
}, "t3").start();
new Thread(() -> {
int stamp = stampedReference.getStamp();
System.out.println(Thread.currentThread().getName() + "\t 第1次版本号" + stamp + "\t值是" + stampedReference.getReference());
//保证线程3完成1次ABA
try {
TimeUnit.SECONDS.sleep(3);
} catch (InterruptedException e) {
e.printStackTrace();
}
//第三个参数是期望的版本号，如果与stampedReference.getStamp()当前版本号相同才会执行
boolean result = stampedReference.compareAndSet(100, 2019, stamp, stamp + 1);
System.out.println(Thread.currentThread().getName() + "\t 修改成功否" + result + "\t最新版本号" + stampedReference.getStamp());
System.out.println("最新的值\t" + stampedReference.getReference());
}, "t4").start();
}
}
什么是公平锁和非公平锁
公平锁：
- 是指多个线程按照申请锁的顺序来获取锁类似队列 先进先出
非公平锁：
- 是指在多线程获取锁的顺序并不是按照申请锁的顺序,有可能后申请的线程比先申请的线程优先获取到锁,在高并发的情况下,有可能造成优先级反转或者饥饿现象
并发包ReentrantLock的创建可以指定构造函数的boolean类型来得到公平锁或者非公平锁 默认是非公平锁
两者区别：
公平锁：
就是很公平,在并发环境中,每个线程在获取锁时会先査看此锁维护的等待队列,如果为空,或者当前线程是等待队列的第个,就占有锁,否则就会加入到等待队列中,以后会按照FFO的规则从队列中取到自己。
非公平锁：
非公平锁，上来就直接尝试占有锁，如果尝试失败，就再采用类似公平锁那种方式。
ReentrantLock而言，通过构造哈数指定该锁是否是公平锁 默认是非公平锁
非公平锁的优点在于吞吐量比公平锁大。
对于synchronized而言 也是一种非公平锁
说一说可重入锁
注意内层和外出必须是同一把锁，否则不会自动获取。
ReentrantLock和synchronized就是一个典型的可重入锁。
可重入锁最大的作用就是避免死锁
验证synchronized 是可重入锁：
class Phone{
public synchronized void sendSms() throws Exception{
System.out.println(Thread.currentThread().getName()+"\tsendSms");
sendEmail();
}
public synchronized void sendEmail() throws Exception{
// TimeUnit.SECONDS.sleep(3);
System.out.println(Thread.currentThread().getName()+"\tsendEmail");
}
}
public class ReenterLockDemo {
public static void main(String[] args) {
Phone phone = new Phone();
new Thread(()->{
try {
phone.sendSms();
} catch (Exception e) {
e.printStackTrace();
}
},"t1").start();
new Thread(()->{
try {
phone.sendSms();
} catch (Exception e) {
e.printStackTrace();
}
},"t2").start();
}
}
运行结果：
t1 sendSms
t1 sendEmail
t2 sendSms
t2 sendEmail
验证Lock是可重入锁：
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
class Phone2 implements Runnable {
private Lock lock = new ReentrantLock();
private Lock lock1 = new ReentrantLock();
@Override
public void run() {
get();
}
private void get() {
lock.lock();
try {
System.out.println(Thread.currentThread().getName() + "\tget");
set();
} finally {
lock.unlock();
}
}
private void set() {
lock1.lock();
try {
System.out.println(Thread.currentThread().getName() + "\tset");
} finally {
lock1.unlock();
}
}
}
public class ReenterLockDemo2 {
public static void main(String[] args) {
Phone2 phone = new Phone2();
Thread t3 = new Thread(phone);
Thread t4 = new Thread(phone);
t3.start();
t4.start();
}
}
什么是自旋锁
CAS算法就是自旋锁的思想。
什么是读写锁（独占锁和共享锁）
代码演示：
import java.util.HashMap;
import java.util.Map;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.locks.ReentrantReadWriteLock;
/**
* 资源类
*/
class MyCaChe {
/**
* 保证可见性
*/
private volatile Map<String, Object> map = new HashMap<>();
private ReentrantReadWriteLock reentrantReadWriteLock = new ReentrantReadWriteLock();
/**
* 写
*
* @param key
* @param value
*/
public void put(String key, Object value) {
reentrantReadWriteLock.writeLock().lock();
try {
System.out.println(Thread.currentThread().getName() + "\t正在写入" + key);
//模拟网络延时
try {
TimeUnit.MICROSECONDS.sleep(300);
} catch (InterruptedException e) {
e.printStackTrace();
}
map.put(key, value);
System.out.println(Thread.currentThread().getName() + "\t正在完成");
} finally {
reentrantReadWriteLock.writeLock().unlock();
}
}
/**
* 读
*
* @param key
*/
public void get(String key) {
reentrantReadWriteLock.readLock().lock();
try {
System.out.println(Thread.currentThread().getName() + "\t正在读取");
//模拟网络延时
try {
TimeUnit.MICROSECONDS.sleep(300);
} catch (InterruptedException e) {
e.printStackTrace();
}
Object result = map.get(key);
System.out.println(Thread.currentThread().getName() + "\t正在完成" + result);
} finally {
reentrantReadWriteLock.readLock().unlock();
}
}
public void clearCaChe() {
map.clear();
}
}
/**
* Description:
* 多个线程同时操作 一个资源类没有任何问题 所以为了满足并发量
* 读取共享资源应该可以同时进行
* 但是
* 如果有一个线程想去写共享资源来 就不应该有其他线程可以对资源进行读或写
* <p>
* 小总结:
* 读 读能共存
* 读 写不能共存
* 写 写不能共存
* 写操作 原子+独占 整个过程必须是一个完成的统一整体 中间不允许被分割 被打断
*
* @author veliger@163.com
* @date 2019-04-13 0:45
**/
public class ReadWriteLockDemo {
public static void main(String[] args) {
MyCaChe myCaChe = new MyCaChe();
for (int i = 1; i <= 5; i++) {
final int temp = i;
new Thread(() -> {
myCaChe.put(temp + "", temp);
}, String.valueOf(i)).start();
}
for (int i = 1; i <= 5; i++) {
int finalI = i;
new Thread(() -> {
myCaChe.get(finalI + "");
}, String.valueOf(i)).start();
}
}
}
运行结果：
2 正在写入2
2 正在完成
5 正在写入5
5 正在完成
3 正在写入3
3 正在完成
4 正在写入4
4 正在完成
1 正在写入1
1 正在完成
2 正在读取
3 正在读取
5 正在读取
4 正在读取
1 正在读取
1 正在完成1
5 正在完成5
2 正在完成2
4 正在完成4
3 正在完成3
synchronized和Look的区别
-
原始构成
synchronized是关键字属于JVM层面，
monitorenter(底层是通过monitor对象来完成，其实wait/notify等方法也依赖于monitor对象只有在同步块或方法中才能调wait/notify等方法
Lock是具体类(java.util.concurrent.locks.Lock)是api层面的锁 -
使用方法
synchronized 不需要用户去手动释放锁，当synchronized代码执行完后系统会自动让线程释放对锁的占用ReentrantLock则需要用户去手动释放锁若没有主动释放锁，就有可能导致出现死锁现象。需要Lock( )利unlock()方法配合try/finally语句块来完成。 -
等待是否可中断
synchronized不可中断，除非抛出异常或者正常运行完成
ReentrantLock可中断
设置超时方法tryLock(Long timeout，TimeUnit unit)
lockInterruptibly()放代码块中，调用interrupt()方法可中断 -
加锁是否公平
synchronized非公平锁
ReentrantLock两者都可以，默认非公平锁，构造方法可以传入booLean值，true为公平锁，false为非公平锁 -
锁绑定多个条件condition
synchronized没有
ReentrantLock用来实现分组唤醒需要唤醒的线程们，可以精确唤醒，而不是像synchronized要么随机唤醒一个线程要么唤醒全部线程。
死锁的分析和排查
产生死锁的主要原因：
- 系统资源不足
- 进程运行推进的顺序不合适
- 资源分配不当
代码演示：
import java.util.concurrent.TimeUnit;
class HoldThread implements Runnable {
private String lockA;
private String lockB;
public HoldThread(String lockA, String lockB) {
this.lockA = lockA;
this.lockB = lockB;
}
@Override
public void run() {
synchronized (lockA) {
System.out.println(Thread.currentThread().getName() + "\t 自己持有锁" + lockA + "尝试获得" + lockB);
try {
TimeUnit.SECONDS.sleep(1);
} catch (InterruptedException e) {
e.printStackTrace();
}
synchronized (lockB) {
System.out.println(Thread.currentThread().getName() + "\t 自己持有锁" + lockB + "尝试获得" + lockA);
}
}
}
}
/**
* Description:
* 死锁是指两个或者以上的进程在执行过程中,
* 因争夺资源而造成的一种相互等待的现象,
* 若无外力干涉那他们都将无法推进下去
*
* @author veliger@163.com
* @date 2019-04-14 0:05
**/
public class DeadLockDemo {
public static void main(String[] args) {
String lockA = "lockA";
String lockB = "lockB";
new Thread(new HoldThread(lockA, lockB), "threadAAA").start();
new Thread(new HoldThread(lockB, lockA), "threadBBB").start();
}
}
jps命令定位进程编号：
jstack找到死锁查看：
synchronized锁升级的过程
一开始是无锁状态，当有线程使用的时候会升级成偏向锁，这时候是单线程状态，一旦有第二个线程竞争锁，将会升级为轻量级锁，其余线程会自旋等待，当自旋到一定次数，或者竞争非常激烈的情况下会升级为重量级锁，这时其余线程进入等待队列，等待调用。
（注意：jdk 1.6以前synchronized 关键字只表示重量级锁，1.6之后区分为偏向锁、轻量级锁、重量级锁。）
锁升级的方向是：无锁——>偏向锁——>轻量级锁——>重量级锁，并且膨胀方向不可逆。
-
偏向锁
偏向锁是JDK6中引入的一项锁优化，大多数情况下，锁不仅不存在多线程竞争，而且总是由同一线程多次获得，为了让线程获得锁的代价更低而引入了偏向锁。偏向锁会偏向于第一个获得它的线程，如果在接下来的执行过程中，该锁没有被其他的线程获取，则持有偏向锁的线程将永远不需要同步。 -
轻量级锁
如果明显存在其它线程申请锁，那么偏向锁将很快升级为轻量级锁。 -
自旋锁
自旋锁原理非常简单，如果持有锁的线程能在很短时间内释放锁资源，那么那些等待竞争锁的线程就不需要做内核态和用户态之间的切换进入阻塞挂起状态，它们只需要等一等（自旋），等持有锁的线程释放锁后即可立即获取锁，这样就避免用户线程和内核的切换的消耗。 -
重量级锁
指的是原始的Synchronized的实现，重量级锁的特点：其他线程试图获取锁时，都会被阻塞，只有持有锁的线程释放锁之后才会唤醒这些线程。
守护线程和用户线程有什么区别呢？
守护线程和用户线程
-
用户 (User) 线程：运行在前台，执行具体的任务，如程序的主线程、连接网络的子线程等都是用户线程。
-
守护 (Daemon) 线程：运行在后台，为其他前台线程服务。也可以说守护线程是 JVM 中非守护线程的 “佣人”。一旦所有用户线程都结束运行，守护线程会随JVM 一起结束工作，main 函数所在的线程就是一个用户线程啊，main 函数启动的同时在 JVM 内部同时还启动了好多守护线程，比如垃圾回收线程。
比较明显的区别之一是用户线程结束，JVM 退出，不管这个时候有没有守护线程运行。而守护线程不会影响 JVM 的退出。
注意事项：
-
setDaemon(true)必须在start()方法前执行，否则会抛出IllegalThreadStateException异常，不能将已经启动的线程设置为守护线程 -
在守护线程中产生的新线程也是守护线程
-
不是所有的任务都可以分配给守护线程来执行，比如读写操作或者计算逻辑
-
守护 (Daemon) 线程中不能依靠 finally 块的内容来确保执行关闭或清理资源的逻辑。因为我们上面也说过了一旦所有用户线程都结束运行，守护线程会随 JVM 一起结束工作，所以守护 (Daemon) 线程中的 finally 语句块可能无法被执行
817
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
