Zhu.Yang

模板解释器

我们都知道 Java 之所以可以一次编译到处运行，完全是因为字节码的原因，字节码就相当于中间层屏蔽了底层细节。但是想要在机器执行，最终还是要翻译成机器指令。

而 JVM 是通过 C/C++ 来编写的，Java 程序编译后，会产生很多字节码指令，每一个字节码指令在 JVM 底层执行的时候又会编程一堆 C 代码，这一堆 C 代码在编译之后又会编程很多的机器指令，这样我们的 java 代码到最终执行的机器指令那一层，所产生的机器指令时指数级的，这也就导致了 Java 执行效率低下。

早期的 JVM 是因为解释执行慢而被人诟病，那么有没有办法优化这个问题呢？我们发现之所以慢是因为 java 和机器指令之间隔了一层 C/C++, 而 GCC 之类的编译器又不能做到绝对的智能编译，所产生的机器码效率就不是很高。因此我们只要跳过 C/C++ 这个层次，直接将 Java 字节码和本地机器码进行一个对应就可以了。

因此 HotSpot 的工程师们废弃了早期的解释执行器，而采用了模板执行器。所谓的模板就是将一个 java 字节码通过人工手动的方式编写为固定模式的机器指令，这部分不在需要 GCC 的帮助，这样就可以大大减少最终需要执行的机器指令，所以才能提高效率。

写在前面

Java 是用 C++ 写的，所以 java 对象最终会映射到 c++ 中的某个对象，用这个对象可以描述所有 Java 对象。而我们所熟知的 synchronized 锁的优化就是基于这个对象来实现的。

对象在内存中的布局

Java 对象在被创建的时候，在内存分配完成后，虚拟机需要对对象进行必要设置， 例如这个对象是哪个类的实例、如何才能找到类的元数据信息、对象的哈希码、对象的 GC 分代年龄等信息。

这些信息存放在对象的对象头 (Object Header) 中。根据虚拟机当前运行状态的不同，如是否启用偏向锁等对象头会有不同的设置方式。

在虚拟机中，对象在内存中存储的布局可以分为 3 块区域：对象头 (Header)、实例数据 (Instance Data) 和对齐填充 (Padding)

观察者模式又叫发布 - 订阅模式，它定义了一种一对多的依赖关系，多个观察者对象可同时监听某一主题对象，当该主题对象状态发生变化时，相应的所有观察者对象都可收到通知。
比如求职者，他们订阅了一些工作发布网站，当有合适的工作机会时，他们会收到提醒。

又或者是当用户注册网站成功的时候，发送一封邮件或者发送一条短信。我们都可以使用观察者模式来解决类似的问题

三年前，我做了一道关于 try-catch-finnaly 的面试题，但我做错了，当时面试官问我为啥错了，我告诉它，我平常不会写这么傻逼的代码，然后面试官就没有问我了。。。。

最近看到其他面试的童鞋，又让我想起了这道题，刚好也试着分析下。

我们知道 Java 虚拟机栈是线程私有的，它的生命周期与线程相同。虚拟机栈是 Java 虚拟机运行时数据区一部分，它描述的是 Java 方法执行的内存模型：每个方法在执行的同时都会创建一个栈帧用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从调用直至执行完成的过程就对应着一个帧栈在虚拟机中入栈到出栈的过程。

常量池

Java 虚拟机管理的内存包含以下几个运行时数据区域

Java 虚拟机运行时数据区

方法区与 java 堆一样，是各个线程共享的内存区域，用于存储已经被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等数据。

JDK8 之前很多人叫它永久代 (这里可以联想下年前代，老年代)，是因为当时 HotSpot 虚拟机的设计团队选择将收集器的分代设计扩展至方法区，或者说使用永久代来实现方法区而已。
这样使得 HotSpot 的垃圾收集器能像管理 Java 堆一样管理这部分内存。但是对于其他虚拟机实现是不存在这个概念的。

运行时常量池 (Runtime ConstantPool) 是方法区的一部分。Class 文件中除了有类的版本、字、方法、接口等描述信息外，还有一项信息是常量池表 (ConstantPoolTable), 用于存放编译期生
成的各种字面量与符号引用，这部分内容将在类加载后存放到方法区的运行时常量池中。

String str = “think123” 其中的 think123 就直接保存在常量池中

在之前的《为什么阿里建议你不要使用 Executors 来创建线程池？》文章中深入分析了一下线程池，这里重温下它的主要流程:

1. 提交一个任务，如果线程池中的工作线程数小于 corePoolSize, 则新建一个工作线程执行任务
2. 如果线程池当前的工作线程已经等于了 corePoolSize, 则将新的任务放入到工作队列中正在执行
3. 如果工作队列已经满了，并且工作线程数小于 maximumPoolSize, 则新建一个工作线程来执行任务
4. 如果当前线程池中工作线程数已经达到了 maximumPoolSize, 而新的任务无法放入到任务队列中，则采用对应的策略进行相应的处理 (默认是拒绝策略)
5. 当线程数大于核心线程数时，线程等待 keepAliveTime 后还是没有任务需要处理的话，收缩线程到核心线程数。(传入 true 给 allowCoreThreadTimeOut 方法，来让线程池在空闲的时候同样回收核心线程。)

在 JDK 自带的策略中有一个 CallerRunsPolicy 策略，很容易被忽视，当任务队列已经满了的时候这个任务会被调用线程池的线程执行。
比如我们在 tomcat 线程中调用了线程池，当线程池的队列满了之后，会将这个任务交给 tomcat 线程执行。这个时候就会影响其他同步执行的线程，甚至可能把线程池搞崩溃。

