JVM相关知识总结整理

JVM启动流程

JVM基本结构

PC寄存器

每个线程拥有一个PC寄存器

在线程创建时创建

指向下一条指令的地址

执行本地方法时，PC的值为undefined

方法区

保存装载的类信息

类型的常量池（JDK6时，String等常量池置于方法，JDK7时，已经移动到了堆）

字段、方法信息

方法字节码

通常和永久区（Perm）关联在一起

Java堆

和程序开发密切相关

应用系统对象都保存在Java堆中

所有线程共享Java堆

对分代GC来说，堆也是分代的

GC的主要工作区间

Java栈

线程私有

栈由一系列帧组成（因此Java栈也叫做帧栈）

帧保存一个方法的局部变量、操作数栈、常量池指针

每一次方法调用创建一个帧，并压栈

Java栈——局部变量表 包含参数和局部变量

public static int runStatic(int i, long l, float f, Object o, byte b) {
return 0;
}

静态方法的局部变量表如下图所示

public int runInstance(char c, short s, boolean b) {
return 0;
}

实例方法的局部变量表如下图所示



Java栈——函数调用组成帧栈

public static int runStatic(int i, long l, float f, Object o, byte b) {
return runStatic(i, l, f, o, b);
}

Java栈——操作数栈

java没有寄存器，所有参数传递使用操作数栈

public static int add(int a, int b) {
int c = 0;
c = a + b;
return c;
}

对应的操作为：

0: iconst_0 // 0 压栈
1: istore_2 // 弹出int，存放于局部变量2
2: iload_0  // 把局部变量0压栈
3: iload_1  // 局部变量1压栈
4: iadd     // 弹出2个变量，求和，结果压栈
5: istore_2 // 弹出结果，放于局部变量2
6: iload_2  // 局部变量2压栈
7: ireturn  // 返回

Java栈——栈上分配

小对象（一般几十个bytes），在没有逃逸的情况下，可以直接分配在栈上

直接分配在栈上，函数调用完成自动清理空间，减轻GC压力

大对象或者逃逸对象无法栈上分配

栈、堆、方法区交互

// 运行时，JVM把AppMain的信息都放入方法区
public class AppMain {
// main方法本身放入方法区
public static void main(String[] args){
// test1 是引用，所以放到栈区里，Sample是自定义对象应该放到堆里面
Sample test1 = new Sample("测试1");
Sample test2 = new Sample("测试2");

test1.printName();
test2.printName();
}
}

// 运行时，JVM把Sample的信息都放入方法区
public class Sample {
private String name;

// new Sample实例后，name引用放入栈区里，name对象放入堆里
public Sample(String name){
this.name = name;
}

// print方法本身放入方法区里
public void printName(){
System.out.println(name);
}
}

内存模型

每一个线程有一个工作内存和主内存

工作内存存放主内存中变量的值的拷贝

当数据从主内存复制到工作存储时，必须出现两个动作：第一，由主内存执行的读（read）操作；第二，由工作内存执行的相应的load操作；当数据从工作内存拷贝到主内存时，也出现两个操作：第一个，由工作内存执行的存储（store）操作；第二，由主内存执行的相应的写（write）操作



每一个操作都是原子的，即执行期间不会被中断

对于普通变量，一个线程中更新的值，不能马上反应在其他线程中



如果需要在其他线程中立即可见，需要使用volatile关键字

volatile

public class VolatileStopThread extends Thread {
private volatile boolean stop = false;
public void stopMe(){
stop = true;
}

@Override
public void run(){
int i = 0;
while(!stop){
i++;
}
System.out.println("Stop thread");
}

public static void main(String args[]) throws InterruptedException {
VolatileStopThread t = new VolatileStopThread();
t.start();
Thread.sleep(1000);
t.stopMe();
Thread.sleep(1000);
}
}

如果没有volatile关键字，server运行就无法停止

volatile不能代替锁，一般认为volatile比锁性能好（不绝对）

选择使用volatile的条件是：语义是否满足应用

可见性

