jvm模型、堆内存与垃圾回收-39

一：性能监控之jvm内存模型

1.程序计数器 Program Counter Register

• 记录的是正在执行的虚拟机字节码指令的地址，
• 此内存区域是唯一一个在JAVA虚拟机规范中没有规定任何OutOfMemoryError的区域

2.虚拟机 VM Stack

• 描述的是 JAVA 方法执行的内存模型，每个方法在执行的时候都会创建一个栈帧， 用于存储局部变量表，操作数栈，动态链接，方法接口等信息
• 局部变量表存储了编译期可知的各种基本数据类型、对象引用
• 线程请求的栈深度不够会报 StackOverflowError 异常
• 栈动态扩展的容量不够会报 OutOfMemoryError 异常
• 虚拟机栈是线程隔离的，即每个线程都有自己独立的虚拟机栈

3.本地方法 Native Stack

• 本地方法栈类似于虚拟机栈，只不过本地方法栈使用的是本地方法

4.堆 Heap

• 几乎所有的对象实例都在堆上分配内存
  

二：堆

所有的对象实例以及数组都要在堆上分配。堆是垃圾收集器管理的主要区域，也被称为“GC 堆”；也是我们优化最多考虑的地方。 堆可以细分为：

1.新生代：Eden 空间 、From Survivor 空间、To Survivor 空间

2.老年代

3.永久代/元空间：Java8 以前永久代，受 jvm 管理，java8 以后元空间，直接使用物理内存。因此， 默认情况下，元空间的大小仅受本地内存限制。

从 Java8 开始，HotSpot 已经完全将永久代（Permanent Generation）移除，取而代之的是一 个新的区域—元空间（MetaSpace）

• 对象创建后，先去新生代区，如果放不下，则取GC垃圾回收。再去新生代区，如果还是放不下，就去老年区
• 老年区是新生代区无法处理的情况下，才会进去。如果老年区可以放下，则分配内存。如果还是放不下，就进行全面GC
• 如果还是放不下，则会报内存溢出异常
• 老年区一般存放生命力持久的对象以及大对象
• Eden园区能放进幸存者区就放进去，放不进去就放进老年区

三：jconsole 与 jvisualvm（可监控本地和远程应用）

Jdk 的两个小工具 jconsole、jvisualvm（升级版的 jconsole）;通过命令行启动，可监控本地和 远程应用。远程应用需要配置

1.jconsole

1）进入jconsole
win+r进入cmd，输入jconsole

双击需要连接的服务
2）查看监控信息

2.jvisualvm（推荐使用）

1）启动
win+r进入cmd，输入jvisualvm

2）jvisualvm 能干什么
监控内存泄露，跟踪垃圾回收，执行时内存、cpu 分析，线程分析…

运行：正在运行的
休眠：sleep
等待：wait
驻留：线程池里面的空闲线程
监视：阻塞的线程，正在等待锁
3）安装插件方便查看垃圾回收（gc）

• 工具->插件
  
• 可用插件->检查版本更新
  
• 如果 503 错误解决：
  打开网址 https://visualvm.github.io/pluginscenters.html
  cmd 查看自己的 jdk 版本，找到对应的
  
• 复制下面查询出来的链接。并重新设置上即可
  
• 下载gc插件
  
• 查看gc