怎样让你的代码更好的被JVM JIT Inlining

JVM JIT编译器优化技术有近100中,其中最最重要的方式就是内联(inlining)。方法内联可以省掉方法栈帧的创建,同时增加了CPU指令cache的命中率,方法内联还使让JIT编译器更多更深入的优化变成可能。本人在fastxml(速度比XPP3(基于xmlpull)还快的xml解析器)开源项目中针对方法内联进行了很多学习和实践,这里总结一下,介绍一下怎么让你的代码更好的被JVM JIT Inlining。

Inlining相关的启动参数

上一篇博客《Java JIT性能调优》中介绍了inlining相关的几个参数,这里copy下: jvm可以通过两个启动参数来控制字节码大小为多少的方法可以被内联:

  • -XX:MaxInlineSize:能被内联的方法的最大字节码大小,默认值为35B,这种方法不需要频繁的调用。比如:一般pojo类中的getter和setter方法,它们不是那种调用频率特别高的方法,但是它们的字节码大小非常短,这种方法会在执行后被内联。
  • -XX:FreqInlineSize:调用很频繁的方法能被内联的最大字节码大小,这个大小可以比MaxInlineSize大,默认值为325B(和平台有关,我的机器是64位mac)

可见,要想inlining就要让你的方法的字节码变得尽可能的小,默认情况下,你的方法要么小于35B(针对普通方法),要么小于325B(针对调用频率很高的方法)。

Inlining调优的工具

同样的上一篇博客《Java JIT性能调优》中也介绍了非常牛x的JIT优化工具JITWatch,该工具的详细文档请看这里:https://github.com/AdoptOpenJDK/jitwatch

为Inlining减少方法字节码

通过JITWatch中提示或者在启动命令中添加-XX:+PrintCompilation  -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining来输出提示信息,我们可以很快定位哪些方法需要优化,从而针对性的调优那些执行频率很高但没有inlining的方法,或者那些很小但不足以小到35Byte的方法。减少方法字节码的方法有很多,下面介绍我在fastxml项目中实践过的9种方法。

方法1. 把分支语句中的代码段抽取到方法中

我们的代码里面常常会有分支语句,比如:if-else、switch。但是我仔细想想,是不是所有的分支都有均等的执行机会,是不是很多时候,某些分支能进入的概率很小或者几乎没有。如果某个分支执行的概率很小,而且这个分支中的代码量不算小,那把这个分支中的代码抽取成一个方法就可以大大缩减当前这个方法的字节码大小。下面举一个著名NIO框架Netty中的一个例子,看优化前的代码:

代码中的config().isAutoRead()默认情况是false,也就是说,在没有专门配置的情况下,这个分支不会进去,而且一般人不会把这个配置为true,所以可以把这个if分支中的代码块抽取为方法,这样方法就变小了一些,而代码的功能没有减少。修改后的代码如下:

这样就很容易的把方法的字节码大小减少了一些,这样read()方法就可以inlining了。详见这篇文章:http://normanmaurer.me/blog_in_progress/2013/11/07/Inline-all-the-Things/

方法2.移除无用的代码

现在IDE(idea、eclipse等)功能很强大,往往能在开发阶段就能提示我们哪些代码是冗余无用的代码,请及时的删除那些无用代码,因为它们会占用方法的字节大小。此处我要说的不是这种IDE能提示我们的场景,而是隐含在我们编写的代码中的无用代码,比如下面的例子:

在方法parseTrimedString的开头处对length进行判断,乍一看,似乎没有什么不合理的,如果要处理的数组长度为0就直接返回null。逻辑上没有问题,IDE也不会提示这一段代码是无用的,但是仔细想想,要是length==0时,要是没有这个判断会怎么样呢? 第一个for循环中有begin<last的判断,避免了循环体中的bytes[begin]数组越界;同样的,第二个for循环里数组下标也被last>begin保护起来了,防止越界;再看看parseString()方法中正好有对length的判断,也就是说方法parseTrimString内部不再需要对length等于0的验证了。这一段代码可以移除。 类似这种非0、非null的判断在我们日常的代码中也是很常见的,其实可以通过一定的约定来减少这种判断,比如:按照约定保证每次方法的返回都不为null,若返回类型为String数组,则返回new String[0];若返回类型为Map<String, String>,则返回new HashMap<String, String>()。

