无锁并发

CAS

原理

无锁编程：Lock Free

CAS 的全称是 Compare-And-Swap，是 CPU 并发原语

• CAS 并发原语表现在 Java 语言中便是 sun.misc.Unsafe 类的各个办法，调用 UnSafe 类中的 CAS 办法，JVM 会完结出 CAS 汇编指令，这是一种完全依赖于硬件的功用，完结了原子操作
• CAS 是一种体系原语，原语归于操作体系范畴，是由若干条指令组成 ，用于完结某个功用的一个进程，而且原语的履行有必要是接连的，履行进程中不允许被中止，所以 CAS 是一条 CPU 的原子指令，不会构成数据不共同的问题，是线程安全的

底层原理：CAS 的底层是 lock cmpxchg 指令（X86 架构），在单核和多核 CPU 下都能够确保比较交流的原子性

• 程序是在单核处理器上运转，会省略 lock 前缀，单处理器自身会保护处理器内的次序共同性，不需求 lock 前缀的内存屏障效果

• 程序是在多核处理器上运转，会为 cmpxchg 指令加上 lock 前缀。当某个核履行到带 lock 的指令时，CPU 会履行总线确定或缓存确定，将修正的变量写入到主存，这个进程不会被线程的调度机制所打断，确保了多个线程对内存操作的原子性

效果：比较当时作业内存中的值和主物理内存中的值，假如相同则履行规矩操作，不然持续比较直到主内存和作业内存的值共同中止

CAS 特点：

• CAS 表现的是无锁并发、无堵塞并发，线程不会堕入堵塞，线程不需求频频切换状况（上下文切换，体系调用）
• CAS 是依据达观锁的思维

CAS 缺陷：

• 履行的是循环操作，假如比较不成功一向在循环，最差的状况某个线程一向取到的值和预期值都不相同，就会无限循环导致饥饿，运用 CAS 线程数不要超越 CPU 的中心数，选用分段 CAS 和主动搬迁机制
• 只能确保一个同享变量的原子操作
  • 关于一个同享变量履行操作时，能够经过循环 CAS 的办法来确保原子操作
  • 关于多个同享变量操作时，循环 CAS 就无法确保操作的原子性，这个时分只能用锁来确保原子性
• 引出来 ABA 问题

达观锁

CAS 与 synchronized 总结：

• synchronized 是从失望的视点动身：总是假定最坏的状况，每次去拿数据的时分都认为他人会修正，所以每次在拿数据的时分都会上锁，这样他人想拿这个数据就会堵塞（同享资源每次只给一个线程运用，其它线程堵塞，用完后再把资源转让给其它线程），因而 synchronized 也称之为失望锁，ReentrantLock 也是一种失望锁，功能较差
• CAS 是从达观的视点动身：总是假定最好的状况，每次去拿数据的时分都认为他人不会修正，所以不会上锁，可是在更新的时分会判别一下在此期间他人有没有去更新这个数据。假如他人修正过，则获取现在最新的值，假如他人没修正过，直接修正同享数据的值，CAS 这种机制也称之为达观锁，归纳功能较好。

Atomic

常用API

常见原子类：AtomicInteger、AtomicBoolean、AtomicLong

结构办法：

• public AtomicInteger()：初始化一个默许值为 0 的原子型 Integer
• public AtomicInteger(int initialValue)：初始化一个指定值的原子型 Integer

常用API：

办法	效果
public final int get()	获取 AtomicInteger 的值
public final int getAndIncrement()	以原子办法将当时值加 1，回来的是自增前的值
public final int incrementAndGet()	以原子办法将当时值加 1，回来的是自增后的值
public final int getAndSet(int value)	以原子办法设置为 newValue 的值，回来旧值
public final int addAndGet(int data)	以原子办法将输入的数值与实例中的值相加并回来 实例：AtomicInteger 里的 value

原理剖析

AtomicInteger 原理：自旋锁 + CAS 算法

CAS 算法：有 3 个操作数（内存值 V， 旧的预期值 A，要修正的值 B）

• 当旧的预期值 A == 内存值 V 此刻能够修正，将 V 改为 B
• 当旧的预期值 A != 内存值 V 此刻不能修正，并从头获取现在的最新值，从头获取的动作便是自旋

剖析 getAndSet 办法：

• AtomicInteger：

  public final int getAndSet(int newValue) {
      /**
      * this: 		当时目标
      * valueOffset:	内存偏移量，内存地址
      */
      return unsafe.getAndSetInt(this, valueOffset, newValue);
  }
  

  valueOffset：偏移量表明该变量值相关于当时目标地址的偏移，Unsafe 便是依据内存偏移地址获取数据

  valueOffset = unsafe.objectFieldOffset
                  (AtomicInteger.class.getDeclaredField("value"));
  //调用本地办法   -->
  public native long objectFieldOffset(Field var1);
  

• unsafe 类：

  // val1: AtomicInteger目标自身，var2: 该目标值得引证地址，var4: 需求变动的字段
  public final int getAndSetInt(Object var1, long var2, int var4) {
      int var5;
      do {
          // var5: 用 var1 和 var2 找到的内存中的实在值
          var5 = this.getIntVolatile(var1, var2);
      } while(!this.compareAndSwapInt(var1, var2, var5, var4));
      return var5;
  }
  

  var5：从主内存中仿制到作业内存中的值（每次都要从主内存拿到最新的值到本地内存），然后履行 compareAndSwapInt() 再和主内存的值进行比较，假定办法回来 false，那么就一向履行 while 办法，直到期望的值和实在值相同，修正数据

• 变量 value 用 volatile 润饰，确保了多线程之间的内存可见性，避免线程从作业缓存中获取失效的变量

  private volatile int value
  

  CAS 有必要凭借 volatile 才干读取到同享变量的最新值来完结比较并交流的效果

剖析 getAndUpdate 办法：

• getAndUpdate：

  public final int getAndUpdate(IntUnaryOperator updateFunction) {
      int prev, next;
      do {
          prev = get();	//当时值，cas的期望值
          next = updateFunction.applyAsInt(prev);//期望值更新到该值
      } while (!compareAndSet(prev, next));//自旋
      return prev;
  }
  

  函数式接口：能够自定义操作逻辑

  AtomicInteger a = new AtomicInteger();
  a.getAndUpdate(i -> i + 10);
  

• compareAndSet：

  public final boolean compareAndSet(int expect, int update) {
      /**
      * this: 		当时目标
      * valueOffset:	内存偏移量，内存地址
      * expect:		期望的值
      * update: 		更新的值
      */
      return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
  }
  

原子引证

原子引证：对 Object 进行原子操作，供给一种读和写都是原子性的目标引证变量

原子引证类：AtomicReference、AtomicStampedReference、AtomicMarkableReference

AtomicReference 类：

• 结构办法：AtomicReference<T> atomicReference = new AtomicReference<T>()

• 常用 API：

  • public final boolean compareAndSet(V expectedValue, V newValue)：CAS 操作
  • public final void set(V newValue)：将值设置为 newValue
  • public final V get()：回来当时值

