帝国危机，线程要罢工了!

Java 帝国发生了一场危机，各个线程正在闹罢工。。。

「发生了什么事，听说各个线程最近正在闹罢工」国王老虚说道

「报告国王，最近各个线程反应创建对象太难了，要求王国进行变革」线程大臣启奏道

「创建对象有什么难的，我们不是用了 bump the pointer 机制吗，new 一下对象不就创建了吗」老虚大惑不解，「我们知道对象一般来说都是先分配在堆上的 Eden 区的，那么在堆上怎样才能快速地给对象分配空间呢?假设堆是内存是绝对规整的，用过的放一边，空闲的放另一边，中间放一个指针作为分界点，那么在分配对象时只需要将指针移动到与对象大小相等的距离即可，这样创建对象只要不断地移动指针就行啦。这就是我们所说说的 bump the pointer（指针碰撞）」老虚边说边画出了以下图示

 
「指针碰撞我们当然知道，如果是单线程这样轻轻移动指针分配对象的方式当然很快，但如果是多线程呢，会产生严重的锁竞争呀」

 多线程分配对象下的锁竞争

「这确实是个问题，锁在多线程下确实会产生比较严重的问题，虽然这里用的是 CAS 乐观锁，但在多线程对象分配上由于锁竞争关系也会有较严重的性能问题」老虚沉思道

TLAB
「能否这样，我们知道对象一般是在 Eden 区分配的，为每个线程创建一块单独的区域，每个线程分配对象时只在自己的区域里分配，在自己的区域分配时也采用 bump the pointer 的方式来分配，这样既可以用 bump the pointer 的方式来加速了对象的创建，又避免了创建对象时的锁竞争，可谓一举双得!」线程大臣说道

「妙啊，我们给这块区域取个名字吧，就叫它 Thread Local Allocation Buffer（即线程本地分配缓存区），这块是线程专用的内存分配区域」老虚道

 
「还有一个问题，这块区域该分配多大呢，如果分配太大，可能一个线程根本就没有分配对象的需求或者分配对象很少，造成了空间的浪费，如果分配太小，则可能某些线程比较活跃，分配的对象比较多，那么就要重新分配一个 TLAB，或者直接在 Eden 上分配，这样频繁分配 TLAB 或者在 Eden 分配会造成资源与性能的浪费」不愧是国王，一眼看出问题的本质

「是的，TLAB 大小主要和两个因素有关：每个 gc 内需要对象分配的线程个数以及线程每次 gc 分配的内存，这两项指标显然也与历史值有关，所以我们需要根据历史值来算出当前应该分配的 TLAB 大小，有一种算法指数平均数算法（EMA）可以干这事」线程大臣也不赖，一眼就抓住了问题的关键

「如果 TLAB 满了咋办」老虚困惑道

「满了就针对此线程创建一个 TLAB，或者直接丢到 Eden 区呗，另外需要说明的是 TLAB 比较适用于小对象的分配，大对象一般直接分配到 Eden 区哦」线程大臣解释道

逃逸分析与标量替换
老虚采纳了线程大臣的建议实现了 TLAB，由于采用了 TLAB 机制，各个线程的工作效率瞬间提升，老虚笑开了花，可是好景不长，新的问题又出现了。。。

「老虚啊，我发现采用 TLAB 之后线程的工作效率确实提升了很多，但一些线程反映由于 GC 时的 STW（stop the word），导致他们啥也干不了，这个问题自 Java 帝国诞生起就出现了，能否解决一下」

「这没办法，STW 是必须的，总不能一边清理垃圾一边扔垃圾吧，那垃圾还怎么收拾地干净」

「STW 确实不能避免，但能否减少 GC 次数呢，GC 次数少了，STW 自然也少了，GC 发生在堆中，那只要对象不分配在堆中，GC 次数不就自然而然少了吗」线臣大臣说到

「难不成要把它分配在栈上？」老虚一听能减少 GC 次数，顿时来了精神

「没错，就是要把它分配在栈上！这样线程在调用栈销毁后对象也就销毁了」线程大臣看起来胸有成竹「但它首先必须满足一个条件：逃逸分析」

「什么是逃逸分析」老虚x疑惑道

逃逸分析是指分析指针动态范围的方法，分析在程序的哪些地方可以访问到指针。当一个变量(或对象)在子程序中被分配时，一个指向变量的指针可能逃逸到其它执行线程中，或是返回到调用者子程序。我们就说这个对象「逃逸」了，否则就说对象未逃逸，未逃逸的对象是可以分配在堆栈上的（采用标量替换的形式）的。
「Talk is cheap, show me your code，举几个例子来吧」老虚道

public class EscapeTest {

    public static Object globalVariableObject;

    public Object instanceObject;

    public void globalVariableEscape(){
        globalVariableObject = new Object(); // 1.静态变量,外部线程可见,发生逃逸
    }

    public void instanceObjectEscape(){
        instanceObject = new Object(); // 2.赋值给堆中实例字段,外部线程可见,发生逃逸
    }

    public Object returnObjectEscape(){
        return new Object();  // 3.返回实例,外部线程可见，发生逃逸
    }

    public void noEscape(){
        //仅创建线程可见,对象无逃逸
        Object noEscape = new Object();  //4. 仅创建线程可见,对象无逃逸
    }

}

我们可以看到，当对象符合以下两种条件时我们就说它逃逸了

1. 被赋值给了对象的字段或类的变量，因为很显然对象分配在堆中，是线程共享的，其他线程可能对其进行修改
2. 对象被传进了不确定的代码中去运行，比如返回给上一个调用栈赋值给其他对象的属性等
   只有那种满足条件 4 的仅创建线程可见的对象，才能被判断为无逃逸，才能将对象分配到堆上

「未逃逸的对象怎样才能被分配在栈上呢？」老虚还是有点困惑

「我们先了解两个名词：标量和聚合量，标量就是不可进一步分解的量，像 Java 的基本类型如 int 等基本类型或者 reference 类型就是标量，聚合量就简单了，就是各个标量的组合，对象其实就是聚合量，所以让对象分配在栈上其实很简单，将其替换为各个标量即可」线程大臣顿了顿，给出了标量替换的 demo

 
「妙啊，通过将对象打散为多个标量，由于标量是直接在栈上分配的，就避免了对象在堆中的分配」这个思路确实给力！老虚立即下令实行

锁消除
「老虚啊，我无意中发现未逃逸的对象还有锁消除功能」线程大臣兴奋地说

「啥是锁消除」老虚挺兴奋的

我们先来看看 StringBuffer 的 append 方法：

@Override
public synchronized StringBuffer append(Object obj) {
  toStringCache = null;
  super.append(String.valueOf(obj));
  return this;
}

你看看是不是有个 synchronized 锁，那如果 StringBuffer 不是逃逸对象，比如下面这样

public void test() {
  StringBuffer sb = new StringBuffer()
  sb.append(s1).append(s2)
  return sb.toString();
}

那 append 方法的 Synchronized 锁就可以消除了对不对

「可以可以」老虚兴奋极了，完成之后 JVM 帝国的生产力又提升了一个新台阶。。。
··············  END  ··············

文章转自公众号：码海