欢迎阅读我的专栏:JavaWeb技术世界
’与其他高级语言不一样,在Java中基本上不会显示地调用分配内存的函数,我们甚至不用关心到底哪些程序指令需要分配内存,哪些不需要分配内存。
我们首先需要从操作系统层面理解物理内存的分配和Java运行的内存分配之间的关系。
1 物理内存就是RAM,还有一个存储单元叫做寄存器,连接处理器和RAM或者寄存器的是地址总线,这个地址总线的宽度影响了物理地址的索引范围,32位地址总线可以寻址4gb内存。
2 除了硬件程序或者驱动程序需要直接访问存储器外,大部分情况下都是通过操作系统提供的接口来访问内存,在java中甚至不需要写和内存相关的代码。
3 不管是在windows还是linux,我们运行程序都要向操作系统申请内存地址,通常操作系统管理内存的申请空间是按照进程来管理的。每个进程拥有一个独立的地址空间,逻辑上是隔离的。
4 但是由于系统内存有限,物理空间需要得到更有效的利用,于是进程在物理上是共享物理内存的。
5 为了实现这一目的,操作系统设计了虚拟内存的概念,每个进程有一个很大的虚拟地址空间,虚拟地址可以让进程共享物理内存,提高利用率,也可以让进程独享大段虚拟地址空间。
进程在不活动的时候,把物理内存中的数据存在磁盘文件中。在windows中就是页面文件,在linux中则是swap分区。真正高效的物理内存留给正在活动的程序使用。
当我们唤醒一个很长时间没有使用的程序时,磁盘会吱吱作响,因为此时在进行页面调度,这种情况需要避免经常出现,否则效率会很低。如果linux上的swap分区被频繁使用,则系统会非常慢,说明物理内存可能严重不足或者某些程序没有释放内存。
计算机有一定大小的内存空间,比如4GB,这些地址空间并不能被用户程序完全使用。因为有一部分空间是内核空间。
内核空间主要是操作系统运行时所使用的用于进程调度,虚拟内存的使用或者硬件资源等的程序逻辑。
为了保证系统的稳定性和安全性,必须划分为两个空间。
访问硬件资源如网络逻辑,执行IO读取磁盘数据等操作,都需要通过系统调用来完成,系统调用就是执行操作系统提供的接口。
而操作系统和硬件之间的交互一般是基于指令集来完成的,机器码根据指令集进行译码,cpu根据指令完成对应的操作,比如访问内存,执行IO操作,以及访问硬件等等。
执行系统调用的时候,需要进行两个内存空间的切换,经常需要在两个内存空间之间进行内容复制。这牺牲了一部分效率,Linux系统sendfile文件传输方式,可以减少这种内核空间到用户空间的数据复制方式。
java堆用于存储java对象,通过-xmx表示堆的最大值,xms表示初始大小,一旦分配完成,堆空间就固定了。不能重新申请。
jvm运行程序的实体是线程,只有java这一个进程代表jvm实例。
线程需要要内存空间来存储一些必要数据,每个线程创建时jvm会为他创建一个堆栈,堆栈的大小根据不同的jvm实现而不同。
通常在256k到756k之间。
线程所占空间比堆空间来说比较小,但使用量可以非常大。
永久代以前的实现是方法区,现在改为元数据区。
jvm是按需加载类的,如果要加载一个jar包是否把这个jar包中所有的类加载到内存中!??
如果是这样,那么一个很大的jar包,如果我们只使用一个类,却需要全部加载,也太浪费了把。
显然不是的,jvm只会加载那些在你的应用程序中明确使用的类到内存中,要查看jvm到底加载了哪些类,可以在启动参数后加上-verbose:class
如果使用自定义类加载器加载类,可能会出现重复加载的情况,如果方法区不能对失效类进行卸载,则可能导致方法区内存泄漏。
一个类A能够被卸载的必要条件如下
1:在Java堆中没加载有A的classloader对象的引用。
2:java堆上没有加载A的classloader已加载的类的class对象引用
3:java堆上没有加载A的类加载器加载的任何类的对象
由于jvm创建的三个默认类加载器都不可能满足这些条件,所以任何系统类加载器加载的类都不能在运行时被释放。
java在1.4后添加了NIO
1 开始支持使用allocatedirect方法为bytebuffer分配内存。
这个方法分配内存使用的是本机内存而不是Java堆上的内存。
2 直接操作这个bytebuffer时不需要进行java内存和本机内存的复制,比起Java内存和内核空间的复制效率要快得多。
3 直接bytebuffer对象会自动清理已分配的本地内存(缓冲区内存),但这个过程只能作为java堆gc的一部分来执行,没办法单独执行。
4 只有在堆内存满时发生GC或者显示调用system.gc时才能释放这部分直接内存,所以会增加gc的次数。
5 如果进制system.gc,则有可能导致直接内存泄漏
JNI技术使得java代码可以调用本机代码(比如c语言程序)。
这部分用到了native memory,也就是本地内存。
由于Java是多线程应用。线程经常被中断,为了恢复时记住上次运行到哪,需要一个程序计数器。
1 Java的栈和线程关联在一起。
2 每个线程有一个栈。
3 每运行一个方法就创建一个新栈帧。
4 栈帧包含了内部变量(方法内部的变量,不是方法参数,方法参数用调用者传来),操作数栈,方法返回值等信息。
5 每个方法执行完成时,每个栈帧都会弹出栈帧的元素作为方法的返回值。
6 java栈的栈顶就是当前的活动栈,pc寄存器会指向这个地址。
堆是存储对象的地方,每一个存储在堆中的对象都是这个对象类的一个副本,它会复制包括继承它的父类的所有非静态属性。
注意是非静态属性,静态属性编译时确定,存在类的元数据中,在方法区。
方法区是存储类结构信息的地方。
class文件被加到jvm中时,会被存储在不同的数据结构中。
其中类的常量池,域,方法数据,方法体,构造函数,类的静态方法等代码都存在这里。
方法区存储的数据比较稳定,不会被频繁回收。
jvm中定义运行时常量池是在方法区中的一部分。
它代表着运行时每个class文件中的常量表,它包括几种常量,编译期的数字常量,方法或者域的引用(在运行时解析连接)。
本地方法栈是伪jvm运行native方法准备的空间,和java栈的作用类似,也叫c栈,代码中的native方法调用会使用这个存储空间,在jvm利用JIT方法编译为native代码后,也会通过这个栈来跟踪和执行方法。
操作系统把内存分配策略分为三种
1 静态内存分配
编译期确定分配空间
2 栈内存分配
内存需求完全未知,动态分配
3 堆内存分配
堆内存分配会划分一定空间为堆内存,然后根据代码需要动态分配空间
1 java的分配和线程绑定在一起,栈的本地变量表通过slot数组来分配,可以复用,由于栈帧的大小确定,所以编译期就可以确定大小,进行内存分配。
栈中主要存放基本类型的变量数据,和对象引用,读取速度较快,仅次于寄存器。
2 应用程序所创建的UI想或者数组都在堆中,并且能够共享。
建立对象时在堆中分配实例,在对应栈中分配引用。
由于堆要动态分配内存,所以存取速度较慢。
java的静态内存在栈上分配,方法运行结束后对应栈帧也就消失了,所以静态内存空间也就回收了。
对象不再被使用时会被回收,这是垃圾回收器要解决的问题。
可达性分析:从GC ROOT出发标记活动集合,剩下的不可达对象就是垃圾
1 方法内部变量对对象的引用
2 java栈中的对象引用
3 常量池中的对象引用,比如对字符串对象的引用
4 本地方法中持有的对象引用
总结一下就是从四个方面找到正在活动的对象引用,比如方法内部,栈中引用,常量池中引用,以及本地方法的引用。
1 young区分为eden和两个survivor区。初始分配到eden区,存活对象进入survivor一个区,这两个survivor保证有一个是空的。
2 old区存放young区的survivor满触发minor gc后仍然存活的对象。如果old区也满则触发full gc。
3 方法区存放类的元数据信息,可以被full gc回收。
visualvm工具的visualgc插件可以观察到不同代的垃圾回收情况。比如占用率,空闲内存,回收次数,耗时情况等。
一般建议young区为整个堆的1/5;survivor和eden是2:8的关系,也就是eden:from:to = 8:1:1
略
有时候我们不知道何时会发生内存溢出,但是发生时我们不知道原因,所以在jvm就加上一个参数可以记下一些当时的情况。
gc日志输出如下参数
-verbose:gc,可以辅助输出gc详细信息
-XX:+printGCDetails,输出gc的详细信息
一般会输出
1 回收器名称
2 各区内存的使用情况和gc后的使用情况
3 各区进行gc的停顿时间
4 整个堆在gc前后的内存
5 gc过程中jvm暂停的总时间
jstat -gcutil
可以分析一些GC的情况
1 各分区的使用空间情况
2 永久代内存情况
3 young gc和 full gc的次数和所用时间
通过jmap -dump 可以用来记下堆的文件快照。然后利用第三方工具如mat来分析整个Heap的对象关联情况
jvm有时会因为一些原因垮掉,因为jvm也是一个程序,可能会出bug导致异常退出。jvm退出会在工作目录产生一个日志文件。使用-XX:ErrorFile可以转储该文件。
一般有三种原因导致退出
1 exception——access——violation
jvm运行自己的代码时出错。
2 sigsegv
jvm正在执行JNI代码时出错
3 exception——stack——overflow
这个栈溢出不是java线程的栈溢出,因为线程的栈溢出只会抛出Stack Overflow exception。
这个主要是因为jvm的代码是c++代码,如果自身运行时栈溢出也会导致jvm退出。
问题:
1 系统负载偏高,达到6,平时基本为1
2 整个系统响应较慢,重启之后恢复正常
解决思路:
PS科普:CMS GC时出现promotion failed跟concurrent mode failure
对于采用CMS进行旧生代GC的程序而言,尤其要注意GC日志中是否有promotion failed和concurrent mode failure两种状况,当这两种状况出现时可能会触发Full GC。
promotion failed是在进行Minor GC时,survivor space放不下、对象只能放入旧生代,而此时旧生代也放不下造成的;concurrent mode failure是在执行CMS GC的过程中同时有对象要放入旧生代,而此时旧生代空间不足造成的。
所以在别一次性占用太多的内存,如果是读文件,可以采用拆分的方法。或者把GC内存调大点
1 查看GC,FGC明显异常,过程中出现了concurrent mode failure。说明在old区分配内存时出现了失败的情况。(多个线程触发young gc,导致多个对象同时进入老年代失败)
2 整个内存占用达到了6gb,超出了平时的4gb,得出可能是出现了内存泄漏的问题。
3 通过jmap -dump 命令查看heap,再通过mat工具分析。
发现一个最大的对象占用了900M内存,显然有问题。
根据mat给出的说明,整个map集合占用了55%的空间
4 再看一下这个对象持有了哪些对象。
仔细查看后发现map持有一个大对象,它的大小没有超出我们预期,但是仔细看其他集合,没有发现所持对象有什么不对的地方。
但是仔细计算整个对象集合的大小发现,对象全都存在,但是大小比正常多了将近一倍,于是想到可能是持有了相同的对象。
5 搜索完集合后发现确实如此,原来是因为业务逻辑要求每天凌晨更新一次老对象,更新后老对象自动释放,但是我们的新引擎是要保存这些对象,以便做编译优化,不能及时释放老对象,导致大对象保存了两份。
问题:
1 淘宝某应用突然导致线上机器报警,Java内存使用验证,达到6gb,超过4gb,而且有几台运行一段时间后导致OOM,JVM退出。
2 观察重启后的机器,发现应用恢复正常,但是发现JVM进程占用的内存一直在增加,大体推断是有内存泄漏。
解决思路:
1 检查了一下最近一周代码更新没有发现内存泄漏的代码。
2 同时检查gc日志,发现 有问题的机器的full gc没有异常,甚至比平时的full gc次数少,cms gc也很少。
3 为了进一步确认gc是否正常,我们找出jvm的heap,用mat分析对文件,整个heap只有不到1g的空间。最大的对象和符合预期,所以不是jvm的堆内存有问题,但是既然堆占用的内存并不多,那为什么java进程占用这么多内存?
4 于是想到了可能是堆外内存的泄漏,也就是本地内存,JIT编译需要本地内存,jvm栈需要本地内存,JNI调用本地代码也需要本地内存存,NIO也会使用Direct buffer申请本地内存。
5 我们用到了direct buffer,于是怀疑它。因为上次引入了mina包,使用了direct buffer,但是为什么direct buffer会回收异常呢。
6 这是想到了一个jvm的bug。
如果使用 -XX:+DisableExplicitGC参数启动jvm,但是又用到了direct buffer,会导致system.gc失效,与此同时我们应用自己触发的gc次数很少,导致directbuffer没有机会被回收,
其分配的本地内存无法被释放。
7 解决办法就是出去 -XX:+DisableExplicitGC,换上-XX:+DisableGCInvokesConcurrent,使得外部的system.gc能够调用成功。
PS:降低每次Full gc的时间
通过ExplicitGCInvokesConcurrent选项,可以使用CMS收集器来触发Full gc
如果系统中大量使用了DirectByteBuffer,需要定期地对native堆做清理,清理时可以使用Full gc,也可以使用CMS,视QPS情况而定;
可以使用-Dsun.rmi.dgc.server.gcInterval=7200000与-Dsun.rmi.dgc.client.gcInterval=7200000 选项控制Full gc时间间隔;
可以使用-XX:DisableExplicitGC选项禁用显示调用Full gc;
如果希望Full gc有更少的停机时间,可以启用-XX:+ExplicitGCInvokesConcurrent或-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses选项。
问题:
1 系统运行20到30分钟后,系统swap区突增,直到swap区使用率达到100%,机器死机。
2 系统内存达到3.5g,已经超过了heap堆设置的上限,但是gc缺很少。
3 old区的空间也几乎没有变化
解决思路:
1 Java进程内存增长非常迅速,进行压测20分钟后就将2gb内存耗光,并且内存耗光后开始使用swap区,很快消耗了swap区的空间,最终导致机器死机,所以可以肯定是内存泄漏。
2 通过jstat分析jvm heap情况和gc统计信息,发现gc很少,full gc几乎没有,jvm堆内存被耗光的话,Full gc应该非常频繁,所以初步判断这次内存泄漏不在堆中
3 进一步排除是jvm堆内存问题,使用jmap dump出内存快照,通过mat分析内存情况。
4 可以得出要么是nio 本地内存泄漏,要么是native memory泄漏。
使用工具检测direct memory占用的空间大小。
发现并不是很多,所以怀疑是native memory出现泄漏。
5 使用oprofier热点分析工具分析当然系统执行的热点代码,如果是当前的native memory泄漏,那么肯定会出现分配内存的代码是热点的情况。
6 发现和预想的情况并不吻合,于是进行功能拆分,查看到底是哪个模块导致泄漏。拆分几次后发现时mina框架给varnish发送失败请求时导致的,而且发送的请求频率越高内存泄漏越严重。但是mina框架没有使用native memory的地方。
科普ps:Varnish
Varnish与一般服务器软件类似,就是一个web缓存代理服务器,分为master(management)进程和child(worker,主要 做cache的工作)进程。master进程读入命令,进行一些初始化,然后fork并监控child进程。child进程分配若干线程进行工作,主要包 括一些管理线程和很多woker线程。
7 使用perftools分析jvm的native memory分配情况,通过perftools得到分析结果,没有发现问题。
8 又回到Java代码,发现代码中使用mina的一个类进行发送和序列化发送数据,使用的是direct buffer,于是改为使用jvm heap来存放数据。
9 按照这个思路,把所有可能出问题的direct buffer转变成Haep堆内存泄漏,如果这个代码有问题,必然会产生jvm heap暴涨。
10 修改代码后运行,果然内存暴涨,gc频繁,分析一下堆,发现堆空间都被socketsessionimpl的writerequestqueue队列所持有,这个对了是mina的写队列,也就是mina不能及时发送数据,导致堵在了这个队列里,所以还是mina导致了direct memory 泄漏。
微信公众号【程序员黄小斜】新生代青年聚集地,程序员成长充电站。作者黄小斜,职业是阿里程序员,身份是斜杠青年,希望和更多的程序员交朋友,一起进步和成长!专注于分享技术、面试、职场等成长干货,这一次,我们一起出发。
关注公众号后回复“2019”领取我这两年整理的学习资料,涵盖自学编程、求职面试、算法刷题、Java技术学习、计算机基础和考研等8000G资料合集。
微信公众号【Java技术江湖】一位阿里 Java 工程师的技术小站,专注于 Java 相关技术:SSM、SpringBoot、MySQL、分布式、中间件、集群、Linux、网络、多线程,偶尔讲点Docker、ELK,同时也分享技术干货和学习经验,致力于Java全栈开发!
关注公众号后回复“PDF”即可领取200+页的《Java工程师面试指南》强烈推荐,几乎涵盖所有Java工程师必知必会的知识点。