一个线程修改了变量，其他线程可以立即知道的方法：

volatile

synchronized（unlock之前，写变量值回主内存）

final（一旦初始化完成，其他线程就可见）

有序性

在本线程内，操作都是有序的

在线程外观察，操作都是无序的（指令重排或主内存同步延时）

指令重排

线程内串行语义

写后读 a = 1; b = a; 写一个变量之后，再读这个位置

写后写 a = 1; a = 2; 写一个变量之后，再写这个变量

读后写 a = b; b = 1; 读一个变量之后，再写这个变量

以上语句不可重排

编译器不考虑多线程间的语义

可重排： a = 1; b = 2;

指令重排——破坏线程间的有序性

class OrderExample {
int a = 0;
boolean flag = false;

public void writer(){
a = 1;
flag = true;
}

public void reader(){
if(flag){
int i = a + 1;
...
}
}
}

线程A首先执行writer()方法

线程B接着执行reader()方法

线程B在int i = a + 1是不一定能看到a已经被赋值为1，因为在writer中，两句话顺序可能打乱



指令重排——保证有序性的方法

class OrderExample {
int a = 0;
boolean flag = false;

public synchronized void writer(){
a = 1;
flag = true;
}

public synchronized void reader(){
if(flag){
int i = a + 1;
...
}
}
}

同步后，即使做了writer重排，因为互斥的缘故，reader线程看writer线程也是顺序执行的



指令重排的基本原则

程序顺序原则：一个线程内保证语义的串行性

volatile规则：volatile变量的写，先发生于读

锁规则：解锁（unlock）必然发生在随后的加锁（lock）前

传递性：A先于B，B先于C，那么A必然先于C

线程的start方法先于它的每一个动作

线程的所有操作先于线程的终结（Thread.join()）

线程的中断（interrupt()）先于被中断线程的代码

对象的构造函数执行结束先于finalize()方法

解释运行

解释执行以解释方式运行字节码

解释执行的意思是：读一句执行一句

编译运行（JIT）

将字节码编译成机器码

直接执行机器码

运行时编译

编译后性能有数量级的提升

常用JVM配置参数

Trace跟踪参数

-verbose:gc

输出虚拟机中GC的详细情况

使用后输出如下：

[Full GC 168K->97K(1984K)， 0.0253873 secs]

168K和97K分别表示垃圾收集GC前后所有存活对象使用的内存容量，数据1984K为堆内存的总容量，收集所需要的时间是0.0253873秒

-XX:+PrintGC

同-verbose:gc

-XX:+PrintGCDetails

打印GC详细信息



-XX:+PrintGCTimeStamps

[GC[DefNew: 4416K->0K(4928K), 0.0001897 secs] 4790K->374K(15872K), 0.0002232 secs]
[Times: user=0.00 sys=0.00, real=0.00 secs]

-Xloggc:log/gc.log

指定GC log的位置，以文件输出

帮助开发人员分析问题

-XX:+PrintHeapAtGC

每次一次GC后，都打印堆信息



-XX:+TraceClassLoading

监控类的加载



-XX:+PrintClassHistogram

按下Ctrl+Break后，打印类的信息



分别显示：序号、实例数量、总大小、类型

堆分配参数

-Xmx -Xms

指定最大堆和最小堆

-Xmx20m -Xms5m

System.out.print("Xmx = ");
System.out.println(Runtime.getRuntime().maxMemory() / 1024.0 / 1024 + "M");

System.out.print("free mem = ");
System.out.println(Runtime.getRuntime().freeMemory() / 1024.0 / 1024 + "M");

System.out.print("total mem = ");
System.out.println(Runtime.getRuntime().totalMemory() / 1024.0 / 1024 + "M");

// 结果为
Xmx = 19.375M
free mem = 4.342750549316406M
total mem = 4.875M

Java会尽可能维持在最小堆

-Xmn

设置新生代大小（官方推荐新生代占堆的3/8）

-XX:NewRatio

新生代（eden + 2 * s）和老年代（不包含永久区）的比值

