JVM0909

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/u014067137/article/details/82558347

1、可以给JVM设置一些参数,如Xmx256m表示JVM的最大可用内存。(x)

最大堆内存是Xmx。除了堆,还有方法区、线程栈,还有本地内存可以使用。

2、jvm堆分为:新生代(一般是一个Eden区,两个Survivor区),老年代(old区)。

      常量池属于 PermGen(方法区)

  • 1,新生代:(1)所有对象创建在新生代的Eden区,当Eden区满后触发新生代的Minor GC,将Eden区和非空闲Survivor区存活的对象复制到另外一个空闲的Survivor区中。(2)保证一个Survivor区是空的,新生代Minor GC就是在两个Survivor区之间相互复制存活对象,直到Survivor区满为止。
  • 2,老年代:当Survivor区也满了之后就通过Minor GC将对象复制到老年代。老年代也满了的话,就将触发Full GC,针对整个堆(包括新生代、老年代、持久代)进行垃圾回收。
  • 3,持久代:持久代如果满了,将触发Full GC。

3、full GC触发的条件

除直接调用System.gc外,触发Full GC执行的情况有如下四种。

1. 旧生代空间不足
旧生代空间只有在新生代对象转入及创建为大对象、大数组时才会出现不足的现象,
当执行Full GC后空间仍然不足,则抛出如下错误:
java.lang.OutOfMemoryError: Java heap space
为避免以上两种状况引起的FullGC,调优时应尽量做到让对象在Minor GC阶段被回收、
让对象在新生代多存活一段时间及不要创建过大的对象及数组。

2. Permanet Generation空间满
PermanetGeneration中存放的为一些class的信息等,当系统中要加载的类、反射的类和调用的方法较多时,Permanet Generation可能会被占满,在未配置为采用CMS GC的情况下会执行Full GC。
如果经过Full GC仍然回收不了,那么JVM会抛出如下错误信息:
java.lang.OutOfMemoryError: PermGen space
为避免Perm Gen占满造成Full GC现象,可采用的方法为增大Perm Gen空间或转为使用CMS GC。

3. CMS GC时出现promotion failed和concurrent mode failure
对于采用CMS进行旧生代GC的程序而言,尤其要注意GC日志中是否有promotion failed和concurrent mode failure两种状况,当这两种状况出现时可能会触发Full GC。
promotionfailed是在进行Minor GC时,survivor space放不下、对象只能放入旧生代,
而此时旧生代也放不下造成的;concurrent mode failure是在执行CMS GC的过程中同时有对象要放入旧生代,而此时旧生代空间不足造成的。
应对措施为:增大survivorspace、旧生代空间或调低触发并发GC的比率,
但在JDK 5.0+、6.0+的版本中有可能会由于JDK的bug29导致CMS在remark完毕后很久才触发sweeping动作。对于这种状况,可通过设置-XX:CMSMaxAbortablePrecleanTime=5(单位为ms)来避免。

4. 统计得到的Minor GC晋升到旧生代的平均大小大于旧生代的剩余空间
这是一个较为复杂的触发情况,Hotspot为了避免由于新生代对象晋升到旧生代导致旧生代空间不足的现象,
在进行Minor GC时,做了一个判断,如果之前统计所得到的Minor GC晋升到旧生代的平均大小大于旧生代的剩余空间,那么就直接触发Full GC。
例如程序第一次触发MinorGC后,有6MB的对象晋升到旧生代,那么当下一次Minor GC发生时,
首先检查旧生代的剩余空间是否大于6MB,如果小于6MB,则执行Full GC。
当新生代采用PSGC时,方式稍有不同,PS GC是在Minor GC后也会检查,
例如上面的例子中第一次Minor GC后,PS GC会检查此时旧生代的剩余空间是否大于6MB,
如小于,则触发对旧生代的回收。
除了以上4种状况外,对于使用RMI来进行RPC或管理的Sun JDK应用而言,默认情况下会一小时执行一次Full GC。
可通过在启动时通过- java-Dsun.rmi.dgc.client.gcInterval=3600000来设置Full GC执行的间隔时间或通过-XX:+ DisableExplicitGC来禁止RMI调用System.gc。
链接:https://www.nowcoder.com/questionTerminal/6e9fadc9f3234551bd92d6331a14607d
来源:牛客网

