为什么设置-Xmx4g但是java进程内存占用达到8g?

本文涉及的产品
文档翻译,文档翻译 1千页
文本翻译,文本翻译 100万字符
图片翻译,图片翻译 100张
简介: 为什么设置-Xmx4g但是java进程内存占用达到8g?

前言


不知道大家在开发过程中有没有遇到过类似的问题,明明通过JVM参数-Xmx4g设置了最大堆内存大小为4g,但是程序运行一段时间后发现占用的内存明显超过了8g,却并没有出现内存溢出等问题,那是什么东西占用了额外的内存空间呢?


一、背景


1.通过free -g查看服务器内存使用情况

89.png

2.通过ps查看java进程

项目启动命令为:


java -Xmx6g -Xms6g - -XX:+UseG1GC -jar /home/pgcp/pgcp-0.0.1-SNAPSHOT.jar


88.png

3.通过top命令查看资源使用情况

87.png

VIRT:virtual memory usage 虚拟内存

1、进程“需要的”虚拟内存大小,包括进程使用的库、代码、数据等

2、假如进程申请100m的内存,但实际只使用了10m,那么它会增长100m,而不是实际的使用量


RES:resident memory usage 常驻内存

1、进程当前使用的内存大小,但不包括swap out

2、包含其他进程的共享

3、如果申请100m的内存,实际使用10m,它只增长10m,与VIRT相反

4、关于库占用内存的情况,它只统计加载的库文件所占内存大小


SHR:shared memory 共享内存

1、除了自身进程的共享内存,也包括其他进程的共享内存

2、虽然进程只使用了几个共享库的函数,但它包含了整个共享库的大小

3、计算某个进程所占的物理内存大小公式:RES – SHR

4、swap out后,它将会降下来


问题:

java项目启动通过Xmx6g设置了最大堆内存为6g,但是项目运行一段时间后发现,项目进行占用的内存飙升到了12g。

难道设置的JVM参数没有生效?内存是被什么东西吃掉了?


二、通过jmap查看JVM内存分配


jmap -heap 打印heap的概要信息,GC使用的算法,heap(堆)的配置及JVM堆内存的使用情况.


命令:

jmap -heap 2196

86.png


发现JVM采用的G1垃圾回收器,堆内存的大小为6g。说明项目启动时设置的JVM参数是生效的。


三、通过NMT分析java进程的内存分配


1.什么是NMT

NMT的全称是Native Memory Tracker ,是一个本地内存跟踪工具。

常用来分析JVM的内存使用情况。


2.如何开启NMT

NMT功能默认关闭,可以通过以下方式开启:

-XX:NativeMemoryTracking=[off | summary | detail]


配置项 说明

off 默认配置

summary 只收集汇总信息

detail 收集每次调用的信息

注意,根据Java官方文档,开启NMT会有5%-10%的性能损耗;


如果想JVM退出时打印退出时的内存使用情况,可以通过如下配置项:


-XX:+UnlockDiagnosticVMOptions -XX:+PrintNMTStatistics


采用如下命令重启项目:

java -Xmx8g -Xms8g - -XX:+UseG1GC -XX:NativeMemoryTracking=detail -jar /home/pgcp/pgcp-0.0.1-SNAPSHOT.jar


3.通过jcmd命令分析java进程的内存

首先通过jps找到对应的Java程序的pid,然后使用如下命令:


jcmd <pid> VM.native_memory


也可以通过一下命令指定内存单位,并将结果输出到文本中

jcmd 16696  VM.native_memory detail scale=MB >temp.txt


85.png

可以看到java进程的整个memory主要包含了Java Heap、Class、Thread、Code、GC、Internal、Symbol、Native Memory Tracking、unknown这几部分;其中reserved表示应用可用的内存大小,committed表示应用正在使用的内存大小。


分析:

可以看到,除了Java Heap占用了8g内存,Class和Internal也各占用了1g左右的内存。


JVM的内存

先放一张JVM的内存划分图,总体上可以分为堆和非堆(粗略划分,基于java8)



84.png

83.png

那么一个Java进程最大占用的物理内存为:

Max Memory = eden + survivor + old + String Constant Pool + Code cache + compressed class space + Metaspace + Thread stack(*thread num) + Direct + Mapped + JVM + Native Memory


堆和非堆内存

堆和非堆内存有以下几个概念:

init

表示JVM在启动时从操作系统申请内存管理的初始内存大小(以字节为单位)。JVM可能从操作系统请求额外的内存,也可以随着时间的推移向操作系统释放内存(经实际测试,这个内存并没有过主动释放)。这个init的值可能不会定义。


used

表示当前使用的内存量(以字节为单位)


committed

表示保证可供 Jvm使用的内存大小(以字节为单位)。 已提交内存的大小可能随时间而变化(增加或减少)。 JVM也可能向系统释放内存,导致已提交的内存可能小于 init,但是committed永远会大于等于used。


max

表示可用于内存管理的最大内存(以字节为单位)。


NMT的输出说明:

