要保障共享变量的线程安全，最熟知的解决办法就是加锁，但是锁在使用上很简单就是加一个关键字Synchronized，但是这个锁性能太差了。为了降低加锁带来的性能损耗，锁被分为了各种各样的分类，根据业务场景不同选用合适的锁，增加系统吞吐量。
按概念分类
悲观锁与乐观锁
悲观锁
悲观锁总是假设最坏的情况，认为共享资源每次被访问的时候就会出现问题(比如共享数据被修改)，所以每次在获取资源操作的时候都会上锁，这样其他线程想拿到这个资源就会阻塞直到锁被上一个持有者释放。
也就是说，共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程。
像 Java 中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。
乐观锁
乐观锁总是假设最好的情况，认为共享资源每次被访问的时候不会出现问题，线程可以不停地执行，无需加锁也无需等待，只是在提交修改的时候去验证对应的资源（也就是数据）是否被其它线程修改了（具体方法可以使用版本号机制或 CAS 算法）。
在 Java 中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式 CAS 实现的。
可重入锁(递归锁)
就是一个线程不用释放，可以重复的获取一个锁n次，只是在释放的时候，也需要相应的释放n次。（简单来说：A线程在某上下文中或得了某锁，当A线程想要在次获取该锁时，不会应为锁已经被自己占用，而需要先等到锁的释放）假使A线程即获得了锁，又在等待锁的释放，就会造成死锁。synchronized和reentrantlock都是可重入锁
写锁（独占）、读锁（共享）
写锁（独占）
独占锁也叫排他锁、互斥锁、独享锁，是指锁在同一时刻只能被一个线程所持有。一个线程加锁后，任何其他试图再次加锁的线程都会被阻塞，直到持有锁线程解锁。通俗来说，就是共享资源某一时刻只能有一个线程访问，其余线程阻塞等待。
如果是公平地独占锁，在持有锁线程解锁时，如果有一个以上的线程在阻塞等待，那么最先抢锁的线程被唤醒变为就绪状态去执行加锁操作，其他的线程仍然阻塞等待。
java中的Synchronized内置锁和ReentrantLock显式锁都是独占锁。
写锁也相当于独占锁，当有一个线程去写，其他线程就必须获取锁才可以执行代码。读锁（共享）
共享锁就是在同一时刻允许多个线程持有的锁。当然，获得共享锁的线程只能读取临界区的数据，不能修改临界区的数据。
JUC中的共享锁包括Semaphore（信号量）、ReadLock（读写锁）中的读锁、CountDownLatch。
而读锁就是一种共享锁，当多个线程去读取时，可以都获取到锁并执行读操作。
公平、非公平锁
公平锁
是指多个线程按照申请锁的顺序来获取锁，类似于排队买饭，先来后到，先来先服务，就是公平的，也就是队列
非公平锁
是指多个线程获取锁的顺序，并不是按照申请锁的顺序，有可能申请的线程比先申请的线程优先获取锁，在高并发环境下，有可能造成优先级翻转，或者饥饿的线程（也就是某个线程一直得不到锁）
公平锁和非公平锁的创建 并发包中ReentrantLock的创建可以指定构造函数的boolean类型来得到公平锁或者非公平锁，默认是非公平锁
死锁
死锁是指两个或两个以上的线程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力干涉那它们都将无法推进下去,如果资源充足,进程的资源请求都能够得到满足,死锁出现的可能性就很低,否则就会因争夺有限的资源而陷入死锁
产生死锁的原因
- 系统资源不足
- 进程运行推进的顺序不合适
- 资源分配不当
代码展示
package com.bilibili.juc.job; import java.util.concurrent.TimeUnit; public class Test { int i = 0; Object lock1 = new Object(); Object lock2 = new Object(); public void a() throws InterruptedException { synchronized (lock1) { TimeUnit.SECONDS.sleep(1); synchronized (lock2) { System.out.println("a"); } } } public void b() throws InterruptedException { synchronized (lock2) { TimeUnit.SECONDS.sleep(1); synchronized (lock1) { System.out.println("b"); } } } public static void main(String[] args) { Test test = new Test(); new Thread(() -> { try { test.a(); } catch (InterruptedException e) { e.printStackTrace(); } }).start(); new Thread(() -> { try { test.b(); } catch (InterruptedException e) { e.printStackTrace(); } }).start(); } }
jstack命令排查
最后一行发现了死锁
PS E:\学习目录\java系列\并发编程\juc_bilibili> jps 25492 Test 27060 Launcher 25848 22316 25964 RemoteMavenServer36 3196 Jps PS E:\学习目录\java系列\并发编程\juc_bilibili> jstack 25492 2023-03-20 14:47:10 Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.162-b12 mixed mode): "DestroyJavaVM" #24 prio=5 os_prio=0 tid=0x0000000003925000 nid=0x1144 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "Thread-1" #23 prio=5 os_prio=0 tid=0x0000000034c86800 nid=0x6698 waiting for monitor entry [0x000000003541f000] java.lang.Thread.State: BLOCKED (on object monitor) at com.bilibili.juc.job.Test.b(Test.java:26) - waiting to lock <0x00000006c1b226d0> (a java.lang.Object) - locked <0x00000006c1b226e0> (a java.lang.Object) at com.bilibili.juc.job.Test.lambda$main$1(Test.java:43) at com.bilibili.juc.job.Test$$Lambda$2/88558700.run(Unknown Source) at java.lang.Thread.run(Thread.java:748) "Thread-0" #22 prio=5 os_prio=0 tid=0x0000000034c32800 nid=0x760 waiting for monitor entry [0x000000003531e000] java.lang.Thread.State: BLOCKED (on object monitor) at com.bilibili.juc.job.Test.a(Test.java:17) - waiting to lock <0x00000006c1b226e0> (a java.lang.Object) - locked <0x00000006c1b226d0> (a java.lang.Object) at com.bilibili.juc.job.Test.lambda$main$0(Test.java:35) at com.bilibili.juc.job.Test$$Lambda$1/128526626.run(Unknown Source) at java.lang.Thread.run(Thread.java:748) "Service Thread" #21 daemon prio=9 os_prio=0 tid=0x0000000031f60800 nid=0x6c6c runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE "C1 CompilerThread11" #20 daemon prio=9 os_prio=2 tid=0x0000000031e91800 nid=0x7310 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "C1 CompilerThread10" #19 daemon prio=9 os_prio=2 tid=0x0000000031e90800 nid=0x6c48 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "C1 CompilerThread9" #18 daemon prio=9 os_prio=2 tid=0x0000000031e97800 nid=0x678c waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "C1 CompilerThread8" #17 daemon prio=9 os_prio=2 tid=0x0000000031e80000 nid=0x4a4 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "C2 CompilerThread7" #16 daemon prio=9 os_prio=2 tid=0x0000000031e76000 nid=0x5a34 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "C2 CompilerThread6" #15 daemon prio=9 os_prio=2 tid=0x0000000031e74800 nid=0x6c50 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "C2 CompilerThread5" #14 daemon prio=9 os_prio=2 tid=0x0000000031e6b800 nid=0x497c waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "C2 CompilerThread4" #13 daemon prio=9 os_prio=2 tid=0x0000000031e69000 nid=0x190 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "C2 CompilerThread3" #12 daemon prio=9 os_prio=2 tid=0x0000000031e5e000 nid=0x5e88 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "C2 CompilerThread2" #11 daemon prio=9 os_prio=2 tid=0x0000000031e5d800 nid=0x6d1c waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "C2 CompilerThread1" #10 daemon prio=9 os_prio=2 tid=0x0000000031e5c800 nid=0x6c78 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "C2 CompilerThread0" #9 daemon prio=9 os_prio=2 tid=0x0000000031e5b000 nid=0x60f0 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "JDWP Command Reader" #8 daemon prio=10 os_prio=0 tid=0x0000000031e3a800 nid=0x4cc8 runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE "JDWP Event Helper Thread" #7 daemon prio=10 os_prio=0 tid=0x0000000031e39000 nid=0x2144 runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE "JDWP Transport Listener: dt_socket" #6 daemon prio=10 os_prio=0 tid=0x0000000031e2d000 nid=0x4910 runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE "Attach Listener" #5 daemon prio=5 os_prio=2 tid=0x0000000031e24800 nid=0x5894 waiting on condition [0x0000000000000000] java.lang.Thread.State: RUNNABLE "Signal Dispatcher" #4 daemon prio=9 os_prio=2 tid=0x0000000031dca800 nid=0x5124 runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE "Finalizer" #3 daemon prio=8 os_prio=1 tid=0x0000000031da6800 nid=0x4038 in Object.wait() [0x000000003371e000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00000006c1908ec0> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143) - locked <0x00000006c1908ec0> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:212) "Reference Handler" #2 daemon prio=10 os_prio=2 tid=0x000000003031e800 nid=0x72f4 in Object.wait() [0x000000003361f000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00000006c1906b68> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:502) at java.lang.ref.Reference.tryHandlePending(Reference.java:191) - locked <0x00000006c1906b68> (a java.lang.ref.Reference$Lock) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153) "VM Thread" os_prio=2 tid=0x0000000030316000 nid=0x72c0 runnable "GC task thread#0 (ParallelGC)" os_prio=0 tid=0x000000000393b000 nid=0x65a4 runnable "GC task thread#1 (ParallelGC)" os_prio=0 tid=0x000000000393c800 nid=0x7054 runnable "GC task thread#2 (ParallelGC)" os_prio=0 tid=0x000000000393e000 nid=0x6b00 runnable "GC task thread#3 (ParallelGC)" os_prio=0 tid=0x000000000393f800 nid=0x6514 runnable "GC task thread#4 (ParallelGC)" os_prio=0 tid=0x0000000003942800 nid=0x69bc runnable "GC task thread#5 (ParallelGC)" os_prio=0 tid=0x0000000003944000 nid=0x3e34 runnable "GC task thread#6 (ParallelGC)" os_prio=0 tid=0x0000000003947000 nid=0x6be4 runnable "GC task thread#7 (ParallelGC)" os_prio=0 tid=0x0000000003948000 nid=0x4eb4 runnable "GC task thread#8 (ParallelGC)" os_prio=0 tid=0x0000000003949800 nid=0x6a10 runnable "GC task thread#9 (ParallelGC)" os_prio=0 tid=0x000000000394a800 nid=0x69a8 runnable "GC task thread#10 (ParallelGC)" os_prio=0 tid=0x000000000394b800 nid=0x6120 runnable "GC task thread#11 (ParallelGC)" os_prio=0 tid=0x000000000394f000 nid=0x5f3c runnable "GC task thread#12 (ParallelGC)" os_prio=0 tid=0x0000000003950000 nid=0x6518 runnable "VM Periodic Task Thread" os_prio=2 tid=0x0000000031f68000 nid=0x65f4 waiting on condition JNI global references: 2358 Found one Java-level deadlock: ============================= "Thread-1": waiting to lock monitor 0x0000000030323d98 (object 0x00000006c1b226d0, a java.lang.Object), which is held by "Thread-0" "Thread-0": waiting to lock monitor 0x00000000303266d8 (object 0x00000006c1b226e0, a java.lang.Object), which is held by "Thread-1" Java stack information for the threads listed above: =================================================== "Thread-1": at com.bilibili.juc.job.Test.b(Test.java:26) - waiting to lock <0x00000006c1b226d0> (a java.lang.Object) - locked <0x00000006c1b226e0> (a java.lang.Object) at com.bilibili.juc.job.Test.lambda$main$1(Test.java:43) at com.bilibili.juc.job.Test$$Lambda$2/88558700.run(Unknown Source) at java.lang.Thread.run(Thread.java:748) "Thread-0": at com.bilibili.juc.job.Test.a(Test.java:17) - waiting to lock <0x00000006c1b226e0> (a java.lang.Object) - locked <0x00000006c1b226d0> (a java.lang.Object) at com.bilibili.juc.job.Test.lambda$main$0(Test.java:35) at com.bilibili.juc.job.Test$$Lambda$1/128526626.run(Unknown Source) at java.lang.Thread.run(Thread.java:748) Found 1 deadlock.
jconsole排查死锁
偏向锁、轻量锁、轻量锁
偏向锁
如果不存在线程竞争的一个线程获得了锁，那么锁就进入偏向状态，此时Mark Word的结构变为偏向锁结构，锁对象的锁标志位（lock）被改为01，偏向标志位（biased_lock）被改为1，然后线程的ID记录在锁对象的Mark Word中（使用CAS操作完成）。以后该线程获取锁时判断一下线程ID和标志位，就可以直接进入同步块，连CAS操作都不需要，这样就省去了大量有关锁申请的操作，从而也就提升了程序的性能。轻量锁
线程在执行同步块之前， JVM 会先在当前线程的栈桢中创建用于存储锁记录 的空间 ，并将对象头中的 Mark Word 复制到锁记录中，官方称为Displaced Mark Word 。然后线程尝试使用CAS将对 象 头 中的 Mark Word 替换为指向锁记录的指针 。如果成功，当前线程获得锁 ，如果失败，表示其他线程 竞争锁 ，当前线程便尝试使用自旋来获取锁 。
重量锁
当多个线程竞争同一个锁时，会导致除锁的拥有者外，其余线程都会自旋，这将导致自旋次数过多，cpu效率下降，所以会将锁升级为重量级锁。
当一个线程获取了该锁后，其余线程想要获取锁，必须等到这个线程释放锁后才可能获取到，没有获取到锁的线程，就进入了阻塞状态。
邮戳锁
StampedLock是JUC并发包里面JDK1.8版本新增的一个锁，该锁提供了三种模式的读写控制，当调用获取锁的系列函数的时候，会返回一个long 型的变量，该变量被称为戳记（stamp),这个戳记代表了锁的状态。
try系列获取锁的函数，当获取锁失败后会返回为0的stamp值。当调用释放锁和转换锁的方法时候需要传入获取锁时候返回的stamp值。