方法3. 抽取重复的代码

很多时候,程序员因为懒惰不愿修改别人的代码,怕承担风险,而是有时候偏向于复制代码,这可能会导致一个方法体内部出现重复的表达式或者代码段。这时候应该把相同的幂等的表达式抽取为临时变量,把相同的代码段抽取为成员方法(不仅可以减少当前方法的字节码,还可能增加方法的复用率,为JIT优化提供了更多可能)。 通过抽取重复的代码来减少字节码,这种方式的效果是显而易见的。这里重点讲解一下,相同的幂等的表达式抽取为临时变量前后的字节码大小差异,看下面的代码:

这段代码中重复出现了docBytes[cursor],通常大家可能会认为这种数组取下标的操作没有几行字节码,应该不耗时,只有这种objA.getField1().getSubField2().getSubSubField3()的字节码多。其实不然,先看看仅docBytes[cursor]一句话的字节码有多少:

这里看出docBytes[cursor]对应9个字节的5行字节码,而这个表达式在上面的语句块中出现了3次,所以一共占用了9*3=27个字节。如果抽取成临时变量那么第二次和第三次使用临时变量即可,而使用临时变量仅占用1个字节,这样又可以减少近18字节。当一个方法里面重复出现的变量越多,优化效果就越明显。

方法4. 优化常量加减运算

先看代码:

上面的代码很简单,其中i=i+2这种写法也很常见,那么看看这行代码对应的字节码是什么样的:

这行代码已经很简单了,只占用4个字节,还有优化空间吗?当然有,我们还有一种常见的写法:

再看看这种写法的字节码:

这一行字节码占用3个字节的空间,而且只有一行字节码。这样一个微小的改动就可以节省1个字节,缩减3条字节码的指令条数。

方法5. 移除无用的初始化赋值

现在一些高级IDE也支持无用初始化的提示,比如:idea(eclipse还不支持这个功能)。如果IDE提示,请尽量移除这些无用的初始化,比如下面的例子:

显然对临时变量sum的初始化是没有作用的,上面的java代码产生的字节码有这些:

如果把对sum的初始化移除,java代码如下:

代码变化很小,改后的字节码如下:

通过对比可以看出移除对sum的初始化后, 字节码少了两行(2个字节)。有时候为了减少字节码就是需要一个字节一个字节的扣,没有办法。

方法6. 尽量复用临时变量

临时变量的初始化是会占用字节码的,减少不必要的临时变量无形之中也减少了临时变量的初始化。看下面的例子:

这个例子中,习惯性的使用临时变量i来作为for循环数组的下标,但是这个临时变量i真的有必要吗? 变量begin虽然是方法的参数,但是它也是这个方法的临时变量,而且它是java中的原始类型,改变begin的值不回对调用toString方法的调用方有任何影响,而且变量begin在方法中没有其他作用,很自然可以使用begin来代替i的下标作用。修改后的代码如下:

可以看到代码中少了一句:int i=begin; 这将减少2字节的2行字节码。 当你很需要这个方法被inlining时,每个字节的减少都来之不易。

方法7. 减少传参个数

有时我们写代码时,为了把方法的输入表达得更准确,会给出一个精确的参数列表,其中可能有多个参数来自相同的对象。比如下面的例子:

这代代码中,可以看到有两处抛出异常,每次创建异常都需要传三个参数:message、row、column。而上面的这个例子,很显然row和column都来自当前对象this,我在优化fastxml时,发现这个地方也可以优化一下,毕竟this.getRow()和this.getColumn()这两个表达式分别占用了4个字节,如果把formatError方法的参数减少为message、parser(即this),就可以减少7个字节的字节码,因为传this仅占用1个字节。

方法8. 把多个if判断转变成map的contain或者数组取下标操作

举个实际的案例,fastxml中为了解析xml中的标签名中的字符是否符合xml规范,我需要做如下的判断:

这一长串的条件判断其对应的字节码如下:

