zhulibin2012

深入理解java虚拟机---java虚拟机内存管理(七)

　　本地方法栈、java堆、方法区

本地方法栈在HotSpot版本内与java虚拟机栈是合二为一的.不单独区分本地方法栈.但是java虚拟机中是有这样一块区域的.

作用:

 1.本地方法栈为虚拟机栈执行java方法服务

 2.本地方法栈为虚拟机栈执行navtive方法服务

　　java堆

java堆是线程共享区的堆内存.供所有线程共享.

作用:

 1.存放对象实例

 2.垃圾收集器管理的主要区域

 3.新生代,老年代,Eden空间

通过参数设定大小: -Xmx -Xms

会报OutMemoryError错误

堆内存设置

原理

JVM堆内存分为2块：Permanent Space 和 Heap Space。
  • Permanent 即 持久代（Permanent Generation），主要存放的是Java类定义信息，与垃圾收集器要收集的Java对象关系不大,也就是之前说的方法区。
  • Heap = { Old + NEW = {Eden, from, to} }，Old 即 年老代（Old Generation），New 即 年轻代（Young Generation）。年老代和年轻代的划分对垃圾收集影响比较大。
  • 可以通过代码展示出来,目前jdk8已经将持久带删除,暂且不论:
  •    首先你说的“持久代”仅仅是HotSpot存在的一个概念，并且将其置于方法区，JRocket与IBM的VM都不存在这个“持久代”，最新的HotSpot也计划将其移除。所以你说的都对，在heap中和在Method Area中并没定论。 

 

 

年轻代

所有新生成的对象首先都是放在年轻代。年轻代的目标就是尽可能快速的收集掉那些生命周期短的对象。年轻代一般分3个区，1个Eden区，2个Survivor区（from 和 to）。

大部分对象在Eden区中生成。当Eden区满时，还存活的对象将被复制到Survivor区（两个中的一个），当一个Survivor区满时，此区的存活对象将被复制到另外一个Survivor区，当另一个Survivor区也满了的时候，从前一个Survivor区复制过来的并且此时还存活的对象，将可能被复制到年老代。

2个Survivor区是对称的，没有先后关系，所以同一个Survivor区中可能同时存在从Eden区复制过来对象，和从另一个Survivor区复制过来的对象；而复制到年老区的只有从另一个Survivor区过来的对象。而且，因为需要交换的原因，Survivor区至少有一个是空的。特殊的情况下，根据程序需要，Survivor区是可以配置为多个的（多于2个），这样可以增加对象在年轻代中的存在时间，减少被放到年老代的可能。

针对年轻代的垃圾回收即 Young GC。

年老代

在年轻代中经历了N次（可配置）垃圾回收后仍然存活的对象，就会被复制到年老代中。因此，可以认为年老代中存放的都是一些生命周期较长的对象。

针对年老代的垃圾回收即 Full GC。

持久代

用于存放静态类型数据，如 Java Class, Method 等。持久代对垃圾回收没有显著影响。但是有些应用可能动态生成或调用一些Class，例如 Hibernate CGLib 等，在这种时候往往需要设置一个比较大的持久代空间来存放这些运行过程中动态增加的类型。

 

所以，当一组对象生成时，内存申请过程如下：

  1. JVM会试图为相关Java对象在年轻代的Eden区中初始化一块内存区域。
  2. 当Eden区空间足够时，内存申请结束。否则执行下一步。
  3. JVM试图释放在Eden区中所有不活跃的对象（Young GC）。释放后若Eden空间仍然不足以放入新对象，JVM则试图将部分Eden区中活跃对象放入Survivor区。
  4. Survivor区被用来作为Eden区及年老代的中间交换区域。当年老代空间足够时，Survivor区中存活了一定次数的对象会被移到年老代。
  5. 当年老代空间不够时，JVM会在年老代进行完全的垃圾回收（Full GC）。
  6. Full GC后，若Survivor区及年老代仍然无法存放从Eden区复制过来的对象，则会导致JVM无法在Eden区为新生成的对象申请内存，即出现“Out of Memory”。

OOM（“Out of Memory”）异常一般主要有如下2种原因：

1. 年老代溢出，表现为：java.lang.OutOfMemoryError:Javaheapspace
这是最常见的情况，产生的原因可能是：设置的内存参数Xmx过小或程序的内存泄露及使用不当问题。
例如循环上万次的字符串处理、创建上千万个对象、在一段代码内申请上百M甚至上G的内存。还有的时候虽然不会报内存溢出，却会使系统不间断的垃圾回收，也无法处理其它请求。这种情况下除了检查程序、打印堆内存等方法排查，还可以借助一些内存分析工具，比如MAT就很不错。

2. 持久代溢出，表现为：java.lang.OutOfMemoryError:PermGenspace
通常由于持久代设置过小，动态加载了大量Java类而导致溢出，解决办法唯有将参数 -XX:MaxPermSize 调大（一般256m能满足绝大多数应用程序需求）。将部分Java类放到容器共享区（例如Tomcat share lib）去加载的办法也是一个思路，但前提是容器里部署了多个应用，且这些应用有大量的共享类库。

