要保障共享变量的线程安全，最熟知的解决办法就是加锁，但是锁在使用上很简单就是加一个关键字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类型来得到公平锁或者非公平锁，默认是非公平锁

死锁

死锁是指两个或两个以上的线程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力干涉那它们都将无法推进下去,如果资源充足,进程的资源请求都能够得到满足,死锁出现的可能性就很低,否则就会因争夺有限的资源而陷入死锁

产生死锁的原因

1. 系统资源不足
2. 进程运行推进的顺序不合适
3. 资源分配不当

代码展示

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 conditionJNI global references: 2358Found 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值。