JVM内存管理
物理内存和虚拟内存
(1)在java中,分配内存和回收内存都由JVM自动完成,甚至不需要写和内存相关的代码
(2)物理内存即RAM还有寄存器(一种存储单元,用于存储计算机单元执行指令(如整形浮点等运算)的中间结果)是处理器通过地址总线连接的。地址总线:其宽度决定了一次可以存寄存器或者RAM中获取多少个bit和处理器最大的可以寻址的范围,每个地址会引用一个字节,所以如果是32位的总线则可以有4G的内存空间。(通常情况下地址总线和RAM或寄存器有相同的位数)
(3)通常操作系统的内存申请空间是按照进程来管理的,每个进程间不会互相重合,操作系统保证每个进程拥有一段独立的地址空间。(逻辑上独立,物理空间不一定独立,如虚拟内存,虚拟内存是计算机系统内存管理的一种技术。它使得应用程序认为它拥有连续的可用的内存(一个连续完整的地址空间),而实际上,它通常是被分隔成多个物理内存碎片,还有部分暂时存储在外部磁盘存储器上,在需要时进行数据交换。)
(4)由于程序越来越庞大何设计的多任务性,物理内存无法满足要求,出现了虚拟内存,虚拟内存使得多个进程可以共享物理内存,并且逻辑上独立。虚拟内存提高了内存利用率,并且可以扩展内存空间,使得一个虚拟的地址可以映射到物理内存,文件或者其他可以寻址的存储上。如一个进程在不活动的情况下,操作系统将这个物理内存中的数据移到一个磁盘文件下(频繁地交换物理内存和磁盘上的数据,会导致效率低下,需要关注)。
内核空间和用户空间
(1)电脑的内存地址空间将被划分为内核地址空间和用户空间,程序只能使用用户空间的内存(指程序能够申请的内存)(如windows32为默认内核空间和用户空间的比例是1:1,linux32为默认的比例是1:3)
(2)内核空间主要指操作系统用于程序调度、虚拟内存或者连接硬件资源等的程序逻辑。程序不能访问操作系统的空间,并且不能直接访问硬件资源,必须通过系统提供的接口调用。(每一次系统调用都会引起内核空间和内存空间的切换,这一操作比较耗时)
Java中的那些组件需要使用内存
(1).java堆:用于存储java对象的内存区域,可以通过Xmx(最大大小)和Xms(初始大小)来控制大小,默认空余堆内存少于40%时就扩大到Xmx,空余堆内存大于70%时就缩小到Xms,因此,服务器一般把xmx和xms设置成一样,避免在GC后调节堆的大小。
(2).每个线程创建时,JVM都会为它创建一个运行方法栈、局部变量的堆还有操作栈。
(3).类和类加载器:类和类的加载器本身同样需要存储空间,存储在永久代PermGen(属于方法区,即java堆的永久区部分)
ps:
- JVM是按需加载类的,隐式加载只会加载那些应用程序中明确使用到的。
- 加载类超过PermGen区大小的话可能会导致内存溢出,所以对于自己实现的类加载器可能会导致类的重复加载时,可能需要实现对类的卸载,需满足:
-
- Java堆中没有对表示该类的类加载器的java.lang.ClassLoader对象的引用,
- Java对中没有该类的对应加载器的java.lang.class对象的引用,
- Java堆上任何该类的类加载器的任何类的所有对象都不存活。
而JVM的默认类加载器都不满足该条件,所以他们加载的类都不能卸载。
(4)NIO:NIO使用ByteBuffer.allocateDirect()方法分配内存,可以避免数据从内核空间到用户空间的复制,提高效率,但是该方法直接使用的是本机内存而不是java堆内存,直接的ByteBuffer对象可以自动清理本机缓存区,但是其只是作为GC时的一部分执行,而GC只在Java堆被填满或者显示调用System.gc()来执行(也就是自动的GC只检查Java堆是否满,而不知道NIO操作的本机内存是否需要释放。),以至于NIO在很多框架中是通过显示调用System.gc()执行NIO内存的释放的(其实2对象本身有clean方法可以释放,见jdk随笔额,heap&direct)
(5)JNI:JNI使得本机代码(如C语言)可以调用java方法,JVM会准备空间以供运行本地方法,也会增加java运行时的本机内存占用。
JVM内存结构
JVM是按照运行时数据的存储结构来划分内存结构的,根据不同的格式存储在不同的区域。运行时数据包括java程序本身的数据信息和JVM运行Java程序需要的额外数据信息,java虚拟机规范将Java运行时数据分为6种:PC寄存器数据、Java栈、堆、方法区、本地方法区、运行时常量池。
PC寄存器数据:
用于保存当前执行程序的内存地址,也就是记录某线程当前执行的方法的那一条指令,如线程的执行被中断后就会依靠这些数据来恢复(JVM规范之定义了对java方法需要记录指针,对本地方法则没有规范)
Java栈:
java栈与线程相关联,每创建一个线程就会为该线程创建一个栈,而线程中运行的每一个方法则与栈中的每一个栈帧关联起来,栈帧中包含局部变量,操作栈,方法返回值等。每一个方法完成,就会弹出栈帧的元素(操作栈的栈顶元素),作为返回值,清除这个栈帧。java栈的栈顶就是当前正在执行的活动栈,PC寄存器会指向这个方法的地址。Java栈和线程对应起来,这些数据不是线程共享的,不存在一致性问题
堆:
存储Java对象的地方,由于时所有线程共享的,所以需要关心数据的一致性问题。
方法区:
用于存储类结构信息,如常量池、域,方法数据、方法体,构造函数、包括类中的专用方法、实力初始化、接口初始化等
- 方法区同样属于java堆的永久代
- 如果使用动态编译时要注意这部分是否能满足类的存储
- 这个区域并不像其他java堆一样频繁地被GC回收
运行时常量池:
包括编译器的数字常量,方法或者域的引用。(注意,这一区域属于方法区)
本地方法栈:
JVM为运行native方法准备的空间。由于很多native方法是用c语言实现的,所以又叫C栈。这个区域jvm并没有严格的限制,由不同的JVM实现者自由实现。
JVM内存分配策略
- 静态内存分配策略:在编译期间必须知道内存空间(8个基本类型)的大小才可以分配(所以可以在编译期间分配内存,但java栈中的局部变量和引用等数据同样使用静态内存分配,该空间大小是在编译期间知道,但是在程序加载时才正式分配的,并且这一部分内存在java栈上分配),不允许可变数据类型或者递归、嵌套等结构的出现。
- 栈内存分配:不需要在编译时知道程序对数据的需求、但在进入程序模块时必须知道数据的要求才可以分配内存。并且按照后进先出的原则进行内存的分配
- 堆内存分配:可以在运行到相应代码才知道内存空间的大小,灵活但是效率较差
JVM的内存分配主要基于堆和栈,
栈:
- 栈的分配时和线程绑定的,为每一个线程创建一个栈,为线程每调用一个新的方法创建一个栈帧
- 栈中主要保存基本类型数据和对象的句柄(引用、指针),栈的数据大小和生存期都必须是确定的,而本地变量和操作栈的大小都可以在编译时(class字节码)确定
- 存取速度比堆要快,仅次于寄存器,这也是为什么运算要留在操作栈中执行
- 栈的内存分配是在程序运行时进行的,只是分配的大小是在编译时确定的
堆
- 堆可供所有线程访问,主要存放实例数据,由于时动态分配内存大小的,所以存取速度较慢,同样通过GC回收内存
- 新对象如何分配内存:根据对应Constant_Class_info类型数据执行new指令,赋值,调用init初始化构造器最后才赋值给变量(所以在初始化完成前不应该把实例指针公布,可类比“对象逸出”的问题),栈中存放的只是指针(引用),而真正的实例数据是存放在堆中的
- 堆在运行时请求操作系统分配内存,灵活但效率低
JVM内存回收策略
静态内存的分配和回收:类中的局部变量和对象的引用都是静态内存分配的(这一部分内存空间在栈上分配),在编译时这一部分空间已经确定,只是在程序被加载时一次性分配,而当方法运行结束时随着对应栈帧的撤销回收。
动态内存分配和回收:像实例等数据只有在JVM解析类对象后才能知道具体需要分配多少空间,并且堆中的这些数据只有在对象不再被引用时才会被回收。只要某个对象不再被其他活动对象所引用就可以被回收,而活动对象是指可以被根集合对象所到达的对象。根集合对象所包含的对象跟jvm具体实现有关,但是大都会包含如下一些元素:方法中局部变量的引用、java操作栈中的对象引用、常量池中的对象引用、本地方法中持有的对象引用、类的class对象(当该Class对象不再被使用时同样会被回收)。
基于分代的垃圾收集算法:分为young、old、perm三个区
young区分为eden区和两个survivor区,eden区满后会触发minorGC,minorGC后仍存活的对象将放到survivor区(若另一个survivor区存在活动对象将放到同一个区中,保证一个survivor区是空的)
old区中已满将会触发FullGC,old区中存放的是:
- Young的survivor区中已满后minorGC仍然存活的对象
- survivor区中足够老的对象
- Eden中已满,并且minorGC后存在,并因为servivor已满无法存放的对象。
perm区主要存放类的class对象,只有在FullGC时才会被回收
三类垃圾收集算法,Serial Collector、Parallel Colllector、CMS Collector
Serial Collector
JVM在client模式下的默认的GC方式(可以通过配置jvm参数 -XX:+UserSerialGC来配置实用该算法)-XX:+PrintGCDetails 可以配置打印GC日志。所有创建的对象都将在Eden区分配,如果创建的对象超过Eden区的大小或者超过PretenureSizeThreshold配置(-XX:PretenureSizeThreshold=123)参数的大小都只能在old区分配。当Eden区空间不足时会触发minorGC,但是触发minorGC之间会检查晋升到Old区的平均对象大小是否大于old的剩余空间,如果大于则触发FullGC,如果小于则根据HandlePromotionFailure(是否允许担保失败)参数,如果为true则仅触发MinorGC,否则触发FullGC。MinorGC时除了将Eden区的非活动对象回收外,还会把一些年老的对象晋升到Old区,而这个年老对象的‘岁数’则通过 -XX:MaxTenuringThreshold=10设置(在survivor的from/to区之间移动一次则为一岁),另外如果To的Servivor区空间不足移入对象时,这些对象也会直接放入Old区。如果old区或者Perm区空间不足时就会触发FullGC。GC时因为是串行的,所以动作是单线程完成的,JVM中的其他应用程序会全部停止。
Parallel Collector
Parallel GC根据MinorGC和FullGC的不同分为三种,分别是ParNewGC、ParallelGC和ParallelOldGC。
ParNewGC:
可以通过参数 -XX:+UseParNewGC参数来指定,与Serail Collector相似,只是回收是多线程并行的,并且通过一个UseAdaptiveSizePolicy配置参数来控制对象经过多少次回收后可以直接放入old区。
ParallelGC:
是server模式JVM下的默认GC方式,可以通过 -XX:+UserParallelGC参数来强制指定,并行回收的线程数可以通过 -XX:ParallelGCThreads来指定,这个值有个计算公式,如果cpu核数小于8,则可以和核数一样,如果大于8值为:3+(核数*5)/8,可以通过 -Xmn:10m来控制Young区的大小,而Eden、FROM区的大小比例可以通过 -XX:SurvivorRatio=8来设置Eden和FromSpace的比值是8:1(当然To区也占1)。当在Eden区中申请内存空间时,如果Eden区不够,则比较当前申请空间时否大于Eden的一半,是的话则直接在old中分配,不是的话则会执行MinorGC,但是执行MinorGC之前会检查old区的平均晋升大小是否大于剩余空间,大于则触发FullGC,并且在执行FullGC后会再一次检查old的晋升的平均大小是否大于剩余空间,不是的话会再次触发FullGC,也就是说可能会触发两次FullGC。,Young区的晋升规则可以通过以下参数设置:AlwaysTenure:默认为false,为true则表示只要在MinorGC时存活则晋升,NeverTenure,默认为false,是true则永不晋升。如果上面两个参数都没有配置的情况下设置UseAdaptiveSizePolicy,则启动时将以InitialTenuringThreshold值作为存活次数的阀值,并且在每次GC后调整。如果不使用UseAdaptiveSizePolicy则将以MaxTenuringThreshold为准(通过-XX:-UseAdaptiveSizePolicy设置)另外如果MinorGC时Servivor的To区空间不够,也会直接放到old区。old或者Perm区满时会触发FullGC,如果配置了参数ScavengeBeforeFullGC则在FullGC之前会触发MinorGC
PrarllelOldGC:
可以通过 -XX:+UseParallelOldGC参数来强制指定,同样可以通过-XX:ParallelGCThreads来指定线程数,这个值有个计算公式,如果cpu核数小于8,则可以和核数一样,如果大于8值为: 3+(核数*5)/8。与ParallelGC的不同在于FullGC,它的FullGC动作为清空整个Heap对中的垃圾对象,清楚Perm区中已经被卸载的类信息,并进行压缩,而ParallelGC只清楚部分heap堆中的垃圾对象,并对部分空间进行压缩。
CMS Collector
可以通过 -XX:+UseConcMarkSweepGC来指定,并发的默认线程为4,也可以通过ParallelCMSThreads指定。CMS Collector使用CMS GC、Minor GC、FullGC。而CMS GC不同于其他两种GC,触发规律是基于Old区、和Perm区的使用率(触发后回收对应old或perm区的内存),达到一定比例就会触发(默认是92%),该比例可以通过CMSInitiatingOccupancyFraction来指定,另外设置让Perm区也使用CMS GC可以通过参数 -XX:+CMSClassUnloadingEnabled来指定。这个模式下的minorGC与Serial Collector基本一致,只是采用多线程。FullGC只在两种情况触发,一种是Eden分配失败后分配到To区,To区满分配到Old区,Old区不够则触发FullGC,另外一种是当CMS GC向Old申请内存失败时会触发FullGC。Hotspot1.6下使用这种算法并显示调用System.gc(如Nio可能需要显示调用),且设置了ExplicitFCInvokesConcurrent参数,将会导致内存泄露。
内存问题分析
日志格式:
[GC [<Collector>:<starting occupancy1> -> <ending occupancy1> (total size1) , <paise time1> secs ] <starting occupancy2> -> <ending occupancy2> (total size2), <paise time2> secs ]
<Collector> 收集器的名称
<starting occupancy1>Young区GC前内存
<endingoccupancy1>Young区GC后内存
<paise time1>YOUNG区局部收集时JVM的暂停时间
<starting occupancy2>表示JVMHeap GC前内存
<endingoccupancy2>表示JVMHeap GC后内存
<paise time2>GC过程中JVM的暂停总时间
GC日志对内存泄露的判断:
- 根据<starting occupancy1> - <ending occupancy1>得到young区被回收或晋升的内存大小,根据<starting occupancy2> - <ending occupancy2>得到当前整个堆的大小变化,两者的差值就是young区晋升到Old区的值
- 假如<ending occupancy2>随时间的延长一直增长,并且伴随频繁的GC,则很有可能是内存泄露,可使用jstat工具分析
- 堆快照的分析,可以通过参数: -XX:+HeadDumpOnOutOfMemoryError来配置在内存耗尽时记录下内存快照,同时可以通过-XX:HeadDumpPath来指定文件路径,这个文件的命名格式如java_[pid].hprof
JVM Crash日志分析:
- 可以通过-XX:ErrorFile = /tmp/log/hs_error_%p.log来指定jvm的日志文件
- 文件信息主要分为四种,退出原因分类、导致退出的Thread信息(栈信息,具体哪行代码出错)、退出时的Process状态信息(所有线程及线程处于的状态,jvm的堆信息)、退出时与操作系统相关信息
- 退出原因主要三种:
-
- EXCEPTION_ACCESS_VIOLATION:运行的是JVM自己的代码,很可能是JVM的BUG
- SIGSEGV:JVM在执行本地代码或者JNI的代码,很可能是第三方本地库有问题
- EXCEPTION_STACK_OVERFLOW:这个是本地栈溢出的错误,可以将JVM的栈的尺寸调大,主要是两个参数-Xss 和 -XX:StackShadowPages=n