public class AtomicReferenceDemo {
    public static void main(String[] args) {
        Student s1 = new Student(33, "z3");
        // 创立原子引证包装类
        AtomicReference<Student> atomicReference = new AtomicReference<>();
        // 设置主内存同享变量为s1
        atomicReference.set(s1);
        // 比较并交流，假如现在主物理内存的值为 z3，那么交流成 l4
        while (true) {
            Student s2 = new Student(44, "l4");
            if (atomicReference.compareAndSet(s1, s2)) {
                break;
            }
        }
        System.out.println(atomicReference.get());
    }
}
class Student {
    private int id;
    private String name;
    //...
}

原子数组

原子数组类：AtomicIntegerArray、AtomicLongArray、AtomicReferenceArray

AtomicIntegerArray 类办法：

/**
*   i		the index
* expect 	the expected value
* update 	the new value
*/
public final boolean compareAndSet(int i, int expect, int update) {
    return compareAndSetRaw(checkedByteOffset(i), expect, update);
}

原子更新器

原子更新器类：AtomicReferenceFieldUpdater、AtomicIntegerFieldUpdater、AtomicLongFieldUpdater

运用字段更新器，能够针对目标的某个域（Field）进行原子操作，只能配合 volatile 润饰的字段运用，不然会呈现异常 IllegalArgumentException: Must be volatile type

常用 API：

• static <U> AtomicIntegerFieldUpdater<U> newUpdater(Class<U> c, String fieldName)：结构办法
• abstract boolean compareAndSet(T obj, int expect, int update)：CAS

public class UpdateDemo {
    private volatile int field;
    public static void main(String[] args) {
        AtomicIntegerFieldUpdater fieldUpdater = AtomicIntegerFieldUpdater
            		.newUpdater(UpdateDemo.class, "field");
        UpdateDemo updateDemo = new UpdateDemo();
        fieldUpdater.compareAndSet(updateDemo, 0, 10);
        System.out.println(updateDemo.field);//10
    }
}

原子累加器

原子累加器类：LongAdder、DoubleAdder、LongAccumulator、DoubleAccumulator

LongAdder 和 LongAccumulator 区别：

相同点：

• LongAddr 与 LongAccumulator 类都是运用非堵塞算法 CAS 完结的
• LongAddr 类是 LongAccumulator 类的一个特例，仅仅 LongAccumulator 供给了更强壮的功用，能够自定义累加规矩，当accumulatorFunction 为 null 时就等价于 LongAddr

不同点：

• 调用 casBase 时，LongAccumulator 运用 function.applyAsLong(b = base, x) 来核算，LongAddr 运用 casBase(b = base, b + x)

• LongAccumulator 类功用愈加强壮，结构办法参数中

  • accumulatorFunction 是一个双目运算器接口，能够指定累加规矩，比方累加或许相乘，其依据输入的两个参数回来一个核算值，LongAdder 内置累加规矩
  • identity 则是 LongAccumulator 累加器的初始值，LongAccumulator 能够为累加器供给非0的初始值，而 LongAdder 只能供给默许的 0

Adder

优化机制

LongAdder 是 Java8 供给的类，跟 AtomicLong 有相同的效果，但对 CAS 机制进行了优化，测验运用分段 CAS 以及主动分段搬迁的办法来大幅度进步多线程高并发履行 CAS 操作的功能

CAS 底层完结是在一个循环中不断地测验修正目标值，直到修正成功。假如竞赛不剧烈修正成功率很高，不然失利率很高，失利后这些重复的原子性操作会耗费功能（导致很多线程空循环，自旋转）

优化中心思维：数据分离，将 AtomicLong 的单点的更新压力分担到各个节点，空间换时刻，在低并发的时分直接更新，能够保证和 AtomicLong 的功能根本共同，而在高并发的时分经过涣散削减竞赛，进步了功能

分段 CAS 机制：

• 在产生竞赛时，创立 Cell 数组用于将不同线程的操作离散（经过 hash 等算法映射）到不同的节点上
• 设置多个累加单元（会依据需求扩容，最大为 CPU 核数），Therad-0 累加 Cell[0]，而 Thread-1 累加 Cell[1] 等，终究将成果汇总
• 在累加时操作的不同的 Cell 变量，因而削减了 CAS 重试失利，然后进步功能

主动分段搬迁机制：某个 Cell 的 value 履行 CAS 失利，就会主动寻觅另一个 Cell 分段内的 value 值进行 CAS 操作。

伪同享

Cell 为累加单元：数组拜访索引是经过 Thread 里的 threadLocalRandomProbe 域取模完结的，这个域是 ThreadLocalRandom 更新的

// Striped64.Cell
@sun.misc.Contended static final class Cell {
    volatile long value;
    Cell(long x) { value = x; }
    // 用 cas 办法进行累加, prev 表明旧值, next 表明新值
    final boolean cas(long prev, long next) {
    	return UNSAFE.compareAndSwapLong(this, valueOffset, prev, next);
    }
    // 省略不重要代码
}

Cell 是数组形式，在内存中是接连存储的，64 位体系中，一个 Cell 为 24 字节（16 字节的目标头和 8 字节的 value），每一个 cache line 为 64 字节，因而缓存行能够存下 2 个的 Cell 目标，当 Core-0 要修正 Cell[0]、Core-1 要修正 Cell[1]，无论谁修正成功都会导致当时缓存行失效，然后导致对方的数据失效，需求从头去主存获取，影响功率。

@sun.misc.Contended：避免缓存行伪同享，在运用此注解的目标或字段的前后各增加 128 字节巨细的 padding，运用 2 倍于大多数硬件缓存行让 CPU 将目标预读至缓存时占用不同的缓存行，这样就不会构成对方缓存行的失效。

源码解析

Striped64 类成员特点：

// 表明当时核算机CPU数量
static final int NCPU = Runtime.getRuntime().availableProcessors()
// 累加单元数组, 懒散初始化
transient volatile Cell[] cells;
// 根底值, 假如没有竞赛, 则用 cas 累加这个域，当 cells 扩容时，也会将数据写到 base 中
transient volatile long base;
// 在 cells 初始化或扩容时只能有一个线程履行, 经过 CAS 更新 cellsBusy 置为 1 来完结一个锁
transient volatile int cellsBusy;

作业流程：

• cells 占用内存是相对比较大的，是惰性加载的，在无竞赛或许其他线程正在初始化 cells 数组的状况下，直接更新 base 域

• 在第一次产生竞赛时（casBase 失利）会创立一个巨细为 2 的 cells 数组，将当时累加的值包装为 Cell 目标，放入映射的槽位上

• 分段累加的进程中，假如当时线程对应的 cells 槽位为空，就会新建 Cell 填充，假如呈现竞赛，就会从头核算线程对应的槽位，持续自旋测验修正

• 分段搬迁后还呈现竞赛就会扩容 cells 数组长度为原本的两倍，然后 rehash，数组长度总是 2 的 n 次幂，默许最大为 CPU 核数，可是能够超越，假如核数是 6 核，数组最长是 8

办法剖析：

