「java堆内存监控」java堆外内存管理

本篇文章给大家谈谈java堆内存监控，以及java堆外内存管理对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、如何监控java堆内存 virtualmachine
• 2、堆内存以及磁盘空间使用情况预警
• 3、如何对java进行内存监控

如何监控java堆内存 virtualmachine

分代收集(Generational Collecting)

基于对对象生命周期分析后得出的垃圾回收算法，把对象分为年轻代、年老代、持久代，对不同生命周期的对象使用不同的算法进行回收。现在的垃圾回收器（从J2SE1.2开始）都是使用此算法。

Sun JVM内存区域分布图

1）Young（年轻代）

Young被划分为三个区间，Eden区和两个大小严格相同的Survivor区，其中Survivor区，在某一时刻只有其中一个是被使用的，另外一个留做垃圾收集时复制对象用。在Young区间变满的时候，Minor GC就会将存活的对象移到空闲的Survivor区中，根据JVM的策略，在经过几次Minor GC后，任然存活于Survivor区的对象将被移动到Tenured中。

2）Tenured（年老代）

Tenured主要保存生命周期长的对象，一般是一些老的对象，当一些对象在Young复制转移一定的次数以后，对象就会被转移到Tenured。一般如果系统中用了application级别的缓存，缓存中的对象往往会被转移到这一区间。

3）Perm（持久代）

Perm主要保存class、method、filed等对象，这部分的空间一般不会溢出，除非一次性加载了很多的类，不过在涉及到应用服务器的热部署时，有时候会遇到java.lang.OutOfMemoryError: PermGen space 的错误，造成这个错误的很大原因就有可能是每次热部署后，旧的class没有被卸载掉，这样就造成了大量的class对象保存在了Perm中，这种情况下一般重新启动应用服务器可以解决问题，或者通过-XX:MaxPermSize=N 将持久代大小设大点。

GC类型

大略上分以下2种

1）Minor GC

一般情况下，当新对象生成，并且在Eden申请空间失败时，就好触发Minor GC在Eden区清除非存活对象，并且把尚且存活的对象移动到Survivor区。然后再整理Survivor的两个区。

2）Full GC

对整个堆进行整理，包括Young、Tenured以及Perm。Full GC比Minor GC要慢，因此应该尽可能减少Full GC。以下几种原因可能导致Full GC：

Tenured或Perm被写满

System.gc被显示调用

上一次GC后堆空间分配策略动态调整

JVM调优参数

JVM提供了相应的参数来对内存大小、垃圾回收算法进行配置。

Non-standard Java HotSpot VM Options

我在32位Windows Server 2003系统8GB物理内存，JDK1.6下测试，最大可设置为1536M，再多JVM就跑不起来了。

-Xms1536M 设置JVM启动后堆的初始内存（这里配置的JVM堆空间只是Young与Tenured）

-Xmx1536M 设置JVM启动后堆的最大内存，一般在生产环境中把这两个参数设为相同值，避免在“上一次GC后堆空间分配策略动态调整”而引起Full GC

-Xss1M 设置每个线程的Java栈大小

-XX:NewRatio=2 设置Tenured和Young的比值为2:1，这样Eden+2*Survivor=1/3

堆内存

-XX:SurvivorRatio=8 设置Eden和一个Survivor的比值为8:1，这样一个Survivor就占Young区的1/10.

-XX:PermSize=64M 设置持久代初始内存

-XX:MaxPermSize=128M 设置持久代最大内存

垃圾收集器

JVM给了三种选择：串行收集器、并行收集器、并发收集器。串行收集器对于处理大数据量的情况时性能太低，所以一般选择使用并行收集器和并发收集器。J2SE5.0以后JVM会根据当前系统配置进行判断（机器配置只要有2个CPU和至少2GB的物理内存JVM将自动以-server模式运行）

1）吞吐量优先的并行收集器，通过 -XX:+UseParallelGC 指定

2）响应时间优先的并发收集器，主要是保证系统的响应时间，减少垃圾收集时的停顿时间。通过 -XX:+UseConcMarkSweepGC 指定。由于CMS GC是和应用并发执行的，因此需要耗费更多的CPU资源。