1.Scavenge GC[Minor GC]:当新对象生成,并且在Eden区申请失败的时候将会出发Scavenge GC。
将会遍历整个Eden区,将活动的对象移到Survivor区,回收不活动的对象。并整理两个Survivor区。
2.Full GC:遍历整个堆,包括年老代和持久代。速度比Scanvenge GC慢很多,所以尽量减少Full GC.
造成Full GC的原因:
     1.年老代被写满
     2.持久代被写满
     3.显示调用System.GC
     4.上一个GC后个heap的各域分配策略动态变化。

4、两个最基本的java回收算法:复制算法和标记清理算法

复制算法:两个区域A和B,初始对象在A,继续存活的对象被转移到B。此为新生代最常用的算法

标记清理:一块区域,标记可达对象(可达性分析),然后回收不可达对象,会出现碎片,那么引出

标记-整理算法:多了碎片整理,整理出更大的内存放更大的对象

两个概念:新生代和年老代

新生代:初始对象,生命周期短的

永久代:长时间存在的对象

整个java的垃圾回收是新生代和年老代的协作,这种叫做分代回收。

P.S:Serial New收集器是针对新生代的收集器,采用的是复制算法

Parallel New(并行)收集器,新生代采用复制算法,老年代采用标记整理

Parallel Scavenge(并行)收集器,针对新生代,采用复制收集算法

Serial Old(串行)收集器,新生代采用复制,老年代采用标记整理

Parallel Old(并行)收集器,针对老年代,标记整理

CMS收集器,基于标记清理

G1收集器:整体上是基于标记 整理 ,局部采用复制

综上:新生代基本采用复制算法,老年代采用标记整理算法。cms采用标记清理。

5、

运行时数据区包括:虚拟机栈区,堆区,方法区,本地方法栈,程序计数器

虚拟机栈区 :也就是我们常说的栈区,线程私有,存放基本类型,对象的引用和 returnAddress ,在编译期间完成分配。

堆区 , JAVA 堆,也称 GC 堆,所有线程共享,存放对象的实例和数组, JAVA 堆是垃圾收集器管理的主要区域。

方法区 :所有线程共享,存储已被虚拟机加载的类信息,常量,静态变量,即时编译器编译后的代码等数据。这个区域的内存回收目标主要是针对常量池的对象的回收和对类型的卸载。

程序计数器 :线程私有,每个线程都有自己独立的程序计数器,用来指示下一条指令的地址。



本地方法栈(Native Method Stacks)与虚拟机栈所发挥的作用是非常相似的,其区别不过是虚拟机栈为虚拟机执行Java方法(也就是字节码)服务,而本地方法栈则是为虚拟机使用到的Native方法服务。虚拟机规范中对本地方法栈中的方法使用的语言、使用方式与数据结构并没有强制规定,因此具体的虚拟机可以自由实现它。甚至有的虚拟机(譬如Sun HotSpot虚拟机)直接就把本地方法栈和虚拟机栈合二为一。与虚拟机栈一样,本地方法栈区域也会抛出StackOverflowError和OutOfMemoryError异常。
运行时数据区包括:程序计数器、虚拟机栈、本地方法栈、Java堆、方法区以及方法区中的运行时常量池

1、程序计数器: 线程私有,是当前线程所执行的字节码的行号指示器,
如果线程正执行一个java方法,计数器记录正在执行的虚拟机字节码指令的地址,
如果线程正在执行的是Native方法,则计数器值为空;

2、虚拟机栈: 即栈区, 线程私有 ,为虚拟机执行 Java 方法(字节码)服务,
每个方法在执行的时会创建一个栈帧用于存放局部变量表、操作数栈、动态链接和方法出口等信息,
每个方法的调用直至执行完成对应于栈帧的入栈和出栈;

3、本地方法栈: 为虚拟机使用的 N ative 方法服务,也是 线程私有 ;

4、Java 堆: 在虚拟机启动时创建, 线程共享 ,唯一目的是存放对象实例,
是垃圾收集器管理的主要区域——” GC 堆“,可以细分为新生代和老年代,
新生代又可以细分为 Eden 空间、 From Survivor 空间和 To Survivor 空间;
物理上可以不连续,但逻辑上连续,可以选择固定大小或者扩展;