• LongAdder#add：累加办法

  public void add(long x) {
      // as 为累加单元数组的引证，b 为根底值，v 表明期望值
      // m 表明 cells 数组的长度 - 1，a 表明当时线程命中的 cell 单元格
      Cell[] as; long b, v; int m; Cell a;
      // cells 不为空阐明 cells 现已被初始化，线程产生了竞赛，去更新对应的 cell 槽位
      // 进入 || 后的逻辑去更新 base 域，更新失利表明产生竞赛进入条件
      if ((as = cells) != null || !casBase(b = base, b + x)) {
          // uncontended 为 true 表明 cell 没有竞赛
          boolean uncontended = true;
          // 条件一: true 阐明 cells 未初始化，多线程写 base 产生竞赛需求进行初始化 cells 数组
          //		  fasle 阐明 cells 现已初始化，进行下一个条件寻觅自己的 cell 去累加
          // 条件二: getProbe() 获取 hash 值，& m 的逻辑和 HashMap 的逻辑相同，确保散列的均匀性
          // 		  true 阐明当时线程对应下标的 cell 为空，需求创立 cell
          //        false 阐明当时线程对应的 cell 不为空，进行下一个条件【将 x 值累加到对应的 cell 中】
          // 条件三: 有取反符号，false 阐明 cas 成功，直接回来，true 阐明失利，当时线程对应的 cell 有竞赛
          if (as == null || (m = as.length - 1) < 0 ||
              (a = as[getProbe() & m]) == null ||
              !(uncontended = a.cas(v = a.value, v + x)))
              longAccumulate(x, null, uncontended);
          	// 【uncontended 在对应的 cell 上累加失利的时分才为 false，其他状况均为 true】
      }
  }
  

• Striped64#longAccumulate：cell 数组创立

  							// x  			null 			false | true
  final void longAccumulate(long x, LongBinaryOperator fn, boolean wasUncontended) {
      int h;
      // 当时线程还没有对应的 cell, 需求随机生成一个 hash 值用来将当时线程绑定到 cell
      if ((h = getProbe()) == 0) {
          // 初始化 probe，获取 hash 值
          ThreadLocalRandom.current(); 
          h = getProbe();	
          // 默许状况下 当时线程肯定是写入到了 cells[0] 方位，不把它作为一次真实的竞赛
          wasUncontended = true;
      }
      // 表明【扩容意向】，false 一定不会扩容，true 或许会扩容
      boolean collide = false; 
      //自旋
      for (;;) {
          // as 表明cells引证，a 表明当时线程命中的 cell，n 表明 cells 数组长度，v 表明 期望值
          Cell[] as; Cell a; int n; long v;
          // 【CASE1】: 表明 cells 现已初始化了，当时线程应该将数据写入到对应的 cell 中
          if ((as = cells) != null && (n = as.length) > 0) {
              // CASE1.1: true 表明当时线程对应的索引下标的 Cell 为 null，需求创立 new Cell
              if ((a = as[(n - 1) & h]) == null) {
                  // 判别 cellsBusy 是否被锁
                  if (cellsBusy == 0) {   
                      // 创立 cell, 初始累加值为 x
                      Cell r = new Cell(x);  
                      // 加锁
                      if (cellsBusy == 0 && casCellsBusy()) {
                          // 创立成功符号，进入【创立 cell 逻辑】
                          boolean created = false;	
                          try {
                              Cell[] rs; int m, j;
                              // 把当时 cells 数组赋值给 rs，而且不为 null
                              if ((rs = cells) != null &&
                                  (m = rs.length) > 0 &&
                                  // 再次判别避免其它线程初始化过该方位，当时线程再次初始化该方位会构成数据丢掉
                                  // 由于这儿是线程安全的判别，进行的逻辑不会被其他线程影响
                                  rs[j = (m - 1) & h] == null) {
                                  // 把新创立的 cell 填充至当时方位
                                  rs[j] = r;
                                  created = true;	// 表明创立完结
                              }
                          } finally {
                              cellsBusy = 0;		// 解锁
                          }
                          if (created)			// true 表明创立完结，能够推出循环了
                              break;
                          continue;
                      }
                  }
                  collide = false;
              }
              // CASE1.2: 条件建立阐明线程对应的 cell 有竞赛, 改变线程对应的 cell 来重试 cas
              else if (!wasUncontended)
                  wasUncontended = true;
              // CASE 1.3: 当时线程 rehash 过，假如新命中的 cell 不为空，就测验累加，false 阐明新命中也有竞赛
              else if (a.cas(v = a.value, ((fn == null) ? v + x : fn.applyAsLong(v, x))))
                  break;
              // CASE 1.4: cells 长度现已超越了最大长度 CPU 内核的数量或许现已扩容
              else if (n >= NCPU || cells != as)
                  collide = false; 		// 扩容意向改为false，【表明不能扩容了】
              // CASE 1.5: 更改扩容意向，假如 n >= NCPU，这儿就永久不会履行到，case1.4 永久先于 1.5 履行
              else if (!collide)
                  collide = true;
              // CASE 1.6: 【扩容逻辑】，进行加锁
              else if (cellsBusy == 0 && casCellsBusy()) {
                  try {
                      // 线程安全的查看，避免期间被其他线程扩容了
                      if (cells == as) {     
                          // 扩容为曾经的 2 倍
                          Cell[] rs = new Cell[n << 1];
                          // 遍历移动值
                          for (int i = 0; i < n; ++i)
                              rs[i] = as[i];
                          // 把扩容后的引证给 cells
                          cells = rs;
                      }
                  } finally {
                      cellsBusy = 0;	// 解锁
                  }
                  collide = false;	// 扩容意向改为 false，表明不扩容了
                  continue;
              }
              // 重置当时线程 Hash 值，这便是【分段搬迁机制】
              h = advanceProbe(h);
          }
          // 【CASE2】: 运转到这阐明 cells 还未初始化，as 为null
          // 判别是否没有加锁，没有加锁就用 CAS 加锁
          // 条件二判别是否其它线程在当时线程给 as 赋值之后修正了 cells，这儿不是线程安全的判别
          else if (cellsBusy == 0 && cells == as && casCellsBusy()) {
              // 初始化标志，开端 【初始化 cells 数组】
              boolean init = false;
              try { 
                 	// 再次判别 cells == as 避免其它线程现已提早初始化了，当时线程再次初始化导致丢掉数据
                  // 由于这儿是【线程安全的，从头查看，经典 DCL】
                  if (cells == as) {
                      Cell[] rs = new Cell[2];	// 初始化数组巨细为2
                      rs[h & 1] = new Cell(x);	// 填充线程对应的cell
                      cells = rs;
                      init = true;				// 初始化成功，符号置为 true
                  }
              } finally {
                  cellsBusy = 0;					// 解锁啊
              }
              if (init)
                  break;							// 初始化成功直接跳出自旋
          }
          // 【CASE3】: 运转到这阐明其他线程在初始化 cells，当时线程将值累加到 base，累加成功直接完毕自旋
          else if (casBase(v = base, ((fn == null) ? v + x :
                                      fn.applyAsLong(v, x))))
              break; 
      }
  }
  

• sum：获取终究成果经过 sum 整合，确保终究共同性，不确保强共同性

  public long sum() {
      Cell[] as = cells; Cell a;
      long sum = base;
      if (as != null) {
          // 遍历 累加
          for (int i = 0; i < as.length; ++i) {
              if ((a = as[i]) != null)
                  sum += a.value;
          }
      }
      return sum;
  }
  

ABA问题

