JVM与Linux内存关系分析

点击上方关注 “终端研发部


 
设为“星标”,和你一起掌握更多数据库知识

在一些物理内存为8g的服务器上,主要运行一个Java服务,系统内存分配如下:Java服务的JVM堆大小设置为6g,一个监控进程占用大约 600m,Linux自身使用大约800m。从表面上,物理内存应该是足够使用的;但实际运行的情况是,会发生大量使用SWAP(说明物理内存不够使用 了),如下图所示。由于SWAP和GC同时发生会致使JVM严重卡顿,所以我们要追问:内存究竟去哪儿了?

3be3c19272536173ce3f186a106a4bb4.jpeg

15097cbaaf02175e7072af962cda5eff.jpeg

要分析这个问题,理解JVM和操作系统之间的内存关系非常重要。接下来主要就Linux与JVM之间的内存关系进行一些分析。

一、Linux与进程内存模型

JVM以一个进程(Process)的身份运行在Linux系统上,了解Linux与进程的内存关系,是理解JVM与Linux内存的关系的基础。下图给出了硬件、系统、进程三个层面的内存之间的概要关系。

d07cbd50546338a1eaf49834f6a29c66.jpeg

从硬件上看,Linux系统的内存空间由两个部分构成:物理内存和SWAP(位于磁盘)。物理内存是Linux活动时使用的主要内存区域;当物理内存不够使用时,Linux会把一部分暂时不用的内存数据放到磁盘上的SWAP中去,以便腾出更多的可用内存空间;而当需要使用位于SWAP的数据时,必须 先将其换回到内存中。

从Linux系统上看,除了引导系统的BIN区,整个内存空间主要被分成两个部分:内核内存(Kernel space)、用户内存(User space)。

内核内存是Linux自身使用的内存空间,主要提供给程序调度、内存分配、连接硬件资源等程序逻辑使用。用户内存是提供给各个进程主要空间,Linux给各个进程提供相同的虚拟内存空间;这使得进程之间相互独立,互不干扰。实现的方法是采用虚拟内存技术:给每一个进程一定虚拟内存空间,而只有当虚拟内存实 际被使用时,才分配物理内存。如下图所示,对于32的Linux系统来说,一般将0~3G的虚拟内存空间分配做为用户空间,将3~4G的虚拟内存空间分配 为内核空间;64位系统的划分情况是类似的。

20b5f4a17496333fb8726a2644633c72.jpeg

从进程的角度来看,进程能直接访问的用户内存(虚拟内存空间)被划分为5个部分:代码区、数据区、堆区、栈区、未使用区。代码区中存放应用程序的机器代码,运行过程中代码不能被修改,具有只读和固定大小的特点。数据区中存放了应用程序中的全局数据,静态数据和一些常量字符串等,其大小也是固定的。堆是运行时程序动态申请的空间,属于程序运行时直接申请、释放的内存资源。栈区用来存放函数的传入参数、临时变量,以及返回地址等数据。未使用区是分配新内 存空间的预备区域。

二、进程与JVM内存空间

JVM本质就是一个进程,因此其内存空间(也称之为运行时数据区,注意与JMM的区别)也有进程的一般特点。但是,JVM又不是一个普通的进程,其在内存空间上有许多崭新的特点,主要原因有两 个:1.JVM将许多本来属于操作系统管理范畴的东西,移植到了JVM内部,目的在于减少系统调用的次数;2. Java NIO,目的在于减少用于读写IO的系统调用的开销。JVM进程与普通进程内存模型比较如下图:

629bc375d166a3192d0143a56b98625b.jpeg

需要说明的是,这个模型的并不是JVM内存使用的精确模型,更侧重于从操作系统的角度而省略了一些JVM的内部细节(尽管也很重要)。下面从用户内存和内核内存两个方面讲解JVM进程的内存特点。

1.用户内存

上图特别强调了JVM进程模型的代码区和数据区指的是JVM自身的,而非Java程序的。普通进程栈区,在JVM一般仅仅用做线程栈。JVM的堆区和普通进程的差别是最大的,下面具体详细说明:

首先是永久代。永久代本质上是Java程序的代码区和数据区。Java程序中类(class),会被加载到整个区域的不同数据结构中去,包括常量池、域、方法数据、方法体、构造函数、以及类中的专用方法、实例初始化、接口初始化等。这个区域对于操作系统来说,是堆的一个部分;而对于Java程序来 说,这是容纳程序本身及静态资源的空间,使得JVM能够解释执行Java程序。

其次是新生代和老年代。新生代和老年代才是Java程序真正使用的堆空间,主要用于内存对象的存储;但是其管理方式和普通进程有本质的区别。

普通进程在运行时给内存对象分配空间时,比如C++执行new操作时,会触发一次分配内存空间的系统调用,由操作系统的线程根据对象的大小分配好空间后返 回;同时,程序释放对象时,比如C++执行delete操作时,也会触发一次系统调用,通知操作系统对象所占用的空间已经可以回收。

JVM对内存的使用和一般进程不同。JVM向操作系统申请一整段内存区域(具体大小可以在JVM参数调节)作为Java程序的堆(分为新生代和老年代);当Java程序申请内存空间,比如执行new操作,JVM将在这段空间中按所需大小分配给Java程序,并且Java程序不负责通知JVM何时可以释放这 个对象的空间,垃圾对象内存空间的回收由JVM进行。

JVM的内存管理方式的优点是显而易见的,包括:第一,减少系统调用的次数,JVM在给Java程序分配内存空间时不需要操作系统干预,仅仅在 Java堆大小变化时需要向操作系统申请内存或通知回收,而普通程序每次内存空间的分配回收都需要系统调用参与;第二,减少内存泄漏,普通程序没有(或者 没有及时)通知操作系统内存空间的释放是内存泄漏的重要原因之一,而由JVM统一管理,可以避免程序员带来的内存泄漏问题。

最后是未使用区,未使用区是分配新内存空间的预备区域。对于普通进程来说,这个区域被可用于堆和栈空间的申请及释放,每次堆内存分配都会使用这个区 域,因此大小变动频繁;对于JVM进程来说,调整堆大小及线程栈时会使用该区域,而堆大小一般较少调整,因此大小相对稳定。操作系统会动态调整这个区域的 大小,并且这个区域通常并没有被分配实际的物理内存,只是允许进程在这个区域申请堆或栈空间。

2.内核内存

应用程序通常不直接和内核内存打交道,内核内存由操作系统进行管理和使用;不过随着Linux对性能的关注及改进,一些新的特性使得应用程序可以使 用内核内存,或者是映射到内核空间。Java NIO正是在这种背景下诞生的,其充分利用了Linux系统的新特性,提升了Java程序的IO性能。

75dfa6345af3c2264643b86e4a153258.jpeg

上图给出了Java NIO使用的内核内存在linux系统中的分布情况。nio buffer主要包括:nio使用各种channel时所使用的ByteBuffer、Java程序主动使用 ByteBuffer.allocateDirector申请分配的Buffer。而在PageCache里面,nio使用的内存主要包 括:FileChannel.map方式打开文件占用mapped、FileChannel.transferTo和 FileChannel.transferFrom所需要的Cache(图中标示 nio file)。

通过JMX可以监控到NIO Buffer和 mapped 的使用情况,如下图所示。不过,FileChannel的实现是通过系统调用使用原生的PageCache,过程对于Java是透明的,无法监控到这部分内存的使用大小。

af3a04a3aef758aa46ba11578eee0fbf.jpeg

Linux和Java NIO在内核内存上开辟空间给程序使用,主要是减少不要的复制,以减少IO操作系统调用的开销。例如,将磁盘文件的数据发送网卡,使用普通方法和NIO时,数据流动比较下图所示:

16ecfaf203f0131d52792ba6bb75cc6e.jpeg

将数据在内核内存和用户内存之间拷贝是比较消耗资源和时间的事情,而从上图我们可以看到,通过NIO的方式减少了2次内核内存和用户内存之间的数据拷贝。这是Java NIO高性能的重要机制之一(另一个是异步非阻塞)。

从上面可以看出,内核内存对于Java程序性能也非常重要,因此,在划分系统内存使用时候,一定要给内核留出一定可用空间。