5、方法区: 线程共享 ,用于存储被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。
被称为“永久代”,是因为 HotSpot虚拟机的设计团队把 GC 分代收集扩展到方法区,
即使用永久代来实现方法区,像 GC 管理 Java 堆一样管理方法区,
从而省去专门为方法区编写内存管理代码,内存回收目标是针对常量池的回收和堆类型的卸载;

6、运行时常量池: 线程共享 ,是方法区的一部分, 
Class文件中存放编译期生成的各种字面量和符号引用,类加载后进入方法区的运行时常量池中。

6、

hotspot的方法区存放在永久代中,因此方法区被人们称为永久代。
永久代的垃圾回收主要包括类型的卸载和废弃常量池的回收。当没有对象引用一个常量的时候,
该常量即可以被回收。而类型的卸载更加复杂。
必须满足一下三点,
    该类型的所有实例都被回收了,
    该类型的ClassLoader被回收了,
    该类型对应的java.lang.Class没有在任何地方被引用,在任何地方都无法通过反射来实例化一个对象



JAVA堆内存分为持久代,年轻代和老年代。
年轻代存放新生成的对象。垃圾回收主要是针对这个区域。
在年轻代中经历了N次垃圾回收依然存活的对象被放入老年代中。
持久代存放的是类定义信息,与垃圾收集器关系不大。



永生代也是可以回收的,条件是 1.该类的实例都被回收。 2.加载该类的classLoader已经被回收 3.该类不能通过反射访问到其方法,而且该类的java.lang.class没有被引用 当满足这3个条件时,是可以回收,但回不回收还得看jvm。

7、https://blog.csdn.net/sivyer123/article/details/17139443详情参考

年老代溢出原因有  循环上万次的字符串处理、创建上千万个对象、在一段代码内申请上百M甚至上G的内存。
持久代溢出原因  动态加载了大量Java类而导致溢出。


堆内存设置
原理
JVM堆内存分为2块:Permanent Space 和 Heap Space。
Permanent 即 持久代(Permanent Generation),主要存放的是Java类定义信息,与垃圾收集器要收集的Java对象关系不大。
Heap = { Old + NEW = {Eden, from, to} },Old 即 年老代(Old Generation),
New 即年轻代(Young Generation)。年老代和年轻代的划分对垃圾收集影响比较大。
年轻代
所有新生成的对象首先都是放在年轻代。年轻代的目标就是尽可能快速的收集掉那些生命周期短的对象。
年轻代一般分3个区,1个Eden区,2个Survivor区(from 和 to)。

大部分对象在Eden区中生成。当Eden区满时,还存活的对象将被复制到Survivor区(两个中的一个),
当一个Survivor区满时,此区的存活对象将被复制到另外一个Survivor区,
当另一个Survivor区也满了的时候,从前一个Survivor区复制过来的并且此时还存活的对象,将可能被复制到年老代。

2个Survivor区是对称的,没有先后关系,所以同一个Survivor区中可能同时存在从Eden区复制过来对象,
和从另一个Survivor区复制过来的对象;
而复制到年老区的只有从另一个Survivor区过来的对象。
而且,因为需要交换的原因,Survivor区至少有一个是空的。
特殊的情况下,根据程序需要,Survivor区是可以配置为多个的(多于2个),
这样可以增加对象在年轻代中的存在时间,减少被放到年老代的可能。

针对年轻代的垃圾回收即 Young GC。

年老代
在年轻代中经历了N次(可配置)垃圾回收后仍然存活的对象,就会被复制到年老代中。
因此,可以认为年老代中存放的都是一些生命周期较长的对象。

针对年老代的垃圾回收即 Full GC。

持久代
用于存放静态类型数据,如 Java Class, Method 等。持久代对垃圾回收没有显著影响。
但是有些应用可能动态生成或调用一些Class,例如 Hibernate CGLib 等,
在这种时候往往需要设置一个比较大的持久代空间来存放这些运行过程中动态增加的类型。


所以,当一组对象生成时,内存申请过程如下:

JVM会试图为相关Java对象在年轻代的Eden区中初始化一块内存区域。
当Eden区空间足够时,内存申请结束。否则执行下一步。
JVM试图释放在Eden区中所有不活跃的对象(Young GC)。
释放后若Eden空间仍然不足以放入新对象,JVM则试图将部分Eden区中活跃对象放入Survivor区。
Survivor区被用来作为Eden区及年老代的中间交换区域。
当年老代空间足够时,Survivor区中存活了一定次数的对象会被移到年老代。
当年老代空间不够时,JVM会在年老代进行完全的垃圾回收(Full GC)。
Full GC后,若Survivor区及年老代仍然无法存放从Eden区复制过来的对象,
则会导致JVM无法在Eden区为新生成的对象申请内存,即出现“Out of Memory”。
OOM(“Out of Memory”)异常一般主要有如下2种原因:

1. 年老代溢出,表现为:java.lang.OutOfMemoryError:Javaheapspace
这是最常见的情况,产生的原因可能是:设置的内存参数Xmx过小或程序的内存泄露及使用不当问题。
例如循环上万次的字符串处理、创建上千万个对象、在一段代码内申请上百M甚至上G的内存。
还有的时候虽然不会报内存溢出,却会使系统不间断的垃圾回收,也无法处理其它请求。
这种情况下除了检查程序、打印堆内存等方法排查,还可以借助一些内存分析工具,比如MAT就很不错。

2. 持久代溢出,表现为:java.lang.OutOfMemoryError:PermGenspace
通常由于持久代设置过小,动态加载了大量Java类而导致溢出 ,
解决办法唯有将参数 -XX:MaxPermSize 调大(一般256m能满足绝大多数应用程序需求)。
将部分Java类放到容器共享区(例如Tomcat share lib)去加载的办法也是一个思路,
但前提是容器里部署了多个应用,且这些应用有大量的共享类库


参数说明
-Xmx3550m:设置JVM最大堆内存为3550M。
-Xms3550m:设置JVM初始堆内存为3550M。此值可以设置与-Xmx相同,以避免每次垃圾回收完成后JVM重新分配内存。
-Xss128k:设置每个线程的栈大小。JDK5.0以后每个线程栈大小为1M,之前每个线程栈大小为256K。
应当根据应用的线程所需内存大小进行调整。在相同物理内存下,减小这个值能生成更多的线程。
但是操作系统对一个进程内的线程数还是有限制的,不能无限生成,经验值在3000~5000左右。
需要注意的是:当这个值被设置的较大(例如>2MB)时将会在很大程度上降低系统的性能。
-Xmn2g:设置年轻代大小为2G。在整个堆内存大小确定的情况下,增大年轻代将会减小年老代,反之亦然。
此值关系到JVM垃圾回收,对系统性能影响较大,官方推荐配置为整个堆大小的3/8。
-XX:NewSize=1024m:设置年轻代初始值为1024M。
-XX:MaxNewSize=1024m:设置年轻代最大值为1024M。
-XX:PermSize=256m:设置持久代初始值为256M。
-XX:MaxPermSize=256m:设置持久代最大值为256M。
-XX:NewRatio=4:设置年轻代(包括1个Eden和2个Survivor区)与年老代的比值。
表示年轻代比年老代为1:4。
-XX:SurvivorRatio=4:设置年轻代中Eden区与Survivor区的比值。
表示2个Survivor区(JVM堆内存年轻代中默认有2个大小相等的Survivor区)与1个Eden区的比值为2:4,
即1个Survivor区占整个年轻代大小的1/6。
-XX:MaxTenuringThreshold=7:表示一个对象如果在Survivor区(救助空间)移动了7次还没有被垃圾回收就进入年老代。
如果设置为0的话,则年轻代对象不经过Survivor区,直接进入年老代,对于需要大量常驻内存的应用,这样做可以提高效率。
如果将此值设置为一个较大值,则年轻代对象会在Survivor区进行多次复制,这样可以增加对象在年轻代存活时间,
增加对象在年轻代被垃圾回收的概率,减少Full GC的频率,这样做可以在某种程度上提高服务稳定性。

8、序列化保存的是对象的状态,静态变量属于类的状态,因此,序列化不保存静态变量。

猜你喜欢

转载自blog.csdn.net/u014067137/article/details/82558347
JVM
今日推荐