ABA 问题：当进行获取主内存值时，该内存值在写入主内存时现已被修正了 N 次，可是终究又改成原本的值

其他线程先把 A 改成 B 又改回 A，主线程仅能判别出同享变量的值与最初值 A 是否相同，不能感知到这种从 A 改为 B 又 改回 A 的状况，这时 CAS 虽然成功，可是进程存在问题

• 结构办法：

  • public AtomicStampedReference(V initialRef, int initialStamp)：初始值和初始版本号

• 常用API：

  • public boolean compareAndSet(V expectedReference, V newReference, int expectedStamp, int newStamp)：期望引证和期望版本号都共同才进行 CAS 修正数据
  • public void set(V newReference, int newStamp)：设置值和版本号
  • public V getReference()：回来引证的值
  • public int getStamp()：回来当时版本号

public static void main(String[] args) {
    AtomicStampedReference<Integer> atomicReference = new AtomicStampedReference<>(100,1);
    int startStamp = atomicReference.getStamp();
    new Thread(() ->{
        int stamp = atomicReference.getStamp();
        atomicReference.compareAndSet(100, 101, stamp, stamp + 1);
        stamp = atomicReference.getStamp();
        atomicReference.compareAndSet(101, 100, stamp, stamp + 1);
    },"t1").start();
    new Thread(() ->{
        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        if (!atomicReference.compareAndSet(100, 200, startStamp, startStamp + 1)) {
            System.out.println(atomicReference.getReference());//100
            System.out.println(Thread.currentThread().getName() + "线程修正失利");
        }
    },"t2").start();
}

Unsafe

Unsafe 是 CAS 的中心类，由于 Java 无法直接拜访底层体系，需求经过本地（Native）办法来拜访

Unsafe 类存在 sun.misc 包，其间一切办法都是 native 润饰的，都是直接调用操作体系底层资源履行相应的使命，依据该类能够直接操作特定的内存数据，其内部办法操作类似 C 的指针。

模拟完结原子整数：

public static void main(String[] args) {
    MyAtomicInteger atomicInteger = new MyAtomicInteger(10);
    if (atomicInteger.compareAndSwap(20)) {
        System.out.println(atomicInteger.getValue());
    }
}
class MyAtomicInteger {
    private static final Unsafe UNSAFE;
    private static final long VALUE_OFFSET;
    private volatile int value;
    static {
        try {
            //Unsafe unsafe = Unsafe.getUnsafe()这样会报错，需求反射获取
            Field theUnsafe = Unsafe.class.getDeclaredField("theUnsafe");
            theUnsafe.setAccessible(true);
            UNSAFE = (Unsafe) theUnsafe.get(null);
            // 获取 value 特点的内存地址，value 特点指向该地址，直接设置该地址的值能够修正 value 的值
            VALUE_OFFSET = UNSAFE.objectFieldOffset(
                		   MyAtomicInteger.class.getDeclaredField("value"));
        } catch (NoSuchFieldException | IllegalAccessException e) {
            e.printStackTrace();
            throw new RuntimeException();
        }
    }
    public MyAtomicInteger(int value) {
        this.value = value;
    }
    public int getValue() {
        return value;
    }
    public boolean compareAndSwap(int update) {
        while (true) {
            int prev = this.value;
            int next = update;
            //							当时目标  内存偏移量    期望值 更新值
            if (UNSAFE.compareAndSwapInt(this, VALUE_OFFSET, prev, update)) {
                System.out.println("CAS成功");
                return true;
            }
        }
    }
}

final

原理

public class TestFinal {
	final int a = 20;
}

字节码：

0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: aload_0
5: bipush 20		// 将值直接放入栈中
7: putfield #2 		// Field a:I
<-- 写屏障
10: return

final 变量的赋值经过 putfield 指令来完结，在这条指令之后也会加入写屏障，确保在其它线程读到它的值时不会呈现为 0 的状况

其他线程拜访 final 润饰的变量会仿制一份放入栈中，功率更高

不行变

不行变：假如一个目标不能够修正其内部状况（特点），那么便是不行变目标

不行变目标线程安全的，不存在并发修正和可见性问题，是另一种避免竞赛的办法

String 类也是不行变的，该类和类中一切特点都是 final 的

• 类用 final 润饰确保了该类中的办法不能被掩盖，避免子类无意间破坏不行变性

• 无写入办法（set）确保外部不能对内部特点进行修正

• 特点用 final 润饰确保了该特点是只读的，不能修正

  public final class String
      implements java.io.Serializable, Comparable<String>, CharSequence {
      /** The value is used for character storage. */
      private final char value[];
      //....
  }
  

• 更改 String 类数据时，会结构新字符串目标，生成新的 char[] value，经过创立副本目标来避免同享的办法称之为保护性仿制

NO-State

无状况：成员变量保存的数据也能够称为状况信息，无状况便是没有成员变量。这品种也是线程安全的。

Servlet 为了确保其线程安全，一般不为 Servlet 设置成员变量，这种没有任何成员变量的类是线程安全的。

ThreadLocal

根本介绍

ThreadLocal 类用来供给线程内部的局部变量，这种变量在多线程环境下拜访（经过 get 和 set 办法拜访）时能确保各个线程的变量相对独立于其他线程内的变量，分配在堆内的 TLAB 中

ThreadLocal 实例通常来说都是 private static 类型的，归于一个线程的本地变量，用于相关线程和线程上下文。每个线程都会在 ThreadLocal 中保存一份该线程独有的数据，所以是线程安全的。

ThreadLocal 效果：

• 线程并发：应用在多线程并发的场景下

• 传递数据：经过 ThreadLocal 完结在同一线程不同函数或组件中传递公共变量，削减传递复杂度

• 线程阻隔：每个线程的变量都是独立的，不会互相影响

对比 synchronized：

synchronized	ThreadLocal
原理	同步机制选用以时刻换空间的办法，只供给了一份变量，让不同的线程排队拜访	ThreadLocal 选用以空间换时刻的办法，为每个线程都供给了一份变量的副本，然后完结一起拜访而相不搅扰
侧重点	多个线程之间拜访资源的同步	多线程中让每个线程之间的数据彼此阻隔

根本运用

常用办法

办法	描绘
ThreadLocal<>()	创立 ThreadLocal 目标
protected T initialValue()	回来当时线程局部变量的初始值
public void set( T value)	设置当时线程绑定的局部变量
public T get()	获取当时线程绑定的局部变量
public void remove()	移除当时线程绑定的局部变量

public class MyDemo {
    private static ThreadLocal<String> tl = new ThreadLocal<>();
    private String content;
    private String getContent() {
        // 获取当时线程绑定的变量
        return tl.get();
    }
    private void setContent(String content) {
        // 变量content绑定到当时线程
        tl.set(content);
    }
    public static void main(String[] args) {
        MyDemo demo = new MyDemo();
        for (int i = 0; i < 5; i++) {
            Thread thread = new Thread(new Runnable() {
                @Override
                public void run() {
                    // 设置数据
                    demo.setContent(Thread.currentThread().getName() + "的数据");
                    System.out.println("-----------------------");
                    System.out.println(Thread.currentThread().getName() + "--->" + demo.getContent());
                }
            });
            thread.setName("线程" + i);
            thread.start();
        }
    }
}

应用场景