参数说明

  • -Xmx3550m：设置JVM最大堆内存为3550M。
  • -Xms3550m：设置JVM初始堆内存为3550M。此值可以设置与-Xmx相同，以避免每次垃圾回收完成后JVM重新分配内存。
  • -Xss128k：设置每个线程的栈大小。JDK5.0以后每个线程栈大小为1M，之前每个线程栈大小为256K。应当根据应用的线程所需内存大小进行调整。在相同物理内存下，减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在3000~5000左右。需要注意的是：当这个值被设置的较大（例如>2MB）时将会在很大程度上降低系统的性能。
  • -Xmn2g：设置年轻代大小为2G。在整个堆内存大小确定的情况下，增大年轻代将会减小年老代，反之亦然。此值关系到JVM垃圾回收，对系统性能影响较大，官方推荐配置为整个堆大小的3/8。
  • -XX:NewSize=1024m：设置年轻代初始值为1024M。
  • -XX:MaxNewSize=1024m：设置年轻代最大值为1024M。
  • -XX:PermSize=256m：设置持久代初始值为256M。
  • -XX:MaxPermSize=256m：设置持久代最大值为256M。
  • -XX:NewRatio=4：设置年轻代（包括1个Eden和2个Survivor区）与年老代的比值。表示年轻代比年老代为1:4。
  • -XX:SurvivorRatio=4：设置年轻代中Eden区与Survivor区的比值。表示2个Survivor区（JVM堆内存年轻代中默认有2个大小相等的Survivor区）与1个Eden区的比值为2:4，即1个Survivor区占整个年轻代大小的1/6。
  • -XX:MaxTenuringThreshold=7：表示一个对象如果在Survivor区（救助空间）移动了7次还没有被垃圾回收就进入年老代。如果设置为0的话，则年轻代对象不经过Survivor区，直接进入年老代，对于需要大量常驻内存的应用，这样做可以提高效率。如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象在年轻代存活时间，增加对象在年轻代被垃圾回收的概率，减少Full GC的频率，这样做可以在某种程度上提高服务稳定性。

疑问解答

-Xmn，-XX:NewSize/-XX:MaxNewSize，-XX:NewRatio 3组参数都可以影响年轻代的大小，混合使用的情况下，优先级是什么？
如下：
  1. 高优先级：-XX:NewSize/-XX:MaxNewSize 
  2. 中优先级：-Xmn（默认等效  -Xmn=-XX:NewSize=-XX:MaxNewSize=?） 
  3. 低优先级：-XX:NewRatio 
推荐使用-Xmn参数，原因是这个参数简洁，相当于一次设定 NewSize/MaxNewSIze，而且两者相等，适用于生产环境。-Xmn 配合 -Xms/-Xmx，即可将堆内存布局完成。
-Xmn参数是在JDK 1.4 开始支持。

实验

设置虚拟机参数: -verbose:gc -XX:+PrintGCDetails -Xms20M -Xmx20M -Xmn10M 

java -verbose:gc:Java应用启动时，可以通过设置verbose参数来输出JVM的gc情况

-XX:+PrintGCDetails:gc的详细信息

-Xms:设置jvm启动时初始内存

-Xmx:设置jvm最大可用内存

-Xmn:设置年轻代的可用内存

典型设置：

    • java -Xmx3550m -Xms3550m -Xmn2g -Xss128k
      -Xmx3550m：设置JVM最大可用内存为3550M。
      -Xms3550m：设置JVM促使内存为3550m。此值可以设置与-Xmx相同，以避免每次垃圾回收完成后JVM重新分配内存。
      -Xmn2g：设置年轻代大小为2G。整个JVM内存大小=年轻代大小 + 年老代大小 + 持久代大小。持久代一般固定大小为64m，所以增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8。
      -Xss128k：设置每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M，以前每个线程堆栈大小为256K。更具应用的线程所需内存大小进行调整。在相同物理内存下，减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在3000~5000左右。
    • java -Xmx3550m -Xms3550m -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:MaxPermSize=16m -XX:MaxTenuringThreshold=0
      -XX:NewRatio=4:设置年轻代（包括Eden和两个Survivor区）与年老代的比值（除去持久代）。设置为4，则年轻代与年老代所占比值为1：4，年轻代占整个堆栈的1/5
      -XX:SurvivorRatio=4：设置年轻代中Eden区与Survivor区的大小比值。设置为4，则两个Survivor区与一个Eden区的比值为2:4，一个Survivor区占整个年轻代的1/6
      -XX:MaxPermSize=16m:设置持久代大小为16m。
      -XX:MaxTenuringThreshold=0：设置垃圾最大年龄。如果设置为0的话，则年轻代对象不经过Survivor区，直接进入年老代。对于年老代比较多的应用，可以提高效率。如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象再年轻代的存活时间，增加在年轻代即被回收的概论。

 设置jvm参数:

 

 

 运行:

 

 

结果分析:

 如上,堆内存最大为20M,而且限制Edin新生代区共10M其中eden为8M,两个2个Survivor区（from 和 to)个1M.

