内存结构-堆栈图（运行时数据区）
原创内存结构-堆栈图（运行时数据区）
原创
共享：堆、方法区、运行时常量池
私有：pc寄存器、jvm栈、native方法栈
https://louluan.blog.csdn.net/article/details/40043991
https://louluan.blog.csdn.net/article/details/50412126
https://louluan.blog.csdn.net/article/details/50529868
1、程序计数器
PC：Program Counter Register 程序计数器（寄存器）
作用：存储了下一条需要执行的（JVM汇编）字节码指令的地址（物理上通过寄存器来实现，因其读取速度极快）
特点：线程私有、不会存在内存溢出（JVM规范中唯一一个不存在内存溢出的区域）
JVM多线程是通过线程轮换并分配执行的指令，每个线程都有自己的PC，这样他们之间不会影响。
JVM指令 -> 解释器 -> 机器码 -> CPU运行
0: getstatic #20 // PrintStream out = System.out;
3: astore_1 // --
4: aload_1 // out.println(1);
5: iconst_1 // --
6: invokevirtual #26 // --
9: aload_1 // out.println(2);
10: iconst_2 // --
11: invokevirtual #26 // --
14: aload_1 // out.println(3);
15: iconst_3 // --
16: invokevirtual #26 // --
19: aload_1 // out.println(4);
20: iconst_4 // --
21: invokevirtual #26 // --
24: aload_1 // out.println(5);
25: iconst_5 // --
26: invokevirtual #26 // --
29: return2、虚拟机栈（VM Stack）：
该栈中的元素叫做栈帧（Stack Frame），线程在调用Java方法时，会为每一个方法创建一个栈帧（存储该方法的：局部变量表、动态链接、方法出口等信息）。
每个方法被调用和完成的过程，都对应一个栈帧从虚拟机栈中入栈和出栈的过程。
虚拟机栈的生命周期与线程相同，线程私有。
栈帧：
虚拟机栈
虚拟机栈：每个线程只能有一个活动栈帧，对应着当前正在执行的那个方法
定义：
1、每个线程运行时所需要的内存，称为虚拟机栈
2、每个栈由多个栈帧（Frame）组成，对应着每次方法调用时所占用的内存
3、每个线程只能有一个活动的栈帧，对应着当前正在执行的那个方法
栈：线程运行时需要的内存
栈帧：每个方法运行时需要的内存，一个栈帧对应一次方法的调用
代码演示虚拟机栈中栈帧的活动：如方法的调用先进后出：
1、先进：方法调用顺序和虚拟机栈的入栈顺序
2、后出：随着最后一个方法调用完，则return返回值，则逐渐的像上一层返回值；与栈帧出栈顺序一样。
方法占用的内存，随着栈帧出栈将被释放掉
问题辨析
1. 垃圾回收是否涉及(管理)栈内存？
不涉及：栈内存是一次次方法的调用产生的栈帧内存，而栈帧内存在每一次方法调用结束后都会被弹出栈即自动回收掉，所以根本不需要垃圾回收来管理栈内存。
2. 栈内存分配越大越好吗？
栈内存，在运行代码时可以通过虚拟机参数来指定。
栈内存越来反而会让线程数变少：因为物理内存大小一定，而线程的栈内存可以改变，在线程同时并发的情况下，即栈内存越大则线程数越少。
一般栈内存大小采用系统默认大小即可。
3. 方法内的局部变量是否线程安全？会不会造成局部变量x的混乱？
不会造成局部变量混乱：首先一个线程对应一个栈，线程内每次方法的调用都会产生一个新的栈帧，即方法内的局部变量是线程私有的。多线程下不会受到其他线程干扰。
但static变量是相反的，静态变量，多线程共享。
若某个东西为线程私有的则就不需要考虑线程安全，共享则需要考虑。
变量是否线程安全：是否为方法内的局部变量，是否逃离的方法的作用域范围(即其他线程有可能访问到)，若逃离则就有可能被其他线程访问，就不再是线程安全。
如果方法内局部变量没有逃离方法的作用范围，它是线程安全的
如果是局部变量引用了对象，并逃离方法的作用范围，需要考虑线程安全
栈内存溢出
栈帧过多导致栈内存溢出：栈内存大小一定，栈帧方法调用过多，回收又慢，在所有栈帧内存大于栈内存情况下会导致栈内存溢出。
方法的递归调用会导致栈帧过多。
第三方的库：如对象转为JSON对象。
栈帧过大导致栈内存溢出：
线程诊断
案例1：CPU占用过多
定位
用top定位哪个进程对cpu的占用过高
ps H -eo pid,tid,%cpu | grep 进程id （用ps命令进一步定位是哪个线程引起的cpu占用过高）
jstack 进程id
可以根据线程id 找到有问题的线程，进一步定位到问题代码的源码行号
案例2：程序运行很长时间没有结果
多个线程发生死锁
本地方法栈（Native Method Stack）：
线程私有，用来存储线程调用的本地方法（本地方法的局部变量表、操作栈等信息），功能与虚拟机栈非常相似。
java虚拟机调用本地方法时，需要给这些本地方法提供的一个内存空间。
本地方法如：Object里的clone()、hashCode()、wait()、notify()等堆（Heap）：线程共享，在虚拟机启动时创建；用来存放对象实例，几乎所有的对象实例都是在这里分配内容
堆区是垃圾回收器管理的主要区域。
定义
Heap 堆
通过 new 关键字，创建对象都会使用堆内存
特点
它是线程共享的，堆中对象都需要考虑线程安全的问题
有垃圾回收机制
堆内存溢出
对象没有被回收一直在使用....？
堆内存诊断
1. jps 工具
查看当前系统中有哪些 java 进程
2. jmap 工具
查看堆内存占用情况 jmap - heap 进程id
3. jconsole 工具
图形界面的，多功能的监测工具，可以连续监测
案例
垃圾回收后，内存占用仍然很高
jvirsualvm方法区（Method Area）：线程共享，用于存储已经被虚机加载的类信息、常量、静态变量、即时编译器编译出来的代码等数据。
方法区存储类的数据
方法区内存溢出
1.8 以前会导致永久代内存溢出
1.8 之后会导致元空间(系统)内存溢出
类加载个数过多导致内存溢出
场景：
spring：代理类、mybatis：mapping接口
常量池
运行时常量池
常量池：就是一张表，虚拟机指令根据这张常量表找到要执行的类名、方法名、参数类型、字面量等信息
运行时常量池：常量池是 *.class 文件中的，当该类被加载，它的常量池信息就会放入运行时常量池，并把里面的符号地址变为真实地址
二进制字节码（类基本信息、常量池、类方法定义、包含了虚机指令）
StringTable
先看几道面试题：
String s1 = "a";
String s2 = "b";
String s3 = "a" + "b"; //s3是常量字符串拼接，在编译期被优化为："ab"，常量池中没有，则入常量池
String s4 = s1 + s2; //s4是两个变量的拼接，在运行期间通过StringBuild做字符串拼接，产生新的字符串对象放在堆里：new String("ab")
String s5 = "ab"; //s5检查常量池中是否有"ab"，发现已有，就不再创建，直接引用已有的对象
String s6 = s4.intern(); //intern方法首先看常量池中是否有这个对象，如果有则返回，如果没有则把这个s4值做一个入池的动作
// 问
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"); //堆中：new String("cd")
String x1 = "cd"; //"cd"入常量池
x2.intern(); //直接引用"cd"
// 问，如果调换了【最后两行代码】的位置呢，如果是jdk1.6呢 //false ？？？
System.out.println(x1 == x2); //false
StringTable 特性（串池，HashTable 存储）
常量池中的字符串仅是符号，第一次用到时才变为对象
利用串池的机制，来避免重复创建字符串对象
字符串变量拼接的原理是 StringBuilder （1.8）
字符串常量拼接的原理是编译期优化
可以使用 intern 方法，主动将串池中还没有的字符串对象放入串池
1.8 将这个字符串对象尝试放入串池，如果有则并不会放入，如果没有则放入串池， 会把串池中的对象返回（即调用intern()方法后会改变s2的值，前后 String s2 = new String("c") + new String("d"); 与 s2.intern(); 发生变化后始终保持一致，为常量值存放在串池）
1.6 将这个字符串对象尝试放入串池，如果有则并不会放入，如果没有会把此对象复制一份，放入串池， 会把串池中的对象返回（即调用intern()方法后不会改变s2的值，前后 String s2 = new String("c") + new String("d"); 与 s2.intern(); 发生变化后其值都是其当时的值，前者还是new的对象存放在堆里，后者为常量值存放在串池）
常量池和串池的关系：
常量池存在于字节码文件中，当运行时，常量池中的信息就会被加载到运行常量池中，这时a、b、ab都还是常量池中的符号，还没有变为java字符串对象
等到具体执行到引用的哪行代码时，如：String s1 = "a";，就会把符号变为相关的java字符串对象，再把该字符串对象存入串池StringTable中（若不存在）
String s4 = s1 + s2；
s4 最终的局部变量astore存储在localVarLabelTable中的Slot4号位置：
StringTable位置：
jvm永久代回收效率比较低，等到整个老年代空间不足，才触发回收，导致StringTable回收效率并不高。
StringTable 存放常量对象，使用比较频繁，若其回收效率不高，则会占用大量的内存，进而会产生永久代的内存不足。
基于以上缺点，就把StringTable 从1.7开始转移到堆里。
在堆里在miniGen就开始回收，大大减轻了字符串对内存的占用。
StringTable垃圾回收机制
StringTable性能调优：底层哈希表
调整 -XX:StringTableSize=桶个数
考虑将字符串是否入池（去除相同地址）
直接内存：操作系统内存，不是java虚拟机内存
常见于NIO操作时，用于数据缓冲区
分配回收成本高，但读写性能高
不收JVM内存回收管理
直接内存基本使用：
演示ByteBuffer，其性能比较高
使用ByteBuffer后：
直接内存溢出：
直接内存释放原理：
ByteBuffer = null； 垃圾回收掉1G内存
垃圾回收不会管理直接内存，为什么会让1G内存释放掉；垃圾回收只能释放java的内存，会自动释放掉无用的对象。
而直接内存需要手动unsafe.freeMemory()来释放掉系统内存。
分配和回收原理
使用了 Unsafe 对象完成直接内存的分配回收，并且回收需要主动调用 freeMemory 方法
ByteBuffffer 的实现类内部，使用了 Cleaner （虚引用）来监测 ByteBuffffer 对象，一旦
ByteBuffffer 对象被垃圾回收，那么就会由 ReferenceHandler 线程通过 Cleaner 的 clean 方法调
用 freeMemory 来释放直接内存
禁用显式回收对直接内存的影响：
不会触发java中的垃圾回收
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。