1、引言
p1什么是JVM?
定义:
Java Virtual Machine - java 程序的运行环境(java 二进制字节码的运行环境)
好处:
一次编写,到处运行(由jvm屏蔽底层操作系统的差异,二进制字节码--所有平台一致)
自动内存管理,垃圾回收功能
数组下标越界检查(数据覆盖跟报异常哪个严重?当然是覆盖)
多态(虚方法表)
比较:
jvm jre jdk

p3常见的jvm
以hotspot为准
p4学习路线

一个类从java源代码编译为java二进制字节码文件后,必须经过这个类加载器,才能被加载到我们的jvm内存结构中。那么类都是放在方法区,类创建的实例对象是放在堆里面,而堆里面的对象在调用方法时会用到虚拟机栈、程序计数器跟本地方法栈。方法执行时每行代码是由执行引擎中的解释器去逐行执行,其中被频繁调用的代码会由即时编译器进行编译优化,垃圾回收会对堆里面不再引用的对象进行垃圾回收。还有一些java代码不方便实现的功能,我们会调用本地方法接口调用底层操作系统。
学习顺序:

2、内存结构
p5 p6程序计数器作用、特点
Program Counter Register 程序计数器(寄存器)
作用,是记住下一条jvm指令的执行地址
特点
是线程私有的
不会存在内存溢出(java虚拟机规范中唯一一个不会内存溢出的)

p7-16 虚拟机栈

Java Virtual Machine Stacks (Java 虚拟机栈)
每个线程运行时所需要的内存,称为虚拟机栈
每个栈由多个栈帧(Frame)组成,对应着每次方法调用时所占用的内存(一个栈帧对应一个方法运行所需要的内存)
每个线程只能有一个活动栈帧,对应着当前正在执行的那个方法

问题辨析
垃圾回收是否涉及栈内存?
答:不需要。栈帧内存在每次方法调用完成后都会被弹出栈。
栈内存分配越大越好吗?
栈内存分配空间 -Xss size
答:不是。栈内存分配越大,线程数越小。
方法内的局部变量是否线程安全?
如果方法内局部变量没有逃离方法的作用访问,它是线程安全的
如果是局部变量引用了对象,并逃离方法的作用范围,需要考虑线程安全
局部变量作为返回值被其他线程拿到,存在指令乱序的情况,线程不安全
栈内存溢出
栈帧过多导致栈内存溢出
栈帧过大导致栈内存溢出

jackson的json会出现循环引用导致栈内存溢出(需要加@jsonignore),fastjson没有这种情况
线程运行诊断
案例1: cpu 占用过多
定位
用top定位哪个进程对cpu的占用过高(但是top命令只能定位到进程,定位不到具体是进程中的哪个线程)

ps H -eo pid,tid,%cpu | grep 进程id (用ps命令进一步定位是哪个线程引起的cpu占用过高)

jstack 进程id
可以根据线程id 找到有问题的线程,进一步定位到问题代码的源码行号

上一张图定位到线程32665,需要转换为16进制0x7f99,再到jstack中输出的信息中找

案例2:程序运行很长时间没有结果
jstack
发现发生了死锁

p17 本地方法栈
调用本地方法时提供的内存空间

p16-p21 堆
前面都是线程私有的
堆是所有对象共享的
定义
Heap 堆
通过 new 关键字,创建对象都会使用堆内存
特点
它是线程共享的,堆中对象都需要考虑线程安全的问题
有垃圾回收机制
堆内存溢出
-Xmx8m

内存诊断
jps 工具
查看当前系统中有哪些 java 进程
jmap 工具(只能某一时刻)
查看堆内存占用情况 jmap - heap 进程id
jconsole 工具
图形界面的,多功能的监测工具,可以连续监测


jamp -heap 18756


案例
垃圾回收后,内存占用仍然很高

p21
jvirsualvm工具(感觉这个挺好用)
p22-p40 方法区
定义

方法区逻辑上是属于堆空间的,但是具体实现上不做限制,看厂商
比如hotspot 1.8以前,方法区的实现叫永久代,就是用的堆内存。而1.8之后变成了元空间,元空间用的是本地内存。


内存溢出
1.8 以前会导致永久代内存溢出
演示永久代内存溢出 java.lang.OutOfMemoryError: PermGen space
-XX:MaxPermSize=8m
1.8 之后会导致元空间内存溢出
由于1.8以后使用的是系统内存,很难演示出内存溢出,所以我们需要进行设置
-XX:MaxMetaspaceSize=8m
演示元空间内存溢出 java.lang.OutOfMemoryError: Metaspace

