JMM
请你谈谈对Volatile的理解
Volatile是jvm提供的轻量级的同步机制（和synchronized差不多，但是没有synchronized那么强大）
- 保证可见性
- 不保证原子性
- 禁止指令重排
什么是JMM
JMM：java内存模型，不存在的东西，概念！约定！
JMM即为JAVA 内存模型（java memory model）。因为在不同的硬件生产商和不同的操作系统下，内存的访问逻辑有一定的差异，结果就是当你的代码在某个系统环境下运行良好，并且线程安全，但是换了个系统就出现各种问题。Java内存模型，就是为了屏蔽系统和硬件的差异，让一套代码在不同平台下能到达相同的访问结果。JMM从java 5开始的JSR-133发布后，已经成熟和完善起来。
关于JMM的一些同步的约定：
- 线程解锁前，必须把工作内存中的共享变量
立刻刷回主存。
主内存中有一个共享变量，假设线程a要操作主内存中的共享变量，它不会直接操作主内存中的共享变量，而是会拷贝一份到线程a的工作内存中，如果线程a修改了自己线程内存中的共享变量，那么在解锁前需要把更新的共享变量的值赋值给主内存中的共享变量。 - 线程加锁前，必须主存中的最新值到工作内存中。
- 线程加锁和解锁是同一把锁。
线程、工作内存、主内存
-
从主存中read变量，load到线程的工作内存中，变量就被加载到了线程的工作内存中
-
执行引擎Use变量，并assign（返回）。
-
将工作内存中的变量write并store到主内存中。
-
lock和unlock
意思就是线程a执行的慢，变量还没有及时刷新到主存中，线程b就已经更改变量并刷新到了主存中，此时线程a依旧拿着旧的变量，这就出现了问题。
需要线程a知道主内存中的值发生了变化。
内存交互操作有8种，虚拟机实现必须保证每一个操作都是原子的，不可在分的（对于double和long类型的变量来说，load、store、read和write操作在某些平台上允许例外）
- lock （锁定）：作用于主内存的变量，把一个变量标识为线程独占状态
- unlock （解锁）：作用于主内存的变量，它把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定
- read （读取）：作用于主内存变量，它把一个变量的值从主内存传输到线程的工作内存中，以便随后的load动作使用
- load （载入）：作用于工作内存的变量，它把read操作从主存中变量放入工作内存中
- use （使用）：作用于工作内存中的变量，它把工作内存中的变量传输给执行引擎，每当虚拟机遇到一个需要使用到变量的值，就会使用到这个指令
- assign （赋值）：作用于工作内存中的变量，它把一个从执行引擎中接受到的值放入工作内存的变量副本中
- store （存储）：作用于主内存中的变量，它把一个从工作内存中一个变量的值传送到主内存中，以便后续的write使用
- write （写入）：作用于主内存中的变量，它把store操作从工作内存中得到的变量的值放入主内存的变量中
JMM对这八种指令的使用，制定了如下规则：
-
不允许read和load、store和write操作之一单独出现。即使用了read必须load，使用了store必须write
-
不允许线程丢弃他最近的assign操作，即工作变量的数据改变了之后，必须告知主存
-
不允许一个线程将没有assign的数据从工作内存同步回主内存
-
一个新的变量必须在主内存中诞生，不允许工作内存直接使用一个未被初始化的变量。就是对变量实施use、store操作之前，必须经过assign和load操作
-
一个变量同一时间只有一个线程能对其进行lock。多次lock后，必须执行相同次数的unlock才能解锁
-
如果对一个变量进行lock操作，会清空所有工作内存中此变量的值，在执行引擎使用这个变量前，必须重新load或assign操作初始化变量的值
-
如果一个变量没有被lock，就不能对其进行unlock操作。也不能unlock一个被其他线程锁住的变量
-
对一个变量进行unlock操作之前，必须把此变量同步回主内存
Volatile
解决程序不知道主内存的值已经被修改过了的问题。
保证可见性
package com.atlinxi.gulimall.springdemo.juc.tvolatile;
import java.util.concurrent.TimeUnit;
public class JMMDemo {
// 不加 volatile 程序就会死循环
// 加 volatile 可以保证可见性
private volatile static int num = 0;
public static void main(String[] args) throws InterruptedException { // main线程
/**
* 线程1无限循环，此时main线程更改了num的值，那么线程1应该停止循环，因为他们操作的是同一变量，
* 然而实际情况是，并没有
*/
new Thread(()->{ // 线程1 对主内存的变化是不知道的
while (num==0){
}
}).start();
TimeUnit.SECONDS.sleep(1);
num = 1;
System.out.println(num);
}
}
不保证原子性
原子性：不可分割
线程a在执行任务的时候，不能被打扰，也不能被分割。要么同时成功，要么同时失败。
package com.atlinxi.gulimall.springdemo.juc.tvolatile;
// volatile 不保证原子性
// 还是会两个线程同时占用，其实还是线程安全的问题
public class VDemo02 {
private volatile static int num = 0;
// 不加synchronized和volatile，每次的num值都不固定
// 加synchronized是可以解决问题的
public static void add(){
num++;
}
public static void main(String[] args) {
// 理论上num结果应该为2w
for (int i = 0; i < 20; i++) {
new Thread(()->{
for (int j = 0; j < 1000; j++) {
add();
}
}).start();
}
while (Thread.activeCount()>2){ // java 中有两个程序是默认在执行的，main gc
Thread.yield();
}
System.out.println(Thread.currentThread().getName() + " " + num);
}
}
如果不加lock和synchronized，怎么保证原子性？
java中的num++在内存中实际上是三步，
- getstatic 获得这个值
- iadd 执行+1操作
- putstatic 写回这个值
所以底层不是一步，不能保证它的原子性操作。
使用原子类，解决原子性问题。
在 Java 中，原子类是指那些提供了原子操作的类，它们可以在不使用锁的情况下实现线程安全的操作。
在多线程环境下，对共享变量的操作可能会出现线程安全问题，比如数据不一致、丢失更新等情况。原子类通过提供原子性的操作，确保对变量的读写等操作是不可分割的，从而避免了这些问题。
package com.atlinxi.gulimall.springdemo.juc.tvolatile;
import java.util.concurrent.atomic.AtomicInteger;
// volatile 不保证原子性
// 还是会两个线程同时占用，其实还是线程安全的问题
public class VDemo02 {
// private volatile static num = 0;
// 使用源自类的Integer
private volatile static AtomicInteger num = new AtomicInteger();
// 不加synchronized和volatile，每次的num值都不固定
// 加synchronized是可以解决问题的
public static void add(){
//num++; // num++ 本身就不是一个原子性操作
num.getAndIncrement(); // AtomicInteger +1，底层不是简单的+1操作，用的是底层的 CAS，cpu的并发原理，效率比synchronized贼高
}
public static void main(String[] args) {
// 理论上num结果应该为2w
for (int i = 0; i < 20; i++) {
new Thread(()->{
for (int j = 0; j < 1000; j++) {
add();
}
}).start();
}
while (Thread.activeCount()>2){ // java 中有两个程序是默认在执行的，main gc
Thread.yield();
}
System.out.println(Thread.currentThread().getName() + " " + num);
}
}
原子类的底层都直接和操作系统挂钩！在内存中修改值！
Unsafe类是一个很特殊的存在！
指令重排
你写的程序，计算机并不是按照你写的那样去执行的。
源代码 -》 编译器优化的重排 --》指令并行也可能会重排 --》内存系统也会重排 --》 执行
处理器在执行指令重排的时候，它会考虑：数据之间的依赖性。
int x = 1; // 1
int y = 2; // 2
x = x + 5; // 3
y = x * x; // 4
// 我们认为和期望的执行顺序是1234，但是执行的时候可能会变成2134 1324
// 但不可能是4123
// 因为处理器在执行指令重排的时候，它会考虑：数据之间的依赖性
可能造成影响的结果，假设abxy四个值默认都是0
线程a操作，x=a,b=1
线程b操作，y=b,a=2
正常的结果：x = 0，y = 0
因为x=a,b=1没有依赖关系，所以指令重排可能会导致执行的顺序颠倒（线程b也是同样），
指令重排导致的诡异结果,x=2,y=1；
指令重排是一个概念，可能写一千万次代码都不一定会发生，但理论上是一定会产生的。
只要加了volatile可以避免指令重排！！！
在系统中有内存屏障，CPU指令，作用：
- 保证特定的操作的执行顺序！
- 可以保证某些变量的内存可见性（利用这些特性volatile实现了可见性）！
Volatile是可以保证可见性。不能保证原子性，由于内存屏障，可以保证避免指令重排的现象产生。
单例模式
饿汉式
package com.demo.juc.single;
// 饿汉式单例
public class Hungry {
// 饿汉式有可能会浪费内存
// 这四组数据非常耗内存资源，饿汉式上来就把所有的资源全部加载进内存中了
// 但是这四组数据的空间并没有被使用
// 可能会浪费空间
private byte[] data1 = new byte[1024*1024];
private byte[] data2 = new byte[1024*1024];
private byte[] data3 = new byte[1024*1024];
private byte[] data4 = new byte[1024*1024];
// 私有构造器，别人就无法new这个对象了
private Hungry() {
}
private final static Hungry hungry = new Hungry();
public static Hungry getInstance(){
return hungry;
}
}
懒汉式
package com.demo.juc.single;
import java.lang.reflect.Constructor;
import java.lang.reflect.InvocationTargetException;
// 懒汉式单例
public class LazyMan {
private static boolean lx = false;
private LazyMan() {
synchronized (LazyMan.class){
if (lx==false){
lx = true;
}else {
throw new RuntimeException("不要试图使用反射破坏异常");
}
// 在使用反射和getInstance两种方式创建对象可以直接这么解决
// if (lazyMan!=null){
// throw new RuntimeException("不要试图使用反射破坏异常");
// }
}
System.out.println(Thread.currentThread().getName() + "ok");
}
// 为了避免指令重排造成的现象，要让lazyMan避免指令重排
private volatile static LazyMan lazyMan;
// 双重检测锁模式的懒汉式单例，简称 DCL懒汉式
public static LazyMan getInstance() {
// 如果不上锁会出现线程安全的问题
if (lazyMan==null){
synchronized (LazyMan.class){
if (lazyMan==null){
lazyMan = new LazyMan(); // 不是一个原子性操作
/**
* 1. 分配内存空间
* 2. 执行构造方法，初始化对象
* 3. 把这个对象指向内存空间
*
* 底层是三步操作，有可能会发生指令重排的现象
* 我们期望执行的步骤是123，真实有可能执行132
*
* 比如a线程执行132，先分配内存空间，再把空对象的内存空间占用了，占用之后再初始化对象
* 这个操作在cpu中是可以做到的
*
* 以上a线程是没有问题的，
* 但此时如果线程b进来，由于线程a将空对象指向内存空间了，线程b判断lazyMan是不等于null的，就会直接返回
* 然而此时lazyMan实际上还没有完成构造
*
*
* 这就是由于指令重排可能导致的现象
*
*/
/**
* double-checked（双重检测）,代码中可以看到，一共进行了两次if判断实例是否为空，为何需要两次判断呢？
* 这里阐述一下原因：
第一个if判断，当线程们来访问资源时，都会进行一次判断，实例是否为空，假若在当前线程之前，
就有一个线程获取了资源，初始化了实例，那么，后进来的线程就不需要再进入同步代码块，
这样就极大的提高了获取实例的效率；
第二个if判断，假若线程1获取了资源，进入了同步代码块，初始化了实例之后，线程2去获取到了资源，
如果不再次进行判断，线程2也将重新进行实例的初始化，那么，获取到的实例地址就不再唯一，
这就违背了单例模式的原则。
**/
// 多线程条件下，假若线程1获取资源后，去创建实例，这时指令发生了重排，
// 第三个步骤和第二个步骤顺序调换，分配空间之后就之间对对象的地址进行了引用，
// 当线程2进来之后发现，实例已经初始化了，就直接将实例对象进行了返回，
// 但是，该实例实际上并没有进行实例化，那么，返回的对象就是一个空对象。
// 而volatile 关键字会禁止指令的重排，就避免了这个问题的出现。这就是单例模式经典写法的经典之处啊！
}
}
}
return lazyMan;
}
public static void main(String[] args) throws NoSuchMethodException, IllegalAccessException, InvocationTargetException, InstantiationException {
// 多线程并发
// for (int i = 0; i < 10; i++) {
// new Thread(()->{
// LazyMan.getInstance();
// }).start();
// }
// 反射
// 只要有反射，任何代码都不安全，任何私有都是纸老虎
// LazyMan lazyMan1 = LazyMan.getInstance();
// 获取空参构造器
Constructor<LazyMan> declaredConstructors = LazyMan.class.getDeclaredConstructor(null);
// 暴力反射，设置为可以直接调用私有修饰的成员方法
// 无视了私有的构造器
declaredConstructors.setAccessible(true);
LazyMan lazyMan2 = declaredConstructors.newInstance();
LazyMan lazyMan3 = declaredConstructors.newInstance();
// com.demo.juc.single.LazyMan@14ae5a5
//com.demo.juc.single.LazyMan@7f31245a
System.out.println(lazyMan3);
System.out.println(lazyMan2);
/**
* 以上得出，反射是可以破坏单例的
*
* 1. LazyMan.getInstance() 和 通过反射创建对象，
* 这两种方式可以通过在空参构造再次判断该对象是否存在来解决
*
* 2. LazyMan lazyMan2 = declaredConstructors.newInstance();
* LazyMan lazyMan3 = declaredConstructors.newInstance();
*
* 如果两次对象都是通过反射来创建对象，那么我们的变量 static lazyMan就失效了，
* 因为我们判断是否是单例都是判断它，而此时这种创建对象的方式直接跳过它了，
* 它永远为null，我们就可以通过反射来一直创建对象
*
* 解决方式可以通过一个开关来决定
*
* 3. 就算这样，依然不是安全的，假设我们知道开关的变量名的话，
* 还可以通过反射来获取变量，重置开关，单例模式就又失效了
*
* 道高一尺，魔高一丈
*/
}
}
静态内部类
package com.demo.juc.single;
// 静态内部类
public class Holder {
private Holder() {
}
public static Holder getInstance(){
return InnerClass.holder;
}
public static class InnerClass {
private static final Holder holder = new Holder();
}
}
枚举
如果类型是枚举类型，则不能使用反射破坏枚举。
枚举是jdk1.5有的，自带单例模式。
package com.demo.juc.single;
import java.lang.reflect.Constructor;
import java.lang.reflect.InvocationTargetException;
// enum 是一个什么？本身也是一个Class类
public enum EnumSingle {
INSTANCE;
public EnumSingle getInstance() {
return INSTANCE;
}
}
class Test{
public static void main(String[] args) throws NoSuchMethodException, IllegalAccessException, InvocationTargetException, InstantiationException {
// EnumSingle instance1 = EnumSingle.INSTANCE;
// EnumSingle instance2 = EnumSingle.INSTANCE;
// // true
// System.out.println(instance1==instance2);
EnumSingle instance1 = EnumSingle.INSTANCE;
Constructor<EnumSingle> declaredConstructor = EnumSingle.class.getDeclaredConstructor(null);
declaredConstructor.setAccessible(true);
EnumSingle instance2 = declaredConstructor.newInstance();
System.out.println(instance1==instance2);
/**
* Exception in thread "main" java.lang.NoSuchMethodException: com.demo.juc.single.EnumSingle.<init>()
* EnumSingle没有这样的方法，意思就是说EnumSingle没有空参构造
*
* 然而我们查看idea target包下的class文件，或者使用javap -p反编译class文件，显示都是有私有空参构造的
* 可能是有什么原因，以上两者实际上都是错误的
*
* 如果使用更专业的jad工具反编译的话，jad -sjava EnumSingle.class，就可以看到并没有空参构造
* 只有一个有参构造，参数是String、int类型，
* 我们此时Constructor<EnumSingle> declaredConstructor = EnumSingle.class.getDeclaredConstructor(String.class,int.class);
*
* 就会报 不能通过反射创建枚举对象的错误，就得到了我们想要的答案，枚举确实是单例的
*
*
*/
}
}
CAS
什么是CAS？
为什么需要学这个？因为大厂必须要深入研究底层。
CAS（比较并交换）：比较当前工作内存中的值和主内存中的值，如果这个值是期望的，那么则执行操作，否则不执行！如果不是就一直循环。
优点：自带原子性
缺点：
- 由于底层是自旋锁，循环会耗时。
- 一次性只能保证一个共享变量的原子性。（其实也够了）
- ABA问题
package com.demo.juc.cas;
import java.util.concurrent.atomic.AtomicInteger;
public class CASDemo {
// CAS，compareAndSet：比较并交换！
// 原子类的底层是用了CAS
public static void main(String[] args) {
AtomicInteger atomicInteger = new AtomicInteger(20);
// 期望、更新
// public final boolean compareAndSet(int expect, int update) {
// 如果我期望的值达到了，那么就更新，否则就不更新
// 再直白点儿就是，如果是我们的期望值20就更新成21，如果不是20就不更新
// CAS 是CPU的并发原语！
System.out.println(atomicInteger.compareAndSet(20, 21));
System.out.println(atomicInteger.get());
System.out.println(atomicInteger.compareAndSet(20, 21));
System.out.println(atomicInteger.get());
/**
*
* true
* 21
* false
* 21
*
* 布尔值代表是否被更新了
*/
atomicInteger.getAndIncrement(); // ++
}
}
Unsafe类 getAndIncrement()实现原理
public class AtomicInteger extends Number implements java.io.Serializable {
// ++ 的底层实现
atomicInteger.getAndIncrement();
public final int getAndIncrement() {
return unsafe.getAndAddInt(this, valueOffset, 1);
}
// java无法操作内存，但是java可以调用c++(native)，c++可以操作内存
// Unsafe 相当于java留了一个后门，可以通过这个类操作内存
private static final Unsafe unsafe = Unsafe.getUnsafe();
private static final long valueOffset;
static {
try {
// 获取内存地址的偏移值
valueOffset = unsafe.objectFieldOffset
(AtomicInteger.class.getDeclaredField("value"));
} catch (Exception ex) { throw new Error(ex); }
}
private volatile int value;
//public final int getAndIncrement() {
// return unsafe.getAndAddInt(this, valueOffset, 1);
}
// 与以上参数对照，this代表当前对象，第二个参数是当前对象内存的值，第三个参数是1
public final class Unsafe {
public final int getAndAddInt(Object var1, long var2, int var4) {
int var5;
do {
// 获取当前对象内存中的值
var5 = this.getIntVolatile(var1, var2);
// cas 比较并交换，
// 如果当前对象(var1)内存中的值(var2)还是var5
// 那就让var5 + 1
// 这是一个内存操作，效率极高
// 同时这是一个自旋锁
} while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));
return var5;
}
ABA问题
package com.demo.juc.cas;
import java.util.concurrent.atomic.AtomicInteger;
public class CASDemo {
// CAS，compareAndSet：比较并交换！
// 原子类的底层是用了CAS
public static void main(String[] args) {
AtomicInteger atomicInteger = new AtomicInteger(20);
// 期望、更新
// public final boolean compareAndSet(int expect, int update) {
// 如果我期望的值达到了，那么就更新，否则就不更新
// 再直白点儿就是，如果是我们的期望值20就更新成21，如果不是20就不更新
// CAS 是CPU的并发原语！
// =================捣乱的线程======================
System.out.println(atomicInteger.compareAndSet(20, 21));
System.out.println(atomicInteger.get());
System.out.println(atomicInteger.compareAndSet(21, 20));
System.out.println(atomicInteger.get());
// =======================期望的线程=====================
System.out.println(atomicInteger.compareAndSet(20, 66));
System.out.println(atomicInteger.get());
/**
* true
* 21
* true
* 20
* true
* 66
*
*
* 以上想表达的意思是，虽然第三个线程拿到的数依然和我们原来的数是一样的，都是20
* 但是这个20并不是最初的那个，而是被前面两个线程更改过的，只不过值碰巧是一样的
*
* 对于我们平时写的sql：乐观锁！
*/
}
}
原子引用
解决ABA问题，引入原子引用。
带版本号的原子操作，和乐观锁的原理是一样的。
package com.atlinxi.gulimall.springdemo.juc.cas;
import com.fasterxml.jackson.databind.deser.std.AtomicReferenceDeserializer;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicInteger;
import java.util.concurrent.atomic.AtomicStampedReference;
public class CASDemo {
// CAS，compareAndSet：比较并交换！
// 原子类的底层是用了CAS
public static void main(String[] args) {
// AtomicInteger atomicInteger = new AtomicInteger(20);
// 第二个参数相当于版本号，
// AtomicStampedReference 如果泛型是包装类，注意对象的引用问题
AtomicStampedReference<Integer> atomicStampedReference = new AtomicStampedReference<>(20,1);
new Thread(()->{
int stamp = atomicStampedReference.getStamp(); // 获得版本号
System.out.println("a1=>"+stamp);
try {
TimeUnit.SECONDS.sleep(2);
} catch (InterruptedException e) {
e.printStackTrace();
}
// 后面两个参数的意思是，期望的版本号和修改以后的版本号
System.out.println(atomicStampedReference.compareAndSet(20, 22, atomicStampedReference.getStamp(),
atomicStampedReference.getStamp() + 1));
System.out.println("a2=>"+atomicStampedReference.getStamp());
System.out.println(atomicStampedReference.compareAndSet(22, 20, atomicStampedReference.getStamp(),
atomicStampedReference.getStamp() + 1));
System.out.println("a3=>"+atomicStampedReference.getStamp());
},"a").start();
new Thread(()->{
int stamp = atomicStampedReference.getStamp(); // 获得版本号
System.out.println("b1=>"+stamp);
// 两个线程都睡眠，是想上面的stamp都获取到最开始的值，就是我们初始化设置的1
// 这个线程睡眠的时间比那个长是因为，我们想的是执行完a线程，再执行b线程，测试才能有我们想要的效果
try {
TimeUnit.SECONDS.sleep(3);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println(atomicStampedReference.compareAndSet(20, 66, stamp, stamp + 1));
System.out.println("b2=>"+atomicStampedReference.getStamp());
},"b").start();
/**
*
*
*
* b1=>1
* a1=>1
* true
* a2=>2
* true
* a3=>3
* false
* b2=>3
*
*/
}
}
各种锁的理解
以下是一些锁的名词，这些分类并不是全是指锁的状态，有的指锁的特性，有的指锁的设计，下面总结的内容是对每个锁的名词进行一定的解释。
乐观锁/悲观锁
悲观锁
线程每次在处理共享数据时都会上锁，其他线程想处理数据就会阻塞直到获得锁。
传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁，读锁，写锁等，都在操作之前先上锁。
Java中的synchronized和reentrantLock等独占锁就是悲观锁的思想实现
乐观锁
线程每次在处理共享数据时都不会上锁，在更新时会通过数据的版本号等机制判断其他线程有没有更新数据。乐观锁适合读多写少的应用场景
乐观锁就是假设最好的情况,每次拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下再次期间别人有没有去更新这个数据,可以使用版本号机制和CAS算法来实现,乐观锁适用于多读的应用类型,这样可以提高吞吐量（即冲突很少发生的情况，这样可以省去所得开销，加大系统的吞吐量），数据库中的write_condition机制,其实就是提供乐观锁。
在Java中Java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。
乐观锁适用于读多写少的场景，可以省去频繁加锁、释放锁的开销，提高吞吐量
在写比较多的场景下，乐观锁会因为版本不一致，不断重试更新，产生大量自旋，消耗 CPU，影响性能。这种情况下，适合悲观锁
独享锁/共享锁
独享锁是指该锁一次只能被一个线程所持有。
共享锁是指该锁可被多个线程所持有。
可重入锁
可重入锁又名递归锁，是指在同一个线程在外层方法获取锁的时候，在进入内层方法会自动获取锁。
synchronized void setA() throws Exception{
Thread.sleep(1000);
setB();
}
synchronized void setB() throws Exception{
Thread.sleep(1000);
}
package com.atlinxi.gulimall.springdemo.juc.lock;
public class Demo1 {
public static void main(String[] args) {
Phone phone = new Phone();
new Thread(()->{
phone.sms();
},"a").start();
new Thread(()->{
phone.sms();
},"b").start();
/**
*
* asms
* acall
* bsms
* bcall
*
* 以上结果证明是可重入锁，
* 如果不是可重入锁的话，执行完sms之后锁就应该被释放了，输出的结果就不能保证顺序了
*/
}
}
class Phone{
public synchronized void sms(){
System.out.println(Thread.currentThread().getName() + "sms");
call(); // call方法中也有一把锁
}
public synchronized void call(){
System.out.println(Thread.currentThread().getName() + "call");
}
}
package com.atlinxi.gulimall.springdemo.juc.lock;
import java.util.concurrent.locks.ReentrantLock;
public class Demo2 {
public static void main(String[] args) {
Phone2 phone2 = new Phone2();
new Thread(()->{
phone2.sms();
},"a").start();
new Thread(()->{
phone2.sms();
},"b").start();
/**
*
* asms
* acall
* bsms
* bcall
*
* 以上结果证明是可重入锁，
* 如果不是可重入锁的话，执行完sms之后锁就应该被释放了，输出的结果就不能保证顺序了
*/
}
}
class Phone2{
ReentrantLock lock = new ReentrantLock();
public void sms(){
try {
lock.lock(); // 细节问题，synchronized可以理解为一把锁
// 而lock我们看到是两把锁，锁住又开这样
// lock锁必须配对，否则就会死在里面（产生死锁）
System.out.println(Thread.currentThread().getName() + "sms");
call(); // call方法中也有一把锁
}finally {
lock.unlock();
}
}
public void call(){
try {
lock.lock();
System.out.println(Thread.currentThread().getName() + "call");
}finally {
lock.unlock();
}
}
}
公平锁/非公平锁
公平锁是指多个线程按照申请锁的顺序来获取锁。
非公平锁是指多个线程获取锁的顺序并不是按照申请锁的顺序，有可能后申请的线程比先申请的线程优先获取锁。有可能，会造成优先级反转或者饥饿现象。
公平锁：十分公平，可以先来后到
非公平锁：十分不公平，可以插队
非公平锁的意义在于，如果第一个线程执行时间是3min，第二个是3s，如果按顺序执行，可以快速执行完毕的第二个线程却被阻塞，就引起了性能倒置。
自旋锁
在Java中，自旋锁是指尝试获取锁的线程不会立即阻塞，而是采用循环的方式去尝试获取锁，这样的好处是减少线程上下文切换的消耗，缺点是循环会消耗CPU。
package com.atlinxi.gulimall.springdemo.juc.lock;
import java.util.concurrent.atomic.AtomicReference;
/**
* 自旋锁
*
* 自定义自旋锁
*/
public class SpinlockDemo {
// int 默认 0
// Thread 默认 null
AtomicReference<Thread> atomicReference = new AtomicReference<>();
// 加锁
public void myLock(){
Thread thread = Thread.currentThread();
System.out.println(Thread.currentThread().getName() + "==>mylock");
while (!atomicReference.compareAndSet(null,thread)){
}
}
// 解锁
public void myUnLock(){
Thread thread = Thread.currentThread();
System.out.println(thread.getName() + "==>myUnlock");
atomicReference.compareAndSet(thread,null);
}
/**
*
* a==>mylock
* b==>mylock
* a==>myUnlock
* b==>myUnlock
*/
}
package com.atlinxi.gulimall.springdemo.juc.lock;
import java.util.concurrent.TimeUnit;
public class TestSpinlock {
public static void main(String[] args) {
SpinlockDemo lock = new SpinlockDemo();
// 底层使用的自旋锁CAS
// lock.myLock();
// lock.myUnLock();
new Thread(()->{
lock.myLock();
try {
TimeUnit.SECONDS.sleep(3);
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
lock.myUnLock();
}
},"a").start();
try {
TimeUnit.SECONDS.sleep(3);
} catch (InterruptedException e) {
e.printStackTrace();
}
new Thread(()->{
lock.myLock();
try {
TimeUnit.SECONDS.sleep(1);
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
lock.myUnLock();
}
},"b").start();
}
}
读写锁
读写锁（Readers-Writer Lock）顾名思义是一把锁分为两部分：读锁和写锁，其中读锁允许多个线程同时获得，因为读操作本身是线程安全的，而写锁则是互斥锁，不允许多个线程同时获得写锁，并且写操作和读操作也是互斥的。
总结来说，读写锁的特点是：读读不互斥、读写互斥、写写互斥。
优点分析
-
提高了程序执行性能：多个读锁可以同时执行，相比于普通锁在任何情况下都要排队执行来说，读写锁提高了程序的执行性能。
-
避免读到临时数据：读锁和写锁是互斥排队执行的，这样可以保证了读取操作不会读到写了一半的临时数据。
读写锁适合多读少写的业务场景，此时读写锁的优势最大。
死锁
死锁测试，怎么排除死锁。
package com.atlinxi.gulimall.springdemo.juc.lock;
import java.util.concurrent.TimeUnit;
public class DeadLockDemo {
public static void main(String[] args) {
String lockA = "lockA";
String lockB = "lockB";
new Thread(new MyThread(lockA,lockB),"t1").start();
new Thread(new MyThread(lockB,lockA),"t2").start();
}
}
class MyThread implements Runnable{
private String lockA;
private String lockB;
public MyThread(String lockA, String lockB) {
this.lockA = lockA;
this.lockB = lockB;
}
@Override
public void run() {
synchronized (lockA){
System.out.println(Thread.currentThread().getName() + lockA);
try {
TimeUnit.SECONDS.sleep(2);
} catch (InterruptedException e) {
e.printStackTrace();
}
synchronized (lockB){
System.out.println(Thread.currentThread().getName() + lockB);
}
}
}
}
/**
t1lockA
t2lockB
下面就是卡死的了
*/
解决问题
- 使用jps -l定位进程号
- 使用 jstack 进程号 找到死锁问题
查看堆栈信息
部分内容转载自：
https://www.cnblogs.com/null-qige/p/9481900.html
https://www.cnblogs.com/hustzzl/p/9343797.html
https://blog.csdn.net/lkx021699/article/details/120264701
华为员工中患忧郁症、焦虑症的不断增多，令人十分担心。有什么办法可以让员工积极、开放、正派地面对人生？我思考再三，不得其解。
任正非：要快乐地度过充满困难的一生
5564
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
