Zhu.Yang

写在前面

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

对象在内存中的布局

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

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

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

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

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

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

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

我们知道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);
  }

}

编写正确的程序难,编写正确的并发程序则是难上加难。既然这么难为什么还要并发,单线程执行不好吗？为了快呀,点个链接你愿意等1分钟吗?,别说等一分钟了,要是有个网页让我等超过10秒钟,我就马上要关掉了。

我们编写的代码在计算机中运行,那么它肯定会用到计算机中的资源,一般都逃不过cpu、内存以及I/O(文件I/O或者网络I/O等)。但是这三者速度上有极大的差异。

CPU的速度远远快于内存,而内存的速度又远远远快于I/O。

比喻: CPU速度相当于 火箭,内存速度相当于 高铁,I/O速度相当于 步行。

而我们的程序运行的快慢实际上是取决于最慢的那个操作–I/O操作,仿佛在这个时候CPU再快都没啥作用。

我们一般都说尽可能少的查询数据库(batch的方式更好),就是为了较少I/O操作