根据规则:

 新生成的对象优先进入到EDEN,b1,b2,b3全部进入,目前eden只剩下2M,但是还有一个4M放不下.所以就会发生Manor GC(发生在新生代)回收,full GC回收的区域为老年代.但是回收失败,所以就发生了应该放到survivor区,但是servivor区也没有内存.就发生了内存分配担保,向老年代去借内存.这时在EDEN的6M进入到老年代.剩余4G进入到Edon中.

 

注意:

一.打印内存信息解释

在Eclipse中可以通过Run As|Run Configurations|Arguments|VM Arguments进行设置。
使用该命令后输出如下：
[Full GC 1224K->1113K(123584K), 0.0120528 secs]
箭头（->）前后的数据1224K和1113K分别表示垃圾收集GC前后所有存活对象使用的内存容量，说明有1224K–1113K = 111K大小的对象被回收，括号内的数据 123584K为堆内存的总容量，收集所需的实际为 0.0120528秒。
需要注意的是：GC会暂用CPU时间片，会造成程序短暂的停顿。
控制台输出GC信息还可以使用如下命令：
在JVM的启动参数中加入-XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCApplicationStoppedTime，按照参数的顺序分别输出GC的简要信息，GC的详细信息、GC的时间信息及GC造成的应用暂停的时间。

二.xms和Xmx设置一致的目的

java内存堆栈不够用时我们会寻求java参数-Xms和-Xmx的帮助，网上也有许多前辈给出了例子，但很多人喜欢把-Xms和-Xmx的值设置成一样的，甚至我还见过有吧-Xms设的比-Xmx还要大（-Xms是最小值，-Xmx是最大值）。

    一开始我也不知道这两个值设成一样会有什么问题，但是我在作项目http://youmonitor.us/ 时发现，当我把-Xms和-Xmx设置成一样时，Java会不断地吃内存。起先不知道怎么回事，经过测试后发现，原来java的垃圾回收器在内存使用达到-Xms值的时候才会开始回收，如果两个值一样，那就意味着，只有当java使用完所有内存时才会回收垃圾，这样一来内存当然不停的涨。

     方法区

作用: 存储虚拟机加载的类信息,常量,静态变量,即时编译器后的代码等数据

　　类信息: 类的版本,字段,方法,接口

方法区和永久代

  1.在HotSpot中使用永久代管理方法区

  2.垃圾回收在方法区的行为

异常定义:OutMemory

  

和java堆一样，方法区是一块所有线程共享的内存区域，用于保存系统的类信息，类的信息有哪些呢。字段、方法、常量池。方法区也有一块内存区域所以方法区的内存大小，决定了系统可以包含多少个类，如果系统类太多，方法区内存不够肯定会导致方法区溢出，虚拟机同样会抛出内存溢出信息。(内存溢出后面相关文章给大家总结)

jdk6和jdk7中，方法区可以理解为永久区(Perm).永久区可以使用参数-XX:PermSize和-XX:MaxPermSize制定。默认情况下-XX:MaxPermSize为64MB.如果你项目中使用代理模式或者CGLIB的话可能在运行的时候生成大量的类，如果这样，需要设置一下永久区的大小，防止永久区内存溢出。

CGLIB会在后面专门的章节和代理模式一起讲解。(这个系列专注的是JVM的讲解)

使用下面代码：

 

[java] view plain copy
 
  1. for (int i = 0; i <10000; i++) {  
  2. CglibWapper c=new CglibWapper("cn.springok.perm"+i)  
  3. }  



 

代码解释：会根据传入的参数动态生成一个类以及类的实例。因为对象实例化，类的字段、方法、常量池保存在方法区，因此操作会占用一定内存的。

大量的类可能导致方法区溢出，使用下面的参数运行代码：

-XX:PermSize=10M  -XX:MaxPermSize=10M -XX:PrintGCDetails

参数说明：

-XX:PermSize=10M  初始永久区大小10M

-XX:MaxPermSize 方法区最大内存10M。

-XX:PrintGCDetails 打印日志详情。

执行程序部分输出如下:

 compacting perm gen  total 86272K, used 86136K [0x44600000, 0x49a40000, 0x64600000) 

   the space 86272K,  99% used [0x44600000, 0x49a1e2f8, 0x49a1e400, 0x49a40000) 

系统内存溢出了，扩大-XX:MaxPermSize值，可以生成更多的类。

可以使用工具Visual VM观察方法区的具体使用情况。

 

需要注意一点：

jdk8中永久区被移除了，取而代之的是元数据区，可能方法区依赖jvm的内存吧。元数据区可以使用-XX:MaxMetaspaceSize制定，跟之前版本的-XX:MaxPermSize一样，分配的值越多，就可以支持更多的类。不同的是元数据区是堆外直接内存，与方法永久区不同，在不指定大小的情况下，虚拟机会耗尽所有可用的系统内存。

元数据区发生溢出，虚拟机一样抛出异常，如下：

java.lang.OutOfMemoryError Metaspace

方法区和持久代和元组的关系解释见下文: 

https://blog.csdn.net/hylexus/article/details/53771460

posted on 2018-05-03 06:08  zhulibin2012  阅读(160)  评论(0)  编辑  收藏  举报

导航