1 内存结构
1.1 程序计数器
1.1.1 定义
Program Counter Register 程序计数器(寄存器)
作用:是记住下一条 jvm
指令的执行地址
特点:
- 是线程私有的(每个线程独有自己的一份)
- 不会存在内存溢出
1.1.2 作用
记住下一条 jvm
指令的执行地址 (0,3,4,5,...
)
线程私有的:
每个线程都有一个自己的程序计数器,里面存储了自己线程运行到了哪条指令
1.2 虚拟机栈
1.2.1 定义
Java Virtual Machine Stacks (Java 虚拟机栈)
- 每个线程运行时所需要的内存,称为虚拟机栈
- 每个栈由多个栈帧(Frame)组成,对应着每次方法调用所占用的内存
- 每个线程只有一个活动栈帧,对应当前正在执行的那个方法
栈:线程运行需要的内存空间
栈中存储着多个栈帧,每个栈帧对应着一个调用过的方法,栈顶为活动栈帧,是当前正在运行的函数;当一个方法运行完成,这个方法对应的栈帧就会出栈
问题辨析
-
垃圾回收是否涉及栈内存?
不需要,每次方法结束时,栈内存就被回收掉了,不需要等待垃圾回收;垃圾回收是用来回收堆内存中的对象的
-
栈内存分配越大越好吗?
- 可以用
-Xss size
指令设置栈内存的大小 - Linux & macOS默认 1024 KB,Windows 依赖虚拟内存的大小
- 可以用
-
方法内的局部变量是否线程安全?
-
如果方法内局部变量没有逃离方法的作用访问,是线程私有的,它是线程安全的
-
如果是局部变量引用了对象,对象是共有的,并逃离方法的作用范围,需要考虑线程安全
-
/**
* 局部变量的线程安全问题
*/
public class d1_local_var_safe {
// 多个线程执行这个方法
public static void method1(String[] args) {
int x = 0;
for (int i = 0; i < 5000; i++) {
x++;
}
System.out.println(x);
}
}
1.2.2 栈内存溢出
- 栈帧过多导致栈内存溢出。例如方法的递归调用
- 栈帧过大导致栈内存溢出
1.2.3 线程运行诊断
案例一:CPU 占用过高
-
可以用 top 命令定位哪个进程对 CPU 的占用过高
-
找到进程后,我们想进一步的定位到具体的线程,可以用
ps
命令ps H pid,tid,%cpu
可以把当前所有线程的pid,tid,cpu
的信息展示出来- 使用管道过滤出具体的进程号:
ps h -eo pid,tid,%cpu | grep 32655
-
jstack 进程id
命令可以列出Java虚拟机中的所有的 Java 线程- 根据
ps
命令找到的线程号可以在jstack
中找到对应的线程,里面给出该线程的状态和问题代码行号
- 根据
案例二:程序运行很长时间没有结果
可能发生了死锁等等
使用 jstack
命令进行检查
1.3 本地方法栈
我们可以通过本地方法调用一些用C/CPP
写的更底层的方法,例如Object类中的clone
, hashCode
… 方法
1.4 堆
1.4.1 定义
Heap 堆:
- 通过 new 关键词创建对象会使用堆内存
特点:
- 他是线程共享的,堆中对象需要考虑线程安全问题
- 堆中有垃圾回收机制
1.4.2 堆内存溢出
不断的向堆中添加对象,且这些对象无法回收,一段时间后会导致堆内存溢出
1.4.3 堆内存诊断
package com.rainsun.d1_Java_memory_structure;
/**
* 堆内存演示
*/
public class d2_heap_memory {
public static void main(String[] args) throws InterruptedException {
System.out.println("1.....");
Thread.sleep(30000);
byte[] array = new byte[1024 * 1024 * 10]; // 10Mb 空间
System.out.println("2.....");
Thread.sleep(30000);
array = null;
System.gc();
System.out.println("3.....");
Thread.sleep(100000L);
}
}
查看堆内存信息:
jps
找到当前运行的线程idjhsdb jmap --pid 线程id --heap
输出堆占用信息
1:
2:
3:没有G1 Heap了
-
jconsole 工具
图形界面的,多功能的监测工具,可以连续监测
1.5 方法区
方法区是线程共享的,存储类相关的信息(方法,构造器,特殊方法,运行时常量池等等)
Chapter 2. The Structure of the Java Virtual Machine (oracle.com)
JDK1.6中的结构:
使用 PermGen
永久代实现
JDK1.8中的结构:
元空间实现,使用操作系统中的本地内存实现:
1.5.4 运行时常量池
- 常量池,就是一张表,虚拟机指令根据这张常量表找到要执行的类名、方法名、参数类型、字面量等信息
- 运行时常量池:
- 常量池是 *.class 文件中的;
- 当程序运行的时候,每个被加载的类,它的.class文件中常量池信息就都会放入运行时常量池,运行时常量池保存了所有被加载了的类中的常量池信息
- 并把里面的符号地址变为真实地址
1.5.5 StringTable
public static void main(String[] args) {
String s1 = "a";
String s2 = "b";
String s3 = "a" + "b";
String s4 = s1 + s2;
}
反编译:
- 常量池中的信息,都会被加载到运行时常量池中,这时 a , b 都是常量池中的符号,还没有变成 Java 字符串对象
- ldc #2 会把 a 符号变为 “a” 字符串对象,并把 “a” 放入 StringTable 中,如果没有则加入新的,有则不加入新的
s1,s2,s3 字符串对象的产生是发生在字符串常量池的 StringTable 中的
s4 字符串对象的产生是通过调用两次 makeConcatWithConstants
方法将常量池中的 “a” ,“b” 进行拼接,在堆中创建了一个新的字符串变量,最后存入临时变量 s4中的。
这是 JDK 21 反编译的结果,JDK 8 不一样,可能是 append.append.toString
StringTable 特性:
- 常量池中的字符串仅是符号,第一次用到时才变为对象
- 利用串池的机制,来避免重复创建字符串对象
- 字符串变量拼接的原理是 StringBuilder (1.8)
- 字符串常量拼接的原理是编译期优化
- 可以使用 intern 方法,主动将串池中还没有的字符串对象放入串池
public static main(String[] args){
String s = new String("a") + new String("b");
}
StringTable 中创建了字符串对象 [“a”,“b”]
在堆中产生了字符串对象,因为使用了 new 来创建 “a”,“b” ,“ab”
intern:
将字符串对象放入 StringTable,如果table中有则不会放入,没有则放入,并把 table 中的对象返回
String s2 = s.intern(); // 堆中的 "ab" 被放入了 StringTable中了, 并将table中的ab返回
public class d3_stringTable {
// 常量池中的信息,都会被加载到运行时常量池中,这时 a , b 都是常量池中的符号,还没有变成 Java 字符串对象
// ldc #2 会把 a 符号变为 "a" 字符串对象,并把 "a" 放入 StringTable 中,如果没有则加入新的,有则不加入新的
public static void main(String[] args) {
String s1 = "a";
String s2 = "b";
String s3 = "a" + "b"; //javac在编译期间的优化,变成了 "ab",结果在编译期就已经确定了
String s4 = s1 + s2; // 堆中的ab: new String("ab")
String s5 = "ab"; // == s3 在table中的ab
String s6 = s4.intern(); // table中ab已经有了,返回table中的ab
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(); // table中 cd 已经存在了,x2放不进去table,x2还是堆中的cd
System.out.println(x1 == x2); // false
/** 最后两行代码的位置调换:
* String x2 = new String("c") + new String("d");
* x2.intern(); // table 中 cd 不存在,x2放入table,x2 变成了table中的cd
* String x1 = "cd"; // x1 用的是table中的cd
* System.out.println(x1 == x2); // true
*/
}
}
1.5.6 StringTable 位置
1.6 中的StringTable在PermGen永久代中实现,它的回收时机比较晚,容易造成永久代的内存空间不足
在1.8中就将StringTable放入堆Heap中实现,它的垃圾回收时机触发比较早,可以更快回收不用的字符串空间
1.5.7 StringTable 垃圾回收
那些没有用到的字符串常量会被垃圾回收
package com.rainsun.d1_Java_memory_structure;
/**
* 演示 StringTable垃圾回收
* -Xmx10m
* -XX:+PrintStringTableStatistics : 打印 StringTable 信息
* -XX:+PrintGCDetails -verbose:gc :打印垃圾回收信息
*/
public class d4_stringTable_GC {
public static void main(String[] args) {
int i = 0;
try {
for (int j = 0; j < 100000; j++) {
String.valueOf(j).intern();
i++;
}
}catch (Throwable e){
e.printStackTrace();
}finally {
System.out.println(i);
}
}
}
1.5.8 StringTable 调优
-XX:StringTableSize=桶个数
可以设置String Table 中桶的个数,类似于一个哈希表,当表越大,每个桶中链表的长度就越小,查找的速度就越快- 考虑将字符串对象是否入池
- 如果字符串大量重复可以让字符串入池,减少重复字符串存在在heap中
1.6 使用操作系统中的直接内存
1.6.1 Direct Memory
- 常见于 NIO 操作,用于数据缓冲区
- 分配回收成本较高,但读写性能高
- 不受 JVM 内存回收管理
- 传统的阻塞式 IO 读取数据的方式:
CPU从Java的用户态转为系统的内核态,这样可以读取磁盘中的文件到系统的缓冲区,但是系统的缓冲区 Java 无法获取,所以还需要将系统缓冲区中的数据传给Java缓冲区
- 使用直接内存进行文件读取:
会产生一块 direct memory的区域,操作系统和Java都可以读取
内存溢出问题
当direct memory占用太大会抛出内存溢出异常
1.6.2 分配和回收原理
-
使用了 Unsafe 对象完成直接内存的分配回收,并且回收需要主动调用 freeMemory 方法
package com.rainsun.d1_Java_memory_structure; import sun.misc.Unsafe; import java.io.IOException; import java.lang.reflect.Field; public class d5_direct_memory { static int _1Gb = 1024*1024*1024; public static void main(String[] args) throws IOException { Unsafe unsafe = getUnsafe(); // 分配内存 long base = unsafe.allocateMemory(_1Gb); unsafe.setMemory(base, _1Gb, (byte) 0); System.in.read(); // 释放内存 unsafe.freeMemory(base); System.in.read(); } public static Unsafe getUnsafe() { try { Field f = Unsafe.class.getDeclaredField("theUnsafe"); f.setAccessible(true); Unsafe unsafe = (Unsafe) f.get(null); return unsafe; } catch (NoSuchFieldException | IllegalAccessException e) { throw new RuntimeException(e); } } }
-
ByteBuffer 的实现类内部,使用了 Cleaner (虚引用)来监测 ByteBuffer 对象,一旦 ByteBuffer 对象被垃圾回收,那么就会由 ReferenceHandler 线程通过 Cleaner 的 clean 方法调用 freeMemory 来释放直接内存
测试:
public class d6_direct_byteBuffer { static int _1Gb = 1024*1024*1024; public static void main(String[] args) throws IOException { ByteBuffer byteBuffer = ByteBuffer.allocateDirect(_1Gb); System.out.println("分配完毕"); System.in.read(); System.out.println("开始释放"); byteBuffer = null; System.gc(); System.in.read(); } }
原理:
// 分配内存后: public static ByteBuffer allocateDirect(int capacity) { return new DirectByteBuffer(capacity); } DirectByteBuffer(int cap) { super(-1, 0, cap, cap, null); boolean pa = VM.isDirectMemoryPageAligned(); int ps = Bits.pageSize(); long size = Math.max(1L, (long)cap + (pa ? ps : 0)); Bits.reserveMemory(size, cap); long base = 0; try { base = UNSAFE.allocateMemory(size); } catch (OutOfMemoryError x) { Bits.unreserveMemory(size, cap); throw x; } UNSAFE.setMemory(base, size, (byte) 0); if (pa && (base % ps != 0)) { // Round up to page boundary address = base + ps - (base & (ps - 1)); } else { address = base; } try { // Cleaner检测this对象(ByteBuffer)是否被垃圾回收,如果被回收了就会调用clean方法调用 Deallocator 中的 run 方法 释放内存 cleaner = Cleaner.create(this, new Deallocator(base, size, cap)); } catch (Throwable t) { // Prevent leak if the Deallocator or Cleaner fail for any reason UNSAFE.freeMemory(base); Bits.unreserveMemory(size, cap); throw t; } att = null; } // 实现 Runnable 接口 private static class Deallocator implements Runnable { private long address; private long size; private int capacity; private Deallocator(long address, long size, int capacity) { assert (address != 0); this.address = address; this.size = size; this.capacity = capacity; } // Deallocator 中的 run 释放了内存 public void run() { if (address == 0) { // Paranoia return; } UNSAFE.freeMemory(address); // 释放内存 address = 0; Bits.unreserveMemory(size, capacity); } } // clean 方法调用 run 方法: public void clean() { if (!remove(this)) return; try { thunk.run(); // Deallocator 中的 run 被调用 } catch (final Throwable x) { AccessController.doPrivileged(new PrivilegedAction<>() { public Void run() { if (System.err != null) new Error("Cleaner terminated abnormally", x) .printStackTrace(); System.exit(1); return null; }}); } }
1.6.3 禁用显示垃圾回收
-XX:+DisableExplicitGC
禁用显式的垃圾回收
显示垃圾回收写法:
System.gc();
这种垃圾回收都是 Full GC的,回收比较满,常用于性能调优
这可能会对Direct memory 的内存回收有影响,因为这里的Direct memory的内存回收是需要Java中的对象被回收时才会被触发的;
例如这里是ByteBuffer对象被回收,触发了分配的直接内存的回收。
所以还是用Unsafe对象手动的调用 freeMemory 进行回收比较好