Sun JDK自带的图形监控和管理工具jconsole

通过Sun JDK自带的一个图形监控和管理工具jconsole能很容易的看到当前虚拟机中的内存状态，我使用的JDK版本是jdk1.6.0_18，这个工具从jdk1.5就有了

堆内存以及磁盘空间使用情况预警

使用知行之桥EDI系统时，由于业务数据量的增多，难免会遇到一些系统异常情况，为了保证企业生产环境的稳定运行，EDI系统自带了错误邮件通知功能。此功能保证了在EDI系统自动处理数据的过程中可以将异常信息及时告知用户，使用户收到邮件及时处理，保证数据的正常传输。

那么除了一些常见的异常情况，随着企业业务数据量的增大，现有服务器环境可能无法提供足够的磁盘空间存放数据处理的日志和文件，特别是在使用跨平台版本（JAVA版本）的知行之桥EDI系统时，此情况比较常见。基于此背景，我们提供了堆内存占用超过80% 邮件预警以及磁盘空间使用率超过80%邮件预警功能。具体实现步骤如下：

Java堆内存管理是影响性能的主要因素之一，堆内存过高可能会造成内存溢出，导致进程无法无法访问，从而使EDI系统无法正常运行。为了避免这一问题的出现，提前预警，可以参考以下步骤进行配置：

1.新建监控脚本java_heap_usage_monitor.sh文件，监控脚本的具体代码如下（注：其中_java=/home/java/jdk1.8.0_201/bin/java是当前环境中java执行路径，需要根据自身情况进行修改）：

2.将监控脚本java_heap_usage_monitor.sh文件拷贝至部署EDI的服务器。 3.给予java_heap_usage_monitor.sh文件执行权限，修改文件权限命令如下：

4.在服务器上测试监控脚本是否工作，执行以下命令，成功执行可以看到当前EDI系统占用堆内存的大小:

5.在EDI系统页面创建Script端口，修改监控脚本java_heap_usage_monitor.sh文件的存放路径，以及邮件预警收件箱地址。

Script端口具体代码如下：

6.设置Script端口自动化功能，设置定时接收，可以选择每天8点自动获取检测堆内存使用情况：

7.配置完成后，知行之桥EDI系统每天8点检测堆内存使用情况，若是堆内存使用超过80%会收到如下主题提示的邮件，邮件正文包含当前进程堆内存使用率：

磁盘空间不足也是影响EDI环境正常运行的一大原因，磁盘空间不足会导致数据无法正常处理，日志信息无法写入。同样为了避免这种情况出现，提前预警，可以参考以下方法进行配置：

1.在EDI系统页面新建Script端口，修改邮件预警收件箱地址信息。

Script端口具体代码如下：

2.设置Script端口自动化功能，设置定时接收，可以选择每天早上8点自动获取检测磁盘空间使用情况：

3.配置完成后，EDI系统每天8点检测磁盘空间使用情况，若是磁盘空间使用率超过80%会收到如下主题提示的邮件，邮件正文包含当前磁盘空间使用率：

扩展阅读：EDI是什么？ | EDI通信专家

如何对java进行内存监控

自动生成 Java 应用逻辑架构

OneAPM 可以智能探知 Java 应用之间的相互调用关系，通过串联复杂的后台组件，动态生成 J2EE 应用整体架构视图。在图中通过简单的点击钻取您可以逐级深入，查看对代码级别的诊断数据。

监控 JVM 性能和健康状况

实时监控 JVM 运行状态，通过图表展示 JVM 内存分配情况、内存使用情况、垃圾收集信息、类加载数量、JVM 线程信息以及会话信息。

快速发现 Java 异常和瓶颈

通过拓扑图直观了解分布式或 SOA 架构应用的运行状态，准确定位系统问题。同时监控后台事务和 Web 事务。

支持自定义报警策略，一旦触发报警通知必达，助您快速发现并修复时间。

关于java堆内存监控和java堆外内存管理的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。