Native Memory Tracking:
Total: reserved=6988749KB, committed=3692013KB
 堆内存
- Java Heap (reserved=5242880KB, committed=3205008KB)
 (mmap: reserved=5242880KB, committed=3205008KB)
 类加载信息
- Class (reserved=1114618KB, committed=74642KB)
 (classes #10657)
 (malloc=4602KB #32974)
 (mmap: reserved=1110016KB, committed=70040KB)
 线程栈
- Thread (reserved=255213KB, committed=255213KB)
 (thread #248)
 (stack: reserved=253916KB, committed=253916KB)
 (malloc=816KB #1242)
 (arena=481KB #494)
 代码缓存
- Code (reserved=257475KB, committed=46551KB)
 (malloc=7875KB #10417)
 (mmap: reserved=249600KB, committed=38676KB)
 垃圾回收
- GC (reserved=31524KB, committed=23560KB)
 (malloc=17180KB #2113)
 (mmap: reserved=14344KB, committed=6380KB)
 编译器
- Compiler (reserved=598KB, committed=598KB)
 (malloc=467KB #1305)
 (arena=131KB #3)
 内部
- Internal (reserved=6142KB, committed=6142KB)
 (malloc=6110KB #23691)
 (mmap: reserved=32KB, committed=32KB)
 符号
- Symbol (reserved=11269KB, committed=11269KB)
 (malloc=8544KB #89873)
 (arena=2725KB #1)
 nmt
- Native Memory Tracking (reserved=2781KB, committed=2781KB)
 (malloc=199KB #3036)
 (tracking overhead=2582KB)
- Arena Chunk (reserved=194KB, committed=194KB)
 (malloc=194KB)
- Unknown (reserved=66056KB, committed=66056KB)
 (mmap: reserved=66056KB, committed=66056KB)


nmt返回结果中有reserved和committed两个值,这里解释一下:

reserved

reserved memory 是指JVM 通过mmaped PROT_NONE 申请的虚拟地址空间,在页表中已经存在了记录(entries),保证了其他进程不会被占用。


在堆内存下,就是xmx值,jvm申请的最大保留内存。


committed

committed memory 是JVM向操做系统实际分配的内存(malloc/mmap),mmaped PROT_READ | PROT_WRITE,相当于程序实际申请的可用内存。

在堆内存下,就是xms值,最小堆内存,heap committed memory。


注意,committed申请的内存并不是说直接占用了物理内存,由于操作系统的内存管理是惰性的,对于已申请的内存虽然会分配地址空间,但并不会直接占用物理内存,真正使用的时候才会映射到实际的物理内存。所以committed > res也是很可能的.


四、解决Internal内存占用过大问题


通过NMT的内存分析,我们已经定位到内存占用持续增长的原因,那么如果解决nternal内部内存持续增长,又不触发full gc的问题呢?

看看我们之前的启动的jvm参数:


-Xmx8g -Xms8g -XX:+UseG1GC  -XX:NativeMemoryTracking=detail


说明:

环境是jdk1.8,堆内存分配8g,采用G1垃圾回收器。


通过jmap查看内存分配:

82.png

发现最大堆内存MaxHeapSize和我们的启动参数设置的一致。

但是发现最大元数据空间内存非常大,这显然不是一个合适的值。


修改jvm参数:

-Xmx4g -Xms4g -Xmn2g   -XX:MetaspaceSize=64m -XX:MaxMetaspaceSize=128m -XX:+UseG1GC  -XX:NativeMemoryTracking=detail


注意:

-XX:PermSize=256m -XX:MaxPermSize=512m 这两个参数对于1.8就是过期的参数。

jdk1.8的元空间大小要通过参数-XX:MetaspaceSize=64m -XX:MaxMetaspaceSize=128m来控制。


修改后重启应用通过jmap查看内存分配:

81.png


JDK8里的元空间实际上使用的也是堆外内存,默认没有设置元空间大小的情况下,元空间最大堆外内存大小和Xmx是一致的。


这里需要额外注意的是:

永久代(JDK8的原生去,换成元数据空间)存放JVM运行时使用的类,永久代的对象在full GC时进行垃圾收集。


下面的图描述了从1.7到1.8,永久代的变更:

80.png


总结


本文主要介绍如何结合top,jmap,NMT工具对java进程的内存进行分析。

1、JDK1.8开始,自带的hostspot虚拟机取消了过去的永久区,而新增了metaspace区,从功能上看,metaspace可以认为和永久区类似,其最主要的功用也是存放类元数据,但实际的机制则有较大的不同。

2、对于JVM里面的内存需要在启动时进行限制,包括我们熟悉的堆内存,也要包括直接内存和元生区,这是保证线上服务正常运行最后的兜底。

3、重新熟悉java进程的内存组成。

java进程的内存组成 = heap + stack + metaspaceSize + directMemory

除了通过-Xmx4g -Xms4g参数控制程序启动的堆内存外,

不要忽视-Xss1024K控制每个stack的大小。

元空间限制:-XX:MetaspaceSize=64m -XX:MaxMetaspaceSize=128m

直接内存使用限制:-XX:MaxDirectMemorySize=128m


参考:https://www.cnblogs.com/rude3knife/p/13570423.html

目录
相关文章
|
14天前
|
存储 Java 编译器
Java内存模型(JMM)深度解析####
本文深入探讨了Java内存模型(JMM)的工作原理,旨在帮助开发者理解多线程环境下并发编程的挑战与解决方案。通过剖析JVM如何管理线程间的数据可见性、原子性和有序性问题,本文将揭示synchronized关键字背后的机制,并介绍volatile关键字和final关键字在保证变量同步与不可变性方面的作用。同时,文章还将讨论现代Java并发工具类如java.util.concurrent包中的核心组件,以及它们如何简化高效并发程序的设计。无论你是初学者还是有经验的开发者,本文都将为你提供宝贵的见解,助你在Java并发编程领域更进一步。 ####
|
9天前
|
缓存 算法 Java
本文聚焦于Java内存管理与调优,介绍Java内存模型、内存泄漏检测与预防、高效字符串拼接、数据结构优化及垃圾回收机制
在现代软件开发中,性能优化至关重要。本文聚焦于Java内存管理与调优,介绍Java内存模型、内存泄漏检测与预防、高效字符串拼接、数据结构优化及垃圾回收机制。通过调整垃圾回收器参数、优化堆大小与布局、使用对象池和缓存技术,开发者可显著提升应用性能和稳定性。
30 6
|
13天前
|
存储 缓存 安全
Java内存模型(JMM):深入理解并发编程的基石####
【10月更文挑战第29天】 本文作为一篇技术性文章,旨在深入探讨Java内存模型(JMM)的核心概念、工作原理及其在并发编程中的应用。我们将从JMM的基本定义出发,逐步剖析其如何通过happens-before原则、volatile关键字、synchronized关键字等机制,解决多线程环境下的数据可见性、原子性和有序性问题。不同于常规摘要的简述方式,本摘要将直接概述文章的核心内容,为读者提供一个清晰的学习路径。 ####
34 2
|
14天前
|
存储 安全 Java
什么是 Java 的内存模型?
Java内存模型(Java Memory Model, JMM)是Java虚拟机(JVM)规范的一部分,它定义了一套规则,用于指导Java程序中变量的访问和内存交互方式。
36 1
|
20天前
|
存储 运维 Java
💻Java零基础:深入了解Java内存机制
【10月更文挑战第18天】本文收录于「滚雪球学Java」专栏,专业攻坚指数级提升,希望能够助你一臂之力,帮你早日登顶实现财富自由🚀;同时,欢迎大家关注&&收藏&&订阅!持续更新中,up!up!up!!
27 1
|
Java Linux C语言
JVM 源码分析之一个 Java 进程究竟能创建多少线程
JVM 源码分析之一个 Java 进程究竟能创建多少线程
JVM 源码分析之一个 Java 进程究竟能创建多少线程
|
Java Linux C语言
JVM源码分析之一个Java进程究竟能创建多少线程
##概述 虽然这篇文章的标题打着JVM源码分析的旗号,不过本文不仅仅从JVM源码角度来分析,更多的来自于Linux Kernel的源码分析,今天要说的是JVM里比较常见的一个问题 这个问题可能有几种表述 * 一个Java进程到底能创建多少线程? * 到底有哪些因素决定了能创建多少线程
6337 0
|
9天前
|
安全 Java 测试技术
Java并行流陷阱:为什么指定线程池可能是个坏主意
本文探讨了Java并行流的使用陷阱,尤其是指定线程池的问题。文章分析了并行流的设计思想,指出了指定线程池的弊端,并提供了使用CompletableFuture等替代方案。同时,介绍了Parallel Collector库在处理阻塞任务时的优势和特点。
|
5天前
|
安全 Java 开发者
深入解读JAVA多线程:wait()、notify()、notifyAll()的奥秘
在Java多线程编程中,`wait()`、`notify()`和`notifyAll()`方法是实现线程间通信和同步的关键机制。这些方法定义在`java.lang.Object`类中,每个Java对象都可以作为线程间通信的媒介。本文将详细解析这三个方法的使用方法和最佳实践,帮助开发者更高效地进行多线程编程。 示例代码展示了如何在同步方法中使用这些方法,确保线程安全和高效的通信。
25 9
|
8天前
|
存储 安全 Java
Java多线程编程的艺术:从基础到实践####
本文深入探讨了Java多线程编程的核心概念、应用场景及其实现方式,旨在帮助开发者理解并掌握多线程编程的基本技能。文章首先概述了多线程的重要性和常见挑战,随后详细介绍了Java中创建和管理线程的两种主要方式:继承Thread类与实现Runnable接口。通过实例代码,本文展示了如何正确启动、运行及同步线程,以及如何处理线程间的通信与协作问题。最后,文章总结了多线程编程的最佳实践,为读者在实际项目中应用多线程技术提供了宝贵的参考。 ####