上面的代码中冒号前的数组为当前行字节码的第一个字节为整个方法体字节码中的位置。可以看到这里面的有11个的if判断,而每次判断都需要加载if判断的两个操作数,第一个操作数为变量b,第二个操作数为常量(比如:“:”),由于代码太长,此处以b == ‘.’为例,其字节码对应58~61处,共7个字节,三行字节码。 由于这个方法相比较的字符串都在ASCII码0~128范围内,所以我这里可以把比较转换为数组下标的方式,数组下标为byte的数值,数组的元素值为当前下标是否是符合xml规范的字符,修改后的代码如下:

可以看到方法变短来很多,字节码也减少了很多,执行速度也快很多。当然Java中原始类型比较适合用数组的方式解决这种众多if判断的问题,如果是对象的话,也可以用Map的方式。

方法9. 必要时把JDK中的类重写成简单的版本

一般而言JDK中的API都是久经考验的、非常完备的、通用的、众多高手智慧的结晶,但是也正是因为它的完备性和通用性,就导致其必然的损失了针对性。当优化到了一定程度后,就需要针对数据场景或者业务场景来进行针对性的优化来,举个例子:给一个基本排好序的数组进行排序时,冒泡比快速排序要快得多,因为这种数组最适合冒泡排序(O(n)时间复杂度),而快速排序时是O(nlog(n))。 看一个实际案例,下面的代码在fastxml的性能测试输出的编译和内联的log中看到StringBuilder的append方法太大了,导致无法内联到下面的方法中。

看看StringBuilder的append方法内容是什么样子:

可以看到append方法一层层调用了几层方法,每个方法不算太大,用JITWatch可以看到优化建议:

The call at bytecode 2 to

Class: java.lang.AbstractStringBuilder

Member: public AbstractStringBuilder append(String)

was not inlined for reason: ‘callee is too large’

The callee method is greater than the max inlining size at the C1 compiler level.

Invocations: 1031

Size of callee bytecode: 50

可以看到public AbstractStringBuilder append(String)这个方法稍大了一点,导致没有内联。这会导致多出一次方法栈,而这个方法可能在程序运行中调用频率很高,如果这个方法不能inlining,势必降低了性能。jdk的源码我们改不了,那我们可以选择不使用jdk的类,而是根据自己的实际场景写一个更简单的类,比如下面这个:

这个代码把安全检查都移除了,也把冗长繁杂的校验和数组扩容都直接移除了,代码变得简洁高效。这么做不会出错么?当然不会,因为在fastxml中,调用方已经保证了其不会出现数组越界,而且保证了初始长度length就是最大长度,所以多一层的安全检查是没有必要的,也没有必要考虑去扩容和复制数组了。在fastxml中,使用这个简化后的代码,使性能提升了10%。

总结

上面这9种方法都是在使用了JITWatch后,根据其提示绞尽脑汁想到的一些办法,通过这些优化,fastxml的性能提升了近1倍,现在fastxml的性能已经是XPP3的1倍左右。优化方法还有很多,针对不同的场景,会有很多不可思议的优化方法,这需要不断的挖掘。欢迎指正。 最后引用大牛Donald Knuth的一句话:

过早的优化是万恶之本

 

Java JIT性能调优

JVM自动监控这所有方法的执行,如果某个方法是热点方法,JVM就计划把该方法的字节码代码编译成本地机器代码,同时还会在后续的执行过程中进行可能的更深层次的优化,编译成机器代码的过程是在独立线程中执行的,不会影响程序的执行;除次以外,JVM还对热点方法和很小的方法内联到调用方的方法中,减少方法栈的创建。这些就是JIT(just in time)。

JIT编译器有近100种优化方式

JIT编译器有近百种优化方式
JIT编译器有近百种优化方式

