JVM内存分析

贴图:

一、程序计数器(Program Counter Register)

????程序计数器就是记录当前线程执行程序的位置,改变计数器的值来确定执行的下一条指令,比如循环、分支、方法跳转、异常处理,线程恢复都是依赖程序计数器来完成。
????Java虚拟机多线程是通过线程轮流切换并分配处理器执行时间的方式实现的。为了线程切换能恢复到正确的位置,每条线程都需要一个独立的程序计数器,所以它是线程私有的。
?
???如果线程正在执行的是一个Java方法,这个计数器记录的是正在执行的虚拟机字节码指令的地址;如果正在执行的是Native方法,这个计数器值则
为空(Undefined)。此内存区域是唯一一个在Java虚拟机规范中没有规定任何OutOfMemoryError情况的区域。

二、java虚拟机栈(VM Stack)

????java虚拟机栈是线程私有,生命周期与线程相同。创建线程的时候就会创建一个java虚拟机栈。
????虚拟机执行java程序的时候,每个方法都会创建一个栈帧,栈帧存放在java虚拟机栈中,通过压栈出栈的方式进行方法调用。
????栈帧又分为一下几个区域:局部变量表、操作数栈、动态连接、方法出口等。
????平时我们所说的变量存在栈中,这句话说的不太严谨,应该说局部变量存放在java虚拟机栈的局部变量表中。
????java的8中基本类型的局部变量的值存放在虚拟机栈的局部变量表中,如果是引用型的变量,则只存储对象的引用地址。

注意:

  • 当用户请求web服务器,每个请求开启一个线程负责用户的响应计算(每个线程分配一个虚拟机栈空间),如果并发量大时,可能会导致内存溢出(OutOfMemoneyError),可以适当的把每个虚拟机栈的大小适当调小一点,减少内存的使用量来提高系统的并发量。
  • 当栈空间调小以后,又会引发方法调用深度的的问题。因为,每个方法都会生成一个栈帧,如果方法调用深度很深就意味着,栈里面存放大量的栈帧,可能导致栈内存溢出(StackOverFlowError)。

三、本地方法栈(Native Method Stack)

????本地方法栈 为虚拟机使用到本地方法服务(native)。本地方法栈为线程私有,功能和虚拟机栈非常类似。线程在调用本地方法时,来存储本地方法的局部变量表,本地方法的操作数栈等等信息。

四、堆(Heap):

????堆是被所有线程共享的区域,实在虚拟机启动时创建的。堆里面存放的都是对象的实例(new 出来的对象都存在堆中)。
????我们平常所说的垃圾回收,主要回收的就是堆区。为了提升垃圾回收的性能,又把堆分成两块区新生代(young)年老代(old),更细一点划分新生代又可划分为Eden区和2个Survivor区(From Survivor和To Survivor)。

  • Eden:新创建的对象存放在Eden区
  • From Survivor和To Survivor:保存新生代gc后还存活的对象。(使用复制算法,导致有一个 Survivor空间浪费)Hotspot虚拟机新生代Eden和Survivor的大小比值为4:1,因为有两个Survivor,所以 Eden:From Survivor:To Survivor比值为8:1:1。
  • 老年代:对象存活时间比较长(经过多次新生代的垃圾收集,默认是15次)的对象则进入老年的。
    当堆中分配的对象实例过多,且大部分对象都在使用,就会报内存溢出异常(OutOfMemoneyError)。

五、方法区

????方法区是被所有线程共享区域,用于存放已被虚拟机加载的类信息,常量,静态变量等数据。被Java虚拟机描述为堆的一个逻辑部分。习惯是也叫它永久代(permanment generation)
????永久代也会垃圾回收,主要针对常量池回收,类型卸载(比如反射生成大量的临时使用的Class等信息)。
????常量池用于存放编译期生成的各种字节码和符号引用,常量池具有一定的动态性,里面可以存放编译期生成的常量;运行期间的常量也可以添加进入常量池中,比如string的intern()方法。
????当方法区满时,无法在分配空间,就会抛出内存溢出的异常(OutOfMemoneyError)。
java8中已经没有方法区了,取而代之的是元空间(Metaspace)。

六:直接内存

????直接内存(Direct Memory)并不是虚拟机运行时数据区的一部分,也不是Java虚拟机规范中定义的内存区域,但是这部分内存也被频繁地使用,而且也可能导致OutOfMemoryError异常出现。
?
???JDK1.4加的NIO中,ByteBuffer有个方法是allocateDirect(int capacity)
,这是一种基于通道(Channel)与缓冲区(Buffer)的I/O方式,它可以使用Native函数库直接分配堆外内存,然后通过一个存储在
Java堆里面的DirectByteBuffer对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能,因为避免了在Java堆和
Native堆中来回复制数据。

作者:jijs
链接:file:///C:/Users/Administrator/Desktop/%E9%9D%A2%E8%AF%95/JVM%E5%86%85%E5%AD%98%E6%A8%A1%E5%9E%8B%20-%20%E7%AE%80%E4%B9%A6.htm
來源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