三、案例分析

1.内存分配问题

通过上面的分析,省略比较小的区域,可以总结JVM占用的内存:
JVM内存 ≈ Java永久代 + Java堆(新生代和老年代) + 线程栈+ Java NIO

回到文章开头提出的问题,原来的内存分配是:6g(java堆) + 600m(监控) + 800m(系统),剩余大约600m内存未分配。

现在分析这600m内存的分配情况:

  1. Linux保留大约200m,这部分是Linux正常运行的需要,

  2. Java服务的线程数量是160个,JVM默认的线程栈大小是1m,因此使用160m内存,

  3. Java NIO buffer,通过JMX查到最多占用了200m,

  4. Java服务使用NIO大量读写文件,需要使用PageCache,正如前面分析,这个暂时不好定量估算大小。

前三项加起来已经560m,因此可以断定Linux物理内存不够使用。

细心的人会发现,引言中给出两个服务器,一个SWAP最多占用了2.16g,另外一个SWAP最多占用了871m;但是,似乎我们的内存缺口没有那么大。事实上,这是由于SWAP和GC同时进行造成的,从下图可以看到,SWAP的使用和长时间的GC在同一时刻发生。

0a9ef0c7b89f90c929fcfc7e2cf90979.jpeg

90730dc5cf518f747123dc683c2f2c23.jpeg

SWAP和GC同时发生会导致GC时间很长,JVM严重卡顿,极端的情况下会导致服务崩溃。原因如下:JVM进行GC时,时需要对相应堆分区的已用 内存进行遍历;假如GC的时候,有堆的一部分内容被交换到SWAP中,遍历到这部分的时候就需要将其交换回内存,同时由于内存空间不足,就需要把内存中堆 的另外一部分换到SWAP中去;于是在遍历堆分区的过程中,(极端情况下)会把整个堆分区轮流往SWAP写一遍。Linux对SWAP的回收是滞后的,我 们就会看到大量SWAP占用。上述问题,可以通过减少堆大小,或者增加物理内存解决。

因此,我们得出一个结论:部署Java服务的Linux系统,在内存分配上,需要避免SWAP的使用;具体如何分配需要综合考虑不同场景下JVM对Java永久代 、Java堆(新生代和老年代)、线程栈、Java NIO所使用内存的需求。

2.内存泄漏问题

另一个案例是,8g内存的服务器,Linux使用800m,监控进程使用600m,堆大小设置4g;系统可用内存有2.5g左右,但是也发生了大量的SWAP占用。

分析这个问题如下:

  1. 在这个场景中, Java永久代 、Java堆(新生代和老年代)、线程栈所用内存基本是固定的,因此,占用内存过多的原因就定位在Java NIO上。

  2. 根据前面的模型,Java NIO使用的内存主要分布在Linux内核内存的System区和PageCache区。查看监控的记录,如下图,我们可以看到发生SWAP之前,也就是 物理内存不够使用的时候,PageCache急剧缩小。因此,可以定位在System区的Java NIO Buffer发生内存泄漏。

adff8a4a7e7609e4366124106a04809c.jpeg

18510ee8b21fb1711587e830cea30183.jpeg

  1. 由于NIO的DirectByteBuffer需要在GC的后期被回收,因此连续申请DirectByteBuffer的程序,通常需要调用 System.gc(),避免长时间不发生FullGC导致引用在old区的DirectByteBuffer内存泄漏。分析到此,可以推断有两种可能的 原因:第一,Java程序没有在必要的时候调用System.gc();第二,System.gc()被禁用。

  2. 最后是要排查JVM启动参数和Java程序的DirectByteBuffer使用情况。在本例中,查看JVM启动参数,发现启用了-XX:+DisableExplicitGC导致System.gc()被禁用。


四、总结

本文详细分析了Linux与JVM的内存关系,比较了一般进程与JVM进程使用内存的异同点,理解这些特性将对Linux系统内存分配、JVM调优、Java程序优化有帮助。限于篇幅关系仅仅列举两个案例,希望起到抛砖引玉的作用。

http://www.open-open.com/lib/view/open1420814127390.html