其中以下三种方式效果非常明显:

  • 把bytecode编译成本地代码(native code):编译后的代码保存在一个特殊的堆上,除非相关的类被卸载,或者本地代码的优化被取消。这个cache有一定的大小限制(可通过启动参数-XX:ReservedCodeCacheSize来修改cache的大小),如果这个cache被装满,则JVM无法编译出更多的本地代码,但通常说不会碰到这种情况的。
    • hot method:默认情况,方法执行次数超过10000次的方法,jvm会编译成本地二进制代码,这个数值可以通过设置启动参数-XX:CompileThreshold=10000来修改。
    • On Stack Replacement (OSR):如果某个循环执行的次数非常多,那么这个循环体代码也可能会编译为本地代码
  • 分支预测(Branch Prediction):降低分支条件判断的结果的随机性,使CPU指令流水线缓存命中率提升
  • 方法内联(inlining,对性能的提升很大):方法内联可以减少方法调用,从而减少方法栈的创建。相信大家都知道循环的速度比递归快很多,就是这个原因,另外方法内联后,还使得一些JIT更深入的优化变成可能。jvm可以通过两个启动参数来控制字节码大小为多少的方法可以被内联:
    • -XX:MaxInlineSize:能被内联的方法的最大字节码大小,默认值为35Byte,这种方法不需要频繁的调用。比如:一般pojo类中的getter和setter方法,它们不是那种调用频率特别高的方法,但是它们的字节码大小非常短,这种方法会在执行后被内联。
    • -XX:FreqInlineSize:调用很频繁的方法能被内联的最大字节码大小,这个大小可以比MaxInlineSize大,默认值为325Byte(和平台有关,我的机器是64位mac)。

这些优化方法通常是层层依赖的,所以当JIT优化后的代码被JVM应用,就会开始尝试进行更上一层次的优化。因此我们写代码的时候,应该尽量往这些优化方式上面靠。

输出JIT编译和内联过的方法

在JVM启动参数中添加三个启动参数,比如下面的命令,把编译信息输出到inline.log文件中,便于后续使用grep命令分析:

inline.log中内容类似这样:

  • 第1列  31:为JVM启动后到该方法被编译相隔的时间,单位为毫秒
  • 第2列  23:编译ID,用来跟踪一个方法的编译、优化、深度优化
  • 第3列  s!:s是指该方法是synchronized,感叹号是指该方法有对异常的处理
  • 第4列  sun.misc.URLClassPath::getLoader:被编译的方法和类名
  • 第5列  (136 bytes):方法的字节码大小
  • 第6列 inline(hot):表示该方法被内联了,且调用频率很高,这一列还有其他值,比如:
    • inline (hot): 该方法被内联了,且调用频率很高
    • too big: 该方法没有被内联,因为方法字节码比-XX:MaxInlineSize的值大
    • hot method too big: 该方法被调用的频率很高,但是方法的字节码比-XX:FreqInlineSize的值大

inline.log文件内容中的方法还以tab缩进的方式来体现方法调用链的层次结构,非常易懂。

输出JIT编译的细节信息

通过添加参数-XX:+PrintCompilation,可以看到的信息其实并不具体,比如:那些方法进行了内联,内联后的二进制代码是怎么样的都没有。而要输出JIT编译的细节信息,就需要在JVM启动参数中添加这个参数:

输出的编译信息,默认情况是在启动JVM的目录下一个名为:hotspot_pid<PID>.log的文件

如果想指定文件路径和文件名的话,可以再添加一个启动参数:

输出的是一个很大的xml文件,可能有几十上百兆,下面摘出部分内容如下(文件中的汇编代码太长,就不贴了):