4表示新生代:老年代=1:4，即新生代占堆的1/5

-XX:SurvivorRatio

设置两个Survivor区和eden的比

8表示两个Survivor:eden=2:8，即一个Survivor占新生代的1/10（官方推荐）

如下例

public static void main(String[] args){
byte[] b = null;
for(int i = 0; i < 10; i++){
b = new byte[1 * 1024 * 1024];
}
}

如果设置

-Xmx20m -Xms20m -Xmn1m -XX:+PrintGCDetails

则没有触发GC，数据全部分配在老年代

如果设置

-Xmx20m -Xms20m -Xmn15m -XX:+PrintGCDetails

则没有触发GC，数据全部分配在eden，老年代没有使用

如果设置

-Xmx20m -Xms20m -Xmn7m -XX:+PrintGCDetails

则进行了2次新生代GC，s0 s1太小需要老年代担保

如果设置

-Xmx20m -Xms20m -Xmn7m -XX:SurvivorRatio=2 -XX:+PrintGCDetails

则进行了3次新生代GC，s0 s1增大

如果设置

-Xmx20m -Xms20m -XX:NewRatio=1 -XX:SurvivorRatio=2 -XX:+PrintGCDetails

则进行了2次新生代GC，新生代空间增大

如果设置

-Xmx20m -Xms20m -XX:NewRatio=1 -XX:SurvivorRatio=3 -XX:+PrintGCDetails

则进行了1次新生代GC，新生代空间增大，s0 s1增大

-XX:+HeapDumpOnOutOfMemoryError

OOM时导出堆到文件

-XX:+HeapDumpPath

导出OOM的路径

示例：

-Xmx20m -Xms5m -XX:+HeapDumpOnOutOfMemoryError -XX:+HeapDumpPath

Vector v = new Vector();
for(int i = 0; i < 25; i++){
v.add(new byte[1 * 1024 * 1024]);
}

-XX:OnOutOfMemoryError

在OOM时，执行一个脚本

“-XX:OnOutOfMemoryError=D:/tools/printstack.bat %p”，printstack.bat的内容为

D:/tools/jdk1.7_40/bin/jstack -F %1 > D:/a.txt

当程序OOM时，在D:/a.txt中会生成线程的dump

可以在OOM时，发送邮件，甚至是重启程序

永久区分配参数

-XX:PermSize -XX:MaxPermSize

设置永久区的初始空间和最大空间

他们表示，一个系统可以容纳多少个类型

使用CGLIB等库的时候，可能会产生大量的类，这些类，有可能撑爆永久区导致OOM

for(int i = 0; i < 100000; i++){
CglibBean bean = new CglibBean("geym.jvm.ch3.perm.bean" + i, new HashMap()); // 不断地产生新的类
}

栈大小分配

-Xss

通常只有几百K

决定了函数调用的深度

每个线程都有独立的栈空间

局部变量、参数分配在栈上

如下例

public class TestStackDeep {
private static int count = 0;

public static void recursion(long a, long b, long c) {
long e = 1, f = 2, g = 3, h = 4, i = 5, k = 6, q = 7, x = 8, y = 9, z = 10;
count++;
recursion(a, b, c);
}

public static void main(String args[]) {
try {
recursion(0L, 0L, 0L);
} catch (Throwable e) {
System.out.println("deep of calling = " + count);
e.printStackTrace();
}
}
}

设置-Xss128K，抛出java.lang.StackOverflowError时，deep of calling = 292

设置-Xss256K，抛出java.lang.StackOverflowError时，deep of calling = 1080

JIT及其相关参数

字节码执行性能较差，所以可以对于热点代码编译成机器码再执行，在运行时的编译，叫做JIT Just-In-Time

JIT的基本思路是，将热点代码，就是执行比较频繁的代码，编译成机器码



相关参数

Xint

解释执行

Xcomp

全部编译执行

Xmixed

默认，混合

GC算法与种类

引用计数法

老牌垃圾回收算法

通过引用计算来回收垃圾

使用者

