zoukankan      html  css  js  c++  java
  • JVM

    1、Java监控工具使用

    1.1jconsole

    jconsole是一种集成了上面所有命令功能的可视化工具,可以分析jvm的内存使用情况和线程等信息。

    启动jconsole

    通过JDK/bin目录下的“jconsole.exe启动Jconsole后,将自动搜索出本机运行的所有虚拟机进程,不需要用户使用jps来查询了,双击其中一个进程即可开始监控。也可以“远程连接服务器,进行远程虚拟机的监控。”

    1.2jvisualvm

    提供了和jconsole的功能类似,提供了一大堆的插件。Jdk/bin目录下有jvisualvm.exe

    插件中,Visual GC(可视化GC)还是比较好用的,可视化GC可以看到内存的具体使用情况。

    2、java内存模型

    2、1内存模型图解

    如上图所示,Java虚拟机运行时数据区域被分为五个区域:(Heap)、栈(Stack)、本地方法栈(Native Stack)、方法区(Method Area)、程序计数器(Program Count Register)

    2、2内存划分(堆、栈、方法区、程序计数器、本地方法栈)

    2、3总结

    1、 线程私有的数据区域有:

       Java虚拟机栈(Java Stack

       本地方法栈(Native Stack

    2、 线程共有的数据区域有:

      堆(Java Heap

      方法区

    3、GC算法

    3、1标记-清除算法(Mark-Sweep)

    1、标记出所有需要回收的对象

    2、在标记完成后统一回收所有被标记的对象

    缺点:一个是效率问题,标记和清除两个过程的效率都不高

    另一个是空间问题,标记清除之后会产生大量不连续的内存碎片,空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时,无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

    3、2复制算法(Copying) 

    1、将可用内存按容量划分为大小相等的两块,每次只使用其中的一块。

    2、当这一块的内存用完了,就将还存活着的对象复制到另外一块上面,然后再把已使用过的内存空间一次清理掉。

    优点:这样使得每次都是对整个半区进行内存回收,内存分配时也就不用考虑内存碎片等复杂情况,只要移动堆顶指针,按顺序分配内存即可,实现简单,运行高效。只是这种算法的代价是将内存缩小为了原来的一半,未免太高了一点。

    缺点:复制收集算法在对象存活率较高时就要进行较多的复制操作,效率将会变低

    3、3标记-整理算法(Mark-Compact)

    1、标记

    2、让所有存活的对象都向一端移动,然后直接清理掉端边界以外的内存

    3、4分代收集算法(Generational Collection)

    1、根据对象存活周期的不同将内存划分为几块。

    2、一般是把Java堆分为新生代和老年代,这样就可以根据各个年代的特点采用最适当的收集算法。

    3在新生代中,每次垃圾收集时都发现有大批对象死去,只有少量存活,那就选用复制算法,只需要付出少量存活对象的复制成本就可以完成收集。

    4老年代中因为对象存活率高、没有额外空间对它进行分配担保,就必须使用“标记—清理”或者“标记—整理”算法来进行回收

    4、垃圾回收器

    4、1Serial收集器

    1、是一个单线程的收集器,“Stop The World

    2、对于运行在Client模式下的虚拟机来说是一个很好的选择

    3、简单而高效

    4、2Serial Old收集器

    1Serial收集器的老年代版本,它同样是一个单线程收集器,使用“标记-整理”算法。

    2、主要意义也是在于给Client模式下的虚拟机使用。

    3、如果在Server模式下,那么它主要还有两大用途:

        一种用途是在JDK 1.5以及之前的版本中与Parallel Scavenge收集器搭配使用[1]

        另一种用途就是作为CMS收集器的后备预案,在并发收集发生Concurrent Mode Failure时使用。

    4、3ParNew收集器

    1Serial收集器的多线程版本

    2、单CPU不如Serial

    3Server模式下新生代首选,目前只有它能与CMS收集器配合工作

    4、使用-XX+UseConcMarkSweepGC选项后的默认新生代收集器,也可以使用-XX+UseParNewGC选项来强制指定它。

    5-XXParallelGCThreads:限制垃圾收集的线程数。

    4、4Parallel Scavenge收集器

    1、吞吐量优先”收集器

    2、新生代收集器,复制算法,并行的多线程收集器

    3、目标是达到一个可控制的吞吐量(Throughput)。

    4、吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间),虚拟机总共运行了100分钟,其中垃圾收集花掉1分钟,那吞吐量就是99%

    5、两个参数用于精确控制吞吐量:

    -XXMaxGCPauseMillis是控制最大垃圾收集停顿时间

    -XXGCTimeRatio直接设置吞吐量大小

    -XX+UseAdaptiveSizePolicy:动态设置新生代大小、EdenSurvivor区的比例、晋升老年代对象年龄

    6、并行(Parallel):指多条垃圾收集线程并行工作,但此时用户线程仍然处于等待状态。

    7、并发(Concurrent):指用户线程与垃圾收集线程同时执行(但不一定是并行的,可能会交替执行),用户

    程序在继续运行,而垃圾收集程序运行于另一个CPU上。

    Parallel Old收集器

    1Parallel Scavenge收集器的老年代版本,使用多线程和“标记-整理”算法。

    2、在注重吞吐量以及CPU资源敏感的场合,都可以优先考虑Parallel ScavengeParallel Old收集器。

     

    CMS收集器一款优秀的收集器

    1、以获取最短回收停顿时间为目标的收集器。

    2、非常符合互联网站或者B/S系统的服务端上,重视服务的响应速度,希望系统停顿时间最短的应用

    3、基于“标记—清除”算法实现的

    4CMS收集器的内存回收过程是与用户线程一起并发执行的

    5、它的运作过程分为4个步骤,包括:

            初始标记,“Stop The World”,只是标记一下GC Roots能直接关联到的对象,速度很快

            并发标记,并发标记阶段就是进行GC RootsTracing的过程

            重新标记,Stop The World”,是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录,但远比并发标记的时间短

            并发清除(CMS concurrent sweep

    6、优点:并发收集、低停顿

    7、缺点:

                CPU资源非常敏感。

                无法处理浮动垃圾,可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。

                一款基于“标记—清除”算法实现的收集器

    G1Garbage-First)收集器

    1、当今收集器技术发展的最前沿成果之一

    2G1是一款面向服务端应用的垃圾收集器。

    3、优点:

            并行与并发:充分利用多CPU、多核环境下的硬件优势

            分代收集:不需要其他收集器配合就能独立管理整个GC

            空间整合:“标记—整理”算法实现的收集器,局部上基于“复制”算法不会产生内存空间碎片            

            可预测的停顿:能让使用者明确指定在一个长度为M毫秒的时间片段内,消耗在垃圾收集上的时间不得超过N毫秒

    4G1收集器的运作大致可划分为以下几个步骤:

            初始标记:标记一下GC Roots能直接关联到的对象,需要停顿线程,但耗时很短

            并发标记:是从GC Root开始对堆中对象进行可达性分析,找出存活的对象,这阶段耗时较长,但可与用户程序并发执行

            最终标记:修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录

            筛选回收:对各个Region的回收价值和成本进行排序,根据用户所期望的GC停顿时间来制定回收计划

    垃圾收集器参数总结

    收集器设置:

    -XX:+UseSerialGC:年轻串行(Serial),老年串行(Serial Old

    -XX:+UseParNewGC:年轻并行(ParNew),老年串行(Serial Old

    -XX:+UseConcMarkSweepGC:年轻并行(ParNew),老年串行(CMS),备份(Serial Old

    -XX:+UseParallelGC:年轻并行吞吐(Parallel Scavenge),老年串行(Serial Old

    -XX:+UseParalledlOldGC:年轻并行吞吐(Parallel Scavenge),老年并行吞吐(Parallel Old

    收集器参数:

    -XX:ParallelGCThreads=n:设置并行收集器收集时使用的CPU数。并行收集线程数。

    -XX:MaxGCPauseMillis=n:设置并行收集最大暂停时间

    -XX:GCTimeRatio=n:设置垃圾回收时间占程序运行时间的百分比。公式为1/(1+n)

    -XX:+CMSIncrementalMode:设置为增量模式。适用于单CPU情况。

    -XX:ParallelGCThreads=n:设置并发收集器年轻代收集方式为并行收集时,使用的CPU数。并行收集线程数。

     5、JVM参数列表(重点,CVTE笔试考过)

    java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:MaxPermSize=16m  -XX:MaxTenuringThreshold=0

    -Xmx3550m:最大堆内存为3550M

    -Xms3550m:初始堆内存为3550m

    此值可以设置与-Xmx相同,以避免每次垃圾回收完成后JVM重新分配内存。

    -Xmn2g:设置年轻代大小为2G

    整个堆大小=年轻代大小 + 年老代大小 + 持久代大小。持久代一般固定大小为64m,所以增大年轻代后,将会减小年老代大小。此值对系统性能影响较大,Sun官方推荐配置为整个堆的3/8

    -Xss128k:设置每个线程的堆栈大小。

    JDK5.0以后每个线程堆栈大小为1M,在相同物理内存下,减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的,不能无限生成,经验值在 3000~5000左右。 

    -XX:NewRatio=4:设置年轻代(包括Eden和两个Survivor区)与年老代的比值(除去持久代)。设置为4,则年轻代与年老代所占比值为14,年轻代占整个堆栈的1/5

    -XX:SurvivorRatio=4:设置年轻代中Eden区与Survivor区的大小比值。

    设置为4,则两个Survivor区与一个Eden区的比值为2:4,一个Survivor区占整个年轻代的1/6

    -XX:MaxPermSize=16m:设置持久代大小为16m

    -XX:MaxTenuringThreshold=15:设置垃圾最大年龄。

    如果设置为0的话,则年轻代对象不经过Survivor区,直 接进入年老代。对于年老代比较多的应用,可以提高效率。如果将此值设置为一个较大值,则年轻代对象会在Survivor区进行多次复制,这样可以增加对象 再年轻代的存活时间,增加在年轻代即被回收的概论。

    收集器设置

    -XX:+UseSerialGC:设置串行收集器

    -XX:+UseParallelGC:设置并行收集器

    -XX:+UseParalledlOldGC:设置并行年老代收集器

    -XX:+UseConcMarkSweepGC:设置并发收集器

    垃圾回收统计信息

    -XX:+PrintGC

    -XX:+PrintGCDetails

    -XX:+PrintGCTimeStamps

    -Xloggc:filename

    并行收集器设置

    -XX:ParallelGCThreads=n:设置并行收集器收集时使用的CPU数。并行收集线程数。

    -XX:MaxGCPauseMillis=n:设置并行收集最大暂停时间

    -XX:GCTimeRatio=n:设置垃圾回收时间占程序运行时间的百分比。公式为1/(1+n)

    并发收集器设置

    -XX:+CMSIncrementalMode:设置为增量模式。适用于单CPU情况。

    -XX:ParallelGCThreads=n:设置并发收集器年轻代收集方式为并行收集时,使用的CPU数。并行收集线程数。

     

     

     

     

     

     

  • 相关阅读:
    LINQ查询表达式(1)
    JSON是什么
    .net序列化
    wampserver
    JQuery系列(1)
    c# 数据类型转换
    并不对劲的uoj311.[UNR #2]积劳成疾
    并不对劲的uoj308.[UNR #2]UOJ拯救计划
    并不对劲的CF1349B&C:Game of Median Life
    并不对劲的复健训练-CF1329B&C:Heap Sequences
  • 原文地址:https://www.cnblogs.com/ahu-lichang/p/6741449.html
Copyright © 2011-2022 走看看