我们还可以通过一些手段来修改线程池的默认行为，比如回收核心线程。或者声明线程池后立即调用 prestartAllCoreThreads 方法，来启动所有核心线程。

我们发现核心线程数只有在工作队列满了之后才会扩容，那么能不能先扩容核心线程，等到达到最大线程数之后再加入工作队列呢？让线程池更弹性，优先开启更多线程呢？

当然可以，tomcat 中的 ThreadPoolExecutor 就是就做了这样的优化。

tomcat 的线程池在创建的时候会先启动所有的核心线程 (prestartAllCoreThreads), 并且会优先扩容线程数。

tomcat 中的 ThreadPoolExecutor 继承自 java.util.concurrent.ThreadPoolExecutor, 并且任务队列使用的是 TaskQueue(继承自 LinkedBlockingQueue<Runnable>)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66

public class ThreadPoolExecutor extends java.util.concurrent.ThreadPoolExecutor {

public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, 
  TimeUnit unit, BlockingQueue<Runnable> workQueue, RejectedExecutionHandler handler) {
      super(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue, handler);
      // 调用父类的方法,先启动所有的核心线程
      prestartAllCoreThreads();
    }
  public void execute(Runnable command) {
    if (command == null)
      throw new NullPointerException();

    int c = ctl.get();
    // 1. 如果工作线程数小于核心线程数(corePoolSize),则创建一个工作线程执行任务
    if (workerCountOf(c) < corePoolSize) {
      if (addWorker(command, true))
          return;
      c = ctl.get();
    }

    // 2. 如果当前是running状态，并且任务队列能够添加任务
    if (isRunning(c) && workQueue.offer(command)) {
      int recheck = ctl.get();

      // 2.1 如果不处于running状态了(使用者可能调用了shutdown方法),
      // 则将刚才添加到任务队列的任务移除
      if (! isRunning(recheck) && remove(command))
          reject(command);
       // 2.2 如果当前没有工作线程,
       // 则新建一个工作线程来执行任务(任务已经被添加到了任务队列)
      else if (workerCountOf(recheck) == 0)
          addWorker(null, false);
    }

    // 3. 队列已经满了的情况下，则新启动一个工作线程来执行任务
    else if (!addWorker(command, false))
      reject(command);
  }

}


public class TaskQueue extends LinkedBlockingQueue<Runnable> {

  // 通过setParent方法设置线程池
  private volatile ThreadPoolExecutor parent = null;

  @Override
  public boolean offer(Runnable o) {
    
    if (parent==null) return super.offer(o);

    // 1. 线程数已经扩容到了最大线程数,此时正常加入队列
    if (parent.getPoolSize() == parent.getMaximumPoolSize()) return super.offer(o);

    // 2. 存在空闲线程将其加入到队列中
    if (parent.getSubmittedCount()<=(parent.getPoolSize())) return super.offer(o);

    // 3. 核心线程数少于最大线程数,不加入队列,而是会创建一个新的工作线程
    if (parent.getPoolSize()<parent.getMaximumPoolSize()) return false;
    
    // 加入队列
    return super.offer(o);
  }
}

比如核心线程数设置为 1, 最大线程数设置为 2, 每个任务执行时间是 5s, 当第一个任务提交之后，submittedCount=1, 会创建一个工作线程执行任务，poolSize 变成 1 (查看 execute 方法的第一步)。

此时第二个任务提交了，submittedCount 的值为 2。不符合 offer 方法中第一和第二个判断，但是符合第三个判断，返回 false, 表示加入队列失败 (表示队列已满)

此时在回到 execute 的第三个条件判断，直接启动一个新的工作线程来执行任务。

这样就做到了优先扩容到最大线程数。来不及处理的多余任务才会放入到队列中。

我们都知道，一个线程直接对应了一个 Thread 对象，在刚开始学习线程的时候我们也知道启动线程是通过 start () 方法，而并非 run () 方法。

那这是为什么呢？

如果你熟悉 Thread 的代码的话，你应该知道在这个类加载的时候会注册一些 native 方法

1
2
3
4
5
6
7
8
9

public
class Thread implements Runnable {
  /* Make sure registerNatives is the first thing <clinit> does. */
  private static native void registerNatives();
  static {
      registerNatives();
  }
}

当我们运行 Java 程序 main 方法的时候，我们都知道当前线程是 main 线程

1

Thread.currentThread().getName()

那么这个 main 线程是被谁启动，又是在什么时候被启动的呢？我们通过源码一探究竟。

最近在看 synchronized 锁优化方面的内容，有些地方看起来不是很方便，干脆就编译个源码来看看。

在 windows 上编译

由于自己常用的电脑操作系统是 win10, 所以最开始是想要在 win10 上编译的，但是一来网上文章太少，二来在 windows 上编译确实麻烦太多了 (windows 可以参考深入理解 JVM 虚拟机这本书), 故放弃了。

在之前的文章中我们讲到过引起多线程 bug 的三大源头问题 (可见性，原子性，有序性问题),java 的内存模型 (Java Memory Model) 可以解决可见性和有序性问题，但是原子性问题如何解决呢？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

public class Counter {

  volatile int count;

  public void add10K() {
    for(int i = 0; i < 10000; i++) {
        count++;
    }
  }

  public int get() {
      return count;
  }

  public static void main(String[] args) throws InterruptedException {

    Counter counter = new Counter();

    Thread t1 = new Thread(() -> counter.add10K());

    Thread t2 = new Thread(() -> counter.add10K());

    t1.start();
    t2.start();

    t1.join();
    t2.join();

    System.out.println(counter.count);
  }

}