ThreadLocal 适用于下面两种场景：

• 每个线程需求有自己单独的实例
• 实例需求在多个办法中同享，但不期望被多线程同享

ThreadLocal 方案有两个杰出的优势：

1. 传递数据：保存每个线程绑定的数据，在需求的当地能够直接获取，避免参数直接传递带来的代码耦合问题
2. 线程阻隔：各线程之间的数据彼此阻隔却又具备并发性，避免同步办法带来的功能丢失

ThreadLocal 用于数据衔接的事务管理：

public class JdbcUtils {
    // ThreadLocal目标，将connection绑定在当时线程中
    private static final ThreadLocal<Connection> tl = new ThreadLocal();
    // c3p0 数据库衔接池目标特点
    private static final ComboPooledDataSource ds = new ComboPooledDataSource();
    // 获取衔接
    public static Connection getConnection() throws SQLException {
        //取出当时线程绑定的connection目标
        Connection conn = tl.get();
        if (conn == null) {
            //假如没有，则从衔接池中取出
            conn = ds.getConnection();
            //再将connection目标绑定到当时线程中，非常重要的操作
            tl.set(conn);
        }
        return conn;
    }
	// ...
}

用 ThreadLocal 使 SimpleDateFormat 从独享变量变成单个线程变量：

public class ThreadLocalDateUtil {
    private static ThreadLocal<DateFormat> threadLocal = new ThreadLocal<DateFormat>() {
        @Override
        protected DateFormat initialValue() {
            return new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
        }
    };
    public static Date parse(String dateStr) throws ParseException {
        return threadLocal.get().parse(dateStr);
    }
    public static String format(Date date) {
        return threadLocal.get().format(date);
    }
}

完结原理

底层结构

JDK8 曾经：每个 ThreadLocal 都创立一个 Map，然后用线程作为 Map 的 key，要存储的局部变量作为 Map 的 value，达到各个线程的局部变量阻隔的效果。这种结构会构成 Map 结构过大和内存走漏，由于 Thread 中止后无法经过 key 删去对应的数据。

JDK8 以后：每个 Thread 保护一个 ThreadLocalMap，这个 Map 的 key 是 ThreadLocal 实例自身，value 是真实要存储的值。

• 每个 Thread 线程内部都有一个 Map (ThreadLocalMap)
• Map 里边存储 ThreadLocal 目标（key）和线程的私有变量（value）
• Thread 内部的 Map 是由 ThreadLocal 保护的，由 ThreadLocal 负责向 map 获取和设置线程的变量值
• 关于不同的线程，每次获取副本值时，别的线程并不能获取到当时线程的副本值，构成副本的阻隔，互不搅扰

JDK8 前后对比：

• 每个 Map 存储的 Entry 数量会变少，由于之前的存储数量由 Thread 的数量决定，现在由 ThreadLocal 的数量决定，在实际编程傍边，往往 ThreadLocal 的数量要少于 Thread 的数量
• 当 Thread 毁掉之后，对应的 ThreadLocalMap 也会随之毁掉，能削减内存的运用，避免内存走漏

成员变量

• Thread 类的相关特点：每一个线程持有一个 ThreadLocalMap 目标，寄存由 ThreadLocal 和数据组成的 Entry 键值对

  ThreadLocal.ThreadLocalMap threadLocals = null
  

• 核算 ThreadLocal 目标的哈希值：

  private final int threadLocalHashCode = nextHashCode()
  

  运用 threadLocalHashCode & (table.length - 1) 核算当时 entry 需求寄存的方位

• 每创立一个 ThreadLocal 目标就会运用 nextHashCode 分配一个 hash 值给这个目标：

  private static AtomicInteger nextHashCode = new AtomicInteger()
  

• 斐波那契数也叫黄金分割数，hash 的增量便是这个数字，带来的优点是 hash 分布非常均匀：

  private static final int HASH_INCREMENT = 0x61c88647
  

成员办法

办法都是线程安全的，由于 ThreadLocal 归于一个线程的，ThreadLocal 中的办法，逻辑都是获取当时线程保护的 ThreadLocalMap 目标，然后进行数据的增删改查，没有指定初始值的 threadlcoal 目标默许赋值为 null

• initialValue()：回来该线程局部变量的初始值

  • 推迟调用的办法，在履行 get 办法时才履行
  • 该办法缺省（默许）完结直接回来一个 null
  • 假如想要一个初始值，能够重写此办法， 该办法是一个 protected 的办法，为了让子类掩盖而设计的

  protected T initialValue() {
      return null;
  }
  

• nextHashCode()：核算哈希值，ThreadLocal 的散列办法称之为斐波那契散列，每次获取哈希值都会加上 HASH_INCREMENT，这样做能够尽量避免 hash 抵触，让哈希值能均匀的分布在 2 的 n 次方的数组中

  private static int nextHashCode() {
      // 哈希值自增一个 HASH_INCREMENT 数值
      return nextHashCode.getAndAdd(HASH_INCREMENT);
  }
  

• set()：修正当时线程与当时 threadlocal 目标相相关的线程局部变量

  public void set(T value) {
      // 获取当时线程目标	
      Thread t = Thread.currentThread();
      // 获取此线程目标中保护的 ThreadLocalMap 目标
      ThreadLocalMap map = getMap(t);
      // 判别 map 是否存在
      if (map != null)
          // 调用 threadLocalMap.set 办法进行重写或许增加
          map.set(this, value);
      else
          // map 为空，调用 createMap 进行 ThreadLocalMap 目标的初始化。参数1是当时线程，参数2是局部变量
          createMap(t, value);
  }
  

  // 获取当时线程 Thread 对应保护的 ThreadLocalMap 
  ThreadLocalMap getMap(Thread t) {
      return t.threadLocals;
  }
  // 创立当时线程Thread对应保护的ThreadLocalMap 
  void createMap(Thread t, T firstValue) {
      // 【这儿的 this 是调用此办法的 threadLocal】，创立一个新的 Map 并设置第一个数据
      t.threadLocals = new ThreadLocalMap(this, firstValue);
  }
  

• get()：获取当时线程与当时 ThreadLocal 目标相相关的线程局部变量

  public T get() {
      Thread t = Thread.currentThread();
      ThreadLocalMap map = getMap(t);
      // 假如此map存在
      if (map != null) {
          // 以当时的 ThreadLocal 为 key，调用 getEntry 获取对应的存储实体 e
          ThreadLocalMap.Entry e = map.getEntry(this);
          // 对 e 进行判空 
          if (e != null) {
              // 获取存储实体 e 对应的 value值
              T result = (T)e.value;
              return result;
          }
      }
      /*有两种状况有履行当时代码
        第一种状况: map 不存在，表明此线程没有保护的 ThreadLocalMap 目标
        第二种状况: map 存在, 可是【没有与当时 ThreadLocal 相关的 entry】，就会设置为默许值 */
      // 初始化当时线程与当时 threadLocal 目标相相关的 value
      return setInitialValue();
  }
  

  private T setInitialValue() {
      // 调用initialValue获取初始化的值，此办法能够被子类重写, 假如不重写默许回来 null
      T value = initialValue();
      Thread t = Thread.currentThread();
      ThreadLocalMap map = getMap(t);
      // 判别 map 是否初始化过
      if (map != null)
          // 存在则调用 map.set 设置此实体 entry，value 是默许的值
          map.set(this, value);
      else
          // 调用 createMap 进行 ThreadLocalMap 目标的初始化中
          createMap(t, value);
      // 回来线程与当时 threadLocal 相关的局部变量
      return value;
  }
  