COM

ActionScript

Python

引用计数器的实现很简单，对于一个对象A，只要有任何一个对象引用了A，则A的引用计数器就加1，当引用失效时，引用计数器就减1。只要对象A的引用计数器的值为0，则对象A就不可能被再被使用



引用计数法的问题

引用和去引用伴随着加法和减法，影响性能

很难处理循环引用

标记-清除

标记-清除算法是现代垃圾回收算法的思想基础。标记-清除算法是将垃圾回收分为两个阶段：标记阶段和清除阶段。一种可行的实现是，在标记阶段，首先通过根结点，标记所有从根节点开始的可达对象。因此，未被标记的对象就是未被引用的垃圾对象，然后，在清除阶段，清除所有未被标记的对象

标记-压缩

标记-压缩算法适合用于存活对象较多的场合，如老年代，它在标记-清除算法的基础上做了一些优化。和标记-清除算法一样，标记-压缩算法也首先需要从根节点开始，对所有可达对象做一次标记。但之后，它并不简单的清理未标记的对象，而是将所有的存活对象压缩到内存的一端，之后，清理边界外所有的空间

复制算法

与标记-清除算法相比，复制算法是一种相对高效的回收方法

不适用于存活对象较多的场合，如老年代

将原有的内存空间分为两块，每次只使用其中一块，在垃圾回收时，将正在使用的内存中的存活对象复制到未使用的内存块中，之后，清除正在使用的内存块中的所有对象，交换两个内存的角色，完成垃圾回收

分代思想

依据对象的存活周期进行分类，短命对象归为新生代，长命对象归为老年代

根据不同代的特点，选取合适的收集算法

少量对象存活，适合复制算法

大量对象存活，适合标记清理或者标记压缩

GC算法总结

引用计数

没有被Java采用

标记-清除

标记-压缩

复制算法

新生代

所有的算法，需要能够识别一个垃圾对象，因此需要给出一个可触及性的定义

可触及性

可触及的

从根节点可以触及到这个对象

根节点包括

栈中引用的对象

方法区中静态成员或者常量引用的对象（全局对象）

JNI方法栈中引用对象

可复活的

一旦所有引用被释放，就是可复活状态

因为在finalize()中可能复活该对象

不可触及的

在finalize()后，可能会进入不可触及状态

不可触及的对象不可能复活

可以回收

public class CanReliveObj {

public static CanReliveObj obj;

@Override
protected void finalize() throws Throwable {
super.finalize();
System.out.println("CanReliveObj finalize called");
obj = this;
}

@Override
public String toString() {
return "I am CanReliveObj";
}

public static void main(String[] args) throws
InterruptedException {
obj = new CanReliveObj();
obj = null;   //可复活
System.gc();
Thread.sleep(1000);
if (obj == null) {
System.out.println("obj 是 null");
} else {
System.out.println("obj 可用");
}
System.out.println("第二次gc");
obj = null;    //不可复活
System.gc();
Thread.sleep(1000);
if (obj == null) {
System.out.println("obj 是 null");
} else {
System.out.println("obj 可用");
}
}
}

// 输出结果为：
CanReliveObj finalize called
obj 可用
第二次gc
obj 是 null

应该尽量避免使用finalize()，操作不慎可能导致错误，因为它的优先级低，何时被调用不确定，何时发生GC也不确定，可以使用try-catch-finally来替代它

Stop-The-World

Stop-The-World

java中一种全局暂停的现象

全局停顿，所有Java代码停止，native代码可以执行，但不能和JVM交互

多半由于GC引起

Dump线程

死锁检查

堆Dump

GC时为什么会有全局停顿

类比在聚会时打扫房间，聚会时很乱，又有新的垃圾产生，房间永远打扫不干净，只有让大家停止活动了，才能将房间打扫干净

危害

长时间服务停止，没有响应

遇到HA系统，可能引起主备切换，严重危害生产环境

GC参数

串行收集器

最古老，最稳定

效率高

可能会产生较长的停顿

-XX:+UseSerialGC

新生代、老年代使用串行回收

新生代复制算法

老年代标记-压缩

并行收集器

ParNew

-XX:+UseParNewGC

新生代并行

老年代串行

Serial收集器新生代的并行版本

复制算法

多线程，需要多核支持

-XX:ParallelGCThreads 限制线程数量



Parallel收集器

类似ParNew

新生代复制算法

老年代标记-压缩

更加关注吞吐量

-XX:+UseParallelGC

使用Parallel收集器+老年代串行

-XX:+UseParallelOldGC

使用Parallel收集器+老年代并行



-XX:MaxGCPauseMills

最大停顿时间，单位毫秒

GC尽力保证回收时间不超过设定值

-XX:GCTimeRatio

0-100的取值范围

垃圾收集时间占总时间的比

默认99，即最大允许1%时间做GC

XX:MaxGCPauseMills和XX:GCTimeRatio，这两个参数是矛盾的，因为停顿时间和吞吐量不可能同时调优

CMS收集器

CMS收集器

Concurrent Mark Sweep 并发（与用户线程一起执行）标记清除

标记-清除算法

并发阶段会降低吞吐量

老年代收集器（新生代使用ParNew）

-XX:+UseConcMarkSweepGC

CMS运行过程比较复杂，着重实现了标记过程，可分为

初始标记

根可以直接关联到的对象

速度快

并发标记（和用户线程一起）

主要标记过程，标记全部对象

重新标记

由于并发标记时，用户线程依然运行，因此在正式清理前，再做修正

并发清除（和用户线程一起）

基于标记结果，直接清理对象



特点

尽可能降低停顿

会影响系统整体吞吐量和性能

比如，在用户线程运行过程中，分一半CPU去做GC，系统性能在GC阶段，反应速度就下降一半

清理不彻底

因为在清理阶段，用户线程还在运行，会产生新的垃圾，无法清理

因为和用户线程一起运行，不能在空间快满时再清理

-XX:CMSInitiatingOccupancyFraction设置触发GC的阀值

如果不幸内存预留空间不够，就会引起concurrent mode failure



-XX:+UseCMSCompactAtFullCollection Full GC后，进行一次整理

整理过程是独占的，会引起停顿时间变长

-XX:+CMSFullGCsBeforeCompaction

设置进行几次Full GC后，进行一次碎片整理

-XX:ParallelCMSThreads

设定CMS的线程数量

-XX:CMSInitiatingPermOccupancyFraction

当永久区占用率达到这一百分比时，启动CMS回收

XX:UseCMSInitiatingOccupancyOnly

表示只在到达阀值的时候，才进行CMS回收

类装载器

class装载验证流程

加载

取得类的二进制流

转为方法区数据结构

在Java堆中生成对应的java.lang.Class对象

链接

验证

目的：保证Class流的格式是正确的

文件格式的验证

是否以0xCAFEBABE开头

版本号是否合理

元数据验证

是否有父类

是否继承了final类

非抽象类是否实现了所有的抽象方法

字节码验证（很复杂）

运行检查

栈数据类型和操作码数据参数是否吻合

跳转指令是否指定到合理的位置

准备

分配内存，并为类设置初始值（方法区中）

public static int v = 1;

在准备阶段中，v会被设置为0

在初始化的<clinit>中才会被设置为1

对于static final类型，在准备阶段就会被赋上正确的值

解析

符合引用（字符串）替换为直接引用（指针或者地址偏移量）

初始化

执行类构造器<clinit>

static变量赋值语句

static{}语句

子类的<clinit>调用前保证父类的<clinit>被调用

<clinit>是线程安全的

什么是类装载器ClassLoader

ClassLoader是一个抽象类

ClassLoader的实例将读入Java字节码将类装载到JVM中

ClassLoader可以定制，满足不同的字节码流获取方式

ClassLoader负责类装载过程中的加载阶段

ClassLoader的重要方法

public Class <?> loadClass(String name) throws ClassNotFoundException

载入并返回一个Class