场景
spring
mybatis
(使用了这种classloader技术,ClassWriter)
常量池,就是一张表,虚拟机指令根据这张常量表找到要执行的类名、方法名、参数类型、字面量等信息
运行时常量池,常量池是 *.class 文件中的,当该类被加载,它的常量池信息就会放入运行时常量池,并把里面的符号地址变为真实地址

类基本信息

常量池
类方法定义:默认生成的无参构造方法、main方法

根据#2、#3、#4到上面的常量池中查找确定这三条执行哪个类的哪个方法。
StringTable(串池)

StringTable[] hashtable结构,不能扩容
常量池中的信息,都会被加载到运行时常量池中,这时a、b、ab都是常量池中的符号,还没有变为java字符串对象。
ldc #2会把a符号变为“a“字符串对象,然后放入我们的串池
……
StringTable["a","b","ab"]
(如果串池中有,直接使用串池中的对象。否则放入串池中)
String s4 = s1 + s2; //new StringBuilder().append("a").append("b").toString()
//相当于new String("ab")
System.out.println(s3 == s4); //false 一个在堆中,一个在队中的串池中


String s5 = "a" + "b"
//直接找到了已经拼接好的ab
//javac 在编译期间的优化,都是常量,结果已经在编译期间确定为ab
//而如果是变量,在代码运行期间值可能会发生变化,例如根据用户的输入来改变s1和s2的值

常量池中的字符串仅是符号,第一次用到时才变为对象
利用串池的机制,来避免重复创建字符串对象
字符串变量拼接的原理是 StringBuilder (1.8)
字符串常量拼接的原理是编译期优化
可以使用 intern 方法,主动将串池中还没有的字符串对象放入串池
1.8 将这个字符串对象尝试放入串池,如果有则并不会放入,如果没有则放入串池, 会把串池中的对象返回
1.6 将这个字符串对象尝试放入串池,如果有则并不会放入,如果没有会把此对象复制一份,放入串池(放入串池的跟intern的对象是两个对象),会把串池中的对象返回
//jdk1.8
String s = new String("a") + new String("b");
//此时串池["a","b"]
//上面这句代码相当于在堆中new了一个新的a、b对象,并用StringBuilder拼接,相当于new("ab"),但是此时ab对象存在于堆中,还没有放入串池
String s2 = s.intern(); //尝试将这个字符串对象放入串池,如果有则不会放入,如果没有则放入串池,会把串池中的对象返回
System.out.println(s2 == "ab") //true
System.out.println(s == "ab") //true
//jdk1.6
String s = new String("a") + new String("b");
String s2 = s.intern();
String x = "ab";
System.out.println(s2 == x); //true
System.out.println(s == x); //false
//jdk1.8
String x = "ab";
String s = new String("a") + new String("b");
String s2 = s.intern();
System.out.println(s2 == x); //true
System.out.println(s == x); //false
面试题
String s1 = "a";
String s2 = "b";
String s3 = "a" + "b";
String s4 = s1 + s2;
String s5 = "ab";
String s6 = s4.intern();
// 问
System.out.println(s3 == s4); //false
System.out.println(s3 == s5); //true
System.out.println(s3 == s6); //true
String x2 = new String("c") + new String("d");
String x1 = "cd";
x2.intern();
// 问,如果调换了【最后两行代码】的位置呢,如果是jdk1.6呢
System.out.println(x1 == x2); //false
StringTable 位置

为什么换位置?原来垃圾回收效率不高
案例实验,当stringtable内存溢出时,1.6环境时会显示永久代空间不足,而1.8环境会显示堆空间不足


stringtalbe垃圾回收机制

j改为10000时会触发垃圾回收
stringtable调优
哈希表的性能跟桶个数相关(下面代码的注释为调整hashtable的桶个数)

p41-p47直接内存
操作系统的内存
常见于 NIO 操作时,用于数据缓冲区
分配回收成本较高,但读写性能高
不受 JVM 内存回收管理

使用了直接内存后

直接内存溢出
既然直接内存不受 JVM 内存回收管理,那直接内存会不会溢出呢?


直接内存释放原理


使用了 Unsafe 对象完成直接内存的分配回收,并且回收需要主动调用 freeMemory 方法
ByteBuffffer 的实现类内部,使用了 Cleaner (虚引用)来监测 ByteBuffffer 对象,一旦ByteBuffffer 对象被垃圾回收,那么就会由 ReferenceHandler 线程通过 Cleaner 的 clean 方法调用 freeMemory 来释放直接内存
p46、47听不懂