JUC高级-0624

最新推荐文章于 2024-04-30 12:12:17 发布

Parzivval

最新推荐文章于 2024-04-30 12:12:17 发布

阅读量202

点赞数

分类专栏： JUC 文章标签： java juc

本文链接：https://blog.csdn.net/lannister_awalys_pay/article/details/131380813

版权

JUC 专栏收录该内容

12 篇文章 0 订阅

订阅专栏

10. ThreadLocal（线程局部变量）

10.1 ThreadLocal基础

大厂面试题
1. ThreadLocal中 ThreadLocalMap的数据结构和关系？
2. ThreadLocal的key是弱引用，这是为什么？
3. ThreadLocal内存泄露问题你知道吗？
4. ThreadLocal中最后为什么要加remove方法？
什么是ThreadLocal
- ThreadLocal提供线程局部变量。这些变量与正常的变量不同，因为每一个线程在访问ThreadLocal实例的时候（通过其get或set方法）都有自己的、独立初始化的变量副本。ThreadLocal实例通常是类中的私有静态字段，使用它的目的是希望将状态（例如，用户ID或事务ID）与线程关联起来。
能干什么？
1. 实现每一个线程都有自己专属的本地变量副本(自己用自己的变量不麻烦别人，不和其他人共享，人人有份，人各一份），主要解决了让每个线程绑定自己的值，通过使用get()和lset()方法，获取默认值或将其值更改为当前线程所存的副本的值从而避免了线程安全问题，比如我们之前讲解的8锁案例，资源类是使用同一部手机，多个线程抢奇同一部手机使用，假如人手一份是不是天下太平？？
2. 对比before和after
  1. before：群雄逐鹿
  2. after：人手一份
API：
1. 构造器：
2. T get() 返回当前线程的此线程局部变量副本中的值。
3. protected T initialValue() 返回此线程局部变量的当前线程的”初始值”。
  1. 返回此线程局部变量的当前线程的"初始值”。该方法将被调用的第一次一个线程访问与可变get（）方法，除非线程先前调用的set(T)方法，在这种情况下initialValue方法将不被调用的线程。通常，每个线程最多调用一次此方法，但如果后续调用remove()后跟get(），则可以再次调用此方法。这个实现只返回nuLL；如果程序员希望线程局部变量具有除nuL1之外的初始值，ThreadLocal必须对ThreadLocal进行子类化，并且重写此方法。通常，将使用匿名内部类。
4. void remove(). 删除此线程局部变量的当前线程值。
5. void set(T value). 将此线程局部变量的当前线程副本设置为指定值。
6. static <S> ThreadLocalxS> withInitial(Suppliers? extends S> supplier). 创建一个线程局部变量。

code:

需求：5个销售卖房子，集团高层只关心销售总量的淮确统计数，按照总销售额统计，方便集团公司给部分发送奖金

创建ThreadLocal：两种方式：

//	原始方法，创建匿名内部类，重写initialValue方法
ThreadLocal<Integer> sales = new ThreadLocal<Integer>(){
        @Override
        protected Integer initialValue() {
            return 0;
        }
    };

//	java8新方法，直接使用静态方法withInitial
ThreadLocal<Integer> threadLocal = ThreadLocal.withInitial(()->0);

修改threadLocal： get与set方法

public void saleHouse() {
        Integer value = threadLocal.get();
        ++value;
        threadLocal.set(value);
    }

阿里巴巴ThreadLocal编码规范

【强制】必须回收自定义的 ThreadLocal 变量，尤其在线程池场景下，线程经常会被复用，如果不清理自定义的 ThreadLocal 变量，可能会影响后续业务逻辑和造成内存泄露等问题。尽量在代理中使用try-finally 块进行回收。

code

try {
    for (int j = 1; j <=5; j++) {
        house.saleHouse();
    }
    System.out.println(Thread.currentThread().getName()+"\t"+"---卖出： "+house.threadLocal.get());
    }catch (Exception e){
       e.printStackTrace();
    }finally {
       house.threadLocal.remove();
    }

Thread、ThreadLocal、ThreadLocalMap关系

ThreadLocalMap是ThreadLocal的静态内部类
Thread与ThreadLocal是两个独立的类
三者关系图

ThreadLocalMap里面代码：里面继承一个弱引用

static class Entry extends WeakReference<ThreadLocal<?>> {
       /** The value associated with this ThreadLocal. */
       Object value;

       Entry(ThreadLocal<?> k, Object v) {
            super(k);
            value = v;
       }
}

源码分析：

get方法：

public T get() {
      Thread t = Thread.currentThread();
      ThreadLocalMap map = getMap(t);
      if (map != null) {
          ThreadLocalMap.Entry e = map.getEntry(this);
          if (e != null) {
              @SuppressWarnings("unchecked")
              T result = (T)e.value;
              return result;
          }
      }
      return setInitialValue();
}

private T setInitialValue() {
        T value = initialValue();
        Thread t = Thread.currentThread();
        ThreadLocalMap map = getMap(t);
        if (map != null)
            map.set(this, value);
        else
            createMap(t, value);
        return value;
}

获取对应线程t的map，如果map是null则返回初始值；如果map非空，就将ThreadLocal作为key传进去获得value值
对于setInitialValue方法：如果map不为空，设置值，否则创建一个map
threadLocalMap实际上就是一个以threadLocal实例为key．任意对象为value的Entry对象

小总结：
1. 近似的可以理解为：ThreadLocalMap从字面上就可以看出这是一个保存ThreadLocal对象的map(其实是以ThreadLocal为Key)，不过是经过了两层包装的ThreadLocal对象：
2. JVM内部维护了一个线程版的Map<ThreadLocal,Value>(通过ThreadLocal对象的set方法，结果把ThreadLocal对象自己当做key，放进了ThreadLoalMap中),每个线程要用到这个的时候，用当前的线程去Map里面获取，通过这样让每个线程都拥有了自己独立的变量，人手一份，竞争条件被彻底消除，在并发模式下是绝对安全的变量。

10.2 ThreadLocal内存泄露问题

阿里面试题：
1. 为什么ThreadLocalMap里面使用弱引用，不用会怎么样
什么是内存泄漏：不再会被使用的对象或者变量占用的内存不能被回收，就是内存泄露。
强软弱虚整体架构：
2. 强引用：即使OOM也不会回收，只有被标记为垃圾才会回收。将强引用指向null，之前的对象会被回收，此时会执行finalize函数，此函数是给JVM工程师调用的，用于做最后的回收工作，现在已经被废弃了。
3. 软引用：OOM时会回收，内存够用时不会回收。高速缓存会使用软引用。
```
SoftReference<MyData> softReference = new SoftReference<>(myData);
```
  应用场景：设计思路是：用一个HashMap来保存图片的路径和相应图片对象关联的软引用之间的映射关系，在内存不足时，
  JVM会自动回收这些缓存图片对象所占用的空间，从而有效地避免了OOM的问题。
```
Map<String, SoftReference<Bitmap>> imageCache =new HashMap<String, SoftReference <Bitmap>>();
```
4. 弱引用：只要gc就会回收
```
WeakReference<MyData> weakReference = new WeakReference<>(myData);
```
5. 虚引用：
```
ReferenceQueue<MyObject> referenceQueue = new ReferenceQueue<>();
9PhantomReference<MyObject> phantomReference = new PhantomReference<>(new MyObject(),referenceQueue);
```
  1. 虚引用必须和引用队列 (ReferenceQueue)联合使用
    虚引用需要java.lang.ref.PhantomReferenqe类来实现,顾名思义，就是形同虚设，与其他几种引用都不同，虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收器回收，它不能单独使用也不能通过它访问对象，虚引用必须和引用队列 (ReferenceQueue)联合使用。
  2. PhantomReference的get方法总是返回null
    虚引用的主要作用是跟踪对象被垃圾回收的状态。仅仅是提供了一种确保对象被 finalize以后，做某些事情的通知机制。
    PhantomReference的get方法总是返回null，因此无法访问对应的引用对象。
  3. 处理监控通知使用
    换句话说，设置虚引用关联对象的唯一目的，就是在这个对象被收集器回收的时候收到一个系统通知或者后续添加进一步的处理，用来实现比finalize机制更灵活的回收操作
6. GcRoots和四大引用小总结
7. Thread引用的关系图：
8. 为什么Entry使用弱引用，不用会怎样？
  1. 当functione1方法执行完毕后，栈帧销毁强引用划也就没有了。但此时线程的ThreadLocalMap里某个entry的key引用还指向这个对象
  2. 若这个key引用是强引用，就会导致key指向的ThreadLocal对象及v指向的对象不能被gc回收，造成内存泄漏：
  3. 若这个key引用是弱引用就大概率会减少内存泄漏的问题(还有一个key为nul的雷，第2个坑后面讲）。使用弱引用，
  4. 就可以使ThreadLocal对象在方法执行完华后顺利被回收且Entrv的kev引用指向为nul。
  6. 当我们为threadLocal/变量赋值，实际上就是当前的Entry(threadLocal实例为key，值为value)往这个threadLocalMap中存放。Entry中的key是弱引用，当threadLocal外部强引用被置为null(t=null),那么系统GC 的时候，根据可达性分析，这个threadLocal实例就没有任何一条链路能够引用到它，这个ThreadLocal势必会被回收。这样一来，ThreadLocalMap中就会出现key为null的Entry，就没有办法访问这些key为null的Entry的value，如果当前线程再迟迟不结束的话，这些key为null的Entry的value就会一直存在一条强引用链：Thread Ref -> Thread -> ThreaLocalMap -> Entry ->value永远无法回收，造成内存泄漏。
  7. 当然，如果当前thread运行结束，threadLocal, threadLocalMap,Entry没有引用链可达，在垃圾回收的时候都会被系统进行回收。
  8. 保套实际德用中我们有时体会思线程池去维护我们的线程，比如在Execuars newFIvedThreagPool()时创建线程的的时候，为了复用线程是不会结束的，所以threadLocal内存泄漏就值得我们小心
  9. 虽然弱引用，保证了key指向的ThreadLocal对象能被及时回收，但是v指向的value对象是需要ThreadLocalMap调用get、set时发现key为null时才会去回收整个entry、value，因此弱引用不能100%保证内存不泄露。我们要在不使用某个ThreadLocal对象后，手动调用remove()方法来删除它，尤其是在线程池中，不仅仅是内存泄露的问题，因为线程池中的线程是重复使用的，意味着这个线程的ThreadLocalMap对象也是重复使用的，如果我们不手动调用remove方法，那么后面的线程就有可能获取到上个线程达留下来的value值，造成bug。
  10. 总结：使用弱引用保证key值指向的ThreadLocal被回收；手动remove保证value值被回收。
9. 清除ThreadLocal中脏Entry
  1. expungeStaleEntry
  2. set()
  3. get()
  4. Remove作用：寻找脏Entry，即key=null的Entry，然后进行删除
  5. 小总结：从前面的set,getEntry.remove方法看出，在threadLocal的生命周期里，针对threadLocal存在的内存泄漏的问题，
    都会通过expungeStaleEntry, cleanSomeSlots,replaceStaleEntry这三个方法清理掉key为null的脏entry。
10. 小总结&最佳实践
  1. ```
  ThreadLocal.withInitial(()->初始化值）	//	否则容易空指针异常
```
2. 建议把ThreadLocal修饰为static：
  - 解释：ThreadLocal能实现了线程的数据隔离，不在于它自己本身，而在于Thread的ThreadLocalMap所以，ThreadLocal可以只初始化一次．只分配一块存储空间就足以了，没必要作为成员变量多次被初始化。
3. （强制）用完记得手动remove

11. Java对象内存布局和对象头

new一个Object对象占多少空间？
对象在内存的布局：在HotSpot虚拟机里，对象在堆内存中的存储布局可以划分为三个部分：对象头（Header）、实例数据（Instance Data）和对齐填充(Padding)
1. 对象头
  1. 对象标记
    2. 哈希码：hashcode
    3. 同步锁标记：synchronized标记
    4. GC标记：
    5. GC次数：经历过的垃圾回收的次数
    6. 偏向锁持有者：
  2. 类元信息（类型指针）：指向元空间的Class对象
  3. 对象头多大？在64位系统中，Mark Word占了8个字节，类型指针占了8个字节，一共是16个字节
  4. 数组对象多一个长度
2. 实例数据
3. 对齐填充：保证8个字节倍数
64位虚拟机

聊聊Object o = new Objet();

JOL工具：引入

<!--官网：http://openjdk.java.net/projects/code-tools/jol/定位：分析对象在JVM的大小和分布-->
<dependency>    
  <groupId>org.openjdk.jol</groupId>    
  <artifactId>jol-core</artifactId>    
  <version>0.9</version>
</dependency>

//	VM堆细节详细情况
System.out.println(VM.current().details());

# WARNING: Unable to attach Serviceability Agent. You can try again with escalated privileges. Two options: a) use -Djol.tryWithSudo=true to try with sudo; b) echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
# Running 64-bit HotSpot VM.
# Using compressed oop with 3-bit shift.
# Using compressed klass with 3-bit shift.
# WARNING | Compressed references base/shifts are guessed by the experiment!
# WARNING | Therefore, computed addresses are just guesses, and ARE NOT RELIABLE.
# WARNING | Make sure to attach Serviceability Agent to get the reliable addresses.
# Objects are 8 bytes aligned.
# Field sizes by type: 4, 1, 1, 2, 2, 4, 4, 8, 8 [bytes]
# Array element sizes: 4, 1, 1, 2, 2, 4, 4, 8, 8 [bytes]
  
//	所有对象分配的字节都是8的整数倍

//	
System.out.println(ClassLayout.parseInstance(o).toPrintable());

# WARNING: Unable to attach Serviceability Agent. You can try again with escalated privileges. Two options: a) use -Djol.tryWithSudo=true to try with sudo; b) echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
java.lang.Object object internals:
 OFFSET  SIZE   TYPE DESCRIPTION                               VALUE
      0     4        (object header)                           01 00 00 00 (00000001 00000000 00000000 00000000) (1)
      4     4        (object header)                           00 00 00 00 (00000000 00000000 00000000 00000000) (0)
      8     4        (object header)                           e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243)
     12     4        (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total

请添加图片描述
5. GC分代年龄：最多15，因为只有4bit，最大值是15
6. 压缩指针说明：开启之后就是4字节

java -XX:+PrintCommandLineFlags -version
默认开启压缩说明
开启了类型指针的压缩，以节约空间，假如不加压缩？？
手动关闭后再看看

12. Synchronized与锁升级

12.1 Synchronized简介

阿里要求：【强制】高并发时，同步调用应该去考量锁的性能拐耗。能用无锁数据结构，就不要用锁；能锁区块，就
不要锁整个方法体；能用对象锁，就不要用类锁。
说明：尽可能使加锁的代码块工作量尽可能的小，避免在锁代码块中调用 RPC 方法。
锁与无锁之间寻求平衡
1. 用锁能够实现数据的安全性，但是会带来性能下降。
2. 无锁能够基于线程并行提升程序性能，但是会带来安全性下降。
锁的升级过程：无锁 -> 偏向锁 -> 轻量级锁(cas) -> 重量级锁
由对象头中的Mark Word根据锁标志位的不同而被复用及锁升级策略

12.2 Synchronized性能变化

java5以前，只有Synchronized，这个是操作系统级别的重量级操作
1. 涉及到操作系统底层用户态和内核态的切换
2. 重量级锁，假如锁的竞争比较激烈的话，性能下降
4. java的线程是映射到操作系统原生线程之上的，如果要阻塞或唤醒一个线程就需要操作系统介入，需要在户态与核心态之间切换，这种切换会消耗大量的系统资源，因为用户态与内核态都有各自专用的内存空间，专用的寄存器等，用户态切换至内核态需要传递给许多变量、参数给内核，内核也需要保护好用户态在切换时的一些寄存器值、变量等，以便内核态调用结束后切换回用户态继续工作。
5. 在Java早期版本中，synchronized属于重量级锁，效率低下，因为监视器锁（monitor）是依赖于底层的操作系统的Mutex Lock来实现的，挂起线程和恢复线程都需要转入内核态去完成，阻塞或唤醒一个Java线程需要操作系统切换CPU状态来完成，这种状态切换需要耗费处理器时间，如果同步代码块中内容过于简单，这种切换的时间可能比用户代码执行的时间还长”，时间成本相对较高，这也是为什么早期的synchronized效率低的原因
6. Java 6之后，为了减少获得锁和释放锁所带来的性能消耗，引入了轻量级锁和偏向锁
为什么每一个对象都可以成为一个锁
1. Monitor可以理解为一种同步工具，也可理解为一种同步机制，常常被描述为一个Java对象。Java对象是天生的Monitor，每一个Java对象都有成为Monitor的潜质，因为在Java的设计中，每一个Java对象自打娘胎里出来就带了一把看不见的锁，它叫做内部锁或者Monitor锁。
2. Monitor的本质是依赖于底层操作系统的Mutex Lock实现，操作系统实现线程之间的切换需要从用户态到内核态的转换，成本非常高。
3. JVM中的同步就是基于进入和退出管程（Monitor）对象实现的。每个对象实例都会有一个 Monitor， Monitor 可以和对象一起创建、销毁。Monitor是由ObjectMonitor实现，而ObjectMonitor是由C++的ObjectMonitor.hpp文件实现，如下所示：
4. 结合之前的synchronized和对象头进行说明：

5. Java 6之后，为了减少获得锁和释放锁所带来的性能消耗，引入了轻量级锁和偏向锁。需要有个逐步升级的过程，别一开始就捅到重量级锁

12.3 锁种类及锁升级

多线程访问情况，3种
1. 只有一个线程来访问，有且唯一Only One
2. 有2个线程A、B来交替访问
3. 竞争激烈，多个线程来访问
锁升级的流程：
1. synchronized用的锁是存在Java对象头里的Mark Word中
2. 锁升级功能主要依赖MarkWord中锁标志位和释放偏向锁标志位
3. 锁的指向：牢记
  1. 偏向锁：MarkWord存储的是偏向的线程ID
  2. 轻量锁：MarkWord存储的是指向线程栈中Lock Record的指针；
  3. 重量锁：MarkWord存储的是指向堆中的monitor对象的指针：
无锁：
1. hashcode是调用的时候才会给生成，否则全是0
2. 前25位不使用，中间31位是hashcode（调用后才有，否则全0）

12.4 偏向锁

场景：单线程竞争
当线程A第一次竞争到锁时，通过操作修改Mark Word中的偏向线程ID、偏向模式。
如果不存在其他线程竞争，那么持有偏向锁的线程将永远不需要进行同步。
简单理解：当一段同步代码一直被同一个线程多次访问，由于只有一个线程那么该线程在后续访问时便会自动获得锁
Hotspot 的作者经过研究发现，大多数情况下：
多线程的情况下，锁不仅不存在多线程竞争，还存在锁由同一线程多次获得的情况，
偏向锁就是在这种情况下出现的，它的出现是为了解决只有在一个线程执行同步时提高性能。
备注：
偏向锁会偏向于第一个访问锁的线程，如果在接下来的运行过程中，该锁没有被其他的线程访问，则持有偏向锁的线程将永远不需要触发同步。也即偏向锁在资源没有竞争情况下消除了同步语句，懒的连CAS操作都不做了，直接提高程序性能
理论落地：
在实际应用运行过程中发现，“锁总是同一个线程持有，很少发生竞争”，也就是说锁总是被第一个占用他的线程拥有，这个线程就是锁的偏向线程。
那么只需要在锁第一次被拥有的时候，记录下偏向线程ID。这样偏向线程就一直持有着锁(后续这个线程进入和退出这段加了同步锁的代码块时，不需要再次加锁和释放锁。而是直接比较对象头里面是否存储了指向当前线程的偏向锁)。
如果相等表示偏向锁是偏向于当前线程的，就不需要再尝试获得锁了，直到竞争发生才释放锁。以后每次同步，检查锁的偏向线程ID与当前线程ID是否一致，如果一致直接进入同步。无需每次加锁解锁都去CAS更新对象头。如果自始至终使用锁的线程只有一个，很明显偏向锁几乎没有额外开销，性能极高。
如果不等，表示发生了竞争，锁己经不是总是偏向于同一个线程了，这个时候会尝试使用CAS来替换MarkWord里面的线程ID为新线程的ID
竞争成功，表示之前的线程不存在了，MarkWord里面的线程ID为新线程的ID，锁不会升级，仍然为偏向锁：
竞争失败，这时候可能需要升级变为轻量级锁，才能保证线程间公平竞争锁。
注意，偏向锁只有遇到其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁，线程是不会主动释放偏向锁的。
技术实现：
一个synchronized方法被一个线程抢到了锁时，那这个方法所在的对象就会在其所在的Mark Word中将偏向锁修改状态位，同时还会有占用前54位来存储线程指针作为标识。若该线程再次访问同一个synchronized方法时，该线程只需去对象头的Mark Word 中去判断一下是否有偏向锁指向本身的ID，无需再进入 Monitor 去竞争对象了。
案例说明：
1. 偏向锁的操作不用直接捅到操作系统，不涉及用户到内核转换，不必要直接升级为最高级，我们以一个account对象的“对象头”为例。
2. 假如有一个线程执行到synchronized代码块的时候，JVM使用CAS操作把线程指针ID记录到Mark Word当中，并修改标偏向标示，标示当前线程就获得该锁。锁对象变成偏向锁（通过CAS修改对象头里的锁标志位），字面意思是“偏向于第一个获得它的线程”的锁。执行完同步代码块后，线程并不会主动释放偏向锁。
3. 这时线程获得了锁，可以执行同步代码块。当该线程第二次到达同步代码块时会判断此时持有锁的线程是否还是自己（持有锁的线程ID也在对象头里），JVM通过account对象的Mark Word判断：当前线程ID还在，说明还持有着这个对象的锁，就可以继续进入临界区工作。由于之前没有释放锁，这里也就不需要重新加锁。 如果自始至终使用锁的线程只有一个，很明显偏向锁几乎没有额外开销，性能极高。
4. 结论：JVM不用和操作系统协商设置Mutex(争取内核)，它只需要记录下线程ID就标示自己获得了当前锁，不用操作系统接入。上述就是偏向锁：在没有其他线程竞争的时候，一直偏向偏心当前线程，当前线程可以一直执行。
5. 上述就是偏向锁：在没有其他线程竞争的时候，一直偏向偏心当前线程，当前线程可以一直执行。
JVM底层命令：
1. java -XX:+PrintFlagsInitial |grep BiasedLock*
2. 重要参数说明：
  1. 实际上偏向锁在JDK1.6之后是默认开启的，但是启动时间有延迟，
  2. 所以需要添加参数*-XX:BiasedLockingStartupDelay=0*，让其在程序启动时立刻启动。
  3. 开启偏向锁：-XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0
  4. 关闭偏向锁：关闭之后程序默认会直接进入*------------------------------------------>>>>>>>>* 轻量级锁状态。
    -XX:-UseBiasedLocking
3. 演示1：从对象头中的代码验证偏向锁存在
  1. 一切默认，演示无效果。演示效果是轻量级锁。
  2. 解释1:虽然开启，默认4秒生效，但是没有使用，就认为关闭了偏向锁，升级为轻量级锁
  3. 所以需要关闭延迟，演示偏向锁时需要设置： -XX:BiasedLockingStartupDelay=0
  4. 参数说明：
    偏向锁在JDK1.6以上默认开启，开启后程序启动几秒后才会被激活，可以使用JVM参数来关闭延退 -XX:BiasedLocking StartupDelay=0
    如果确定锁通常处于竞争状态则可通过JVM参数 -xx:-UseBiasedLocking 关闭偏向锁，那么默认会进入轻量级锁。就是说，如果竞争比较激烈，可以直接捅到轻量级锁
4. 演示2:
  1. 程序故意停止5秒再运行，也可以看到偏向锁的101代码。
  2. 偏向锁带ID的情况，101后面就不再是全0，而是指向偏向线程的ID
5. 偏向锁的撤销（开始有第二个线程开始抢夺）
  1. 偏向锁使用一种等到竞争出现才释放锁的机制，只有当其他线程竞争锁时，持有偏问飲的原来线程才会视撒
  2. 撤销需要等待全局安全点(该时间点上没有字节码正在执行)，同时检查持有偏向锁的线程是否还在执行．
    1. 第一个线程正在执行synchrorized方法(处于同步块)，它还没有执行完，其它线程来抢夺，该偏向锁会被取消掉并出现锁升级。此时轻量级锁由原持有偏向锁的线程持有，继续执行其同步代码，而正在竞争的线程会进入自旋等待获得该轻量级锁。
    2. 第一个线程执行完成synchronized方法(退出同步块)．则将对象头设置成无锁状态并撤销偏向锁，重新偏向。
6. 总体流程：
  1. 这个图里面偏向锁升级为轻量级锁的时候少画了一部，就是比较是否是自己的线程ID，是的话不进行CAS，否则CAS。偏向锁的升级发生在CAS失败后。
  2. 补充讨论什么情况下CAS会成功，当旧线程不复存在时，JVM会将锁对象的markword改变为无锁状态，此时CAS才会成功。
  3. 进去之后，检查锁状态，其中无锁和偏向锁都认为是无锁状态，他们后两位都是01
  4. 然后检查是偏向锁还是真的无锁，如果是偏向锁，比较一下是不是自己，是自己继续偏向锁；否则竞争升级锁；不是偏向锁的话，直接获得锁然后变成偏向锁
  5. CAS失败后，开始执行锁的撤销，进入一个安全点之后STW停机，检查持有锁的线程状态，如果退出了则直接去获取锁，此时获取到的锁已经升级为轻量级锁，图中画的有误；如果还在执行，则升级轻量级锁，下次在判断就不会走那个无锁分支了，直接进入轻量级锁。
7. Java15之后逐步废弃偏向锁。草！
  1. 废弃原因：开销过大，维护成本较大

12.5 轻量级锁

是什么：多线程竞争，但是任意时刻最多只有一个线程竞争，即不存在锁竞争太过激烈的情况，也就没有线程阻寨。
本质就是CAS替代阻塞；有一点点竞争，但是等待不严重，近似交替执行
后两位代码：00
轻量级锁是为了在线程近乎交替执行同步块时提高性能。
主要目的：在没有多线程竞争的前提下，通过CAS减少重量级锁使用操作系统互斥量产生的性能浓耗．说白了先自旋，不行才升级阻塞。
升级时机：当关闭偏向锁功能或多线程竞争偏向锁会导致偏向锁升级为轻量级锁
假如线程A己经拿到锁，这时线程B又来抢该对象的锁，由于该对象的锁己经被线程A拿到，当前该锁己是偏向锁了。
而线程B在争抢时发现对象头Mark Word中的线程ID不是线程B自己的线程ID(而是线程A)，那线程B就会进行CAS操作希望能获得锁。
此时线程B操作中有两种情况：
1. 如果锁获取成功，直按替换Mark Word中的线程ID为B自己的ID(A 一 B)，重新偏向于其他线程(即将偏向锁交给其他线程，相当于当前线程"被"释放了锁)，该锁会保持偏向锁状态，A线程Over，B线程上位；
2. 如果锁获取失败，则偏向锁升级为轻量级锁(设置偏向锁标识为0并设置锁标志位为00)，此时轻量级锁由原持有偏向锁的线程持有，继续执行其同步代码，而正在竞争的线程B会进入自旋等待获得该轻量级锁。
补充说明：
1. 前62位指向线程栈中Lock Record的指针
2. JVM会为每个线程在当前线程的栈帧中创建用于存储锁记录的空间，官方称为Displaced Mark Word。若一个线程获得锁时发现是轻量级锁，会把锁的Mark Word复制到自己的Displaced Mark Word里面。然后线程尝试用CAS将锁的MarkWord替换为指向锁记录的指针。如果成功，当前线程获得锁，如果失败，表示Mark Word已经被替换成了其他线程的锁记录，说明在与其它线程竞争锁，当前线程就尝试使用自旋来获取锁。意思就是用DisPlaced MarkWord进行自旋，存储的是检查时持有锁的线程
3. 在获取锁的过程中，Displaced MarkWord存储锁对象原本的markword，然后把锁里面的markword修改成自己的线程ID。之所以保存Displaced markword，用于锁的释放和升级。8中将进一步解释，此处补充说明6.
如何理解通过CAS获取轻量级锁：
1. 锁是一个对象，其对象头里面有markword字段，这个默认存储hashcode，
2. 线程在获取锁的过程中，HotSpot VM会为每一个线程分配一个数据结构叫锁记录，里面有两部分组成：锁对象头的备份，指向自己的指针；备份存储锁的初始值，用来CAS获取锁，同时也用来释放锁、升级为重量级锁。指向自己的指针用于在CAS是将锁对象的markword替换成自己的线程ID
3. 总之：每个线程都是以锁对象头markword初始值作为期望，然后修改成自己的锁记录的指针，释放锁的时候再改回期望值，期望值在加锁期间就存储在lock Record中。
4. 为什么不像偏向锁那样直接存储线程ID：因为轻量级锁需要释放，释放的时候需要恢复原始markword，所以需要对锁对象头进行备份。同时锁记录里面存储了线程指针。
轻量级锁的释放：
1. 在释放锁时，当前线程会使用 CAS操作将Displaced Mark Word的内容复制回锁的Mark Word里面。如果没有发生竞争，那么这个复制的操作会成功。如果有其他线程因为自旋多次导致轻量级锁升级成了重量级锁，那么CAS操作会失败，此时会释放锁并唤醒被阻塞的线程。
代码演示获取锁：如果关闭偏向锁，就可以直接进入轻量级锁： -XX: -UseBiasedLocking
流程梳理，图片参照12.4.6中图片：
1. 偏向锁升级为轻量级锁，或者一开始就是轻量级锁的时候，第一步先尝试CAS修改锁对象头的markword，让其指向自己，从二获得锁。
2. 如果失败，则进行自旋，直到成功获取或者达到一定次数升级为重量级锁
轻量级锁升级：
1. Java6之前：
  1. 默认启用，默认情况下自旋的次数是10次：-XX:PreBlockSpin=10来修改
  2. 或者自旋线程数超过cpu核数一半
  3. 上述了解即可，别用了。
2. Java6之后：自适应
  1. 自适应意味着自旋的次数不是固定不变的
  2. 而是根据：
    1. 同一个锁上一次自旋的时间。
    2. 拥有锁线程的状态来决定。
3. 自适应自旋锁的大致原理
  1. 线程如果自旋成功了，那下次自旋的最大次数会增加，因为JVM认为既然上次成功了，那么这一次也很大概率会成功。
  2. 反之，如果很少会自旋成功，那么下次会减少自旋的次数甚至不自旋，避免CPU空转。
轻量锁和偏向锁的区别和不同
1. 争夺轻量级锁失败时，自旋尝试抢占锁
2. 轻量级锁每次退出同步块都需要释放锁，而偏向锁是在竞争发生时才释放锁

12.6 重量级锁

前62位存储：指向堆中互斥量的指针（Moniter）；最后两位是10
重量级锁原理
Java中synchronized的重量级锁，是基于进入和退出Monitor对象实现的。在编译时会将同步块的开始位置插入monitor enter指令，
结束位置插入monitor exit指令。当线程执行到monitor enter指令时，会尝试获取对象所对应的Monitor所有权，如果获取到了，即获取到了锁，会在Monitor的owner中存放当前线程的id，这样它将处于锁定状态，除非退出同步块，否则其他线程无法获取到这个Monitor。

12.7 小总结

锁升级后，hashcode去哪了
1. 详细阐述：锁升级为轻量级或重量级锁后，Mark Word中保存的分别是线程栈帧里的锁记录指针和重量级锁指针，己经没有位置再保存哈希码，Gc年龄了，那么这些信息被移动到哪里去了呢？
2. 注意，这里只有偏向锁不能记录锁对象头初始的markword，轻量级锁可以记录在lock record中；重量级锁记录在monitor中。
3. 在Java语言里面一个对象如果计算过哈希码，就应该一直保持该值不变（强烈推荐但不强制，因为用户可以重载hashCode()方法按自己的意愿返回哈希码），否则很多依赖对象哈希码的API都可能存在出错风险。而作为绝大多数对象哈希码来源的Object::hashCode()方法，返回的是对象的一致性哈希码（identity Hash Code），这个值是能强制保证不变的，它通过在对象头中存储计算结果来保证第一次计算之后，再次调用该方法取到的哈希码值永远不会再发生改变。因此，当一个对象己经计算过一致性哈希码后，它就再也无法进入偏向锁状态了：而当一个对象当前正处于偏向锁状态，又收到需要计算其一致性哈希码请求时，它的偏向状态会被立即撤销，并且锁会膨胀为重量级锁。在重量级锁的实现中，对象头指向了重量级锁的位置，代表币量级锁的ObjectMonitor类里有字段可以记录非加锁状态（标志位为“01”）下的Mark Word，其中百然可以存储原来的哈希码。
4. 进一步翻译：
  1. 在无锁状态下，Mark Word中可以存储对象的identity hash code值。当对象的hashCode()方法第一次被调用时，JVM会生成对应的identity hash code值并将该值存储到Mark Word中。
  2. 对于偏向锁，在线程获取偏向锁时，会用Thread ID和epoch值覆盖identity hash code所在的位置。如果一个对象的hashCode()方法己经被调用过一次之后，这个对象不能被设置偏向锁。因为如果可以的化，那Mark Word中的identity hash code必然会被偏向线程Id给覆盖，这就会造成同一个对象前后两次调用hashCode()方法得到的结果不一致。
  3. 升级为轻量级锁时，JVM会在当前线程的栈帧中创建一个锁记录(Lock Record)空间，用于存储锁对象的Mark Word拷贝，该拷贝中可以包含identity hash code，所以轻量级锁可以和identity hash code共存，哈希码和GC年龄自然保存在此，释放锁后会将这些信息写回到对象头。
  4. 升级为重量级锁后，Mark Word保存的重蛋级锁指针，代表重量级锁的ObjectMonitor类里有字段记录非加锁状态下的Mark Word，锁释放后也会将信息写回到对象头。
各种锁的优缺点：
2. synchronized锁升级过程总结：一句话，就是先自旋，不行再阻塞。
3. 实际上是把之前的悲观锁(重量级锁)变成在一定条件下使用偏向锁以及使用轻量级(自旋锁CAS)的形式
4. synchronized在修饰方法和代码块在字节码上实现方式有很大差异，但是内部实现还是基于对象头的MarkWord来实现的
5. JDK1.6之前synchronized使用的是重量级锁，JDK1.6之后进行了优化，拥有了无锁->偏向锁->轻量级锁->重量级锁的升级过程，而不是无论什么情况都使用重量级锁。
6. 偏向锁:适用于单线程适用的情况，在不存在锁竞争的时候进入同步方法/代码块则使用偏向锁。
7. 轻量级锁：适用于竞争较不激烈的情况(这和乐观锁的使用范围类似)，存在竞争时升级为轻量级锁，轻量级锁采用的是自旋锁，如果同步方法/代码块执行时间很短的话，采用轻量级锁虽然会占用cpu资源但是相对比使用重量级锁还是更高效。
8. 重量级锁：适用于竞争激烈的情况，如果同步方法/代码块执行时间很长，那么使用轻量级锁自旋带来的性能消耗就比使用重量级锁更严重，这时候就需要升级为重量级锁。