时间: 2024-11-03 22:46:14

JVM内存分析的相关文章

JVM内存分析命令

原文:http://www.javaranger.com/archives/1063 jinfo: 查看Java进程的栈空间大小:sudo -u tomcat /home/java/default/bin/jinfo -flag ThreadStackSize 14750 查看是否使用了压缩指针:sudo -u tomcat /home/java/default/bin/jinfo -flag UseCompressedOops 14750 查看系统属性:sudo -u tomcat /home

Java内存分析1 - 从两个程序说起

这次看一些关于JVM内存分析的内容. 首先来看两个程序,这里是程序一:JVMStackTest,看下代码: package com.zhyea.robin.jvm; public class JVMStackTest { private static int count = 0; private void recur() { ++count; recur(); System.out.println("recur()方法执行结束"); } public static void main(

配置JVM内存 查看内存工具

一.配置JVM内存 1.配置JVM内存的参数有四个: -XmxJavaHeap最大值,默认值为物理内存的1/4,最佳设值应该视物理内存大小及计算机内其他内存开销而定: -XmsJavaHeap初始值,Server端JVM最好将-Xms和-Xmx设为相同值,开发测试机JVM可以保留默认值: -XmnJavaHeapYoung区大小,不熟悉最好保留默认值: -Xss每个线程的Stack大小,不熟悉最好保留默认值: 2.如何配置JVM内存分配: (1)当在命令提示符下启动并使用JVM时(只对当前运行的

jvm内存对象分析

1.jmap -histo <pid> 可以查看指定pid的jvm内存状况 2.jmap -dump:file=dump.txt <pid> 以将指定pid的jvm中堆信息输出到文件中 在服务器上,这个文件比较大,我在公司的服务器上生成的文件2.3G 所以,最好不要在服务器上分析这个文件 可以将文件拷贝到本地,CRT可以用sz命令将文件下载到本地 3.jhat -J-Xmx4096m dump.txt 分析dump文件,由于我生成的文件比较大(2.3G),所以给了4096m内存去分

JVM内存最大能调多大分析

上次用weblogic 把 -XmxXXXX 设成2G,就启动不起来,设小点就起来了,当时很气,怎么2G都起不了,今天在看到了一篇解释,转过来了这 次一位老友提出了这个问题,记得当年一个java高手在blogjava提出后,被骂 上次用weblogic 把 -XmxXXXX 设成2G,就启动不起来,设小点就起来了,当时很气,怎么2G都起不了,今天在看到了一篇解释,转过来了 这 次一位老友提出了这个问题,记得当年一个java高手在blogjava提出后,被骂得半死.大家使用java -XmxXXX

Java调优之jvm和线程的内存分析

这几天因为自己开发的一个网站在768M内存的机器上撑不起100多个用户的运行,因为每个用户启用功能后,系统将为每个用户分配8个左右的独立线程,我的这篇文章http://www.mzone.cc/article/311.html也有介绍的.在内存小的机器上经常出现的问题就是Cann't allocate memory和OutOfMemoryError错误,这个要从jvm的内存结构来进行分析了.在jvm内存调整过程中,我们经常使用的参数就是: -Xms 为jvm启动时分配的内存,比如-Xms200m

Linux与jvm内存关系分析

原文出处: 美团技术团队 引言 在一些物理内存为8g的服务器上,主要运行一个Java服务,系统内存分配如下:Java服务的JVM堆大小设置为6g,一个监控进程占用大约600m,Linux自身使用大约800m.从表面上,物理内存应该是足够使用的:但实际运行的情况是,会发生大量使用SWAP(说明物理内存不够使用了),如下图所示.同时,由于SWAP和GC同时发生会致使JVM严重卡顿,所以我们要追问:内存究竟去哪儿了? 要分析这个问题,理解JVM和操作系统之间的内存关系非常重要.接下来主要就Linux与

JVM 监控以及内存分析

1 内存分析1.1 jmap -histo 命令pid=`jps | awk '{if ($2 == "Jps") print $1}'`jmap -histo $pid >>1.txt 查看pid中类的内存占用num     #instances(实例数)         #bytes(占用字节)  class name class name 解读B代表byte C代表char D代表double F代表float I代表int J代表long Z代表boolean 前边

jvm 内存,线程,gc分析

1.查看 gc的次数,和各个垃圾回收区域的内存比例  jstat : jstat -gcutil pid interval(ms) 例子:jstat -gcutil 332 1000 参数说明如下: S0: 新生代中Survivor space 0区已使用空间的百分比 S1: 新生代中Survivor space 1区已使用空间的百分比E: 新生代已使用空间的百分比O: 老年代已使用空间的百分比P: 永久带已使用空间的百分比 YGC: 从应用程序启动到当前,发生Yang GC 的次数 YGCT: