文章内容不确保百分百正确
暂未阅读《深入理解Java虚拟机》进行校对
本文适合入门 JVM
笔记来源：B站黑马程序员的视频
章节推荐：内存结构、垃圾回收算法、编译器处理、类加载
前言
什么是JVM
定义
Java Virtual Machine - Java程序的运行环境 (Java二进制字节码的运行环境)
优点
- 一次编写，到处运行 (JVM屏蔽了字节码与操作系统的差异)
- 自动内存管理，垃圾回收功能 (c++需要手动释放)
- 数组下标越界，越界检查
- 多态 (虚方法表)
比较
JVM JRE JDK
基础类库：Data类、线程类...
编译工具：javac...
IDE工具：idea...
学习路线
主要分为
类加载器模块、内存结构模块、执行引擎模块
方法区
存放创建的类
堆
存放类创建的实例、对象
虚拟机栈、程序计数器、本地方法栈
调用类的方法时
解释器
逐行执行代码
即使编译器
经常调用的代码
垃圾回收
堆中不在使用的对象进行垃圾回收
内存结构
程序计数器
定义
Program Counter Register 程序计数器 (寄存器)
通过寄存器实现功能
代码执行流程
源代码 -> JVM指令 -> 解释器 -> 机器码 -> CPU
作用
记住下一条JVM指令的执行地址
流程
第一条指令执行时，会把下一个指令的地址放到程序计数器中，当第一条执行执行完毕，解释器会到程序计数器中拿到下一条指令的执行地址
特点
- 线程私有 (每个线程都有自己的程序计数器)
- 不会存在内存溢出
虚拟机栈
除了win默认都是1M，可以通过 -Xss 设置栈大小
定义
每个线程运行时需要的内存空间 (每个线程都要有内存空间)，称为虚拟机栈
每个栈由多个栈帧组成，对应着每次方法调用时所占用的内存 (方法掉方法、递归)
每个线程只能有一个活动栈帧，对应着当前正在执行的那个方法
流程
当调用一个方法时，会分配一个栈帧(参数，局部变量，返回地址) 压入栈中。当方法执行完会将栈帧弹出
问题辨析
1、垃圾回收是否涉及栈内存？
不会，每次方法结束时，栈帧被弹出。
2、栈内存分配越大越好吗？
不是，栈内存越大，线程就越少。因为内存是固定的。
3、方法内的局部变量是否线程安全？
如果方法内局部变量没有逃离方法的作用范围 (没有return) ，它是线程安全的。
如果是局部变量引用了对象，并逃离了方法的作用方法，它是线程不安全的。
栈内存溢出
java.lang.StackOverflowError
栈帧过多导致栈内存溢出 (递归)
栈帧过大导致栈内存溢出
线程运行诊断
1、CPU占用过多
用top命令定位哪个进程对cpu的占用过高
ps H -eo pid,tid,%cpu | grep 进程id命令进一步定位是哪个线程引起的cpu占用过高
jstack 进程id找出哪个线程出现的问题 (jdk提供)
- 根据线程id(转为16进制去找线程名，继续定位到代码行数)
本地方法栈
给调用本地方法(c，c++代码底层代码)提供内存空间
堆
可以通过 -Xmx8m可以修改堆空间大小
定义
用过new关键字，创建对象都会使用堆内存。静态变量、类对象
特点
它是线程共享的，堆中对象都需要考虑线程安全的问题
内存不连续
有垃圾回收机制
内存溢出
java.lang.OutOfMemoryError: Java heap space
堆内存诊断
1、jps工具
查看当前系统中有哪些java进程
jps
2、jmap工具
查看堆内存占用情况
jmap -heap 进程id
3、jconsole工具
图形界面的，多功能的监测工具，可以连续监测
4、垃圾回收后，内存占用仍然很高
jvirsualvm工具
方法区
定义
主要存储类、类加载器、常量。
方法区与堆一样，是各个线程共享的内存区域。
方法区在JVM启动的时候被创建，内存不连续。
通过 -XX:MaxMetaspaceSize=8m可以修改方法区空间大小
方法区的大小决定了系统可以保存多少个类，如果系统定义了太多的类，导致方法区内存溢出。
java.lang.OutOfMemoryError: Metaspace
组成
在jdk7及以前，习惯上把方法区，称为永久代。
jdk8开始，使用元空间(本地内存)取代了永久代。元空间存放在堆外内存中。
内存溢出
动态代理可能会导致内存溢出
类加载器
用来加载类的二进制字节码
ClassWriter用来生成类的二进制字节码 (类基本信息，常量池，类方法定义，包含了虚拟机指令)
ClassWriter cw = new ClassWriter(0);
// 版本号，public，类名，包名，父类，接口
cw.visit(Opcodes.V1_8, Opcodes.ACC_PUBLIC, "Class" + i, null, "java/lang/Object", null);
byte[] code = cw.toByteArray();
// 加载类
xxx类对象.defineClass("Class" + i, code, 0, code.length);常量池
先了解二进制字节码：类基本信息，常量池，类方法定义，包含了虚拟机指令
javap -v xxxxx.class反编译为JVM指令码，可以看到二进制字节码的信息
常量池就是一张表，虚拟机指令根据这张常量表找到要执行的类名、方法名、参数类型、字面量等信息
// 类的基本信息
Last modified 2022年6月21日; size 587 bytes
SHA-256 checksum 0d68484a029be065fc8077decf230d346f754e32335f8c0998ebc6c8185f75dd
Compiled from "HelloWorld.java"
public class com.zmz.jvm.HelloWorld
minor version: 0
major version: 52
flags: (0x0021) ACC_PUBLIC, ACC_SUPER
this_class: #5 // com/zmz/jvm/HelloWorld
super_class: #6 // java/lang/Object
interfaces: 0, fields: 0, methods: 2, attributes: 1
// 常量池
Constant pool:
#1 = Methodref #6.#21 // java/lang/Object."<init>":()V
#2 = Fieldref #22.#23 // java/lang/System.out:Ljava/io/PrintStream;
#3 = String #24 // hello world
#4 = Methodref #25.#26 // java/io/PrintStream.println:(Ljava/lang/String;)V
#5 = Class #27 // com/zmz/jvm/HelloWorld
#6 = Class #28 // java/lang/Object
#7 = Utf8 <init>
#8 = Utf8 ()V
#9 = Utf8 Code
#10 = Utf8 LineNumberTable
#11 = Utf8 LocalVariableTable
#12 = Utf8 this
#13 = Utf8 Lcom/zmz/jvm/HelloWorld;
#14 = Utf8 main
#15 = Utf8 ([Ljava/lang/String;)V
#16 = Utf8 args
#17 = Utf8 [Ljava/lang/String;
#18 = Utf8 MethodParameters
#19 = Utf8 SourceFile
#20 = Utf8 HelloWorld.java
#21 = NameAndType #7:#8 // "<init>":()V
#22 = Class #29 // java/lang/System
#23 = NameAndType #30:#31 // out:Ljava/io/PrintStream;
#24 = Utf8 hello world
#25 = Class #32 // java/io/PrintStream
#26 = NameAndType #33:#34 // println:(Ljava/lang/String;)V
#27 = Utf8 com/zmz/jvm/HelloWorld
#28 = Utf8 java/lang/Object
#29 = Utf8 java/lang/System
#30 = Utf8 out
#31 = Utf8 Ljava/io/PrintStream;
#32 = Utf8 java/io/PrintStream
#33 = Utf8 println
#34 = Utf8 (Ljava/lang/String;)V
// 类方法定义
{
public com.zmz.jvm.HelloWorld();
descriptor: ()V
flags: (0x0001) ACC_PUBLIC
Code:
stack=1, locals=1, args_size=1
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return
LineNumberTable:
line 8: 0
LocalVariableTable:
Start Length Slot Name Signature
0 5 0 this Lcom/zmz/jvm/HelloWorld;
public static void main(java.lang.String[]);
descriptor: ([Ljava/lang/String;)V
flags: (0x0009) ACC_PUBLIC, ACC_STATIC
Code: // 虚拟机指令
stack=2, locals=1, args_size=1
0: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream;
3: ldc #3 // String hello world
5: invokevirtual #4 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
8: return
LineNumberTable:
line 10: 0
line 11: 8
LocalVariableTable:
Start Length Slot Name Signature
0 9 0 args [Ljava/lang/String;
MethodParameters:
Name Flags
args
}
SourceFile: "HelloWorld.java"
运行时常量池
常量池是 *.class 文件中的，当该类被加载，它的常量池信息就会放入运行时常量池，并把里面的符号地址变为真实地址
串池
特性
常量池中的字符串仅是符号，第一次用到时才变为对象
利用串池的机制，来避免重复创建字符串对象
字符串变量拼接的原理是StringBuilder
字符串常量拼接的原理是编译器优化
可以使用 intern方法主动将串池中还没有的字符串对象放入串池
- 1.8将这个字符串对象尝试放入串池，如果有不放入，没有则放入，最后返回串池中的对象
- 1.6将这个字符串对象尝试放入串池，如果有不放入，如果没有复制一份放入，最后返回串池的对象
StringTable hashTable结构，不能扩容
常量池与串池的关系
package com.zmz.jvm;
/**
* @author 张明泽
* Create by 2022/6/22 20:56
*/
public class StringTable {
// 常量池中的信息，都会被加载到运行时常量池中，这时a,b,ab都是常量池中的符号还没有变成java字符串对象
// 当执行到主方法的虚拟机指令 ( ldc #2) 时，a 符号变为 "a" 字符串对象 然后 准备放入到 串池 中
// StringTable ["a"]
// b 符号变为 "b" 字符串对象
// StringTable中无 b 对象，则 StringTable["a","b"]
// ab 符号变为 "ab" 字符串对象
// StringTable中无 ab 对象，则 StringTable["a","b","ab"]
public static void main(String[] args) {
String s1 = "a";
String s2 = "b";
String s3 = "ab";
}
}String s1 = "a";
String s2 = "b";
String s3 = "ab";
String s4 = s1 + s2;
String s5 = "a" + "b";s3、s4、s5是否相同？
字符串变量拼接
package com.zmz.jvm;
/**
* @author 张明泽
* Create by 2022/6/22 20:56
*/
public class StringTable {
public static void main(String[] args) {
// 放在堆的串池中
String s1 = "a";
String s2 = "b";
String s3 = "ab";
// 创建StringBuilder 追加两个值 最后转换为一个新的String对象
// new StringBuilder().append("a").append("b").toString() new String("ab")
String s4 = s1 + s2; // 放在堆中
}
}
// s3!=s49: new #5 // class java/lang/StringBuilder
12: dup
13: invokespecial #6 // Method java/lang/StringBuilder."<init>":()V
16: aload_1
17: invokevirtual #7 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
20: aload_2
21: invokevirtual #7 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringB
uilder;
24: invokevirtual #8 // Method java/lang/StringBuilder.toString:()Ljava/lang/String;javac在编译期优化
package com.zmz.jvm;
/**
* @author 张明泽
* Create by 2022/6/22 20:56
*/
public class StringTable {
public static void main(String[] args) {
String s1 = "a";
String s2 = "b";
String s3 = "ab";
String s4 = s1 + s2;
// 虚拟机指令会找到ab对象 不会再次放到串池中了
// javac 在编译期的优化，结果已经在编译期确定为ab
String s5 = "a" + "b";
}
}
// s3 == s5 s3 != s429: ldc #4 // String ab字符串延迟加载
package com.zmz.jvm;
/**
* @author 张明泽
* Create by 2022/6/22 21:49
*/
public class StringNumbers {
public static void main(String[] args) {
System.out.println();
System.out.println("1");
System.out.println("2");
System.out.println("3");
// 不会在创建字符串"1"了
// 执行一行代码(一行虚拟机指令)创建一个对象 "1"已经在串池中了不会在创建
// Memory 中不会变大了
System.out.println("1");
System.out.println("2");
System.out.println("3");
}
}intern
package com.zmz.jvm;
/**
* @author 张明泽
* Create by 2022/6/23 10:48
*/
public class Intern {
// 常量池中 StringTable["a", "b"] ( 只存常量 )
public static void main(String[] args) {
String s = new String("a") + new String("b");
// 堆中创建对象 new String("a") new String("b")
// new String("ab") 动态拼接都在堆中创建,不会放到串池中
// 将 s 对象放到串池中,如果有则不会放入,没有则放入,最后都会返回串池的对象 ["a","b","ab"]
String s2 = s.intern(); // 放进去了
System.out.println(s2 == "ab");
System.out.println(s == "ab");
}
}package com.zmz.jvm;
/**
* @author 张明泽
* Create by 2022/6/23 10:48
*/
public class Intern2 {
// 常量池中 StringTable["ab", "a", "b"] ( 只存常量 )
public static void main(String[] args) {
String x = "ab";
String s = new String("a") + new String("b");
// new String("ab")是堆中创建的
// 将 s 对象放到串池中,如果有则不会放入,没有则放入,最后都会返回串池的对象 ["a","b","ab"]
String s2 = s.intern(); // 没放进去 s != "ab"
System.out.println(s2 == "ab");// true
System.out.println(s == "ab"); // false
}
}位置
模拟报错
-XX MaxPermSize=10m
报java.lang.OutOfMemoryError: PermGen space证明1.6串池是永久代
1.6串池在永久代中时，回收效率不高，永久代内存不足。
-Xmx10m 设置堆的大小
报java.lang.OutOfMemoryError: GC overhead limit exceeded垃圾回收效率过低
继续设置 -XX:-UseGCOverheadlimit
报 java.lang.OutOfMemoryError: Java heap space 证明1.8串池是元空间
1.8串池放在堆中，可以垃圾回收，效率更高。
垃圾回收
StringTable是有垃圾回收的
package com.zmz.jvm;
/**
* @author 张明泽
* Create by 2022/6/23 16:18
*/
/**
* 演示 StringTable 垃圾回收
* -Xmx10m -XX:+PrintStringTableStatistics -XX:+PrintGCDEtails -verbose:gc
*/
public class StringTableGC {
public static void main(String[] args) {
int i = 0;
try {
for (int j = 0; j < 10000; j++) {
String.valueOf(j).intern();
}
} catch (Throwable e) {
e.printStackTrace();
} finally {
System.out.println(i);
}
}
}性能调优
1、-XX:StringTableSize=200000调整串池的桶个数
根据字符常量的多少，调整SringTable桶的大小，使哈希分布更均匀，让哈希碰撞更小(底层是HashTable)。
-Xms设置初始Java堆大小，而-Xmx设置最大Java堆大小。
-Xms500m -Xmx500m -XX:+PrintStringTableStatistics -XX:StringTableSize=200000
设置桶的大小为200000个，默认是60000多个。
2、考虑将字符串对象是否入池
存在大量字符串且有重复现象，可以利用让每个字符串入池，根据串池的特性相同的不会入池可达到降低内存的使用效果
public class demo {
public static void main(String[] args) {
List<String> address = new ArrayList<>();
System.in.read();
for (int i = 0; i < 10; i++) {
try (BufferedReader reader = new BufferedReader(new InputStreamReader(new FileInputStream("linux.words"),"utf-8"))) {
String line = null;
long start = System.nanoTime();
while (true) {
line = reader.readLine(); // 直接在堆中了
if (line == null) {
break;
}
// address.add(line); 1
address.add(line.intern()); // 2
}
System.out.println("cost:" + (System.nanoTime()-start)/1000000);
}
}
System.in.read();
}1、
2、
直接内存
Direct Memory
操作系统的内存
定义
常见于NIO操作，用于数据缓冲区
分配回收成本较高，但读写性能高
不受JVM内存回收管理
NIO操作和IO操作对比
package com.zmz.jvm;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.nio.ByteBuffer;
import java.nio.channels.FileChannel;
/**
* @author 张明泽
* Create by 2022/6/23 21:54
*/
public class DirectMemory {
static final String FROM = "";
static final String TO = "";
static final int _1Mb = 1024 * 1024;
public static void main(String[] args) {
io();
directBuffer();
}
public static void directBuffer() {
long start = System.nanoTime();
try (FileChannel from = new FileInputStream(FROM).getChannel();
FileChannel to = new FileOutputStream(TO).getChannel();) {
ByteBuffer b = ByteBuffer.allocateDirect(_1Mb);
while (true) {
int len = from.read(b);
if (len == -1) {
break;
}
b.flip();
to.write(b);
b.clear();
}
} catch (Exception e) {
}
}
public static void io() {
long start = System.nanoTime();
try(FileInputStream from = new FileInputStream(FROM);
FileOutputStream to = new FileOutputStream(TO);
) {
byte[] buf = new byte[_1Mb];
while (true) {
int len = from.read(buf);
if (len == -1) {
break;
}
to.write(buf,0,len);
}
} catch (Exception e) {
}
long end = System.nanoTime();
System.out.println("用时" + (end - start) / 1000_000.0);
}
}
内存溢出
Java.lang.OutOfMemoryError: Direct buffer memory
释放原理
使用了Unsafe对象完成直接内存的分配回收，并且回收需要主动调用freeMemory方法。(直接内存不受java管制)
ByteBuffer的实现内部类，使用了Cleaner(虚引用)来监测ByteBuffer对象，一旦ByteBuffer对象被垃圾回收，那么就会由ReferenceHandler线程通过Cleaner的clean方法调用freeMemory来释放直接内存
package com.zmz.jvm;
import sun.misc.Unsafe;
import java.io.IOException;
/**
* @author 张明泽
* Create by 2022/6/24 0:46
*/
public class ByteBufferGC {
static final int _1GB = 1024 * 1024 * 1024;
public static void main(String[] args) throws IOException {
Unsafe unsafe = Unsafe.getUnsafe();
// 分配内存
long base = unsafe.allocateMemory(_1GB);
unsafe.setMemory(base,_1GB,(byte)0);
System.in.read();
// 释放内存
unsafe.freeMemory(base);
System.in.read();
}
}禁用显式gc
显式gc是 Full gc 对性能有影响
package com.zmz.jvm;
import java.io.IOException;
import java.nio.ByteBuffer;
/**
* @author 张明泽
* Create by 2022/6/24 0:33
*/
public class ByteBufferDemo {
/**
* -XX:+DisableExplicitGC 禁用显式的gc
* @param args
* @throws IOException
*/
public static void main(String[] args) throws IOException {
ByteBuffer byteBuffer = ByteBuffer.allocateDirect(1024 * 1024 * 1024);
System.out.println("分配完毕");
System.in.read();
System.out.println("开始释放");
byteBuffer = null;
System.gc(); // 显式的垃圾回收, Full GC
System.in.read();
}
}垃圾回收
如何判断对象可以回收
引用计数法
一个对象被其他变量所引用，使计数 +1，用两次计数 +2，不在引用计数 -1。当计数为0时，就被回收。
A引用B，B引用A。此时会导致内存泄露。
可达性分析算法
java虚拟机中的垃圾回收器采用的是 可达性分析 来探索所有存活的对象
流程
Root : 肯定不能当成垃圾回收的对象称为根对象。
扫描堆中的对象，看是否能够沿着 GC Root 对象为起点的引用链找到该对象，找不到，表示可以回收。
哪些对象可以作为 GC Root 对象？
可以使用 Eclipse Memory Analyzer 工具查看哪些对象可以作为 root 对象
四种引用
强引用
只有所有GC Roots对象都不通过 强引用 引用该对象，该对象才能被垃圾回收
软引用
仅有 软引用 引用该对象时，在垃圾回收后，内存仍不足时会再次触发垃圾回收，回收软引用对象
可以配合引用队列来释放引用自身
/**
* 演示软引用
* -Xmx20m -XX:+PrintGCDetails -verbose:gc
*/
public static void strongReference() throws IOException {
List<byte[]> list = new ArrayList<>();
for (int i= 0; i< 5; i++) {
list.add(new byte[4 * 1024 * 1024]);
// java.lang.OutOfMemoryError: Java heap space 强引用导致
}
}
public static void softReference() {
// list --> SoftReference --> byte[]
List<SoftReference<byte[]>> list = new ArrayList<>();
for (int i= 0; i< 5; i++) {
SoftReference<byte[]> ref = new SoftReference<>(new byte[4 * 1024 * 1024]);
System.out.println(res.get());
list.add(ref);
System.out.println(list.size());
}
// 循环结束
for (SoftReference<byte[]> ref : list) {
System.out.println(ref.get()); // 前四个都是null
}
}// 软引用也可以清除掉 使用引用队列
public static void softReference() {
List<SoftReference<byte[]>> list = new ArrayList<>();
// 引用队列
ReferenceQueue<byte[]> queue = new ReferenceQueue<>();
for (int i= 0; i< 5; i++) {
// 关联了引用队列，当软引用所关联的 byte[] 被回收时，软引用自己会加入到 queue 中去
SoftReference<byte[]> ref = new SoftReference<>(new byte[4 * 1024 * 1024]);
System.out.println(res.get());
list.add(ref);
System.out.println(list.size());
}
Reference<? extends byte[]> poll = queue.poll();
while (poll != null) {
list.remove(poll);
poll = queue.poll();
}
for (SoftReference<byte[]> ref : list) {
System.out.println(ref.get()); // 只剩下一个对象了
}
}弱引用
仅有 弱引用 引用该对象时，在垃圾回收时，无论内存是否充足，都会回收弱引用对象
可以配合引用队列来释放引用自身
/**
* 演示弱引用
* -Xmx20m -XX:+PrintGCDetails -verbose:gc
*/
public static void weakReference() {
// list --> WeakReference --> byte[]
List<WeakReference<byte[]>> list = new ArrayList<>();
for (int i= 0; i< 5; i++) {
WeakReference<byte[]> ref = new WeakReference<>(new byte[4 * 1024 * 1024]);
list.add(ref);
}
// 循环结束
for (SoftReference<byte[]> ref : list) {
System.out.println(ref.get()); // 不一定几个空
}
}虚引用
必须配合引用队列使用，主要配合 ByteBuffer 使用，被引用对象回收时，会将虚引用入队，由 Reference Handler 线程调用虚引用相关方法释放直接内存
终结期引用
无需手动编码，但其内部配合引用队列使用，在垃圾回收时，终结器引用入队(被引用对象暂时没有被回收)，再由 Finalizer 线程通过终结器引用找到被引用对象并调用它的 finalize 方法，第二次 GC 时才能回收被引用对象
垃圾回收算法
标记清除
Mark Sweep
优点
速度快
缺点
产生内存碎片 (空间不连续)
标记整理
Mark Compact
优点
没有内存碎片
缺点
速度慢
复制
Copy
优点
不会产生内存碎片
缺点
占用双倍内存空间
分代回收
堆内存分成两部分：新生代、老年代
- 对象首先分配在
伊甸园区域 - 新生代空间不足时，触发
minor gc，伊甸园 和 from 存活的对象使用copy复制到to中，存活的对象年龄加1，并且交换from 和 to - minor gc 会引发
stop the world，暂停其他用户的线程，等垃圾回收结束，用户线程才恢复运行 - 当对象寿命超过阈值时或新生代内存不够，会晋升至老年代，最大寿命是15 (4bit 1111)
- 当老年代空间不足，先尝试 minor gc，如果之后空间仍不足，那么触发full gc
相关VM参数
| 含义 | 参数 |
|---|---|
| 堆初始大小 | -Xms |
| 堆最大大小 | -Xmx 或 -XX：MaxNewSize=size |
| 新生代大小 | -Xmn 或 (-XX:NewSize=size + -XX:MaxNewSize=size) |
| 幸存区比例 (动态) | -XX:InitialSurvivorRatio=ratio 和 -XX:+UseAdaptiveSizePolicy |
| 幸存区比例 | -XX:SurvivorRatio=ratio |
| 晋升阈值 | -XX:MaxTenuringThreshold=threshold |
| 晋升详情 | -XX:+PrintTenuringDistribution |
| GC详情 | -XX:PrintGCDetails -verbose:gc |
| FullGC前MinorGC | -XX:+ScavengeBeforeFullGC |
GC分析
gc过程
public class demo {
private static final int _512KB = 512 * 1024;
private static final int _1MB = 1024 * 1024;
private static final int _6MB = 6 * 1024 * 1024;
private static final int _7MB = 7 * 1024 * 1024;
private static final int _8MB = 8 * 1024 * 1024;
// -Xms20M -Xmx20M -Xmn10M -XX:+UseSerialGC -XX:+PrintGCDetails -verbose:gc
public static void main(String[] args) {
ArrayList<byte[]> list = new ArrayList<>();
list.add(new byte[_7MB]);
}
}Heap
def new generation total 9216K, used 2489K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
eden space 8192K, 30% used [0x00000000fec00000, 0x00000000fee6e678, 0x00000000ff400000)
from space 1024K, 0% used [0x00000000ff400000, 0x00000000ff400000, 0x00000000ff500000)
to space 1024K, 0% used [0x00000000ff500000, 0x00000000ff500000, 0x00000000ff600000)
tenured generation total 10240K, used 0K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)
the space 10240K, 0% used [0x00000000ff600000, 0x00000000ff600000, 0x00000000ff600200, 0x0000000100000000)
Metaspace used 3270K, capacity 4496K, committed 4864K, reserved 1056768K
class space used 345K, capacity 388K, committed 512K, reserved 1048576Klist.add(new byte[_7MB]);
list.add(new byte[_512KB]);[GC (Allocation Failure) [DefNew: 2489K->813K(9216K), 0.0039382 secs] 2489K->813K(19456K), 0.0040188 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
Heap
def new generation total 9216K, used 8740K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
eden space 8192K, 96% used [0x00000000fec00000, 0x00000000ff3bd8d0, 0x00000000ff400000)
from space 1024K, 79% used [0x00000000ff500000, 0x00000000ff5cb7c8, 0x00000000ff600000)
to space 1024K, 0% used [0x00000000ff400000, 0x00000000ff400000, 0x00000000ff500000)
tenured generation total 10240K, used 0K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)
the space 10240K, 0% used [0x00000000ff600000, 0x00000000ff600000, 0x00000000ff600200, 0x0000000100000000)
Metaspace used 3331K, capacity 4496K, committed 4864K, reserved 1056768K
class space used 357K, capacity 388K, committed 512K, reserved 1048576Klist.add(new byte[_7MB]);
list.add(new byte[_512KB]);
list.add(new byte[_512KB]);[GC (Allocation Failure) [DefNew: 2489K->813K(9216K), 0.0023137 secs] 2489K->813K(19456K), 0.0023661 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[GC (Allocation Failure) [DefNew: 8657K->512K(9216K), 0.0045134 secs] 8657K->8450K(19456K), 0.0045535 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
Heap
def new generation total 9216K, used 1106K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
eden space 8192K, 7% used [0x00000000fec00000, 0x00000000fec94930, 0x00000000ff400000)
from space 1024K, 50% used [0x00000000ff400000, 0x00000000ff480048, 0x00000000ff500000)
to space 1024K, 0% used [0x00000000ff500000, 0x00000000ff500000, 0x00000000ff600000)
tenured generation total 10240K, used 7938K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)
the space 10240K, 77% used [0x00000000ff600000, 0x00000000ffdc08a8, 0x00000000ffdc0a00, 0x0000000100000000)
Metaspace used 3331K, capacity 4496K, committed 4864K, reserved 1056768K
class space used 357K, capacity 388K, committed 512K, reserved 1048576K大对象OOM
/**
* @author 张明泽
* Create by 2022/6/28 20:20
*/
public class NewGeneration {
private static final int _512KB = 512 * 1024;
private static final int _1MB = 1024 * 1024;
private static final int _6MB = 6 * 1024 * 1024;
private static final int _7MB = 7 * 1024 * 1024;
private static final int _8MB = 8 * 1024 * 1024;
// -Xms20M -Xmx20M -Xmn10M -XX:+UseSerialGC -XX:+PrintGCDetails -verbose:gc
public static void main(String[] args) {
ArrayList<byte[]> list = new ArrayList<>();
// 伊甸园放不下了直接OOM
// 不会触发gc
list.add(new byte[_8MB]);
}
}Heap
def new generation total 9216K, used 2653K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
eden space 8192K, 32% used [0x00000000fec00000, 0x00000000fee975e8, 0x00000000ff400000)
from space 1024K, 0% used [0x00000000ff400000, 0x00000000ff400000, 0x00000000ff500000)
to space 1024K, 0% used [0x00000000ff500000, 0x00000000ff500000, 0x00000000ff600000)
tenured generation total 10240K, used 8192K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)
the space 10240K, 80% used [0x00000000ff600000, 0x00000000ffe00010, 0x00000000ffe00200, 0x0000000100000000)
Metaspace used 3331K, capacity 4496K, committed 4864K, reserved 1056768K
class space used 357K, capacity 388K, committed 512K, reserved 1048576K// GC 、 Full GC 内存依旧不够,报异常
list.add(new byte[_8MB]);[GC (Allocation Failure) [DefNew: 2489K->814K(9216K), 0.0015852 secs][Tenured: 8192K->9004K(10240K), 0.0099491 secs] 10681K->9004K(19456K), [Metaspace: 3324K->3324K(1056768K)], 0.0117726 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
[Full GC (Allocation Failure) [Tenured: 9004K->8987K(10240K), 0.0021227 secs] 9004K->8987K(19456K), [Metaspace: 3324K->3324K(1056768K)], 0.0021454 secs] [Times: user=0.02 sys=0.00, real=0.00 secs]
Heap
def new generation total 9216K, used 246K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
eden space 8192K, 3% used [0x00000000fec00000, 0x00000000fec3d890, 0x00000000ff400000)
from space 1024K, 0% used [0x00000000ff500000, 0x00000000ff500000, 0x00000000ff600000)
to space 1024K, 0% used [0x00000000ff400000, 0x00000000ff400000, 0x00000000ff500000)
tenured generation total 10240K, used 8987K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)
the space 10240K, 87% used [0x00000000ff600000, 0x00000000ffec6c98, 0x00000000ffec6e00, 0x0000000100000000)
Metaspace used 3356K, capacity 4496K, committed 4864K, reserved 1056768K
class space used 360K, capacity 388K, committed 512K, reserved 1048576K
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at com.zmz.jvm.NewGeneration.main(NewGeneration.java:23)多线程
线程是独立的，一个线程堆内存溢出，不会影响别的线程运行。
垃圾回收器
串行
串行垃圾回收器 SerialGC
特点
单线程 (stop the world)
堆内存较小，适合个人电脑
Serial 工作在新生代 --- 复制算法
SerialOld 工作在老年代 --- 标记整理算法
相关参数
开启串行垃圾回收器 -XX:+UseSerialGC Serial + SerialOld
为了满足分代收集理念，Serial收集器分别在年轻代和老年代各实现了一个版本，老年代是Serial Old，使用标记整理算法。Serial在回收垃圾的整个过程中都是采用单线程的方式，所以STW的时间会很长，内存越大，STW时间越长，用户的卡顿时间就很长，现在我们生产环境堆分配的一般都是几个G以上的，所以Serial收集器一定会很慢很慢，在很早之前的jdk版本中有使用，现在都不主动用这个了，只有在使用CMS回收器并发清理失败的情况下系统会默认回退到这种方式。
吞吐量优先(并行)
并行垃圾回收器 Parallel GC 多个线程同时进行GC(用户线程停止)
特点
多线程
堆内存较大，多核cpu
让单位时间内，STW 的时间最短 (一口吃的多)
标记-整理 算法
吞吐量 = 用户应用程序运行的时间 / （应用程序运行的时间 + 垃圾回收的时间）
jdk8默认的垃圾回收器
相关参数
开启并行垃圾回收器 -XX:+UseParallelGC
控制线程数 -XX:ParallerGCThreads=n
自适应 -XX:+UseAdaptiveSizePolicy 动态调整伊甸园和from、to的大小
根据目标调整堆的大小-XX:GCTimeRatio=ratio 1 / (1 + ratio)
最大暂停毫秒数-XX:MaxGCPauseMillis=ms 默认是200ms
响应时间优先(并发)
并发垃圾回收器 CMS用户线程和GC同时进行
特点
多线程
堆内存较大，多核cpu
尽可能让单次 STW 的时间更短 (吃的快)
并发标记清除算法
CMS工作在老年代
并发失败时(内存碎片过多)会退化到串行垃圾回收器
CMS中STW的停顿时间得到了很好的解决：CMS在回收的过程中允许和GC线程和用户线程同时发生（并发）且将标记对象的过程延长，每次只标记一点点，以获取最短回收停顿时间为目标。
相关参数
开启响应时间优先(并发)垃圾回收器 -XX:+UseConcMarkSweepGC
控制线程数 -XX:ParallelGCThreads=n
控制并发线程数 -XX:ConcGCThreads=threads 线程个数的4分支1
执行CMS内存占比-XX:CMSInitiatingOccupancyFraction=percent 默认65左右
标记前先对新生代进行垃圾回收-XX:+CMSScavengeBeforeRemark
ParNew
和Parallel的实现基本一样，唯一不同的是它可以和CMS搭配使用，而Parallel不可以，当设置了回收器是cms的时候，JVM则会默认开启ParNew作为年轻代的回收器且无法关闭，对于Parallel的一些参数也可以在ParNew里面用。
G1
2017年 JDK9 默认，废弃了 CMS 垃圾回收器
并发垃圾回收器 G1
使用场景
- 同时注重吞吐量和低延迟，默认的暂停目标是200ms
- 超大堆内存，会将堆划分为多个大小相等的 Region
- 整体上是
标记 + 整理算法，两个区域之间是复制算法
相关JVM参数
-XX:+UseG1GC
-XX:G1HeapRegionSize=size
-XX:MaxGCPauseMillis=time
G1垃圾回收阶段
Young Collection
新生代垃圾回收 (STW)
Young Collection + CM
在Young GC时会进行 GC Root 的初始标记 (STW时)
老年代占用堆空间比例达到阈值时，进行并发标记 (不会STW) ，由下面的 JVM 参数决定
-XX:InitialtingHeapOccupancyPercent=percnet 默认是45%
Mixed Collection
会对E、S、O进行全面垃圾回收
- 最终标记 (Remark) 会 STW (并发时可能会漏掉一些)
- 拷贝存活 (Evacuation) 会 STW
优点回收老年代中垃圾最多的区，为了达到暂停时间短的目标
-XX:MaxGCPauseMillis=ms
Full GC
SerialGC、ParallelGC、CMS、G1 新生代内存不足发生的垃圾回收 --- minor GC
SerialGC、ParallelGC 老年代内存不足发生的垃圾回收 --- Full GC
CMS、G1并发回收失败时(内存碎片过多) 会退化为串行，进行Full GC
跨代引用
新生代回收的跨代引用 (老年代引用新生代) 问题
新生代回收时，先找到 Root 对象，Root对象一部分来自老年代中。
直接遍历老年代效率非常低，因此采用 卡表 技术，把老年代细分成 card (默认512K)。
如果老年代有一个对象引用了新生代的对象，就标记为 赃卡 。好处是 GC Root 遍历时，只需要找到赃卡的区域，减小了搜索范围提高了效率。
新生代有 Remembered Set 记录 有哪些赃卡，当对新生代垃圾回收时会通过 set 找到赃卡。
当引用变更(异步)通过 post-write barrier + dirty card queue 更新赃卡
卡表（Card Table）
有个场景，老年代的对象可能引用新生代的对象，那标记存活对象的时候，需要扫描老年代中的所有对象。因为该对象拥有对新生代对象的引用，那么这个引用也会被称为GC Roots。那不是得又做全堆扫描？成本太高了吧。
HotSpot给出的解决方案是一项叫做卡表（Card Table）的技术。该技术将整个堆划分为一个个大小为512字节的卡，并且维护一个卡表，用来存储每张卡的一个标识位。这个标识位代表对应的卡是否可能存有指向新生代对象的引用。如果可能存在，那么我们就认为这张卡是脏的。
在进行Minor GC的时候，我们便可以不用扫描整个老年代，而是在卡表中寻找脏卡，并将脏卡中的对象加入到Minor GC的GC Roots里。当完成所有脏卡的扫描之后，Java虚拟机便会将所有脏卡的标识位清零。
想要保证每个可能有指向新生代对象引用的卡都被标记为脏卡，那么Java虚拟机需要截获每个引用型实例变量的写操作，并作出对应的写标识位操作。
卡表能用于减少老年代的全堆空间扫描，这能很大的提升GC效率。
CMS 与 G1 的区别
1、使用范围不一样
CMS收集器是老年代的收集器，可以配合新生代的Serial和ParNew收集器一起使用
G1收集器收集范围是老年代和新生代。不需要结合其他收集器使用
2、STW的时间
CMS收集器以最小的停顿时间为目标的收集器。
G1收集器可预测垃圾回收的停顿时间（建立可预测的停顿时间模型）
3、垃圾碎片
CMS收集器是使用“标记-清除”算法进行的垃圾回收，容易产生内存碎片
G1收集器使用的是“标记-整理”算法，进行了空间整合，降低了内存空间碎片。
4、过程
CMS回收垃圾的4个阶段：
初始标记、并发标记、重新标记、并发清理
初始标记
会让线程全部停止，也就是 Stop the World 状态
并发标记：
对所有的对象进行追踪，这个阶段最耗费时。但这个阶段是和系统并发运行的，所以不会对系统运行造成影响
重新标记：
由于第二阶段是并发执行的，一边标记垃圾对象，一边创建新对象，老对象会变成垃圾对象。 所以第三阶段也会进入 Stop the World 状态，并且重新标记，标记的是第二阶段中变动过的少数对象，所以运行速度很快
并发清理：
这个阶段也是会耗费很多时间，但由于是并发运行的，所以对系统不会造成很大的影响
CMS采用 标记-清理 的算法，标记出垃圾对象，清除垃圾对象。算法是基于老年代执行的，因为新生代产生无法接受该算法产生的碎片垃圾。
优点：并发收集，低停顿
不足：
- 无法处理浮动垃圾，并发收集会造成内存碎片过多
- 由于并发标记和并发清理阶段都是并发执行，所以会额外消耗CPU资源
G1回收垃圾的4个阶段
初始标记、并发标记、最终标记、筛选回收
初始标记：
标记GC Roots 可以直接关联的对象，该阶段需要线程停顿但是耗时短
并发标记：
寻找存活的对象，可以与其他程序并发执行，耗时较长
最终标记：
并发标记期间用户程序会导致标记记录产生变动（好比一个阿姨一边清理垃圾，另一个人一边扔垃圾）虚拟机会将这段时间的变化记录在Remembered Set Logs 中。最终标记阶段会向Remembered Set合并并发标记阶段的变化。这个阶段需要线程停顿，也可以并发执行
筛选回收：
对每个Region的回收成本进行排序，按照用户自定义的回收时间来制定回收计划
控制G1回收垃圾的时间
-XX:MaxGCPauseMillis=200 （默认200ms）
G1和CMS相比，有几个特点：
- 控制回收垃圾的时间：这个是G1的优势，可以控制回收垃圾的时间，还可以建立停顿的时间模型，选择一组合适的Regions作为回收目标，达到实时收集的目的
- 空间整理：和CMS一样采用标记-清理的算法，但是G1不会产生空间碎片，这样就有效的使用了连续空间，不会导致连续空间不足提前造成GC的触发
- 对大对象的处理。在CMS内存中，如果一个对象过大，进入S1、S2区域的时候大于改分配的区域，对象会直接进入老年代。G1处理大对象时会判断对象是否大于一个Region大小的50%，如果大于50%就会横跨多个Region进行存放
什么情况下应该考虑使用G1
- 实时数据占用超过一半的堆空间
- 对象分配或者晋升的速度变化大
- 希望消除长时间的GC停顿（超过0.5-1秒）
Remark
pre-write barrier + satb_mark_queue
并发标记时，对象处理状态
黑色：处理完成
灰色：正在处理当中
白色：尚未处理
没箭头：当成垃圾
当对象引用发生改变，JVM给该对象加入一个写屏障。
写屏障指令会将 C （A）并变为灰色 加入一个队列中，并发标记结束后，进入重新标记，会将队列中的对象处理
JDK 8u20 字符串去重
优点
节省大量内存
缺点
略微多占用了 cpu 是时间，新生代回收时间略微增加
开启
-XX:+UseStringDeduplication
String s1 = new String("hello"); //char[] {'h','e','l','l','o'}
String s2 = new String("hello"); //char[] {'h','e','l','l','o'}- 将所有新分配的字符串放入一个队列
- 当新生代回收时，G1 并发检查是否有字符串重复
- 如果它们值一样，让他们引用同一个char[]
注意，与 String.intern() 不一样
- String.intern()关注的是字符串对象
- 而字符串去重关注的是char[]
- 在 JVM 内部，使用了不同的字符串表
JDK 8u40 并发标记类卸载
所有对象都经过并发标记后，就能知道哪些类不再被使用，当一个类加载器的所有类都不再使用，则卸载它所加载的所有类
-XX:+ClassUnloadingWithConcurrentMark默认启用
JDK 8u60 回收巨型对象
一个对象大于 region 的一半时，称之为巨型对象
G1 不会对巨型对象进行拷贝
回收时被优先考虑
G1会跟踪老年代所有 incoming 引用，这样老年代 incoming 引用为0的巨型对象就可以在新生代垃圾回收时处理掉
JDK 9 并发标记起始时间的调整
并发标记必须在堆空间沾满前完成，否则退化为 FullGC
jdk9 之前需要使用 -XX:InitiatingHeapOccupancyPercent
jdk9可以动态调整
-XX:InitiatingHeapOccupancyPercent用来设置初始值- 进行数据采样并动态调整
- 总会添加一个安全的空档空间
GC调优
查看运行参数
java -XX:+PrintCommandLineFlags"jdk\bin\java -XX:+PrintFlagsFinal" -version | findstr "GC"调优领域
内存
锁竞争
cpu占用
IO
确定目标
低延迟还是高吞吐量，选择合适的回收器
- CMS
- G1
- ZGC
- ParallelGC
- Zing
最快的GC是不发生GC
查看 Full GC 前后的内存占用，考虑下面几个问题
- 数据是不是过多
数据表示是否太臃肿
- 对象图
- 对象大小
- 是否存在内存泄露
新生代调优
新生代的特点
所有的new操作的内存分配分厂廉价
- TLAB thread-local allocation buffer
- 死亡对象的回收代价是零
- 大部分对象用过即死
- Minor GC 的时间远远低于 Full GC
新生代越大，老年代越小。会导致老年代内存过小触发 Full GC，时间会比 Minor GC 时间更长。
建议
新生代为大于堆的 25%，小于堆的 50%。
新生代的垃圾回收主要是 复制 算法，复制也有标记过程。主要是复制过程，即使新生代很大也不会减少垃圾回收的时间。
幸存区大到能保留 当前活跃对象 + 需要晋升对象
优化
晋升阈值配置得当，让长时间存活对象尽快晋升
-XX:MaxTenuringThreshold=threshold
-XX:+PrintTenuringDistribution
老年代调优
以 CMS 为例
CMS 的老年代内存大一点好
如果并发标记过程中，产生浮动垃圾，如果此时内存不够，会退化成串行垃圾回收，SWT时间特别长。
如果没有发生 Full GC，说明程序不需要调优，否则先尝试调优新生代
观察发生 Full GC 时老年代内存占用，将老年代内存预设调大 1/4 - 1/3
-XX:CMSInitiatingOccupancyFraction=percent 老年代空间占用 占 老年代总体的多少时触发 CMS
调优案例
1、Full GC 和 Minor GC频繁
Full GC 频繁是因为老年代内存不足，新生代源源不断向老年代晋升。解决：增加新生代内存，幸存区内存，提高晋升阈值
2、请求高峰期发生 Full GC，单次暂停时间特别长 (CMS)
查看日志，应是发生在重新标记时期。
-XX:+CMSScavengeBeforeRemark重新标记前先进行一次垃圾回收
类加载与字节码
类文件结构
字节码指令
基础指令
javap工具
自己分析类文件结构十分复杂，利用javap工具来反编译 class 文件
javap -v HelloWorld.class -v 参数会输出详细信息
Classfile /D:/java项目/面试题/InterviewQuestions/target/classes/com/zmz/jvm/HelloWorld.class
Last modified 2022年6月21日; size 587 bytes
SHA-256 checksum 0d68484a029be065fc8077decf230d346f754e32335f8c0998ebc6c8185f75dd
Compiled from "HelloWorld.java"
public class com.zmz.jvm.HelloWorld
minor version: 0
major version: 52 // jdk版本8
flags: (0x0021) ACC_PUBLIC, ACC_SUPER
this_class: #5 // com/zmz/jvm/HelloWorld
super_class: #6 // java/lang/Object
interfaces: 0, fields: 0, methods: 2, attributes: 1
Constant pool:
#1 = Methodref #6.#21 // java/lang/Object."<init>":()V
#2 = Fieldref #22.#23 // java/lang/System.out:Ljava/io/PrintStream;
#3 = String #24 // hello world
#4 = Methodref #25.#26 // java/io/PrintStream.println:(Ljava/lang/String;)V
#5 = Class #27 // com/zmz/jvm/HelloWorld
#6 = Class #28 // java/lang/Object
#7 = Utf8 <init>
#8 = Utf8 ()V
#9 = Utf8 Code
#10 = Utf8 LineNumberTable
#11 = Utf8 LocalVariableTable
#12 = Utf8 this
#13 = Utf8 Lcom/zmz/jvm/HelloWorld;
#14 = Utf8 main
#15 = Utf8 ([Ljava/lang/String;)V
#16 = Utf8 args
#17 = Utf8 [Ljava/lang/String;
#18 = Utf8 MethodParameters
#19 = Utf8 SourceFile
#20 = Utf8 HelloWorld.java
#21 = NameAndType #7:#8 // "<init>":()V
#22 = Class #29 // java/lang/System
#23 = NameAndType #30:#31 // out:Ljava/io/PrintStream;
#24 = Utf8 hello world
#25 = Class #32 // java/io/PrintStream
#26 = NameAndType #33:#34 // println:(Ljava/lang/String;)V
#27 = Utf8 com/zmz/jvm/HelloWorld
#28 = Utf8 java/lang/Object
#29 = Utf8 java/lang/System
#30 = Utf8 out
#31 = Utf8 Ljava/io/PrintStream;
#32 = Utf8 java/io/PrintStream
#33 = Utf8 println
#34 = Utf8 (Ljava/lang/String;)V
{
public com.zmz.jvm.HelloWorld();
descriptor: ()V
flags: (0x0001) ACC_PUBLIC
Code:
stack=1, locals=1, args_size=1
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return
LineNumberTable:
line 8: 0
LocalVariableTable:
Start Length Slot Name Signature
0 5 0 this Lcom/zmz/jvm/HelloWorld;
public static void main(java.lang.String[]);
descriptor: ([Ljava/lang/String;)V
flags: (0x0009) ACC_PUBLIC, ACC_STATIC
Code:
stack=2, locals=1, args_size=1
0: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream;
3: ldc #3 // String hello world
5: invokevirtual #4 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
8: return
LineNumberTable:
line 10: 0
line 11: 8
LocalVariableTable:
Start Length Slot Name Signature
0 9 0 args [Ljava/lang/String;
MethodParameters:
Name Flags
args
}
SourceFile: "HelloWorld.java"
图解流程
原始java代码
public class demo {
public static void main(String[] args) {
int a = 10;
int b = Short.MAX_VALUE + 1;
int c = a + b;
System.out.println(c);
}
}编译后的字节码
Last modified 2022年7月2日; size 673 bytes
SHA-256 checksum 5149dd9082bcc94ba21a3f7317a52f06a3eb552daa41c082abf27446a3066070
Compiled from "IllustrationProcess.java"
public class com.zmz.jvm.IllustrationProcess
minor version: 0
major version: 52
flags: (0x0021) ACC_PUBLIC, ACC_SUPER
this_class: #6 // com/zmz/jvm/IllustrationProcess
super_class: #7 // java/lang/Object
interfaces: 0, fields: 0, methods: 2, attributes: 1
Constant pool:
#1 = Methodref #7.#26 // java/lang/Object."<init>":()V
#2 = Class #27 // java/lang/Short
#3 = Integer 32768
#4 = Fieldref #28.#29 // java/lang/System.out:Ljava/io/PrintStream;
#5 = Methodref #30.#31 // java/io/PrintStream.println:(I)V
#6 = Class #32 // com/zmz/jvm/IllustrationProcess
#7 = Class #33 // java/lang/Object
#8 = Utf8 <init>
#9 = Utf8 ()V
#10 = Utf8 Code
#11 = Utf8 LineNumberTable
#12 = Utf8 LocalVariableTable
#13 = Utf8 this
#14 = Utf8 Lcom/zmz/jvm/IllustrationProcess;
#15 = Utf8 main
#16 = Utf8 ([Ljava/lang/String;)V
#17 = Utf8 args
#18 = Utf8 [Ljava/lang/String;
#19 = Utf8 a
#20 = Utf8 I
#21 = Utf8 b
#22 = Utf8 c
#23 = Utf8 MethodParameters
#24 = Utf8 SourceFile
#25 = Utf8 IllustrationProcess.java
#26 = NameAndType #8:#9 // "<init>":()V
#27 = Utf8 java/lang/Short
#28 = Class #34 // java/lang/System
#29 = NameAndType #35:#36 // out:Ljava/io/PrintStream;
#30 = Class #37 // java/io/PrintStream
#31 = NameAndType #38:#39 // println:(I)V
#32 = Utf8 com/zmz/jvm/IllustrationProcess
#33 = Utf8 java/lang/Object
#34 = Utf8 java/lang/System
#35 = Utf8 out
#36 = Utf8 Ljava/io/PrintStream;
#37 = Utf8 java/io/PrintStream
#38 = Utf8 println
#39 = Utf8 (I)V
{
public com.zmz.jvm.IllustrationProcess();
descriptor: ()V
flags: (0x0001) ACC_PUBLIC
Code:
stack=1, locals=1, args_size=1
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return
LineNumberTable:
line 7: 0
LocalVariableTable:
Start Length Slot Name Signature
0 5 0 this Lcom/zmz/jvm/IllustrationProcess;
public static void main(java.lang.String[]);
descriptor: ([Ljava/lang/String;)V
flags: (0x0009) ACC_PUBLIC, ACC_STATIC
Code:
stack=2, locals=4, args_size=1
0: bipush 10
2: istore_1
3: ldc #3 // int 32768
5: istore_2
6: iload_1
7: iload_2
8: iadd
9: istore_3
10: getstatic #4 // Field java/lang/System.out:Ljava/io/PrintStream;
13: iload_3
14: invokevirtual #5 // Method java/io/PrintStream.println:(I)V
17: return
LineNumberTable:
line 9: 0
line 10: 3
line 11: 6
line 12: 10
line 13: 17
LocalVariableTable:
Start Length Slot Name Signature
0 18 0 args [Ljava/lang/String;
3 15 1 a I
6 12 2 b I
10 8 3 c I
MethodParameters:
Name Flags
args
}
SourceFile: "IllustrationProcess.java"
常量池载入运行时常量池
没超过范围的常量 不会存到运行时常量池
方法字节码载入方法区
main 线程开始运行，分配栈帧内存
栈帧绿色部分代表 局部变量表
栈帧蓝色部分代表 操作数栈
bipush 10
将一个 byte 压入操作数栈 (其长度会补齐4个字节)
sipush 将一个 short 压入操作数栈 (其长度会补齐4个字节)
ldc 将一个 int 压入操作数栈
ldc2_w 将一个 long 压入操作数栈 (分两次压入，因为 long 是8个字节)
这里小的数字都是和字节码指令存在一起，超过 short 范围的数字存入了常量池
istore_1
将操作数栈顶数据弹出，存入局部变量表的 slot 1
ldc #3
从常量池加载 #3 数据到操作数栈
注意 Short.MAX_VALUE 是 32767，所以 32768 实际是在编译期间计算好的
istore_2
iload_1
iLoad_2
iadd
istore_3
getstatic #4
iload_3
invokevirtual #5
找到常量池 #5 项
定位到方法区 java/io/PrintStream.println:(I)V方法
生成新的栈帧(分配 locals、stack等)
传递参数，执行新栈帧中的字节码
执行完毕，弹出栈帧
清除 main 操作数栈内容
return
完成 main 方法调用，弹出 main栈帧
程序结束
变量存储
局部变量：在方法体里面定义的变量，该变量会在程序执行到方法体时被初始化，存储在栈内存中。
成员变量：类体之内，方法体之外定义的变量，它又分为实例变量和静态变量。
实例变量：没有被static修饰的成员变量，实例变量是对象所拥有的，在创建对象时被初始化，存储在堆内存中。
静态变量：被static修饰的成员变量，静态变量是被所有对象共享的，在类加载时会被初始化，存储在方法区中。
分析 i++
静态变量是放在操作数栈上执行的！
题目
public class i {
public static void main(String[] args) {
int a = 10;
int b = a++ + ++a + a--;
System.out.println(a);
System.out.println(b);
}
}字节码
Last modified 2022年7月2日; size 594 bytes
SHA-256 checksum 07378ac83f91ab95203a9b76f0b376bfabc3e3eb0f15177bd22337aa8e83f1fc
Compiled from "i.java"
public class com.zmz.jvm.i
minor version: 0
major version: 52
flags: (0x0021) ACC_PUBLIC, ACC_SUPER
this_class: #4 // com/zmz/jvm/i
super_class: #5 // java/lang/Object
interfaces: 0, fields: 0, methods: 2, attributes: 1
Constant pool:
#1 = Methodref #5.#23 // java/lang/Object."<init>":()V
#2 = Fieldref #24.#25 // java/lang/System.out:Ljava/io/PrintStream;
#3 = Methodref #26.#27 // java/io/PrintStream.println:(I)V
#4 = Class #28 // com/zmz/jvm/i
#5 = Class #29 // java/lang/Object
#6 = Utf8 <init>
#7 = Utf8 ()V
#8 = Utf8 Code
#9 = Utf8 LineNumberTable
#10 = Utf8 LocalVariableTable
#11 = Utf8 this
#12 = Utf8 Lcom/zmz/jvm/i;
#13 = Utf8 main
#14 = Utf8 ([Ljava/lang/String;)V
#15 = Utf8 args
#16 = Utf8 [Ljava/lang/String;
#17 = Utf8 a
#18 = Utf8 I
#19 = Utf8 b
#20 = Utf8 MethodParameters
#21 = Utf8 SourceFile
#22 = Utf8 i.java
#23 = NameAndType #6:#7 // "<init>":()V
#24 = Class #30 // java/lang/System
#25 = NameAndType #31:#32 // out:Ljava/io/PrintStream;
#26 = Class #33 // java/io/PrintStream
#27 = NameAndType #34:#35 // println:(I)V
#28 = Utf8 com/zmz/jvm/i
#29 = Utf8 java/lang/Object
#30 = Utf8 java/lang/System
#31 = Utf8 out
#32 = Utf8 Ljava/io/PrintStream;
#33 = Utf8 java/io/PrintStream
#34 = Utf8 println
#35 = Utf8 (I)V
{
public com.zmz.jvm.i();
descriptor: ()V
flags: (0x0001) ACC_PUBLIC
Code:
stack=1, locals=1, args_size=1
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return
LineNumberTable:
line 7: 0
LocalVariableTable:
Start Length Slot Name Signature
0 5 0 this Lcom/zmz/jvm/i;
public static void main(java.lang.String[]);
descriptor: ([Ljava/lang/String;)V
flags: (0x0009) ACC_PUBLIC, ACC_STATIC
Code:
stack=2, locals=3, args_size=1
0: bipush 10
2: istore_1
3: iload_1
4: iinc 1, 1
7: iinc 1, 1
10: iload_1
11: iadd
12: iload_1
13: iinc 1, -1
16: iadd
17: istore_2
18: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream;
21: iload_1
22: invokevirtual #3 // Method java/io/PrintStream.println:(I)V
25: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream;
28: iload_2
29: invokevirtual #3 // Method java/io/PrintStream.println:(I)V
32: return
LineNumberTable:
line 9: 0
line 10: 3
line 11: 18
line 12: 25
line 13: 32
LocalVariableTable:
Start Length Slot Name Signature
0 33 0 args [Ljava/lang/String;
3 30 1 a I
18 15 2 b I
MethodParameters:
Name Flags
args
}
SourceFile: "i.java"分析
注意 iinc 指令是直接在局部变量 slot 上进行运算
a++ 和 ++a 的区别是先执行 iload 还是 先执行 iinc
条件判断指令
byte、short、char 都会按 int 比较，因为操作数栈都是4字节
goto 用来进行跳转到指定行号的字节码
循环控制指令
while 和 for 的字节码，是一模一样的
x++判断结果
x++ 先 iload 进 操作数栈 中，然后 局部变量表 中将 x + 1。
最后执行赋值操作，将 0 赋值给 1。
最终结果还是 0。
构造方法
静态代码块在类加载时执行，且只执行一次(在main方法之前执行)。
cinit
public class demo {
static int i = 10;
static {
i = 20;
}
static {
i = 30;
}
}编译器会按从上至下的顺序，收集所有 static 静态代码块和静态成员复制的代码，合并为一个特殊的方法<cinit>( )V
Code:
stack=1, locals=0, args_size=0
0: bipush 10
2: putstatic #2 // Field i:I
5: bipush 20
7: putstatic #2 // Field i:I
10: bipush 30
12: putstatic #2 // Field i:I
15: return
<cinit>( )V 方法会在类加载的初始化阶段被调用
init
实例代码块并未在类加载时执行，只要是构造方法执行(创建对象时)，一定会在构造方法执行之前执行实例代码块。
public class Init {
private String a = "s1";
{
b = 20;
}
private int b = 10;
{
a = "s2";
}
public Init(String a, int b) {
this.a = a;
this.b = b;
}
public static void main(String[] args) {
Init i = new Init("s3", 30);
System.out.println(i.a);
System.out.println(i.b);
}
}编译器会按从上至下的顺序，收集所有{}代码块和成员变量赋值的代码，形成新的构造方法，但原始构造方法内的代码总是在最后
public com.zmz.jvm.Int_demo(java.lang.String, int);
descriptor: (Ljava/lang/String;I)V
flags: (0x0001) ACC_PUBLIC
Code:
stack=2, locals=3, args_size=3
0: aload_0 // 加载this
1: invokespecial #1 // 父类Method java/lang/Object."<init>":()V
4: aload_0
5: ldc #2 // String s1
7: putfield #3 // Field a:Ljava/lang/String;
10: aload_0
11: bipush 20
13: putfield #4 // Field b:I
16: aload_0
17: bipush 10
19: putfield #4 // Field b:I
22: aload_0
23: ldc #5 // String s2
25: putfield #3 // Field a:Ljava/lang/String;
28: aload_0
29: aload_1
30: putfield #3 // Field a:Ljava/lang/String;
33: aload_0
34: iload_2
35: putfield #4 // Field b:I
38: return
LocalVariableTable:
Start Length Slot Name Signature
0 39 0 this Lcom/zmz/jvm/Int_demo;
0 39 1 a Ljava/lang/String;
0 39 2 b I方法调用
public class MethodCall {
public MethodCall(){};
private void test1(){};
private final void test2(){};
private void test3(){};
public static void test4(){};
public static void main(String[] args) {
MethodCall m = new MethodCall();
m.test1();
m.test2();
m.test3();
m.test4();
MethodCall.test4();
}
} public static void main(java.lang.String[]);
descriptor: ([Ljava/lang/String;)V
flags: (0x0009) ACC_PUBLIC, ACC_STATIC
Code:
stack=2, locals=2, args_size=1
0: new #2 // class com/zmz/jvm/MethodCall
3: dup
4: invokespecial #3 // Method "<init>":()V
7: astore_1
8: aload_1
9: invokespecial #4 // Method test1:()V
12: aload_1
13: invokespecial #5 // Method test2:()V
16: aload_1
17: invokevirtual #6 // Method test3:()V
20: aload_1 // 静态方法不需要对象
21: pop // 从栈中弹出
22: invokestatic #7 // Method test4:()V
25: invokestatic #7 // Method test4:()V
28: return
invokevirtual 是动态执行public方法，因为不确定此方法是否重写。多态调用
多态原理
**
* 禁用指针压缩
* -XX:-UseCompressedOops -XX:-UseCompressedClassPointers
*/
public class Polymorphism_demo1 {
public static void test(Animal animal) {
animal.eat();
System.out.println(animal.toString());
}
public static void main(String[] args) throws IOException {
test(new Cat());
test(new Dog());
System.in.read();
}
}
abstract class Animal {
public abstract void eat();
@Override
public String toString() {
return "我是" + this.getClass().getSimpleName();
}
}
class Dog extends Animal {
@Override
public void eat() {
System.out.println("我是狗，吃粮食");
}
}
class Cat extends Animal {
@Override
public void eat() {
System.out.println("我是猫，吃鱼");
}
}利用 HSDB 工具 根据进程 id 查看
java -cp ./lib/sa-jdi.jar sun.jvm.hotspot.HSDB
当执行 invokevirtual 指令时，
- 先通过栈帧中的对象引用找到对象
- 分析对象头(有8个字节)，找到对象的实际 class
- class 结构中有 vtable，它在类加载的链接阶段就已经根据方法的重写规则生成好了
- 查表得到方法的具体地址
- 执行方法的字节码
异常处理
try
public static void main(java.lang.String[]);
descriptor: ([Ljava/lang/String;)V
flags: ACC_PUBLIC, ACC_STATIC
Code:
stack=1, locals=3, args_size=1
0: iconst_0
1: istore_1
2: bipush 10
4: istore_1
5: goto 12
8: astore_2
9: bipush 20
11: istore_1
12: return
Exception table:
from to target type
2 5 8 Class java/lang/Exception
LocalVariableTable:
Start Length Slot Name Signature
9 3 2 e Ljava/lang/Exception;
0 13 0 args [Ljava/lang/String;
2 11 1 i I
Exception table 结构，前必后开的范围，一旦这个范围内的字节码执行出现异常，则通过 type 匹配异常类型，如果一致，进入 target 所指示行号
8行的字节码指令 astore_2 是将异常对象引用存入局部变量表的 slot2 位置
多个catch
若多个 catch ，但只能进入 Exception table 中的一个分支，所以局部变量表 slot 2 位置被共用
finally
public class Exception_finally {
public static void main(String[] args) {
int i = 0;
try {
i = 10;
} catch (Exception e) { // 可能有平级异常 或 error
i = 20;
} finally {
i = 30;
}
}
}public static void main(java.lang.String[]);
descriptor: ([Ljava/lang/String;)V
flags: ACC_PUBLIC, ACC_STATIC
Code:
stack=1, locals=4, args_size=1
0: iconst_0
1: istore_1
2: bipush 10
4: istore_1
5: bipush 30 // finally
7: istore_1 // i = 30
8: goto 27
11: astore_2
12: bipush 20
14: istore_1
15: bipush 30 // finally
17: istore_1 // i = 30
18: goto 27
21: astore_3 // catch any
22: bipush 30 // finally
24: istore_1
25: aload_3
26: athrow
27: return
Exception table:
from to target type
2 5 11 Class java/lang/Exception
2 5 21 any
11 15 21 any
LineNumberTable:finally 中的代码被复制了3份，分别放入 try 流程，catch 流程以及 catch 剩余的异常类型流程
面试题
1、finally 出现 return
public class Finally_demo1 {
public static void main(String[] args) {
int result = test();
System.out.println(result);
}
public static int test() {
try {
return 10;
} finally {
return 20;
}
}
}public static int test();
descriptor: ()I
flags: ACC_PUBLIC, ACC_STATIC
Code:
stack=1, locals=2, args_size=0
0: bipush 10 // 10 放入栈顶
2: istore_0 // 10 -> slot 0 从栈顶移除 (存到 slot 0 中)
3: bipush 20 // 20 放入栈顶
5: ireturn // 返回 20
6: astore_1 // catch any -> slot 1 从栈顶移除
7: bipush 20 // 20 放入栈顶
9: ireturn // 返回栈顶 20
Exception table:
from to target type
0 3 6 any跟上个例子的 finally相比，发现没有 athrow 了。意味着：如果在 finally 中出现了 return，会吞掉异常。
public class Finally_demo1 {
public static void main(String[] args) {
int result = test();
System.out.println(result);
}
public static int test() {
try {
int i = 1 / 0;
} finally {
return 20;
}
}
}2、finally 对返回值影响
public class Finally_demo2 {
public static void main(String[] args) {
int result = test();
System.out.println(result);
}
public static int test() {
int i = 10;
try {
return i; //
} finally {
i = 20;
}
}
} public static int test();
descriptor: ()I
flags: ACC_PUBLIC, ACC_STATIC
Code:
stack=1, locals=3, args_size=0
0: bipush // 放入操作数栈中 10
2: istore_0 // 出栈 存到 slot 0 位置
3: iload_0 // 从 slot 0 位置加载到操作数栈
4: istore_1 // 10 -> slot 1,暂存，目的是为了固定返回值
5: bipush 20
7: istore_0
8: iload_1 // slot 1 暂存的值 加载到操作数栈中
9: ireturn // 返回 10
10: astore_2
11: bipush 20
13: istore_0
14: aload_2
15: athrow
Exception table:
from to target type
3 5 10 any编译期处理
所谓的语法糖，其实就是指 java 编译器把 .java 源代码编译为 .class 字节码的过程中，自动生成和转换的一些代码，主要是为了减轻程序员的负担。
默认构造器
public class Candy1 {
}编译器替我们生成
public class Candy1 {
public Candy1 {
super(); // 调用父类 Object 的无参构造方法，即调用 java/lang/Object."<init>":()V
}
}自动拆装箱
public class Candy2 {
public static void main(String[] args) {
Integer x = 1;
int y = x;
}
}jdk 5 以前是无法编译成功的
public class Candy2 {
public static void main(String[] args) {
Integer x = Integer.valueOf(1);
int y = x.intValue();
}
}jdk 5 以后都有编译器在编译阶段完成
泛型集合取值
jdk 5 以后加入的特性，但 java 在编译泛型代码后会执行 泛型擦除 的动作，即泛型信息在编译为字节码以后就丢失了，实际的类型都当做了 Object 类型来处理。
public class Candy2 {
public static void main(String[] args) {
List<Integer> list = new ArrayList<>();
list.add(10); // 实际调用的是 List.add(Object e)
Integer x = list.get(0); // 实际调用的是 Object obj = List.get(int index)
}
}在取值时，编译器真正生成的字节码中，还要额外做一个类型转换的操作：
Integer x = (Integer)list.get(0);如果前面的 x 变量类型修改为 int 基本类型那么最终生成嗯对字节码是：
int x = ((Integer)list.get(0)).intValue();还好这些麻烦事都不用自己做
擦除的是字节码上的泛型信息，可以看到 LocalVariableTypeTable 仍然保留了方法参数泛型的信息
使用反射，仍然能够获得这些信息：
/**
* @author 张明泽
* Create by 2022/7/6 17:05
*/
public class Candy3 {
/**
* 利用反射获取泛型类型
*
* @param args
* @throws NoSuchMethodException
*/
public static void main(String[] args) throws NoSuchMethodException {
Method test = Candy3.class.getMethod("test", List.class, Map.class);
Type[] types = test.getGenericParameterTypes();
for (Type type : types) {
if (type instanceof ParameterizedType) {
ParameterizedType parameterizedType = (ParameterizedType) type;
System.out.println("原始类型：" + parameterizedType.getRawType());
Type[] actualTypeArguments = parameterizedType.getActualTypeArguments();
for (Type actualTypeArgument : actualTypeArguments) {
System.out.println("泛型参数" + actualTypeArgument);
}
}
}
}
public Set<Integer> test(List<String> list, Map<Integer, Object> map) {
return null;
}
}原始类型：interface java.util.List
泛型参数class java.lang.String
原始类型：interface java.util.Map
泛型参数class java.lang.Integer
泛型参数class java.lang.Object可变参数
public class Candy4 {
public static void foo(String... args) {
String[] array = args; // 直接赋值
System.out.println(array);
}
}可变参数 String... args 其实是一个 String[] args，从代码中的复制语句中就可以看出来。
同样 java 编译器会在编译期间将 String... args 变为 String[] args
数组的循环
public class Candy5 {
public static void main(String[] args) {
int[] array = {1,2,3,4,5};
for (int e : array) {
System.out.println(e);
}
}
}会被编译器转换为
public class Candy5 {
public Candy5(){};
public static void foo(String[] args) {
int[] array = {1,2,3,4,5};
for (int i = 0; i < array.length; i++) {
int e = array[i];
System.out.println(e);
}
}
}foreach 循环
集合
public class Candy5_2 {
public static void main(String[] args) {
List<Integer> list = Arrays.asList(1,2,3,4,5);
for (Integer i : list) {
System.out.println(i);
}
}
}会被编译器转换为
public class Candy5_2 {
public Candy5_2(){};
public static void main(String[] args) {
List<Integer> list = Arrays.asList(1,2,3,4,5);
Iterator iter = list.iterator();
while (iter.hasNext()) {
Integer e = (Integer)iter.next();
System.out.println(e);
}
}
}switch 字符串
会执行两遍 switch，第一遍是根据字符串的 hashCode 和 equals 将字符串的转换为相应 byte 类型 ，第二遍才是利用 byte 执行进行比较。
hashCode 是为了提高效率，减少可能的比较；而 equals 是为了防止 hashCode 冲突，例如 BM 和 C。这两个字符串的 hashCode 值都是 2123
public static void choose(String str) {
switch (str) {
case "hello": {
System.out.println("h");
}
case "world": {
System.out.println("w");
break;
}
}
}public static void choose(String str) {
byte x = -1;
switch (str.hashCode()) {
case 99162322: {
if (str.equals("hello")) {
x = 0;
}
}
case 113318802: {
if (str.equals("wrold")) {
x = 1;
}
}
}
switch (x) {
case 0:
System.out.println("h");
break;
case 1:
System.out.println("h");
}
}switch 枚举
定义一个合成类 (JVM来使用)
会定义一个整数数组
static int[] map = new int[2];
static {
map[Sex.MALE.ordinal()] = 1; // ordinal()枚举编号
map[Sex.MALE.ordinal()] = 2;
}
// 取值
public static void foo(Sex sex) {
int x = $MAP.map[sex.ordinal()];
switch (x) {
case 1:
System.out.println("男");
break;
case 2:
System.out.println("女");
break;
}
}枚举类
jdk 7 新增枚举类
enum Sex {
MALE, FEMALE
}转换后
public final class Sex extends Enum<Sex> {
public static final Sex MALE;
public static final Sex FEMALE;
private static final Sex[] $VALUES;
static {
MALE = new Sex("MALE", 0);
FEMALE = new Sex("FEMALE", 1);
$VALUES = new Sex[]{MALE, FEMALE};
}
/**
* Sole constructor. Programmers cannot invoke this constructor.
* It is for use by code emitted by the compiler in response to
* enum type declarations.
*
* @param name - The name of this enum constant, which is the identifier
* used to declare it.
* @param ordinal - The ordinal of this enumeration constant (its position
* in the enum declaration, where the initial constant is
assigned
*/
private Sex(String name, int ordinal) {
super(name, ordinal);
}
public static Sex[] values() {
return $VALUES.clone();
}
public static Sex valueOf(String name) {
return Enum.valueOf(Sex.class, name);
}
}try-with-resources
JDK 7 开始新增了对需要关闭的资源处理的特殊语法 try-with-resources
try(资源变量 = 创建资源对象){
} catch() {
}其中资源对象需要实现 AutoCloseable 接口，例如 InputStream 、 OutputStream 、Connection 、 Statement 、 ResultSet 等接口都实现了 AutoCloseable ，使用 try-with-
resources 可以不用写 finally 语句块，编译器会帮助生成关闭资源代码，例如：
public class Candy9 {
public static void main(String[] args) {
try(InputStream is = new FileInputStream("d:\\1.txt")) {
System.out.println(is);
} catch (IOException e) {
e.printStackTrace();
}
}
}public class Candy9 {
public Candy9() {
}
public static void main(String[] args) {
try {
InputStream is = new FileInputStream("d:\\1.txt");
Throwable t = null;
try {
System.out.println(is);
} catch (Throwable e1) {
// t 是我们代码出现的异常
t = e1;
throw e1;
} finally {
// 判断了资源不为空
if (is != null) {
// 如果我们代码有异常
if (t != null) {
try {
is.close();
} catch (Throwable e2) {
// 如果 close 出现异常，作为被压制异常添加
t.addSuppressed(e2);
}
}
else {
// 如果我们代码没有异常，close 出现的异常就是最后 catch 块中的 e
is.close();
}
}
}
} catch (IOException e) {
e.printStackTrace();
}
}
}为什么要设计一个 addSuppressed(Throwable e) （添加被压制异常）的方法呢？是为了防止异常信
息的丢失（想想 try-with-resources 生成的 fianlly 中如果抛出了异常）
方法重写时的桥接方法
方法重写时对返回值分两种情况：
- 父子类的返回值完全一致
- 子类返回值可以是父类返回值的子类（比较绕口，见下面的例子）
class A {
public Number m() {
return 1;
}
}
class B extends A {
@Override
// 子类 m 方法的返回值是 Integer 是父类 m 方法返回值 Number 的子类
public Integer m() {
return 2;
}
}对于子类，java 编译器会做如下处理：
class B extends A {
public Integer m() {
return 2;
}
// 此方法才是真正重写了父类 public Number m() 方法
public synthetic bridge Number m() {
// 调用 public Integer m()
return m();
}
}匿名异步类
public class Candy11 {
public static void main(String[] args) {
Runnable runnable = new Runnable() {
@Override
public void run() {
System.out.println("ok");
}
};
}
}转换
final class Candy11$1 implements Runnable {
Candy11$1() {
}
public void run() {
System.out.println("ok");
}
}
public class Candy11 {
public static void main(String[] args) {
Runnable runnable = new Candy11$1();
}
}类加载阶段
加载
将类的字节码载入方法区中，内部采用 C++ 的 instanceKlass 描述 java 类，它的重要 field 有：
- _java_mirror 即 java 的类镜像，例如对 String 来说，就是 String.class，作用是把 klass 暴
- 露给 java 使用
- _super 即父类
- _fields 即成员变量
- _methods 即方法
- _constants 即常量池
- _class_loader 即类加载器
- _vtable 虚方法表
- _itable 接口方法表
如果这个类还有父类没有加载，先加载父类
加载和链接可能是交替运行的
instanceKlass 这样的【元数据】是存储在方法区（1.8 后的元空间内），但 _java_mirror
是存储在堆中
可以通过前面介绍的 HSDB 工具查看
链接
验证
验证类是否符合 JVM规范，安全性检查
用 UE 等支持二进制的编辑器修改 HelloWorld.class 的魔数，在控制台运行
准备
为 static 变量分配空间，设置默认值
- static 变量在 JDK 7 之前存储于 instanceKlass 末尾，从 JDK 7 开始，存储于 _java_mirror(堆) 末尾
- static 变量
分配空间和赋值是两个步骤，分配空间在准备阶段完成，赋值在初始化阶段完成 - 如果 static 变量是 final 的基本类型，以及字符串常量，那么编译阶段值就确定了，赋值在准备阶段完成
- 如果 static 变量是 final 的，但属于引用类型，那么赋值也会在初始化阶段完成
解析
将常量池中的符号引用解析为直接引用
public class Load2 {
public static void main(String[] args) throws ClassNotFoundException, IOException {
ClassLoader classloader = Load2.class.getClassLoader();
// loadClass 方法不会导致类的解析和初始化
Class<?> c = classloader.loadClass("cn.itcast.jvm.t3.load.C");
// new C();
System.in.read();
}
}
class C {
D d = new D();
}
class D {
}初始化
<clinit>()V 方法
初始化即调用 <clinit>()V ，虚拟机会保证这个类的『构造方法』的线程安全
发生的时机
概括得说，类初始化是【懒惰的】
- main 方法所在的类，总会被首先初始化
- 首次访问这个类的静态变量或静态方法时
- 子类初始化，如果父类还没初始化，会引发
- 子类访问父类的静态变量，只会触发父类的初始化
- Class.forName
- new 会导致初始化
不会导致类初始化的情况
- 访问类的 static final 静态常量（基本类型和字符串）不会触发初始化 (包装类型)会触发
- 类对象.class 不会触发初始化
- 创建该类的数组不会触发初始化
- 类加载器的 loadClass 方法
- Class.forName 的参数 2 为 false 时
应用
final class Singleton {
static {
System.out.println("Singleton init");
}
private Singleton() {
}
public static void test() {
System.out.println("Singleton test");
}
// 内部类中保存单例
private static class LazyHolder {
static {
System.out.println("LazyHolder init");
}
static final Singleton INSTANCE = new Singleton();
}
// 第一次调用 getInstance 方法，才会导致内部类加载和初始化其静态成员
public static Singleton getInstance() {
return LazyHolder.INSTANCE;
}
}
public class SingletonTest {
public static void main(String[] args) {
Singleton.test();
Singleton.getInstance();
}
}类加载器
| 名称 | 加载哪的类 | 说明 |
|---|---|---|
| Bootstrap ClassLoader | JAVA_HOME/jre/lib | 无法直接访问(c++写的) |
| Extension ClassLoader | JAVA_HOME/jre/lib/ext | 上级为 Bootstrap，显示为 null |
| Application ClassLoader | classpath | 上级为 Extension |
| 自定义类加载器 | 自定义 | 上级为 Application |
双亲委派类加载模式
自下而上有没有加载，有就终止返回；没有到 Bootstrap 顶层后自上而下处理
启动类加载器
public class demo_1 {
public static void main(String[] args) throws ClassNotFoundException {
Class<?> aClass = Class.forName("com/zmz/jvm/classLoader/F");
System.out.println(aClass.getClassLoader());
}
}
class F {
static {
System.out.println("bootstrap F init");
}
}bootstrap F init
null扩展类加载器
package com.zmz.jvm.load
public class G {
static {
System.out.println("classpath G init");
}
}public class Load5_2 {
public static void main(String[]args) throws ClassNotFoundException {
Class<?> aClass = Class.forName("com.zmz.jvm.load.G");
System.out.println(aClass.getClassLoader());
}
}classpathGinit
sun.misc.Launcher$AppClassLoader@18b4aac2写一个同名的类
package com.zmz.jvm.load
public class G {
static {
System.out.println("extGinit");
}
}打个jar包
E:\jvm\out\jvm>jar -cvf my.jar com/zmz/jvm/load/G.class
已添加清单
正在添加:com/zmz/jvm/t3/load/G.class(输入=481)(输出=322)(压缩了33%)将 jar包拷贝到 JAVA_HOME/jre/lib/ext
重新执行 Load5_2
extGinit
sun.misc.Launcher$ExtClassLoader@29453f44双亲委派模式
所谓的双亲委派，就是指调用类加载器的 loadClass方法时，查找类的规则
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized (getClassLoadingLock(name)) {
// 首先查找该类是否已经被该类加载器加载过了
Class<?> c = findLoadedClass(name);
//如果没有被加载过
if (c == null) {
long t0 = System.nanoTime();
try {
//看是否被它的上级加载器加载过了 Extension的上级是Bootstarp，但它显示为null
if (parent != null) {
c = parent.loadClass(name, false);
} else {
//看是否被启动类加载器加载过
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
// ClassNotFoundException thrown if class not found
// from the non-null parent class loader
//捕获异常，但不做任何处理
}
if (c == null) {
//如果还是没有找到，先让拓展类加载器调用findClass方法去找到该类，如果还是没找到，就抛出异常
//然后让应用类加载器去找classpath下找该类
long t1 = System.nanoTime();
c = findClass(name);
// 记录时间
sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
sun.misc.PerfCounter.getFindClasses().increment();
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
}例子
public class Load5_3 {
public static void main(String[] args) throws ClassNotFoundException {
Class<?> aClass = Load5_3.class.getClassLoader().loadClass("cn.itcast.jvm.t3.load.H");
System.out.println(aClass.getClassLoader());
}
}执行流程为：
1. sun.misc.Launcher$AppClassLoader //1 处， 开始查看已加载的类，结果没有
2. sun.misc.Launcher$AppClassLoader // 2 处，委派上级
sun.misc.Launcher$ExtClassLoader.loadClass()
3. sun.misc.Launcher$ExtClassLoader // 1 处，查看已加载的类，结果没有
4. sun.misc.Launcher$ExtClassLoader // 3 处，没有上级了，则委派 BootstrapClassLoader
查找
5. BootstrapClassLoader 是在 JAVA_HOME/jre/lib 下找 H 这个类，显然没有
6. sun.misc.Launcher$ExtClassLoader // 4 处，调用自己的 findClass 方法，是在
JAVA_HOME/jre/lib/ext 下找 H 这个类，显然没有，回到 sun.misc.Launcher$AppClassLoader
的 // 2 处
7. 继续执行到 sun.misc.Launcher$AppClassLoader // 4 处，调用它自己的 findClass 方法，在
classpath 下查找，找到了线程上下文类加载器
我们在使用 JDBC 时，都需要加载 Driver 驱动
public class DriverManager {
// 注册驱动的集合
private final static CopyOnWriteArrayList<DriverInfo> registeredDrivers
= new CopyOnWriteArrayList<>();
// 初始化驱动
static {
loadInitialDrivers();
println("JDBC DriverManager initialized");
}
}看一下类加载器
System.out.println(DriverManager.class.getClassLoader());打印 null，表示它的类加载器是 Bootstrap ClassLoader，会到 JAVA_HOME/jre/lib 下搜索类，但 JAVA_HOME/jre/lib 下显然没有 mysql-connector-java-5.1.47.jar 包，这样问题来了，在 DriverManager 的静态代码块中，怎么能正确加载 com.mysql.jdbc.Driver 呢？
DrivaerManager
public class DriverManager {
// List of registered JDBC drivers
private final static CopyOnWriteArrayList<DriverInfo> registeredDrivers = new CopyOnWriteArrayList<>();
private static volatile int loginTimeout = 0;
private static volatile java.io.PrintWriter logWriter = null;
private static volatile java.io.PrintStream logStream = null;
// Used in println() to synchronize logWriter
private final static Object logSync = new Object();
/* Prevent the DriverManager class from being instantiated. */
private DriverManager(){}
/**
* Load the initial JDBC drivers by checking the System property
* jdbc.properties and then use the {@code ServiceLoader} mechanism
*/
static {
loadInitialDrivers();
println("JDBC DriverManager initialized");
}loadInitialDrivers()
private static void loadInitialDrivers() {
String drivers;
try {
drivers = AccessController.doPrivileged(new PrivilegedAction<String>() {
public String run() {
return System.getProperty("jdbc.drivers");
}
});
} catch (Exception ex) {
drivers = null;
}
// 1.使用 ServiceLoader 机制加载驱动，即 SPI
AccessController.doPrivileged(new PrivilegedAction<Void>() {
public Void run() {
ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);
Iterator<Driver> driversIterator = loadedDrivers.iterator();
try{
while(driversIterator.hasNext()) {
driversIterator.next();
}
} catch(Throwable t) {
// Do nothing
}
return null;
}
});
println("DriverManager.initialize: jdbc.drivers = " + drivers);
// 2.使用 jdbc.drivers 定义的驱动名加载驱动
if (drivers == null || drivers.equals("")) {
return;
}
String[] driversList = drivers.split(":");
println("number of Drivers:" + driversList.length);
for (String aDriver : driversList) {
try {
println("DriverManager.Initialize: loading " + aDriver);
Class.forName(aDriver, true,
ClassLoader.getSystemClassLoader());
// 这里的 ClassLoader.getSystemClassLoader() 就是应用程序类加载器
} catch (Exception ex) {
println("DriverManager.Initialize: load failed: " + ex);
}
}
}先看 2）发现它最后是使用 Class.forName 完成类的加载和初始化，关联的是应用程序类加载器，因此 可以顺利完成类加载
再看 1）它就是大名鼎鼎的 Service Provider Interface （SPI） 约定如下，在 jar 包的 META-INF/services 包下，以接口全限定名名为文件，文件内容是实现类名称
ServiceLoader<接口类型> allImpls = ServiceLoader.load(接口类型.class);
Iterator<接口类型> iter = allImpls.iterator();
while(iter.hasNext()) {
iter.next();
}
来得到实现类，体现的是【面向接口编程+解耦】的思想，在下面一些框架中都运用了此思想：
- JDBC Servlet 初始化器
- Spring 容器
- Dubbo（对 SPI 进行了扩展）
接着看 ServiceLoader.load 方法：
public static <S> ServiceLoader<S> load(Class<S> service) {
// 获取线程上下文类加载器
ClassLoader cl = Thread.currentThread().getContextClassLoader();
return ServiceLoader.load(service, cl);
}线程上下文类加载器是当前线程使用的类加载器，默认就是应用程序类加载器，它内部又是由 Class.forName 调用了线程上下文类加载器完成类加载，具体代码在 ServiceLoader 的内部类 LazyIterator 中
自定义类加载器
使用场景
- 想加载非 classpath 随意路径中的类文件
- 通过接口来使用实现，希望解耦时，常用在框架设计
- 这些类希望予以隔离，不同应用的同名类都可以加载，不冲突，常见于 tomcat 容器
步骤
- 继承ClassLoader父类
要遵从双亲委派机制，重写 findClass 方法
- 不是重写loadClass方法，否则不会走双亲委派机制
- 读取类文件的字节码
- 调用父类的 defineClass 方法来加载类
- 使用者调用该类加载器的 loadClass 方法
破坏双亲委派模式
双亲委派模型的第一次“被破坏”其实发生在双亲委派模型出现之前——即JDK1.2面世以前的“远古”时代
- 建议用户重写findClass()方法，在类加载器中的loadClass()方法中也会调用该方法
双亲委派模型的第二次“被破坏”是由这个模型自身的缺陷导致的
- 如果有基础类型又要调用回用户的代码，此时也会破坏双亲委派模式
双亲委派模型的第三次“被破坏”是由于用户对程序动态性的追求而导致的
- 这里所说的“动态性”指的是一些非常“热”门的名词：代码热替换（Hot Swap）、模块热部署（Hot Deployment）等
运行期优化
即时编译
public class JIT1 {
public static void main(String[] args) {
for (int i = 0; i < 200; i++) {
long start = System.nanoTime();
for (int j = 0; j < 1000; j++) {
new Object();
}
long end = System.nanoTime();
System.out.printf("%d\t%d\n",i,(end - start));
}
}
}结果是后面创建对象的速度量级变小
原因
分层编译
JVM 将执行状态分成了 5 个层次：
- 0层：解释执行，用解释器将字节码翻译为机器码
- 1层：使用 C1 即时编译器编译执行（不带 profiling）
- 2层：使用 C1 即时编译器编译执行（带基本的profiling）
- 3层：使用 C1 即时编译器编译执行（带完全的profiling）
- 4层：使用 C2 即时编译器编译执行
profiling 是指在运行过程中收集一些程序执行状态的数据，例如【方法的调用次数】，【循环的 回边次数】等
即时编译器（JIT）与解释器的区别
解释器
- 将字节码解释为机器码，下次即使遇到相同的字节码，仍会执行重复的解释
- 是将字节码解释为针对所有平台都通用的机器码
即时编译器
- 将一些字节码编译为机器码，并存入 Code Cache，下次遇到相同的代码，直接执行，无需再编译
- 根据平台类型，生成平台特定的机器码
对于大部分的不常用的代码，我们无需耗费时间将其编译成机器码，而是采取解释执行的方式运行；另一方面，对于仅占据小部分的热点代码，我们则可以将其编译成机器码，以达到理想的运行速度。 执行效率上简单比较一下 Interpreter < C1 < C2，总的目标是发现热点代码（hotspot名称的由 来），并优化这些热点代码
逃逸分析
逃逸分析（Escape Analysis）简单来讲就是，Java Hotspot 虚拟机可以分析新创建对象的使用范围，并决定是否在 Java 堆上分配内存的一项技术
逃逸分析的 JVM 参数如下：
- 开启逃逸分析：-XX:+DoEscapeAnalysis
- 关闭逃逸分析：-XX:-DoEscapeAnalysis
- 显示分析结果：-XX:+PrintEscapeAnalysis
逃逸分析技术在 Java SE 6u23+ 开始支持，并默认设置为启用状态，可以不用额外加这个参数
对象逃逸状态
全局逃逸（GlobalEscape）
即一个对象的作用范围逃出了当前方法或者当前线程，有以下几种场景：
- 对象是一个静态变量
- 对象是一个已经发生逃逸的对象
- 对象作为当前方法的返回值
参数逃逸（ArgEscape）
- 即一个对象被作为方法参数传递或者被参数引用，但在调用过程中不会发生全局逃逸，这个状态是通过被调方法的字节码确定的
没有逃逸
- 即方法中的对象没有发生逃逸
逃逸分析优化
针对上面第三点，当一个对象没有逃逸时，可以得到以下几个虚拟机的优化
锁消除
我们知道线程同步锁是非常牺牲性能的，当编译器确定当前对象只有当前线程使用，那么就会移除该对象的同步锁
例如，StringBuffer 和 Vector 都是用 synchronized 修饰线程安全的，但大部分情况下，它们都只是在当前线程中用到，这样编译器就会优化移除掉这些锁操作
锁消除的 JVM 参数如下：
- 开启锁消除：-XX:+EliminateLocks
- 关闭锁消除：-XX:-EliminateLocks
锁消除在 JDK8 中都是默认开启的，并且锁消除都要建立在逃逸分析的基础上
标量替换
首先要明白标量和聚合量，基础类型和对象的引用可以理解为标量，它们不能被进一步分解。而能被进一步分解的量就是聚合量，比如：对象
对象是聚合量，它又可以被进一步分解成标量，将其成员变量分解为分散的变量，这就叫做标量替换。
这样，如果一个对象没有发生逃逸，那压根就不用创建它，只会在栈或者寄存器上创建它用到的成员标量，节省了内存空间，也提升了应用程序性能
标量替换的 JVM 参数如下：
- 开启标量替换：-XX:+EliminateAllocations
- 关闭标量替换：-XX:-EliminateAllocations
- 显示标量替换详情：-XX:+PrintEliminateAllocations
标量替换同样在 JDK8 中都是默认开启的，并且都要建立在逃逸分析的基础上
栈上分配
当对象没有发生逃逸时，该对象就可以通过标量替换分解成成员标量分配在栈内存中，和方法的生命周期一致，随着栈帧出栈时销毁，减少了 GC 压力，提高了应用程序性能
方法内联
内联函数
内联函数就是在程序编译时，编译器将程序中出现的内联函数的调用表达式用内联函数的函数体来直接进行替换
private static int square(final int i) {
return i * i;
}System.out.println(square(9));如果发现 square 是热点方法，并且长度不太长时，会进行内联，所谓的内联就是把方法内代码拷贝、 粘贴到调用者的位置：
System.out.println(9 * 9);反射优化
public class Reflect1 {
public static void foo() {
System.out.println("foo...");
}
public static void main(String[] args) throws NoSuchMethodException, InvocationTargetException, IllegalAccessException {
Method foo = Demo3.class.getMethod("foo");
for(int i = 0; i<=16; i++) {
foo.invoke(null);
}
}
}foo.invoke 前面 0 ~ 15 次调用使用的是 MethodAccessor 的 NativeMethodAccessorImpl 实现
invoke
@CallerSensitive
public Object invoke(Object obj, Object... args)
throws IllegalAccessException, IllegalArgumentException,
InvocationTargetException
{
if (!override) {
if (!Reflection.quickCheckMemberAccess(clazz, modifiers)) {
Class<?> caller = Reflection.getCallerClass();
checkAccess(caller, clazz, obj, modifiers);
}
}
//MethodAccessor是一个接口，有3个实现类，其中有一个是抽象类
MethodAccessor ma = methodAccessor; // read volatile
if (ma == null) {
ma = acquireMethodAccessor();
}
return ma.invoke(obj, args);
}
会由DelegatingMehodAccessorImpl去调用NativeMethodAccessorImpl
NativeMethodAccessorImpl源码
class NativeMethodAccessorImpl extends MethodAccessorImpl {
private final Method method;
private DelegatingMethodAccessorImpl parent;
private int numInvocations;
NativeMethodAccessorImpl(Method var1) {
this.method = var1;
}
//每次进行反射调用，会让numInvocation与ReflectionFactory.inflationThreshold的值（15）进行比较，并使使得numInvocation的值加一
//如果numInvocation>ReflectionFactory.inflationThreshold，则会调用本地方法invoke0方法
public Object invoke(Object var1, Object[] var2) throws IllegalArgumentException, InvocationTargetException {
if (++this.numInvocations > ReflectionFactory.inflationThreshold() && !ReflectUtil.isVMAnonymousClass(this.method.getDeclaringClass())) {
MethodAccessorImpl var3 = (MethodAccessorImpl)(new MethodAccessorGenerator()).generateMethod(this.method.getDeclaringClass(), this.method.getName(), this.method.getParameterTypes(), this.method.getReturnType(), this.method.getExceptionTypes(), this.method.getModifiers());
this.parent.setDelegate(var3);
}
return invoke0(this.method, var1, var2);
}
void setParent(DelegatingMethodAccessorImpl var1) {
this.parent = var1;
}
private static native Object invoke0(Method var0, Object var1, Object[] var2);
}//ReflectionFactory.inflationThreshold()方法的返回值
private static int inflationThreshold = 15;一开始if条件不满足，就会调用本地方法invoke0
随着numInvocation的增大，当它大于ReflectionFactory.inflationThreshold的值16时，就会本地方法访问器替换为一个运行时动态生成的访问器，来提高效率
这时会从反射调用变为正常调用，即直接调用 Reflect1.foo()
内存模型
JMM ( Java Memory Model) 定义了一套在多线程读写共享数据时（成员变量、数组）时，对数据的可见性、有序 性、和原子性的规则和保障
原子性
问题提出
两个线程对初始值为 0 的静态变量一个做自增，一个做自减，各做 5000 次，结果是 0 吗？
问题分析
以上的结果可能是正数、负数、零。为什么呢？因为 Java 中对静态变量的自增，自减并不是原子操作。 例如对于 i++ 而言（i 为静态变量），实际会产生如下的 JVM 字节码指令：
getstatic i // 获取静态变量i的值
iconst_1 // 准备常量1
iadd // 加法
putstatic i // 将修改后的值存入静态变量i而 Java 的内存模型如下，完成静态变量的自增，自减需要在主存和线程内存中进行数据交换：
解决方法
synchronized( 对象 ) {
要作为原子操作代码
}static int i = 0;
static Object obj = new Object();
public static void main(String[] args) throws InterruptedException {
Thread t1 = new Thread(() -> {
for (int j = 0; j < 5000; j++) {
synchronized (obj) {
i++;
}
}
});
Thread t2 = new Thread(() -> {
for (int j = 0; j < 5000; j++) {
synchronized (obj) {
i--;
}
}
});
t1.start();
t2.start();
t1.join();
t2.join();
System.out.println(i);
}你可以把 obj 想象成一个房间，线程 t1，t2 想象成两个人。 当线程 t1 执行到 synchronized(obj) 时就好比 t1 进入了这个房间，并反手锁住了门，在门内执行 count++ 代码。 这时候如果 t2 也运行到了 synchronized(obj) 时，它发现门被锁住了，只能在门外等待。 当 t1 执行完 synchronized{} 块内的代码，这时候才会解开门上的锁，从 obj 房间出来。t2 线程这时才 可以进入 obj 房间，反锁住门，执行它的 count-- 代码。
注意
上例中 t1 和 t2 线程必须用 synchronized 锁住同一个 obj 对象，如果 t1 锁住的是 m1 对 象，t2 锁住的是 m2 对象，就好比两个人分别进入了两个不同的房间，没法起到同步的效果。
可见性
先来看一个现象，main 线程对 run 变量的修改对于 t 线程不可见，导致了 t 线程无法停止：
static boolean run = true;
public static void main(String[] args) throws InterruptedException {
Thread t = new Thread(() -> {
while (run) {
// ....
}
});
t.start();
Thread.sleep(1000);
run = false; // 线程t不会如预想的停下来
}原因
1、初始状态， t 线程刚开始从主内存读取了 run 的值到工作内存。
2、因为 t 线程要频繁从主内存中读取 run 的值，JIT 编译器会将 run 的值缓存至自己工作内存中的高速缓存中，减少对主存中 run 的访问，提高效率
3、1 秒之后，main 线程修改了 run 的值，并同步至主存，而 t 是从自己工作内存中的高速缓存中读 取这个变量的值，结果永远是旧值
解决
volatile（易变关键字） 它可以用来修饰成员变量和静态成员变量，他可以避免线程从自己的工作缓存中查找变量的值，必须到 主存中获取它的值，线程操作 volatile 变量都是直接操作主存
可见性
它保证的是在多个线程之间，一个线程对 volatile 变量的修改对另一 个线程可见， 不能保证原子性，仅用在一个写线程，多个读线程的情况： 上例从字节码理解是这样的：
getstatic run // 线程 t 获取 run true
getstatic run // 线程 t 获取 run true
getstatic run // 线程 t 获取 run true
getstatic run // 线程 t 获取 run true
putstatic run // 线程 main 修改 run 为 false， 仅此一次
getstatic run // 线程 t 获取 run falsesynchronized 语句块既可以保证代码块的原子性，也同时保证代码块内变量的可见性。但缺点是 synchronized是属于重量级操作，性能相对更低
有序性
int num = 0;
boolean ready = false;
// 线程1 执行此方法
public void actor1(I_Result r) {
if(ready) {
r.r1 = num + num;
} else {
r.r1 = 1;
}
}
// 线程2 执行此方法
public void actor2(I_Result r) {
num = 2;
ready = true;
}结果
1、4、0
0：线程2 执行 ready = true，切换到线程1，进入 if 分支，相加为 0，再切回线程2 执行 num = 2
这种现象叫做指令重排，是 JIT 编译器在运行时的一些优化
解决
volatile 修饰的变量，可以禁用指令重排
有序性理解
JVM 会在不影响正确性的前提下，可以调整语句的执行顺序，思考下面一段代码
static int i;
static int j;
// 在某个线程内执行如下赋值操作
i = ...; // 较为耗时的操作
j = ...;可以看到，至于是先执行 i 还是 先执行 j ，对最终的结果不会产生影响。
这种特性称之为指令重排，多线程下 指令重排 会影响正确性，例如著名的 double-checked locking 模式实现单例
public final class Singleton {
private Singleton() {
}
private static Singleton INSTANCE = null;
public static Singleton getInstance() {
// 实例没创建，才会进入内部的 synchronized代码块
if (INSTANCE == null) {
synchronized (Singleton.class) {
// 也许有其它线程已经创建实例，所以再判断一次
if (INSTANCE == null) {
INSTANCE = new Singleton();
}
}
}
return INSTANCE;
}
}以上的实现特点是： 懒惰实例化 首次使用 getInstance() 才使用 synchronized 加锁，后续使用时无需加锁 但在多线程环境下，上面的代码是有问题的， INSTANCE = new Singleton() 对应的字节码为：
0: new #2 // class cn/itcast/jvm/t4/Singleton
3: dup
4: invokespecial #3 // Method "<init>":()V
7: putstatic #4 // Field
INSTANCE:Lcn/itcast/jvm/t4/Singleton;其中 4 7 两步的顺序不是固定的，也许 jvm 会优化为：先将引用地址赋值给 INSTANCE 变量后，再执行 构造方法，如果两个线程 t1，t2 按如下时间序列执行：
时间1 t1 线程执行到 INSTANCE = new Singleton();
时间2 t1 线程分配空间，为Singleton对象生成了引用地址（0 处）
时间3 t1 线程将引用地址赋值给 INSTANCE，这时 INSTANCE != null（7 处）
时间4 t2 线程进入getInstance() 方法，发现 INSTANCE != null（synchronized块外），直接
返回 INSTANCE
时间5 t1 线程执行Singleton的构造方法（4 处）这时 t1 还未完全将构造方法执行完毕，如果在构造方法中要执行很多初始化操作，那么 t2 拿到的是将是一个未初始化完毕的单例
对 INSTANCE 使用 volatile 修饰即可，可以禁用指令重排，但要注意在 JDK 5 以上的版本的 volatile 才 会真正有效
happens-before
happens-before 规定了哪些写操作对其它线程的读操作可见，它是可见性与有序性的一套规则总结， 抛开以下 happens-before 规则，JMM 并不能保证一个线程对共享变量的写，对于其它线程对该共享变 量的读可见
线程解锁 m 之前对变量的写，对于接下来对 m 加锁的其它线程对该变量的读可见
static int x; static Object m = new Object(); new Thread(()->{ synchronized(m) { x = 10; } },"t1").start(); new Thread(()->{ synchronized(m) { System.out.println(x); } },"t2").start();线程对 volatile 变量的写，对接下来其它线程对该变量的读可见
volatile static int x; new Thread(()->{ x = 10; },"t1").start(); new Thread(()->{ System.out.println(x); },"t2").start();
线程 start 前对变量的写，对该线程开始后对该变量的读可见
static int x; x = 10; new Thread(()->{ System.out.println(x); },"t2").start();线程结束前对变量的写，对其它线程得知它结束后的读可见（比如其它线程调用 t1.isAlive() 或 t1.join()等待它结束）
static int x; Thread t1 = new Thread(()->{ x = 10; },"t1"); t1.start(); t1.join(); System.out.println(x);线程 t1 打断 t2（interrupt）前对变量的写，对于其他线程得知 t2 被打断后对变量的读可见（通 过t2.interrupted 或 t2.isInterrupted）
static int x; public static void main(String[] args) { Thread t2 = new Thread(() -> { while (true) { if (Thread.currentThread().isInterrupted()) { System.out.println(x); break; } } }, "t2"); t2.start(); new Thread(() -> { try { Thread.sleep(1000); } catch (InterruptedException e) { e.printStackTrace(); } x = 10; t2.interrupt(); }, "t1").start(); while (!t2.isInterrupted()) { Thread.yield(); } System.out.println(x); }- 对变量默认值（0，false，null）的写，对其它线程对该变量的读可见
- 具有传递性，如果 x hb-> y 并且 y hb-> z 那么有 x hb-> z
CAS
CAS 即 Compare and Swap ，它体现的一种乐观锁的思想，比如多个线程要对一个共享的整型变量执 行 +1 操作：
// 需要不断尝试
while(true) {
int 旧值 = 共享变量 ; // 比如拿到了当前值 0
int 结果 = 旧值 + 1; // 在旧值 0 的基础上增加 1 ，正确结果是 1
/*
这时候如果别的线程把共享变量改成了 5，本线程的正确结果 1 就作废了，这时候
compareAndSwap 返回 false，重新尝试，直到：
compareAndSwap 返回 true，表示我本线程做修改的同时，别的线程没有干扰
*/
if( compareAndSwap ( 旧值, 结果 )) {
// 成功，退出循环
}
}获取共享变量时，为了保证该变量的可见性，需要使用 volatile 修饰。结合 CAS 和 volatile 可以实现无 锁并发，适用于竞争不激烈、多核 CPU 的场景下。
- 因为没有使用 synchronized，所以线程不会陷入阻塞，这是效率提升的因素之一
- 但如果竞争激烈，可以想到重试必然频繁发生，反而效率会受影响
CAS 底层依赖于一个 Unsafe 类来直接调用操作系统底层的 CAS 指令，下面是直接使用 Unsafe 对象进行线程安全保护的一个例子
乐观锁与悲观锁
CAS 是基于乐观锁的思想：最乐观的估计，不怕别的线程来修改共享变量，就算改了也没关系， 我吃亏点再重试呗。
synchronized 是基于悲观锁的思想：最悲观的估计，得防着其它线程来修改共享变量，我上了锁 你们都别想改，我改完了解开锁，你们才有机会。
原子操作类
juc（java.util.concurrent）中提供了原子操作类，可以提供线程安全的操作，例如：AtomicInteger、 AtomicBoolean等，它们底层就是采用 CAS 技术 + volatile 来实现的。
// 创建原子整数对象
private static AtomicInteger i = new AtomicInteger(0);
public static void main(String[] args) throws InterruptedException {
Thread t1 = new Thread(() -> {
for (int j = 0; j < 5000; j++) {
i.getAndIncrement(); // 获取并且自增 i++
// i.incrementAndGet(); // 自增并且获取 ++i
}
});
Thread t2 = new Thread(() -> {
for (int j = 0; j < 5000; j++) {
i.getAndDecrement(); // 获取并且自减 i--
}
});
t1.start();
t2.start();
t1.join();
t2.join();
System.out.println(i);
}synchronized 优化
Java HotSpot 虚拟机中，每个对象都有对象头（包括 class 指针和 Mark Word）。Mark Word 平时存 储这个对象的 哈希码、分代年龄，当加锁时，这些信息就根据情况被替换为 标记位、线程锁记录指针、重量级锁指针、线程 ID 等内容
轻量级锁
如果一个对象虽然有多线程访问，但多线程访问的时间是错开的（也就是没有竞争），那么可以使用轻 量级锁来优化。这就好比：
学生（线程 A）用课本占座，上了半节课，出门了（CPU时间到），回来一看，发现课本没变，说明没 有竞争，继续上他的课。
如果这期间有其它学生（线程 B）来了，会告知（线程A）有并发访问，线程 A 随即升级为重量级锁， 进入重量级锁的流程。
而重量级锁就不是那么用课本占座那么简单了，可以想象线程 A 走之前，把座位用一个铁栅栏围起来
假设有两个方法同步块，利用同一个对象加锁
static Object obj = new Object();
public static void method1() {
synchronized( obj ) {
// 同步块 A
method2();
}
}
public static void method2() {
synchronized( obj ) {
// 同步块 B
}
}每个线程都的栈帧都会包含一个锁记录的结构，内部可以存储锁定对象的 Mark Word
锁膨胀
如果在尝试加轻量级锁的过程中，CAS 操作无法成功，这时一种情况就是有其它线程为此对象加上了轻 量级锁（有竞争），这时需要进行锁膨胀，将轻量级锁变为重量级锁。
重量锁
重量级锁竞争的时候，还可以使用自旋来进行优化，如果当前线程自旋成功（即这时候持锁线程已经退 出了同步块，释放了锁），这时当前线程就可以避免阻塞。
在 Java 6 之后自旋锁是自适应的，比如对象刚刚的一次自旋操作成功过，那么认为这次自旋成功的可能 性会高，就多自旋几次；反之，就少自旋甚至不自旋，总之，比较智能
自旋会占用 CPU 时间，单核 CPU 自旋就是浪费，多核 CPU 自旋才能发挥优势。
好比等红灯时汽车是不是熄火，不熄火相当于自旋（等待时间短了划算），熄火了相当于阻塞（等 待时间长了划算）
Java 7 之后不能控制是否开启自旋功能
偏向锁
轻量级锁在没有竞争时（就自己这个线程），每次重入仍然需要执行 CAS 操作。Java 6 中引入了偏向锁 来做进一步优化：只有第一次使用 CAS 将线程 ID 设置到对象的 Mark Word 头，之后发现这个线程 ID 是自己的就表示没有竞争，不用重新 CAS.
撤销偏向需要将持锁线程升级为轻量级锁，这个过程中所有线程需要暂停（STW）
访问对象的 hashCode 也会撤销偏向锁
如果对象虽然被多个线程访问，但没有竞争，这时偏向了线程 T1 的对象仍有机会重新偏向 T2， 重偏向会重置对象的 Thread ID
撤销偏向和重偏向都是批量进行的，以类为单位
如果撤销偏向到达某个阈值，整个类的所有对象都会变为不可偏向的
可以主动使用 -XX:-UseBiasedLocking 禁用偏向锁