cbb7e7bb3214531d8e75815dde3ff089.jpeg

收藏=白嫖,点赞+关注才是真爱!!!本篇文章如有不对之处,还请在评论区指出~

本文转自 https://www.cnblogs.com/melojun/p/mysql-index.html,如有侵权,请联系删除。

最后说一句(别白嫖,求关注)

回复 【idea激活】即可获得idea的激活方式
回复 【Java】获取java相关的视频教程和资料
回复 【SpringCloud】获取SpringCloud相关多的学习资料
回复 【python】获取全套0基础Python知识手册
回复 【2020】获取2020java相关面试题教程
回复 【加群】即可加入终端研发部相关的技术交流群
阅读更多
用 Spring 的 BeanUtils 前,建议你先了解这几个坑!

lazy-mock ,一个生成后端模拟数据的懒人工具

在华为鸿蒙 OS 上尝鲜,我的第一个“hello world”,起飞!

字节跳动一面:i++ 是线程安全的吗?

一条 SQL 引发的事故,同事直接被开除!!

太扎心!排查阿里云 ECS 的 CPU 居然达100%

一款vue编写的功能强大的swagger-ui,有点秀(附开源地址)


相信自己,没有做不到的,只有想不到的在这里获得的不仅仅是技术!



喜欢就给个“在看”
JVM参数设置详细说明、JVM 参数设置详细说明 1: heap size a: -Xmx 指定jvm的最大heap大小,如:-Xmx=2g b: -Xms 指定jvm的最小heap大小,如:-Xms=2g,高并发应用,建议-Xmx一样,防止因为内存收缩/突然增大带来的性能影响。 c: -Xmn 指定jvm中New Generation的大小,如:-Xmn256m。这个参数很影响性能,如果你的程序需要比较多的临时内存,建议设置到512M,如果用的少,尽量降低这个数值,一般来说128/256足以使用了。 d: -XX:PermSize= 指定jvm中Perm Generation的最小值,如:-XX:PermSize=32m。这个参数需要看你的实际情况,可以通过jmap命令看看到底需要多少。 e: -XX:MaxPermSize= 指定Perm Generation的最大值,如:-XX:MaxPermSize=64m f: -Xss 指定线程桟大小,如:-Xss128k,一般来说,webx框架下的应用需要256K。如果你的程序有大规模的递归行为,请考虑设置到512K/1M。这个需要全面的测试才能知道。不过,256K已经很大了。这个参数对性能的影响比较大的。 g: -XX:NewRatio= 指定jvm中Old Generation heap sizeNew Generation的比例,在使用CMS GC的情况下此参数失效,如:-XX:NewRatio=2 h: -XX:SurvivorRatio= 指定New Generation中Eden Space一个Survivor Space的heap size比例,-XX:SurvivorRatio=8,那么在总共New Generation为10m的情况下,Eden Space为8m i: -XX:MinHeapFreeRatio= 指定jvm heap在使用率小于n的情况下,heap进行收缩,Xmx==Xms的情况下无效,如:-XX:MinHeapFreeRatio=30 j: -XX:MaxHeapFreeRatio= 指定jvm heap在使用率大于n的情况下,heap 进行扩张,Xmx==Xms的情况下无效,如:-XX:MaxHeapFreeRatio=70 k: -XX:LargePageSizeInBytes= 指定Java heap的分页页面大小, 如:-XX:LargePageSizeInBytes=128m 2: garbage collector a: -XX:+UseParallelGC 指定在New Generation使用parallel collector,并行收集,暂停,app threads,同时启动多个垃圾回收thread,不能CMS gc一起使用。系统吨吐量优先,但是会有较长长时间的app pause,后台系统任务可以使用此 gc b: -XX:ParallelGCThreads= 指定parallel collection时启动的thread个数,默认是物理processor的个数 c: -XX:+UseParallelOldGC 指定在Old Generation使用parallel collector d: -XX:+UseParNewGC 指定在New Generation使用parallel collector,是UseParallelGC的gc的升级版本,有更好的性能或者优点,可以CMS gc一起使用 e: -XX:+CMSParallelRemarkEnabled 在使用UseParNewGC的情况下,尽量减少mark的时间 f: -XX:+UseConcMarkSweepGC 指定在Old Generation使用concurrent cmark sweep gc、gc threadapp thread并行(在init-markremark时pause app thread)。app pause时间较短,适合交互性强的系统,如web server g: -XX:+UseCMSCompactAtFullCollection 在使用concurrent gc的情况下,防止memory fragmention,对live object进行整理,使memory 碎片减少 h: -XX:CMSInitiatingOccupancyFraction= 指示在old generation 在使用了n%的比例后,启动concurrent collector,默认值是68,如:-XX:CMSInitiatingOccupancyFraction=70 有个bug,在低版本(1.5.09 and early)的jvm上出现, http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6486089 i: -XX:+UseCMSInitiatingOccupancyOnly 指示只有在old generation在使用了初始化的比例后concurrent collector启动收集 3:others a: -XX:MaxTenuringThreshold= 指定一个object在经历了n次young gc后转移到old generation区,在linux64的java6下默认值是15,此参数对于throughput collector无效,如:-XX:MaxTenuringThreshold=31 b: -XX:+DisableExplicitGC 禁止java程序中的full gc,如System.gc()的调用。最好加上么,防止程序在代码里误用了。对性能造成冲击。 c: -XX:+UseFastAccessorMethods get、set方法转成本地代码 d: -XX:+PrintGCDetails 打应垃圾收集的情况如: [GC 15610.466: [ParNew: 229689K->20221K(235968K), 0.0194460 secs] 1159829K->953935K(2070976K), 0.0196420 secs] e: -XX:+PrintGCTimeStamps 打应垃圾收集的时间情况,如: [Times: user=0.09 sys=0.00, real=0.02 secs] f: -XX:+PrintGCApplicationStoppedTime 打应垃圾收集时,系统的停顿时间,如: Total time for which application threads were stopped: 0.0225920 seconds 4: a web server product sample and process JAVA_OPTS=" -server -Xmx2g -Xms2g -Xmn256m -XX:PermSize=128m -Xss256k -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70 " 最初的时候我们用UseParallelGCUseParallelOldGC,heap开了3G,NewRatio设成1。这样的配置下young gc发生频率约12、3秒一次,平均每次花费80ms左右,full gc发生的频率极低,每次消耗1s左右。从所有gc消耗系统时间看,系统使用率还是满高的,但是不论是young gc还是old gc,application thread pause的时间比较长,不合适 web 应用。我们也调小New Generation的,但是这样会使full gc时间加长。 后来我们就用CMS gc(-XX:+UseConcMarkSweepGC),当时的总heap还是3g,新生代1.5g后,观察不是很理想,改为jvm heap为2g新生代设置-Xmn1g,在这样的情况下young gc发生的频率变成7、8秒一次,平均每次时间40-50毫秒左右,CMS gc很少发生,每次时间在init-markremark(two steps stop all app thread)总共平均花费80-90ms左右。 在这里我们曾经New Generation调大到1400m,总共2g的jvm heap,平均每次ygc花费时间60-70ms左右,CMS gc的init-markremark之平均在50ms左右,这里我们意识到错误的方向,或者说CMS的作用,所以进行了修改。 最后我们调小New Generation为256m,young gc 2、3秒发生一次,平均停顿时间在25毫秒左右,CMS gc的init-markremark之平均在50ms左右,这样使系统比较平滑,经压力测试,这个配置下系统性能是比较高的。 在使用CMS gc的时候他有两种触发gc的方式:gc估算触发heap占用触发。我们的1.5.0.09 环境下有次old 区heap占用在30%左右,她就频繁gc,个人感觉系统估算触发这种方式不靠谱,还是用 heap 使用比率触发比较稳妥。 这些数据都来自64位测试机,过程中的数据都是我在jboss log找的,当时没有记下来,可能存在一点点偏差,但不会很大,基本过程就是这样。 5: 总结 web server作为交互性要求较高的应用,我们应该使用Parallel+CMS,UseParNewGC这个在jdk6 -server上是默认的new generation gc,新生代不能太大,这样每次pause会短一些。CMS mark-sweep generation可以大一些,可以根据pause time实际情况控制。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值