protected final Class<?> defineClass(byte[] b, int off, int len)

定义一个类，不公开调用

protected Class<?> findClass(String name) throws ClassNotFoundException

loadClass回调该方法，自定义ClassLoader的推荐做法

protected final Class<?> findLoadedClass(String name)

寻找已经加载的类

ClassLoader的分类

BootStrap ClassLoader（启动ClassLoader）

Extension ClassLoader（扩展ClassLoader）

App ClassLoader（应用ClassLoader/系统ClassLoader）

Custom ClassLoader（自定义ClassLoader）

ClassLoader的协同工作

锁

对象头Mark

Mark Word，对象头的标记，32位

描述对象的hash、锁信息，垃圾回收标记，年龄

指向锁记录的指针

指向monitor的指针

GC标记

偏向锁线程ID

偏向锁

大部分情况是没有竞争的，所以可以通过偏向来提高性能

所谓的偏向，就是偏心，即锁会偏向于当前已经占有锁的线程

将对象头Mark的标记设置为偏向，并将线程ID写入对象头Mark

只要没有竞争，获得偏向锁的线程，在将来进入同步块，不需要做同步

当其他线程请求相同的锁时，偏向模式结束

-XX:+UseBiasedLocking

默认启用

在竞争激烈的场合，偏向锁会增加系统负担

轻量级锁

普通的锁处理性能不够理想，轻量级锁是一种快速的锁定方法

如果对象没有被锁定

将对象头的Mark指针保存到锁对象中

将对象头设置为指向锁的指针（在线程栈空间中）

如果轻量级锁失败，表示存在竞争，升级为重量级锁（常规锁）

在没有锁竞争的前提下，减少传统锁使用OS互斥量产生的性能损耗

在竞争激烈时，轻量级锁会多做很多额外操作，导致性能下降

自旋锁

当竞争存在时，如果线程可以很快获得锁，那么可以不在OS层挂起线程，让线程做几个空操作（自旋）

JDK1.6中-XX:+UseSpinning开启

JDK1.7中，去掉此参数，改为内置实现

如果同步块很长，自旋失败，会降低系统性能

如果同步块很短，自旋成功，节省线程挂起切换时间，提升系统性能

JVM中获取锁的步骤

偏向锁可用会尝试偏向锁

轻量级锁可用会先尝试轻量级锁

以上都失败，尝试自旋锁

再失败，尝试普通锁，使用OS互斥量在操作系统层挂起

锁优化方法

减少锁持有时间

public synchronized void syncMethod(){
othercode1();
mutextMethod();
othercode2();
}

=>

public void syncMethod2(){
othercode1()
synchronized(this){
mutextMethod();
}
othercode2();
}

减小锁粒度

将大对象，拆成小对象，大大增加并行度，降低锁竞争

偏向锁，轻量级锁成功率提高

ConcurrentHashMap

若干个Segment：Segment<K,V>[] segments

Segment中维护HashEntry<K,V>

put操作时，先定位到Segment，锁定一个Segment，执行input

在减小锁粒度后，ConcurrentHashMap允许若干个线程同时进入

锁分离

根据功能进行锁分离

ReadWriteLock

读多写少的情况，可以提高性能

锁粗化

如果对同一个锁不停的进行请求、同步和释放，其本身也会消耗系统宝贵的资源，反而不利于性能的优化

public void demoMethod(){
synchronized(lock){
// do sth
}

// 做其他不需要同步的工作，但能很快执行完毕
synchronized(lock){
// do sth
}
}

=>

public void demoMethod(){
// 整合成一次锁请求
synchronized(lock){
// do sth
// 做其他不需要同步的工作，但能很快执行完毕
// do sth
}
}

锁消除

在即时编译器时，如果发现不可能被共享的对象，则可以消除这些对象的锁操作

无锁

锁是悲观的操作

无锁是乐观的操作

无锁是一种实现方式

CAS(Compare And Swap)

非阻塞的同步

CAS(V,E,N)

在应用层面判断多线程的干扰，如果有干扰，则通知线程重试