• remove()：移除当时线程与当时 threadLocal 目标相相关的线程局部变量

  public void remove() {
      // 获取当时线程目标中保护的 ThreadLocalMap 目标
      ThreadLocalMap m = getMap(Thread.currentThread());
      if (m != null)
          // map 存在则调用 map.remove，this时当时ThreadLocal，以this为key删去对应的实体
          m.remove(this);
  }
  

LocalMap

成员特点

ThreadLocalMap 是 ThreadLocal 的内部类，没有完结 Map 接口，用独立的办法完结了 Map 的功用，其内部 Entry 也是独立完结

// 初始化当时 map 内部散列表数组的初始长度 16
private static final int INITIAL_CAPACITY = 16;
// 寄存数据的table，数组长度有必要是2的整次幂。
private Entry[] table;
// 数组里边 entrys 的个数，能够用于判别 table 当时运用量是否超越阈值
private int size = 0;
// 进行扩容的阈值，表运用量大于它的时分进行扩容。
private int threshold;

存储结构 Entry：

• Entry 继承 WeakReference，key 是弱引证，意图是将 ThreadLocal 目标的生命周期和线程生命周期解绑
• Entry 约束只能用 ThreadLocal 作为 key，key 为 null (entry.get() == null) 意味着 key 不再被引证，entry 也能够从 table 中铲除

static class Entry extends WeakReference<ThreadLocal<?>> {
    Object value;
    Entry(ThreadLocal<?> k, Object v) {
        // this.referent = referent = key;
        super(k);
        value = v;
    }
}

结构办法：推迟初始化的，线程第一次存储 threadLocal – value 时才会创立 threadLocalMap 目标

ThreadLocalMap(ThreadLocal<?> firstKey, Object firstValue) {
    // 初始化table，创立一个长度为16的Entry数组
    table = new Entry[INITIAL_CAPACITY];
    // 【寻址算法】核算索引
    int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1);
    // 创立 entry 目标，寄存到指定方位的 slot 中
    table[i] = new Entry(firstKey, firstValue);
    // 数据总量是 1
    size = 1;
    // 将阈值设置为 （当时数组长度 * 2）/ 3。
    setThreshold(INITIAL_CAPACITY);
}

成员办法

• set()：增加数据，ThreadLocalMap 运用线性勘探法来解决哈希抵触

  • 该办法会一向勘探下一个地址，直到有空的地址后刺进，若刺进后 Map 数量超越阈值，数组会扩容为原本的 2 倍

    假定当时 table 长度为16，核算出来 key 的 hash 值为 14，假如 table[14] 上现已有值，而且其 key 与当时 key 不共同，那么就产生了 hash 抵触，这个时分将 14 加 1 得到 15，取 table[15] 进行判别，假如仍是抵触会回到 0，取 table[0]，以此类推，直到能够刺进，能够把 Entry[] table 当作一个环形数组

  • 线性勘探法会呈现堆积问题，能够采取平方勘探法解决

  • 在勘探进程中 ThreadLocal 会复用 key 为 null 的脏 Entry 目标，并进行废物整理，避免呈现内存走漏

  private void set(ThreadLocal<?> key, Object value) {
      // 获取散列表
      ThreadLocal.ThreadLocalMap.Entry[] tab = table;
      int len = tab.length;
      // 哈希寻址
      int i = key.threadLocalHashCode & (len-1);
      // 运用线性勘探法向后查找元素，碰到 entry 为空时中止勘探
      for (ThreadLocal.ThreadLocalMap.Entry e = tab[i]; e != null; e = tab[i = nextIndex(i, len)]) {
          // 获取当时元素 key
          ThreadLocal<?> k = e.get();
          // ThreadLocal 对应的 key 存在，【直接掩盖之前的值】
          if (k == key) {
              e.value = value;
              return;
          }
          // 【这两个条件谁先建立不一定，所以 replaceStaleEntry 中还需求判别 k == key 的状况】
          // key 为 null，可是值不为 null，阐明之前的 ThreadLocal 目标现已被收回了，当时是【过期数据】
          if (k == null) {
              // 【碰到一个过期的 slot，当时数据复用该槽位，替换过期数据】
              // 这个办法还进行了废物整理动作，避免内存走漏
              replaceStaleEntry(key, value, i);
              return;
          }
      }
  	// 逻辑到这阐明碰到 slot == null 的方位，则在空元素的方位创立一个新的 Entry
      tab[i] = new Entry(key, value);
      // 数量 + 1
      int sz = ++size;
      // 【做一次启发式整理】，假如没有铲除任何 entry 而且【当时运用量达到了负载因子所定义，那么进行 rehash
      if (!cleanSomeSlots(i, sz) && sz >= threshold)
          // 扩容
          rehash();
  }
  

  // 获取【环形数组】的下一个索引
  private static int nextIndex(int i, int len) {
      // 索引越界后从 0 开端持续获取
      return ((i + 1 < len) ? i + 1 : 0);
  }
  

  // 在指定方位刺进指定的数据
  private void replaceStaleEntry(ThreadLocal<?> key, Object value, int staleSlot) {
      // 获取散列表
      Entry[] tab = table;
      int len = tab.length;
      Entry e;
  	// 勘探式整理的开端下标，默许从当时 staleSlot 开端
      int slotToExpunge = staleSlot;
      // 以当时 staleSlot 开端【向前迭代查找】，找到索引靠前过期数据，找到以后替换 slotToExpunge 值
      // 【确保在一个区间段内，从最前面的过期数据开端整理】
      for (int i = prevIndex(staleSlot, len); (e = tab[i]) != null; i = prevIndex(i, len))
          if (e.get() == null)
              slotToExpunge = i;
  	// 以 staleSlot 【向后去查找】，直到碰到 null 中止，仍是线性勘探
      for (int i = nextIndex(staleSlot, len); (e = tab[i]) != null; i = nextIndex(i, len)) {
          // 获取当时节点的 key
          ThreadLocal<?> k = e.get();
  		// 条件建立阐明是【替换逻辑】
          if (k == key) {
              e.value = value;
              // 由于原本要在 staleSlot 索引处刺进该数据，现在找到了i索引处的key与数据共同
              // 可是 i 方位间隔正确的方位更远，由于是向后查找，所以仍是要在 staleSlot 方位刺进当时 entry
              // 然后将 table[staleSlot] 这个过期数据放到当时循环到的 table[i] 这个方位，
              tab[i] = tab[staleSlot];
              tab[staleSlot] = e;
              // 条件建立阐明向前查找过期数据并未找到过期的 entry，但 staleSlot 方位现已不是过期数据了，i 方位才是
              if (slotToExpunge == staleSlot)
                  slotToExpunge = i;
              // 【整理过期数据，expungeStaleEntry 勘探式整理，cleanSomeSlots 启发式整理】
              cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
              return;
          }
  		// 条件建立阐明当时遍历的 entry 是一个过期数据，而且该方位前面也没有过期数据
          if (k == null && slotToExpunge == staleSlot)
              // 勘探式整理过期数据的开端下标修正为当时循环的 index，由于 staleSlot 会放入要增加的数据
              slotToExpunge = i;
      }
  	// 向后查找进程中并未发现 k == key 的 entry，阐明当时是一个【取代过期数据逻辑】
      // 删去原有的数据引证，避免内存走漏
      tab[staleSlot].value = null;
      // staleSlot 方位增加数据，【上面的一切逻辑都不会更改 staleSlot 的值】
      tab[staleSlot] = new Entry(key, value);
      // 条件建立阐明除了 staleSlot 以外，还发现其它的过期 slot，所以要【敞开整理数据的逻辑】
      if (slotToExpunge != staleSlot)
          cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
  }
  