这些内容很难读懂,建议使用JITWatch(https://github.com/AdoptOpenJDK/jitwatch/)的可视化界面来查看JIT编译的细节信息。同时JITWatch还可以给出很多优化建议,给我们有效的优化代码提供参考,详见下文。

JIT编译模式

上面的输出的细节编译信息inline.log文件中,有个字段上“compiler=C2”,这里的C2就是JIT的编译模式,C2表示这个方法进行了深度优化。下面介绍下JIT的编译模式

C1: 通常用于那种快速启动的GUI应用,对应启动参数:-client

C2: 通常用于长时间允许的服务端应用,对应启动参数:-server

分层编译模式(tiered compilation):这是自从Java SE 7以后的新特性,可通过添加启动参数来开启:

这个特性在应用启动阶段使用C1模式以达到快速启动的效果,一旦应用程序运行起来以后,C2模式将取代C1模式,以进行更深度的优化。在Java SE 8中,这个特性是默认的。

JITWatch

前面也提到了,JITWatch可以通过可视化界面来帮助我们分析JVM输出的JIT编译输出日志,还可以帮助我们静态分析jar中的代码是否符合JIT编译优化的条件,还可以以曲线图形的方式展示JIT编译的整个过程中的一些指标,还给我们的代码提意见和建议,非常好用的工具。

下载

JITWatch需要在github上把代码clone下来,然后用maven来运行,地址为:https://github.com/AdoptOpenJDK/jitwatch/

安装hsdis

如果在jvm的启动参数中添加了下面的启动参数:

但是你发现启动你的java程序后,有如下的报错信息:

或者启动啦JITWATCH后,打开了某个编译信息log文件,但是看不到每个方法编译后的汇编信息,且那么你就需要安装hsdis。hsdis可以帮助我们查看编译后的本地代码,具体可以参考JITWatch提供的文档,根据自己的系统类型来选择安装:https://github.com/AdoptOpenJDK/jitwatch/wiki/Building-hsdis,如果你是mac,可以参考这篇文章:http://nitschinger.at/Printing-JVM-generated-Assembler-on-Mac-OS-X/

如果安装了hsdis库后,仍然在JITWatch中看不到汇编信息,那你检查下环境变量配置是否正确,实在不行可以尝试下重启电脑。

运行JITWwatch

在代码根目录下执行launchUI.sh(Linux/Mac)或则launchUI.bat(windows)

如果你使用maven,也可以在代码根目录下这样运行(其他运行方式,请参考JITWatch的github首页)

如果你使用的是mac,而且idk版本是jdk7,且运行mvn clean compile exec:java时出现下面的错误和异常时: 

请在org.adoptopenjdk.jitwatch.launch.LaunchUI类的main函数开头处添加下面的代码(或者直接使用我fork修改好的JITWatch):

然后重新运行即可看到JITWatch的界面。

用JITWatch来帮助优化代码

首先点击“Open Log”按钮,选择前面提到过的hotspot_pid<PID>.log文件,然后点击“Start”分析该文件。随后就会在左边生成程序运行过程中加载的类及其目录结构。选择某个类后,右侧会展示该类对应的方法。这些方法中可能部分方法前面有个绿颜色的勾,这说明这个方法被编译成本地代码,选中这个方法后,可以在下方看到该方法具体信息,比如方法调用次数,方法大小等。如下图所示:

jitwatch加载JIT编译log文件
jitwatch加载JIT编译log文件

这个界面中,顶部的工具栏都可以自己尝试一下,个人觉得“TopList”和“Suggest”比较直接,我们根据这两个就可以快速的定位需有优化哪些代码了,大体是什么原因导致未编译或者未内联。

选中方法后,点击“TriView”即可查看该方法和字节码和编译后的汇编代码,如下图:

jitwatch方法字节码和编译后的本地代码查看
jitwatch方法字节码和编译后的本地代码查看

如果你左边的java代码看不到,那你就需要在上一个界面中点击“Config”来添加源码路径或者源码文件以告诉JITWatch从哪里找源码;如果你右边的汇编代码看不到,说明你上面的hsdis未安装好,请重新安装。

此时,点击上面的“Chain”按钮,即可看到该方法调用了哪些方法,以及这些方法是否被编译了,是否被内联了。如下图所示:

JITWatch查看方法编译和内联状态
JITWatch查看方法编译和内联状态

总结

JIT的功能能显著提升java程序的性能,尤其是编译为本地代码和内联功能。内联需要方法比较小,也就是说写代码时就尽量把方法写得更小,让方法的复用度更高,复用的越多,就越可能被编译为本地代码。高性能的框架和类库针对JVM的JIT功能进行优化是非常有必要的,JVM提供的调试输出参数和JITWatch这样友好的工具能大大帮助我们快速的发现和定位需要优化的代码,大大提升了效率。

尽管我们可以手动调整JIT相关的一些参数,来让我们的更多的方法被编译和被内联,但一般不建议这么做(大牛都这么说)。

JIT编译成本地代码的过程也是需要消耗时间的,而且编译后本地代码不一定会使用(made not entrant,如果JVM根据一段时间的执行后进行了某项优化,但是在后来的某次执行时验证之前的优化是不完备的,那么JVM会取消这个优化,继续用解释执行的方式来执行字节码),所以并不是把所有或者大部分代码都编译一定会性能最优,那有可能也是灾难。

我所了解的JVM JIT性能调优的大致原理和方法就是这些,如有错误请指出。

性能优化永远是最后一步,不要提前过早开始性能优化。

Reference

如果你有耐心,就看看下面的文章吧,因为它们比我写的更详细

http://www.oracle.com/technetwork/articles/java/architect-evans-pt1-2266278.html

https://www.chrisnewland.com/images/jitwatch/HotSpot_Profiling_Using_JITWatch.pdf

http://www.docklandsljc.uk/presentations/2015/ChrisNewland-JITWatch.pdf

http://blog.csdn.net/hengyunabc/article/details/26898657

https://advancedweb.hu/2016/05/27/jvm_jit_optimization_techniques/

JVM启动参数:http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html

JITWatch使用文档:https://github.com/AdoptOpenJDK/jitwatch/wiki (右侧的页面目录分类很清晰)

https://advancedweb.hu/2016/05/27/jvm_jit_optimization_techniques/

https://advancedweb.hu/2016/06/28/jvm_jit_optimization_techniques_part_2/

【译】JVM的默认参数

如果在META-INF/MANIFEST.MF文件里面设置了Main-Class属性,那么你就可以很方便的通过java -classpath myapp.jar Main命令甚至更简洁的java -jar myapp.jar命令,来启动java虚拟机。这些命令会使用默认的设置来启动JVM。

要想看到JVM执行时使用在使用哪些参数以及其各参数默认值,可以使用这个命令:

java -XX:+PrintFlagsFinal -version

如果这些参数还不够全,你可以打开几个开关:

java -XX:+UnlockDiagnosticVMOptions -XX:+UnlockExperimentalVMOptions -XX:+PrintFlagsFinal -version

大部分的参数都可以安全的看到默认值,但是某些参数需要在生产环境运行时来调整。

(后面花括号里面有product的表示可以在启动参数中设置的,花括号里面是“product rw”的表示你还可以在jvm启动后使用类似下面的命令来设置这些参数)

jinfo -flag -PrintHeapAtGC=true <pid>

基本的内存参数设置

对java应用而言,最基本的设置莫过于java堆大小的初始值和最大值设置了(一般认为生产环境初始值和最大值设置成一样的比较合适)。

  • -Xms<size> 设置java堆大小的初始值
  • -Xmx<size> 设置java堆大小的最大值

如果你使用的java7或者更早版本的jdk,你可能发现“OutOfMemoryError: PermGen space”,这时你需要使用-XX:MaxPermSize=<size>参数来增大Perm区大小。server虚拟机默认的Perm区大小是64M,但很多应用所需的Perm区空间不止64M。

如果JVM虚拟机耗尽了堆空间,且GC垃圾回收不了时,会抛出“java.lang.OutOfMemoryError:Java heap space”,要分析内存占用情况,可以添加参数-XX:+HeapDumpOnOutOfMemoryError参数,这个参数会在抛出java.lang.OutOfMemoryError异常时,dump堆空间的数据到当前工作目录下的一个文件中,-XX:HeapDumpPath=<path>可以指定这个dump文件的具体位置

垃圾回收(GC)

垃圾回收策略有很多,这里不细说,可以参考Java Garbage Collection Distilled

不管你正在使用那一个垃圾收集器,你都可以用日志的方式记录一段事件的垃圾回收的过程,来观察垃圾回收的效果。你可以添加参数-verbose:gc来把垃圾回收日志输出到标准输出(STDOUT),但更好的方式是通过参数-Xloggc:<pathtofile>把垃圾回收日志输出到指定的文件。

同时添加-XX:+PrintGCDateStamps参数可以记录下垃圾回收的时间戳,添加-XX:+PrintGCDetails可以记录下垃圾回收的事件细节。

默认情况下,垃圾回收日志文件不断变大,但JVM还内置支持回转日志文件(rotating the file),可搭配使用这三个参数:

  • -XX:+UseGCLogFileRotation 开启回转日志文件
  • -XX:GCLogFileSize=8K 设置单个文件最大的文件大小
  • -XX:NumberOfGCLogFiles=1 设置回转日志文件的个数

最后,你可能需要使用-XX:+DisableExplicitGC参数来显性的关闭手动GC功能(即调用jdk的建议GC的api:System.gc()),让System.gc()方法变成一个空方法,让垃圾回收托管给JVM的垃圾收集器。

实例

java -Xms10g -Xmx10g -XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError -XX:+DisableExplicitGC -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xloggc:/var/log/myapp/gc.log -XX:+UseGCLogFileRotation -XX:GCLogFileSize=10M -XX:NumberOfGCLogFiles=20 -jar myapp.jar

这个例子使虚拟机分配10GB内存和256MB给perm区(java7)。内存溢出时dump堆空间的共鞥启动了,使用G1(garbage first)垃圾收集器,垃圾收集日志记录到/var/log/myapp/gc.log中,同时开启了日志文件回转功能。

Referece

[译]生产环境中异常堆栈丢失的解决方案

今天我发现生产环境日志中有许多NullPointerException 没有堆栈。我们发现,当一些异常抛出的足够多时,JIT编译器会优化掉异常堆栈。下面的代码可以重现异常堆栈丢失的问题。我们的代码跑在jdk 1.6上(小版本号不记得了)

用下面的命令运行上面代码,异常丢失的情况就出现了(异常栈的长度从2变为了0):

javac NpeThief.java && java -classpath . NpeThief
javac NpeThief.java && java -server -classpath . NpeThief

如何解决呢?下面的参数设置可以修复这个问题,让NullPointerException异常堆栈的长度保持为2,不变为0:
javac NpeThief.java && java -XX:-OmitStackTraceInFastThrow -server -classpath . NpeThief
javac NpeThief.java && java -XX:-OmitStackTraceInFastThrow -classpath . NpeThief
javac NpeThief.java && java -Xint -classpath . NpeThief
javac NpeThief.java && java -Xint -server -classpath . NpeThief

可以看出,解决方案是:使用-XX:-OmitStackTraceInFastThrow参数让JIT不使用对异常堆栈的优化[1,2];或者设置-Xint让虚拟机以解释方式执行类的字节码,不将字节码编译为本机码[3]。那么-XX:-OmitStackTraceInFastThrow参数具体是什么意思呢?

JVM参数-XX:-OmitStackTraceInFastThrow参数可以关掉JVM对堆栈信息的优化。如果设置了这个参数,那么异常堆栈就能完整输出了。

“在服务器中的VM编译器现在提供准确的所有的“冷”内置异常堆栈回溯功能。为了性能考虑,当这些异常被抛出很多次时,这个方法会被重新编译,此后编译器将使用一种更快的抛出异常的方式,即抛出预先分配好的不带堆栈信息的异常。要完全关闭掉这种预分配的异常,就需要使用-XX:-OmitStackTraceInFastThrow参数。“http://java.sun.com/j2se/1.5.0/relnotes.html

请问设置这个参数后会影响性能吗?我确实使用这个方式java [args] -classpath . NpeThief做个了非常天真的测试。如我所期望的,只是编译慢了。但这解决了生产环境的问题吗?

答案是没有,我们需要修改生产环境JVM的启动参数,否则看到的log还是没有堆栈信息的。在我们修改了JVM启动参数,重新部署部署了以后,完整的异常堆栈信息出来了,问题解决了。

Reference

[1] Related sun bug 4292742 NullPointerException with no stack trace
[2] Helpful StackOverflow discussion of NullPointerException missing stack traces
[3] -Xint: Operate in interpreted-only mode. Compilation to native code is disabled, and all bytecodes are executed by the interpreter. The performance benefits offered by the Java HotSpot VMs’ adaptive compiler will not be present in this mode.

本文翻译自:Hotspot caused exceptions to lose their stack traces in production – and the fix