精华内容
下载资源
问答
  • 常用JVM参数

    2019-03-18 11:25:27
    常用JVM参数 -Xms:初始堆大小,默认为物理内存的1/64(<1GB);默认(MinHeapFreeRatio参数可以调整)空余堆内存小于40%时,JVM就会增大堆直到-Xmx的最大限制 -Xmx:最大堆大小,默认(MaxHeapFreeRatio参数可以...

    常用JVM参数
    -Xms:初始堆大小,默认为物理内存的1/64(<1GB);默认(MinHeapFreeRatio参数可以调整)空余堆内存小于40%时,JVM就会增大堆直到-Xmx的最大限制
    -Xmx:最大堆大小,默认(MaxHeapFreeRatio参数可以调整)空余堆内存大于70%时,JVM会减少堆直到 -Xms的最小限制
    -Xmn:新生代的内存空间大小,注意:此处的大小是(eden+ 2 survivor space)。与jmap -heap中显示的New gen是不同的。整个堆大小=新生代大小 + 老生代大小 + 永久代大小。在保证堆大小不变的情况下,增大新生代后,将会减小老生代大小。此值对系统性能影响较大,Sun官方推荐配置为整个堆的3/8。
    -XX:SurvivorRatio:新生代中Eden区域与Survivor区域的容量比值,默认值为8。两个Survivor区与一个Eden区的比值为2:8,一个Survivor区占整个年轻代的1/10。
    -Xss:每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M,以前每个线程堆栈大小为256K。应根据应用的线程所需内存大小进行适当调整。在相同物理内存下,减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的,不能无限生成,经验值在3000~5000左右。一般小的应用, 如果栈不是很深, 应该是128k够用的,大的应用建议使用256k。这个选项对性能影响比较大,需要严格的测试。和threadstacksize选项解释很类似,官方文档似乎没有解释,在论坛中有这样一句话:"-Xss is translated in a VM flag named ThreadStackSize”一般设置这个值就可以了。
    -XX:PermSize:设置永久代(perm gen)初始值。默认值为物理内存的1/64。
    -XX:MaxPermSize:设置持久代最大值。物理内存的1/4。

    展开全文
  • 常用JVM参数配置

    2016-07-10 09:58:53
    在java启动脚本的参数配置中经常会看到一些形如:-XX:|->name的jvm参数,表示开启或关闭某项特性或属性,+代表开启,-代表关闭,下面介绍一些常用的内存分配配置参数

    在java启动脚本的参数配置中经常会看到一些形如:-XX:<+|->name的jvm参数,表示开启或关闭某项特性或属性,+代表开启,-代表关闭,下面介绍一些常用的内存分配配置参数

    -XX:name=<n>的选项表示需要带有数字,n即为数字。一些控制属性大小值的数字后面还可以带k/m/g表示KB/MB/GB。其他的数字选项则表示比率或百分比。

    -client 指定jvm把应用当成客户端类型程序进行优化,启用该配置后,内存占用是最重要的性能指标,远比高吞吐量重要。

    -server 指定jvm使用服务器类型进行优化,该选项适用于高吞吐量比启动时间和内存占用更重要的程序。

    -d64 表示加载64位jvm,而不是默认的32位jvm,开启该指令后可以使用更大的内存,64位jvm比32位jvm可以使用更多的内存,但是也会带来一定的性能损耗。这是因为java引用的长度从32位增加到了64位,长度的增加使得缓存行中的容纳的oops变少了,cpu高速缓存的效率也会降低。因此64位jvm上的cpu高速缓存效率的降低就会导致64位jvm的性能比32位jvm降低8%-20%。但是如果要启用64位jvm时,java堆内存最大值不超过32g时可以通过指针压缩来提升性能 -XX:+useCompressedOops

    -XX:+userCompressedOops 开启压缩指针特性,oops(Ordinary Object Pointer)是指普通对象指针,jvm内部以它来引用java对象。开启改特性后,会使64位jvm不但有更大的堆,而且还有32为jvm的性能。

    -Xms<n>[g|m|k] 配置java堆内存的初始值和最小值,是新生代和老年代的总和,<n>表示尺寸大小,[g|m|k] 表示尺寸的单位,java堆大小永远不会小于该配置值。

    -Xmx<n>[g|m|k] 配置java堆内存的最大值,java堆永远不会超过该配置值,如果超过后,系统就会报内存溢出异常。如果-Xmx大于Xms,java堆的大小会根据应用的需要扩展或者缩减,java堆的扩展或缩减需要FullGC,所以一般建议-Xms和-Xmx设置成相同的值。

    -XX:NewSize=<n>[g|m|k] 配置java堆内存新生代的初始大小和最小尺寸

    -XX:MaxNewSize=<n>[g|m|k] 配置java堆内存新生代的最大尺寸,如果-XX:MaxNewSize大于-XX:NewSize,新生代的大小会根据应用的需求而扩展或缩减,新生代的扩展或缩减需要FullGC,所以一般建议把-XX:MaxNewSize和-XX:NewSize设置成相同的值。下面还有个简单配置可以实现这样的效果

    -Xmn<n>[g|m|k]  同时配置新生代的初始值、最小值和最大值,如果希望-XX:MaxNewSize和-XX:NewSize设置成相同的值,可以使用这一行配置即可。

    -XX:NewRatio=<n> 配置新生代和老年代的尺寸比。例如:n为3,则比率为1:3,即新生代站新生代和老年代大小总和的1/4。如果java堆扩展或缩减,jvm将根据此比率调整新生代和老年代的大小。

    -XX:PermSize=<n>[g|m|k]  配置永久代的初始值和最小值

    -XX:MaxPermSize=<n>[g|m|k]  配置永久代的最大内存,如果-XX:MaxPermSize大于-XX:PermSize,永久代的尺寸会随着应用的需要而扩展或缩减,永久代的扩展或缩减也需要进行FllGC,所以一般建议设置成相同值。

    -XX:SurvivorRatio=<n> 配置单块Survivor区与Eden区的大小比率,<n>为比率,根据该配置的比率可以计算出Survivor区的内存大小:

    survivor size = -Xmn<n>/(-XX:SurvivorRatio=<n>  + 2)

    -XX:InitialSurvivorRatio=<n> 配置Survivor区初始比率,应该与Throughput收集器配置使用,这个选项通过在Throughput收集器开启自适应调整尺寸时使用,jvm会自适应调整Survivor区大小使应用可以正常运行。

    -XX:TargetSurvivorRatio=<percent> 在进行MinorGC之后,Suivivor区被占用的最大值,该值是Survivor区被占用的百分数,默认为50%。


    展开全文
  • 文章目录摘要jvm垃圾回收器 ...言归正传,有了充实的理论基础,便要开始运用于实践当中,本篇博客主要讲解jvm垃圾回收器的分类和选择,常用jvm参数,性能监控工具以及调优实战,带你一步步揭开jvm的神秘面纱...

    摘要

      本篇博客接着jvm专题系列—详解垃圾回收机制及其算法讲解,看懂此篇博客需要你对jvm内存结构,垃圾回收机制和算法有一定了解,所以推荐没有了解的朋友可以先看一下上篇jvm的博客,大神请无视。言归正传,有了充实的理论基础,便要开始运用于实践当中,本篇博客主要讲解jvm垃圾回收器的分类和选择,常用jvm参数,性能监控工具以及调优实战,带你一步步揭开jvm的神秘面纱。

    jvm垃圾回收器

      我们知道,jvm堆内存分为新生代和老生代,新生代采用复制算法,老生代采用标记-清除或者标记-整理算法来收集和清理垃圾,关于算法的具体实现便是接下来要讲解的垃圾回收器。
      jvm垃圾回收器目前主要有7种:serial收集器、parnew收集器、parallel scavenge收集器、serial old 收集器、parallel old收集器、cms收集器、g1收集器。7种垃圾回收器做进一步划分可以分为:
      新生代收集器:Serial、ParNew、Parallel Scavenge
      老生代收集器:CMS、Serial Old、Parallel Old
      整堆收集器: G1
      新生代收集器只能收集新生代的垃圾,老生代收集器只能收集老生代的垃圾,而整堆收集器G1新老通吃,值得一提的是,G1收集器将整个Java堆划分为多个大小相等的独立区域(Region)。虽然也保留了新生代、老年代的概念,但新生代和老年代不再是相互隔离的,他们都是一部分Region(不需要连续)的集合,所以G1收集器的堆内存结构跟我们之前介绍的结构区别是很大的,它标记了每个Region所属的区域,然后再对其进行垃圾回收。
      下图为jvm垃圾回收器图示:
    垃圾回收器图示
      如上图,连线表示可以搭配使用。你也许会好奇为什么cms不能和perallel scavenge搭配使用,cms为什么可以跟serial old搭配使用,parallel old为什么只能和parallel sacvenge搭配使用。首先回答第一个问题:parallel scavenge没有使用其他Gc通用的Gc框架,导致两者无法搭配,至于为什么没有使用同一个框架,这完全是人为原因,跟技术没有关系(也许未来可以实现两者共用吧)。第二个问题:二者其实并非搭配使用,cms收集器(并发收集器)采用的是标记-清除算法,与用户线程并发运行,所以会产生浮动垃圾(标记完垃圾之后产生的垃圾),当cms运行期间预留内存无法满足程序需要的时候,便会启动后备方案,使用serial old来进行收集(标记-整理),释放内存空间。第三个问题:parallel old跟parallel scavenge一样,为并行收集器,不能跟serial和parnew的原因同问题一。
      在这里有一个概念:并行收集器和并发收集器,可以把用户线程作为参照物,跟用户线程一起运行称之为并发,没有用户线程参与称之为并行。

    Serial收集器

      Serial收集器是最原始的一款垃圾收集器,也称之为串行收集器,顾名思义,它是单线程运行的,而且不止如此,它在收集垃圾的时候,会暂停其他所有的工作线程,直到收集结束,被称之“stop the world”。想象一下,比如你在看电影,每看五分钟需要暂停几秒钟,这显然是令人难以接受的。serial收集器的运行流程如下:
    serial运行流程
      对于"stop the world"这种不良体验,虚拟机的开发者表示非常理解,但也心存委屈:“你妈妈为你打扫房间的时候,肯定会让你老老实实坐着或者出去待着,如果一边打扫,你一边扔纸屑,那房间永远也无法打扫干净。”这听起来很有道理,并且事实的确如此,同时虚拟机开发团队也在为消除或减少内存回收而导致的停顿而一直努力着!

    ParNew收集器

      ParNew收集器其实就是Serial收集器的多线程版本,除了使用多条线程收集垃圾之外,其他行为基本和Serial收集器的实现完全一样。ParNew收集器只有在多核CPU的环境下才能发挥出它的优势(多线程收集速度快,停顿时间缩短),如果是单核CPU它甚至不如Serial收集器的效果好(单核CPU的线程切换导致额外开销)。它的运行流程如下:
    ParNew运行流程

    Parallel Scavenge收集器

      Parallel Scavenge与ParNew类似,也是一款并行多线程收集器,相比于ParNew,它的目标则是达到一个可控制的吞吐量(吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间)),如果虚拟机总共运行了100分钟,垃圾收集花了1分钟,那么吞吐量变为100-1/100=99%。
      停顿时间越短越适合与用户进行交互的程序,良好的响应速度可以提升用户体验,而高吞吐量则是可以高效利用cpu,主要用于在后台运算不需要进行用户交互的任务。
      Parallel Scavenge提供了两个参数来控制吞吐量:-XX:MaxGCPauseMillis(控制停顿时间(jvm尽量不超过设置的时间),单位ms),-XX:GCTimeRatio(吞吐量大小,大于0小于100),但你千万不要以为把停顿时间的参数设小,吞吐量参数设大就可以让垃圾收集的速度变快,停顿时间的缩短是靠牺牲吞吐量和新生代空间来换取的:系统把新生代调小,比如由1000兆调节为700兆,收集700兆的空间速度必然比1000兆快,但是相应的收集频率会增高,原来10s收集一次,每次停顿100ms,现在需要5s收集一次,每次停顿70ms(相当于10s停顿140ms),停顿时间确实下降了,但是吞吐量也降了下来。
      所以,Parallel Scavenge也被称为“吞吐量优先收集器”,此收集器还有一个参数:-XX:+UseAdaptiveSizePolicy,打开这个参数之后,不需要我们再额外设置新生代的大小以及新生代eden和survivor的比例等参数了,jvm会根据当前系统的运行情况动态调整这些参数以提供最合适的停顿时间和吞吐量,这种调节方式称为GC自适应的调节策略,同时这也是Parallel Scavenge和ParNew的重要区别之一。

    Serial Old收集器

      Serial Old跟Serial一样是一个单线程收集器,使用“标记-整理”算法。他可以作为CMS收集器的后备军,运行流程同Serial收集器运行流程。

    Parallel Old收集器

      Parallel Old收集器跟Parallel Scavenge一样是一个并行多线程收集器,采用“标记-整理”算法。它与Parallel Scavenge搭配适用于增加吞吐量以及CPU资源敏感的场合。工作流程如下:
    parallel old 工作流程

    CMS收集器

      CMS收集器全称Concurrent Mark Sweep,主打并发收集,低停顿,适用于B/S系统的服务端,我们熟知的淘宝网站使用的便是CMS收集器,它的收集器线程可以跟用户线程一起工作,这也是与并行收集器所不同的地方,运行流程如下:
    CMS运行流程
      由上图可见,尽管CMS可以跟用户线程一起运行,但它同样也无法避免“stop the world”,之前的博客讲过可达性原则,即在初始标记和重新标记验证对象死活的时候也会引起工作线程的停顿,只是停顿的时间较短。CMS收集器是一款非常优秀的垃圾回收器,但它也存在以下缺点:
      1.对CPU资源敏感。事实上,面向并发设计的程序对CPU资源都较为敏感,在并发阶段,他虽然不会使用户线程停顿,但是也会因为占用了一部分CPU资源而使应用程序变慢,总吞吐量就会降低。
      2.无法处理浮动垃圾,可能出现“Concurrent Mode Failure”导致另一次Full Gc(收集老生代成为Full Gc)。由于CMS在并发清理阶段用户线程依然运行着并不断产生垃圾,这部分垃圾出现在重新标记之后,所以在本次Gc中无法清理,这部分垃圾就称为浮动垃圾。CMS在垃圾收集的时候用户线程仍在运行,所以他不能向其他收集器一样等到老生代几乎填满再进行回收,需要预留一部分空间供并发时的程序使用,可以通过:-XX:CMSInitIatingOccupancyFaction的参数值来调节触发收集的百分比,一般不需要特意动它。如果预留空间无法满足程序运行的需要,那么就会出现Concurrent Mode Failure,这个时候就轮到Serial Old收集器登场了,jvm会临时使用Serial Old来重新对老年代进行垃圾收集,这同时也就意味着系统停顿时间变长,所以此参数设置过高容易引起大量Concurrent Mode Failure,反而降低性能!
      3.产生大量内存碎片。CMS利用的是标记-清除算法来进行垃圾收集(比标记-整理快),这必然会不可避免的产生内存碎片,内存碎片过多时,就算剩余空间很足,但是无法找到连续的内存空间去分配新来的大对象,就会不得不提前触发Full GC。我们可以通过开启XX:UseCMSCompactAtFullCollection参数来解决此问题(默认开启),这样CMS在顶不住要进行Full GC时会对内存碎片进行合并整理,但这也会使得停顿时间变长(内存整理无法并发执行)。通过XX:CMSFullGCsBeforeCompaction可以设置执行多少次不合并整理的Full Gc后,执行一次带合并整理的Full Gc,默认为0,即每次进入Full Gc时都会进行碎片整理。

    G1收集器

      G1收集器是当今收集器技术发展的最前沿成果之一,它是一款面向服务端应用的垃圾收集器。
      G1收集器具备以下特点:
      1.并行和并发
      2.分代收集
      3.空间整合:从整体看它基于标记-整理算法,从局部(两个Region之间)来看则是基于复制算法,这意味着它在运行的时候不会产生内存碎片,有利于程序长时间执行,不会因为分配大对象找不到连续的空间而提前触发Full Gc
      4.可预测停顿:可以让使用者明确指定在一个长度为M毫秒的时间片段内,垃圾回收的时间不超过N毫秒。运行流程如下:
    G1运行流程
      虽然G1收集器有诸多优点,但它的应用案例却少之又少,而且也缺乏与之相关的性能测试,但相信在未来G1会是最终的胜利者,我们可以一直观望!如果你的收集器目前没有什么问题,那么大可以维持现状,如果你的应用追求的是吞吐量,那么G1并不会为你带来什么特别的好处。

    最好的垃圾回收器 ?

      看到这里,我想你应该会明白不存在什么最好的垃圾回收器,选择什么回收器需要我们根据实际的业务场景来确定,如果追求低停顿,可以考虑ParNew+CMS组合,如果追求高吞吐量,可以考虑Parallel Scavenge+Parallel Old组合,单核CPU下还可以考虑最经典的Serial组合!

    常用的jvm参数

      通过jvm参数设置可以让我们实现对jvm的个性化定制,提高系统性能。使用参数只需要在java命令后面加上就可以,例如 java -Xmx100m hello,在eliplse和idea中同样可以很方便的进行设置,设置方法自行百度。

    堆参数

    堆参数
      jdk8永久代已经废弃,替换为Metaspace(本地内存),相应参数可以自行百度,默认值大约为4096M,一般的应用来说足够了。堆参数中可以适当把年轻代的内存设置的大一些,可以有效减少Full Gc的次数,提升系统的响应速度。

    回收器参数

    回收器参数
      通过上表的参数可以指定使用的垃圾回收器,后面会介绍常用的回收器参数组合。

    常用参数

    常用参数
      如上表,后面的几个参数可以打印GC日志,另外通过Xloggc:log/gc.log可以指定gc日志的位置,查看垃圾回收的情况,同时在OOM的时候可以在指定路径生成dump文件,方便我们可以使用性能监控工具分析查看。其中,xss参数值得注意,它是为每个线程所分配的内存大小,一般来说不会超过2兆,所以,xss设置的越大,可运行的线程总数就越少,但相应的每个线程栈的深度也就越深,不容易发生栈溢出,反之容易发生栈溢出,这也就是为什么有的公司严禁使用递归的原因,因为它会一直不停压栈。一般来说,jvm默认的大小基本已经够用,不需要再特别去设置。

    回收器常用组合

    回收器常用组合
      如上表,第二和第三种组合使用最为广泛!

    性能监控工具

      要想更进一步的分析jvm的运行情况,一款好的监控工具显得格外重要,幸运的是,jdk本身就自带了许多优秀的小工具,就在其bin目录下,如jps(相信大家熟知,打印jvm进程信息),jstat(查看运行时信息),jinfo(查看和修改虚拟机配置),jmap(生成dump文件)等等,当然最有名的当属jvisualvm,它几乎把jvm所有的工具命令整合并用图形化界面的方式为我们展现了出来,堪称业界良心!值得注意的是,这些小工具本身并不大,小的几十k,大的也不过几百k,实际上它们都只是一个壳子,真正的方法实现都封装进了tools.jar当中,有兴趣的朋友可以反编译看一下其中的源码实现。
      在使用jvisualvm之前,我们以tomcat为例,随便启动一个tomcat应用,便于一会去监控tomcat的进程信息。
    启动tomcat
      如上图,我成功的启动了tomcat,并且使用jps命令查看到了tomcat的进程id为875(Bootstrap为tomcat的启动应用),然后我用jstat命令打印出了5行jvm进程在200ms内的运行时信息(感兴趣的朋友可以百度以下每列的具体含义),注意有一列为MC,jdk1.8之前是PC,MC代表Metaspace(本地内存),PC为永久代分配的内存,这也说明了jdk1.8已然废弃了永久代。
      回归正题,让我们运行jvisualvm(环境变量配置的没有问题直接敲命令即可成功启动),如下:
    jvisualvm
      双击tomcat便可以监控其进程状态,如下:
    tomcat监控
      这里可以载入dump文件,我们可以通过查看类的实例数来查看实例创建的个数,如果某个实例个数过多或占用内存过大那么可以考虑发生了内存泄漏(无效引用得不到及时释放造成内存空间浪费):
    在这里插入图片描述
      jvisualvm还可以安装插件帮助我们更加方便的去监控jvm,一个很受欢迎的插件便是visual gc,我们可以去访问https://visualvm.github.io/pluginscenters.html选择对应的版本下载,然后在工具——》插件菜单中进行安装。
      安装完成后重启,效果如下:
    visual gc
      好了,常用的功能就是这些,远程连接请自行百度,教程很多,下面我们来看一个优化案例。

    调优案例

      由于环境限制,在本地复现问题相对来说比较困难,所以在这里主要通过第一人称故事的方式来进行讲解。
      我们公司为客户做了一套数据利用系统供用户多维度查询数据并导出生成excel,下面是系统的具体配置:
      服务器:centos7一台
      内存:64G
      jdk版本:1.8
      web服务器:springboot内置tomcat
      客户规模:一千人左右
      讲道理,一千人使用,这种服务器配置可以说是非常奢侈了,所以感觉上是完全不会有问题的。但是后来客户却反应说偶尔系统在导出excel的时候会有较长时间的卡顿,最长的时候甚至长达半分钟才能有所响应,于是便迅速介入调查。
      首先考虑是不是sql有问题,但是卡顿的情况是偶尔发生,平时反应速度很快,所以暂时排除了这种可能。
      然后去询问运维人员有没有进行服务器维护相关的操作,得到的答案是否定的,这就让人陷入了困扰之中。
      没办法,这种问题只能从jvm上找原因了,于是使用了jvisualvm来进行系统监控,当我看到堆内存的时候吓了一跳,足足设置了40g,后来经过询问,原来部署程序的哥们不想浪费宝贵的服务器资源,所以故意把堆内存设置的很大。相信我们都有优化eclipse或idea的体验,默认的xmx比较小,当我们调大之后eclipse或idea的速度明显就快了很多,所以哥们想到了这一点,毫不留情的把系统堆内存设置到了40g。
      其实到这里问题已经比较明显了,大概率是进行Full GC的时候由于堆内存过大而需要耗费大量时间(stop the world)导致系统停顿时间过长,因此用户便无法获得及时响应,后来我通过输出gc日志发现果然是Full GC引起的问题,40g的内存,一次消耗半分钟也不足为奇。那么为什么会发生Full GC呢?原因其实很简单,客户在导出excel的时候生成的workbook对象需要封装大量的数据,所以属于大对象,会被直接分配到老生代,随着时间推移,大对象越积越多,老生代内存不够用时,自然要触发Full GC。值得一提的是,如果确认程序中不会有大对象的产生,那么可能对象都没有进入老生代的机会,这种场景下主要在新生代中进行垃圾回收(minor gc),速度是非常快的,系统就会“飞起来”,但一般不会有这种理想的情况。
      卡顿的原因定位了,优化的方法也显而易见,最简单的方法:调小堆内存即可!后来除了调小堆内存,还做了以下优化:
    1.调小堆内存到4g
    2.单机部署6个节点,使用nginx负载均衡,提高cpu的利用率
    3.使用ParNew+CMS收集器组合(jdk默认为Parallel Scavenge+Parallel Old组合)
      优化过后,问题成功得到了解决。
      通过此案例也许会对你有所启发,很多人认为单机部署一个应用程序独占一台服务器是最好的选择,因为这样不会有其他程序抢占cpu资源,实际上这也不是绝对的,具体情况还需要具体分析。另外如果对jvm不够了解,不要贸然设置参数,否则可能会留下很大的坑,默认的往往不会有太大的问题。
      说到底,jvm调优只是一个辅助手段,大部分情况下往往都是代码层面的问题,通过优化代码,擅用设计模式,优化数据库结构,合理建立索引等方式照样会让系统稳定流畅运行。

    小结

      本篇博客的内容到这里就结束了,希望能对你有所启发,之后我会介绍jvm类加载器相关的知识并且手动实现一个简易的热部署插件。感谢您的观看,再见!

    展开全文
  • 常用JVM参数显示命令

    2019-05-07 23:16:45
    用来查看基于HotSpot的JVM里面中,所有具有访问权限的Java进程的具体状态, 包括进程ID,进程启动的路径及启动参数等等,与unix上的ps类似,只不过jps是用来显示java进程,可以把jps理解为ps的一个子集。 jstack ...

    jps

    用来查看基于HotSpot的JVM里面中,所有具有访问权限的Java进程的具体状态, 包括进程ID,进程启动的路径及启动参数等等,与unix上的ps类似,只不过jps是用来显示java进程,可以把jps理解为ps的一个子集。

    jstack

    jstack用于打印出给定的java进程ID或core file或远程调试服务的Java堆栈信息,

    常用命令:jstack [-l] pid

     jmap

     查看堆栈信息: jmap -heap 16190

    jstat

    Jstat 用于监控基于HotSpot的JVM,对其堆的使用情况进行实时的命令行的统计,使用jstat我们可以对指定的JVM做如下监控: 

    - 类的加载及卸载情况 
    - 查看新生代、老生代及持久代的容量及使用情况 
    - 查看新生代、老生代及持久代的垃圾收集情况,包括垃圾回收的次数及垃圾回收所占用的时间 
    - 查看新生代中Eden区及Survior区中容量及分配情况等

    常用命令:jstat -gcutil 17561 1000 10

    展开全文
  • 都是对JVM规范中方法区的实现. 不过元空间与永久代之间最大的区别在于: 元空间并不存在虚拟机中, 而是使用本地内存. 因此默认的情况下, 元空间的大小仅仅受本地内存的限制. 还是使用以下的代码作为实例. public ...
  • 参数 含义 说明 -XX:CIComcompile 最大并行编译数 如果设置大于1,虽然编译速度会提高,但是同样影响系统稳定性,会增加JVM崩溃的可能 -XX:InitialHeapSize=100M 初始化堆大小 简写-Xms100M -XX:MaxHeapSize...
  • SUN的官方站点介绍JVM Options时,只列出了很小一部分:http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html#G1Options
  • 在前几篇的 JVM系列 中,我们已经具备了 JVM 相关的基础知识,现在我们需要将学到的知识,在实际场景中运用起来,通过配置相关的
  • 常用JVM配置参数.

    2017-06-16 17:32:03
    常用JVM配置参数.
  • 常用JVM配置参数.ppt

    2017-05-25 12:43:31
    常用JVM配置参数.ppt
  • 3.常用JVM参数选项: 打印设置的XX选项及值: 栈,堆,方法区内存大小设置: 1.栈: 2.堆: 3.方法区: 4.OOM相关VM参数选项: 4.垃圾回收器常用参数: 1.Serial回收器: 2.ParNew回收...
  • JVM参数类型及常用参数JVM参数类型标配参数X参数XX参数JVM默认配置参数如何查看一个正在运行中的java程序,它的某个jvm参数是否开启?具体指是多少常用JVM参数 JVM参数类型 标配参数 java -version java -help ...
  • 常用JVM虚拟机参数说明 原文地址:https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html 非标准选项 参数 说明 -Xcomp 强制JVM虚拟机在方法第一次被调用的时候就进行本地编译。 ...
  • 常用JVM参数

    2017-06-06 11:26:40
    常用JVM参数(jdk7)堆设置-Xms:初始堆大小-Xmx:最大堆大小-XX:NewSize=n:设置年轻代大小-XX:NewRatio=n:设置年轻代和年老代的比值。如:为3,表示年轻代与年老代比值为1:3,年轻代占整个年轻代年老代和的1/4-XX:...
  • 常用JVM配置参数

    2017-02-13 15:59:41
    【声明】  欢迎转载,但请保留文章原始出处→_→  ...  本文主要内容: Trace跟踪参数 ...栈的分配参数 零、在IDE的后台打印GC日志:既然学习JVM,阅读GC日志是处理Java虚拟机内存问题的基础技能,它只是
  • 【JVM实战】JVM参数调优

    千次阅读 2020-03-30 14:45:24
    文章目录JVM参数调优一、调优基本概念二、常用JVM参数三、GC调优思路 JVM参数调优 一、调优基本概念 在调整性能时,JM有三个组件 堆大小调整 垃圾收集器调整 JIT编译器调整 大多数调优选项都与调整堆大小和选择的...
  • 常用JVM命令参数详解

    千次阅读 2019-05-20 14:01:42
    这里汇总平时用到的、看到的一些虚拟机参数。现在看不懂没关系,反正之后都会用到的: (1)-Xms20M 表示设置JVM启动内存的最小值为20M,必须以M为单位 (2)-Xmx20M 表示设置JVM启动内存的最大值为20M,必须以M为...
  • jvm 常用参数

    2016-02-24 09:24:00
    jvm 常用参数
  • 一、Trace跟踪参数(跟踪GC、类、变量的内存变化情况)打开GC跟踪日志(每次执行GC的信息都能打印,...XX:+TraceClassLoading二、堆的分频参数-Xmx10M 指定最大堆,JVM最多能够使用的堆空间 (超过该空间引发OOM)-...
  • JVM参数及调优

    2020-01-03 13:48:34
    调优基本概念 常用JVM参数 GC调优思路 通用GC参数 JVM有自适应调整参数的功能。 垃圾收集器Parallel参数调优 垃圾收集器CMS参数调优 垃圾收集器G1调优参数 ...
  • 常用JVM命令参数

    千次阅读 2016-04-20 18:26:15
    之后写的东西就会用到虚拟机参数了,现在这里汇个总自己平时用到的、看到的一些虚拟机参数。现在看不懂没关系,反正之后都会用到的: (1)-Xms20M 表示设置堆容量的最小值为20M,必须以M为单位 (2)-Xmx20M ...
  • [GC (Allocation Failure) 3344K->1296K(9728K), 0.0004129 secs] [GC (Allocation Failure) 3344K->1296K(9728K), 0.0003914 secs] [GC (Allocation Failure) 3344K->1296K(9728K), 0.0003756 secs]
  • JVM常用参数

    2018-10-03 14:02:36
    JVM常用参数 堆 -Xms和—Xmx 堆的最小值 &amp;amp;amp; 堆的最大值 默认值是物理内存的1/4(&amp;amp;lt;1GB) &amp;amp;amp; 默认值是物理内存的1/64(&amp;amp;lt;1GB) 空余堆内存小于40%时,JVM...
  • Trace跟踪参数 -XX:printGC 打印GC的简要信息 -Xloggc:log/gc.log --- 指定GC log的位置,以文件输出 --- 帮助开发人员分析问题 -XX:+TraceClassLoading 监控类的加载 堆的分配参数 -Xmx 指定最大...
  • 常用JVM配置参数
  • JVM常用参数选项介绍

    2019-09-10 18:41:31
    JVM参数选项类型介绍 标准参数选项 -X参数选项 -XX参数选项 JVM参数选项如何设置 打印设置的XX选项及值 堆、栈、方法区等内存大小设置 OutofMemory相关的选项 垃圾收集器相关选项 GC日志相关选项 其他参数...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 131,851
精华内容 52,740
关键字:

常用的jvm参数