private static int prevIndex(int i, int len) {
    // 构成一个盘绕式的拜访，头索引越界后置为尾索引
    return ((i - 1 >= 0) ? i - 1 : len - 1);
}

• getEntry()：ThreadLocal 的 get 办法以当时的 ThreadLocal 为 key，调用 getEntry 获取对应的存储实体 e

  private Entry getEntry(ThreadLocal<?> key) {
      // 哈希寻址
      int i = key.threadLocalHashCode & (table.length - 1);
      // 拜访散列表中指定指定方位的 slot 
      Entry e = table[i];
      // 条件建立，阐明 slot 有值而且 key 便是要寻觅的 key，直接回来
      if (e != null && e.get() == key)
          return e;
      else
          // 进行线性勘探
          return getEntryAfterMiss(key, i, e);
  }
  // 线性勘探寻址
  private Entry getEntryAfterMiss(ThreadLocal<?> key, int i, Entry e) {
      // 获取散列表
      Entry[] tab = table;
      int len = tab.length;
      // 开端遍历，碰到 slot == null 的状况，查找完毕
      while (e != null) {
  		// 获取当时 slot 中 entry 目标的 key
          ThreadLocal<?> k = e.get();
          // 条件建立阐明找到了，直接回来
          if (k == key)
              return e;
          if (k == null)
               // 过期数据，【勘探式过期数据收回】
              expungeStaleEntry(i);
          else
              // 更新 index 持续向后走
              i = nextIndex(i, len);
          // 获取下一个槽位中的 entry
          e = tab[i];
      }
      // 阐明当时区段没有找到相应数据
      // 【由于寄存数据是线性的向后寻觅槽位，都是紧挨着的，不行能跳过一个 空槽位 在后面放】，能够削减遍历的次数
      return null;
  }
  

• rehash()：触发一次全量整理，假如数组长度大于等于长度的 2/3 * 3/4 = 1/2，则进行 resize

  private void rehash() {
      // 清楚当时散列表内的【一切】过期的数据
      expungeStaleEntries();
      // threshold = len * 2 / 3，便是 2/3 * (1 - 1/4)
      if (size >= threshold - threshold / 4)
          resize();
  }
  

  private void expungeStaleEntries() {
      Entry[] tab = table;
      int len = tab.length;
      // 【遍历一切的槽位，整理过期数据】
      for (int j = 0; j < len; j++) {
          Entry e = tab[j];
          if (e != null && e.get() == null)
              expungeStaleEntry(j);
      }
  }
  

  Entry 数组为扩容为原本的 2 倍 ，从头核算 key 的散列值，假如遇到 key 为 null 的状况，会将其 value 也置为 null，协助 GC

  private void resize() {
      Entry[] oldTab = table;
      int oldLen = oldTab.length;
      // 新数组的长度是老数组的二倍
      int newLen = oldLen * 2;
      Entry[] newTab = new Entry[newLen];
      // 计算新table中的entry数量
      int count = 0;
  	// 遍历老表，进行【数据搬迁】
      for (int j = 0; j < oldLen; ++j) {
          // 拜访老表的指定方位的 entry
          Entry e = oldTab[j];
          // 条件建立阐明老表中该方位有数据，或许是过期数据也或许不是
          if (e != null) {
              ThreadLocal<?> k = e.get();
              // 过期数据
              if (k == null) {
                  e.value = null; // Help the GC
              } else {
                  // 非过期数据，在新表中进行哈希寻址
                  int h = k.threadLocalHashCode & (newLen - 1);
                  // 【线程勘探】
                  while (newTab[h] != null)
                      h = nextIndex(h, newLen);
                  // 将数据寄存到新表合适的 slot 中
                  newTab[h] = e;
                  count++;
              }
          }
      }
  	// 设置下一次触发扩容的目标：threshold = len * 2 / 3;
      setThreshold(newLen);
      size = count;
      // 将扩容后的新表赋值给 threadLocalMap 内部散列表数组引证
      table = newTab;
  }
  

• remove()：删去 Entry

  private void remove(ThreadLocal<?> key) {
      Entry[] tab = table;
      int len = tab.length;
      // 哈希寻址
      int i = key.threadLocalHashCode & (len-1);
      for (Entry e = tab[i]; e != null; e = tab[i = nextIndex(i, len)]) {
          // 找到了对应的 key
          if (e.get() == key) {
              // 设置 key 为 null
              e.clear();
              // 勘探式整理
              expungeStaleEntry(i);
              return;
          }
      }
  }
  

整理办法

• 勘探式整理：沿着开端方位向后勘探整理过期数据，沿途中碰到未过期数据则将此数据 rehash 在 table 数组中的定位，重定位后的元素理论上更接近 i = entry.key & (table.length - 1)，让数据的排列更紧凑，会优化整个散列表查询功能

  // table[staleSlot] 是一个过期数据，以这个方位开端持续向后查找过期数据
  private int expungeStaleEntry(int staleSlot) {
      // 获取散列表和数组长度
      Entry[] tab = table;
      int len = tab.length;
      // help gc，先把当时过期的 entry 置空，在撤销对 entry 的引证
      tab[staleSlot].value = null;
      tab[staleSlot] = null;
      // 数量-1
      size--;
      Entry e;
      int i;
      // 从 staleSlot 开端向后遍历，直到碰到 slot == null 完毕，【区间内整理过期数据】
      for (i = nextIndex(staleSlot, len); (e = tab[i]) != null; i = nextIndex(i, len)) {
          ThreadLocal<?> k = e.get();
          // 当时 entry 是过期数据
          if (k == null) {
              // help gc
              e.value = null;
              tab[i] = null;
              size--;
          } else {
              // 当时 entry 不是过期数据的逻辑，【rehash】
              // 从头核算当时 entry 对应的 index
              int h = k.threadLocalHashCode & (len - 1);
              // 条件建立阐明当时 entry 存储时产生过 hash 抵触，向后偏移过了
              if (h != i) {
                  // 当时方方位空
                  tab[i] = null;
                  // 以正确方位 h 开端，向后查找第一个能够寄存 entry 的方位
                  while (tab[h] != null)
                      h = nextIndex(h, len);
                  // 将当时元素放入到【间隔正确方位更近的方位，有或许便是正确方位】
                  tab[h] = e;
              }
          }
      }
      // 回来 slot = null 的槽位索引，图例是 7，这个索引代表【索引前面的区间现已整理完结废物了】
      return i;
  }
  

• 启发式整理：向后循环扫描过期数据，发现过期数据调用勘探式整理办法，假如接连几回的循环都没有发现过期数据，就中止扫描

  //  i 表明启发式整理作业开端方位，一般是空 slot，n 一般传递的是 table.length 
  private boolean cleanSomeSlots(int i, int n) {
      // 表明启发式整理作业是否铲除了过期数据
      boolean removed = false;
      // 获取当时 map 的散列表引证
      Entry[] tab = table;
      int len = tab.length;
      do {
          // 获取下一个索引，由于勘探式回来的 slot 为 null
          i = nextIndex(i, len);
          Entry e = tab[i];
          // 条件建立阐明是过期的数据，key 被 gc 了
          if (e != null && e.get() == null) {
              // 【发现过期数据重置 n 为数组的长度】
              n = len;
              // 表明整理过过期数据
              removed = true;
              // 以当时过期的 slot 为开端节点 做一次勘探式整理作业
              i = expungeStaleEntry(i);
          }
          // 假定 table 长度为 16
          // 16 >>> 1 ==> 8，8 >>> 1 ==> 4，4 >>> 1 ==> 2，2 >>> 1 ==> 1，1 >>> 1 ==> 0
          // 接连经过这么多次循环【没有扫描到过期数据】，就中止循环，扫描到空 slot 不算，由于不是过期数据
      } while ((n >>>= 1) != 0);
      // 回来铲除符号
      return removed;
  }
  

参阅视频：space.bilibili.com/457326371/

内存走漏

Memory Leak：内存走漏是指程序中动态分配的堆内存由于某种原因未开释或无法开释，构成体系内存的糟蹋，导致程序运转速度减慢乃至体系崩溃等严重后果，内存走漏的堆积终将导致内存溢出。

弱引证消除了 ThreadLocal 引证内存走漏，但存在 key 为 null 的 Entry 内存走漏，需求手动 remove 依托 ThreadLocal 内部的 expungeStaleEntry() 消除。

强引证（Strong Reference）：通常咱们经过new来创立一个新目标时回来的引证便是一个强引证，若一个目标经过一系列强引证可抵达，它便是强可达的(strongly reachable)，那么它就不被收回

弱引证（Weak Reference）：弱引证的目标具有更时间短的生命周期。在废物收回器线程扫描它所管辖的内存区域的进程中，一旦发现了只具有弱引证的目标，不管当时内存空间足够与否，都会收回它的内存

软引证（Soft Reference）：软引证和弱引证的区别在于，若一个目标是弱引证可达，无论当时内存是否充足它都会被收回，而软引证可达的目标在内存不充足时才会被收回，因而软引证要比弱引证“强”一些

虚引证（Phantom Reference）：虚引证是Java中最弱的引证，那么它弱到什么程度呢？它是如此脆弱以至于咱们经过虚引证乃至无法获取到被引证的目标，虚引证存在的仅有效果便是当它指向的目标被收回后，虚引证自身会被加入到引证队列中，用作记载它指向的目标已被收回。

• 假如 key 运用强引证：运用完 ThreadLocal ，threadLocal Ref 被收回，可是 threadLocalMap 的 Entry 强引证了 threadLocal，构成 threadLocal 无法被收回，无法完全避免内存走漏

• 假如 key 运用弱引证：运用完 ThreadLocal ，threadLocal Ref 被收回，ThreadLocalMap 只持有 ThreadLocal 的弱引证，所以threadlocal 也能够被收回，此刻 Entry 中的 key = null。但没有手动删去这个 Entry 或许 CurrentThread 仍然运转，仍然存在强引证链，value 不会被收回，而这块 value 永久不会被拜访到，也会导致 value 内存走漏

• 两个主要原因：

  • 没有手动删去这个 Entry
  • CurrentThread 仍然运转

根本原因：ThreadLocalMap 是 Thread的一个特点，生命周期跟 Thread 相同长，假如没有手动删去对应 Entry 就会导致内存走漏

解决办法：运用完 ThreadLocal 中存储的内容后将它 remove 掉就能够

ThreadLocal 内部解决办法：在 ThreadLocalMap 中的 set/getEntry 办法中，经过线性勘探法对 key 进行判别，假如 key 为 null（ThreadLocal 为 null）会对 Entry 进行废物收回。所以运用弱引证比强引证多一层保证，就算不调用 remove，也有时机进行 GC。

变量传递

根本运用

子线程：创立子线程的线程是父线程，比方实例中的 main 线程便是父线程

ThreadLocal 中存储的是线程的局部变量，假如想完结线程间局部变量传递能够运用 InheritableThreadLocal 类

public static void main(String[] args) {
    ThreadLocal<String> threadLocal = new InheritableThreadLocal<>();
    threadLocal.set("父线程设置的值");
    new Thread(() -> System.out.println("子线程输出：" + threadLocal.get())).start();
}
// 子线程输出：父线程设置的值

完结原理

InheritableThreadLocal 源码：

public class InheritableThreadLocal<T> extends ThreadLocal<T> {
    protected T childValue(T parentValue) {
        return parentValue;
    }
    ThreadLocalMap getMap(Thread t) {
       return t.inheritableThreadLocals;
    }
    void createMap(Thread t, T firstValue) {
        t.inheritableThreadLocals = new ThreadLocalMap(this, firstValue);
    }
}

完结父子线程间的局部变量同享需求追溯到 Thread 目标的结构办法：

private void init(ThreadGroup g, Runnable target, String name, long stackSize, AccessControlContext acc,
                  // 该参数默许是 true
                  boolean inheritThreadLocals) {
  	// ...
    Thread parent = currentThread();
    // 判别父线程（创立子线程的线程）的 inheritableThreadLocals 特点不为 null
    if (inheritThreadLocals && parent.inheritableThreadLocals != null) {
        // 仿制父线程的 inheritableThreadLocals 特点，完结父子线程局部变量同享
        this.inheritableThreadLocals = ThreadLocal.createInheritedMap(parent.inheritableThreadLocals); 
    }
    // ..
}
// 【本质上仍是创立 ThreadLocalMap，仅仅把父类中的可继承数据设置进去了】
static ThreadLocalMap createInheritedMap(ThreadLocalMap parentMap) {
    return new ThreadLocalMap(parentMap);
}

private ThreadLocalMap(ThreadLocalMap parentMap) {
    // 获取父线程的哈希表
    Entry[] parentTable = parentMap.table;
    int len = parentTable.length;
    setThreshold(len);
    table = new Entry[len];
	// 【逐个仿制父线程 ThreadLocalMap 中的数据】
    for (int j = 0; j < len; j++) {
        Entry e = parentTable[j];
        if (e != null) {
            ThreadLocal<Object> key = (ThreadLocal<Object>) e.get();
            if (key != null) {
                // 调用的是 InheritableThreadLocal#childValue(T parentValue)
                Object value = key.childValue(e.value);
                Entry c = new Entry(key, value);
                int h = key.threadLocalHashCode & (len - 1);
                // 线性勘探
                while (table[h] != null)
                    h = nextIndex(h, len);
                table[h] = c;
                size++;
            }
        }
    }
}

参阅

• 参阅文章：blog.csdn.net/feichitianx…
• JavaYouth